Maslow’s Hierarchy of Cloud

We all know Maslow’s hierarchy of needs and it’s various uses in psychology, sociology, management, and marketing in someway or the other. In the original pyramid, Maslow uses the terms (in order) “physiological”, “safety”, “belongingness” and “love”, “esteem”, “self-actualization”, and “self-transcendence” to describe a pattern that human motivations generally move through from lower to higher layers.

While talking to our users, we realized, we have a hierarchy of needs for the cloud, too. Note, these needs are independent of location of the cloud (as in public, private, or hybrid clouds), which is rather influenced by trust, but that’s a topic by itself. In the following I will go into a bit more detail on what I call the “Hierarchy of Cloud” and how recent infrastructure developments like containerization are changing the game.

The Traditional Hierarchy of Cloud

In traditional cloud offerings we usually see various needs that are catered to, including “reliability”, “speed”, “scalability”, and “flexibility vs. ease-of-use”. Some might also add “price” to this list, however, price is rather an influencing factor in this context, as usually with higher price you can get better reliability, speed, etc. These are basically the expectation dimensions that are imposed on users from the supplier side of cloud infrastructures.

The ranking of these needs may vary based on the use-case at hand, but generally users want at least a certain amount of reliability before they go for speed/performance. Analog to that, a certain amount of speed usually comes before needing to scale up. These first layers are things that any cloud provider can provide to a certain amount. Note, there’s a “versus” in the last layer and this is one of the harder differentiators between cloud offerings. On the one side PaaS providers like Heroku score higher on ease-of-use, but are less flexible in terms of freedom to use any language, framework, data store you want. On the other side IaaS providers like AWS score high on flexibility, but lower on ease-of-use, especially the more you go into more complex use cases and architectures.

The New Hierarchy of Cloud

Now with containerization, microservices, and cluster infrastructures we can see change coming to some of these layers and even added layers, which were previously not possible from an external provider, on top of that.

First, as I explained in a previous blog post we can go one step further and have resilience (not only reliability). As software can only hardly be “bug free” and taking into account Murphy’s Law (“If anything can go wrong, it will”), we need to move from a thinking that minimizes failure and outages, i.e. optimize for mean time between failures (MTBF), to one where we optimize for mean time to recovery (MTTR). This optimization needs to happen not only in development, but also in deployment, which has significant implications as to requirements for cloud infrastructures.

Second, with what some now call Containers-as-a-Service (CaaS), we can remove the “vs” in the (previously) top layer. With containers we can build infrastructure that is as flexible as any IaaS with the ease-of-use of PaaS solutions. A user just needs to package their applications and services into containers (no matter what language, framework, or data store they use) and can then deploy those easily to the CaaS. The deployment is usually accompanied by a simple definition of the configuration of the containers, so that the CaaS knows how to run (and best also how to scale and manage) them for the user.

Third, adoption of microservices architectures is getting more and more common. They sure are not a free lunch, but implemented right, they enable companies to innovate continuously through faster iterations and extensions to their software. Thus, we at Giant Swarm think cloud users of the future deserve a platform that enables them to build microservice applications faster. So on top of our infrastructure (that you could put into the above-mentioned CaaS category), we offer our users services to help them get to a first microservice architecture quickly. However, as we believe that users should have the utmost freedom on their infrastructure (remember, flexible like a IaaS), we let our users keep the flexibility to change the tooling to their own liking and needs.

Based on these three advancements in cloud infrastructure, we believe the new hierarchy of cloud should look like the one above, where ideally users can opt for a resilient cloud solution that offers flexibility and ease-of-use, and on top of that is optimized for microservice architectures. Again, like with the traditional hierarchy of cloud, the order of needs can differ from use case to use case, especially the higher up you get in the pyramid. At the same time lower level of the cloud become more and more common, like running water or electricity. Our goal with Giant Swarm is to make the whole pyramid become like that, so that the users focus on iterating and innovating on their product instead of having to worry about their cloud needs. If you think that sounds like a good idea get in touch with us.