IaaS/PaaS became legacy

Maja
04.06.2020 16:07 Comment(s)

There used to be a clear separation of approaches in cloud computing: IaaS, PaaS and SaaS. But then containers came along, Kubernetes and a massive ecosystem of tools with funny names. This blew up the number of options developers have for building and running cloud-native software. 


But where does all of this fit in the traditional IaaS/PaaS model? This is actually a question we got from several non-technical decision makers. Time to dive in and get this cleared up. 

Let's start at the beginning: IaaS, PaaS and SaaS 

Traditionally, there are three well-known options for running cloud-native software: IaaS (Infrastructure as a Service), PaaS (Platform as a Service) and SaaS (Software as a Service). As a reminder, consider a typical illustration you will find anywhere on the web of what these models are and how they differ. 

PaaS seems to be the way to go if you want to focus on the application layer, whereas IaaS gives much more control on how the application is run. Although all PaaS providers approach PaaS differently, there are some common services that are typically provided: database and infrastructure services, development and deployment services. The latter include services supporting devops, such as continuous integration and delivery (CI/CD), runtime services, including monitoring and logging, tenant management, provisioning, scaling, and finally services that support security and governance.

PaaS is dead, long live IaaS! 

Unfortunately, PaaS did not live up to its promise. Years ago analysts predicted that PaaS would have 1/3 of the total cloud computing market. In reality, its market share has always stayed around 10%, depending on the source. 

 

One of the reasons cited is that PaaS is the most ill-defined area of cloud computing. Approaches, features, and definitions vary widely, with many PaaS providers offering a specific focus, such as tight integration with a common database technology. 

 

As such, most PaaS offerings are opiniated and put the developer in a sandbox, with only a restricted set of features and functions provided. Businesses are concerned about choices being made for them and the resulting lock-in. Applications have to be changed and built to make use of the non-standard and restricted set of features and functions of the PaaS provider. 

 

In fact, it turns out that the main competitor of PaaS is IaaS. Point in fact is that the focus of the three big public cloud providers, AWS, GCP and Azure, is clearly on continuing to add more and more IaaS services.

New kid on the block: containers

Containers and microservices took off like wildfire several years ago. 

 

Containers became popular because they are a relatively simple (and open source) way for developers to package an application and all its dependencies, such as OS and software libraries, on a laptop and then deploy it to a server unchanged. 

 

Microservices became popular because that type of architecture, where an application is broken down into individually managed components, is an improvement over monolithic architectures in terms of governance, scalability, deployment and other factors.

 

Note that microservices do not have to use containers, but they are one of the more popular ways of deploying microservices. 

 

However, containers are not sufficient to get an application up and running. Applications need to be scaled up and down, scheduled, made redundant and resilient, rolled out and back. Furthermore, service discovery, health checks, configuration and secrets need to be provided and managed. That is where container orchestration, for example with Kubernetes, comes in. 

Kubernetes:  a modern approach

Kubernetes is often positioned as a more modern alternative to PaaS. Although both PaaS and container orchestration (sometimes referred to as Containers as a Service, or CaaS) both abstract some degree of the infrastructure, PaaS provides a much higher level of abstraction and opinion. Therefore, In the end, the question of PaaS versus CaaS comes down again to the level of control or customization required for each application.

In the meantime there are almost 100 Certified Kubernetes distributions and platforms according to the Cloud Native Computing Foundation (CNCF). 

 

While Kubernetes excels at managing the relationships between containers and scheduling them onto lower-level resources, it intentionally does not tackle a long list of other essentials. 

Cloud Native Computing Foundation: 
a map through the previously uncharted terrain of cloud native tools

Take a look at the CNCF landscape, depicting 1,398 (open source) projects or tools, representing a total funding of $ 65.92 billion. 

The CNCF landscape is organized according to categories. On the left-hand side you will find, from top to bottom: App Definition and Development, Orchestration & Management, Runtime and Provisioning. Each of these categories has sub categories. The categories seem to be similar to the layers in the IaaS/PaaS stacks: Application layer, Service brokerage, Runtime layer, and so on. However, the CNCF landscape categories cannot be stacked as layers, and here's why. 

 

In order to build and run cloud-native software as containers with Kubernetes, tools have to be selected from the (sub) categories, but not necessarily all (sub) categories. These decisions depend on the needs of the software, i.e how secure, available, scalable, etc. it has to be. Furthermore, not all tools can be put in a box or, in this case a category, because they cut across the landscape. Picking one of these crosscutting tools obviously affects the selection of a tool from another category since overlap has to be avoided. Although this appears to simplify the matter, since it restricts the number of choices, in reality it does not because this information has to be extracted from the tool's available documentation. 

 

A simple calculation of the number of options this landscape provides, by multiplying the number of options per sub category, leads to the astronomical number of 4.8e25 or 48 septillion options.

 

CNCF also provides a so-called trail map through this technological jungle. These are the steps that are recommended for leveraging open source, cloud native tools. Everything after step 3 is apparently optional. 

 

1. Containerization 

Commonly done with Docker containers.


2. CI/CD

Changes to source code automatically result in a new container being built, tested, and deployed to staging and eventually, perhaps, to production.


3. Orchestration & Application Definition

Kubernetes is the market-leading orchestration solution.


4. Observability & Analysis

Pick solutions for monitoring, logging and tracing.


5. Service Proxy, Discovery & Mesh

These solutions offer health checking, routing and load balancing. 


6. Networking, Policy & Security

This includes policy engines for authorization, admission control, data filtering and so on, as well as anomaly detection.


7. Distributed Database & Storage

These solutions offer more resilience and scalability through for example sharding. Furthermore, storage orchestration of diverse storage solutions and storing data in a distributed way are also enabled. 


8. Steaming & Messaging

Higher performance messaging systems.


9. Container Registry & Runtime

Storing, signing and scanning content, as well as container runtimes. 


10. Software Distribution

For example secure software distribution. 

 

We've annotated the CNCF landscape with the 10 steps from the CNCF trail map. The numbered circles encompass the sub categories that you have to choose from for the step with that number. For each step the trail map gives example tools. These are underlined. It gets complicated when steps crosscut categories, e.g. steps 8 and 10. 

Although the CNCF trail map clearly limits the number of options, the resulting number, calculated by multiplying all options per step, is still quite astronomical: 1.55e16 or 15 quadrillion options. 

 

Finally, let us not forget serverless computing. This is a new model of cloud native computing, enabled by architectures that do not require server management to build and run applications. It concerns a finer-grained deployment model where applications, bundled as one or more functions, are uploaded to a platform and then executed, scaled, and billed in response to the exact demand needed at the moment. Serverless is shown on the right-hand side of the CNCF landscape and contains 57 tools.

IaaS vs. PaaS is a dangerous oversimplification

The conclusion is that the IaaS-PaaS model that served us well in the past is currently a dangerous oversimplification of the cloud-native ecosystem that is available for building and running cloud-native software. Not only is the ecosystem huge, the number of options to choose from is astronomical. Furthermore, the CNCF landscape is a moving target as it is updated almost daily with new tools or tools that have changed status. 

 

As developers struggle to keep up with this cloud-native ecosystem and to make the right choices for their applications, it is important that decision makers realize the extent of the complexity. The IaaS/PaaS model is not going to help with that and will even give a false sense of control. IaaS/PaaS became legacy. 

Cumundi blueprints guided by non-functional requirements

Although at Cumundi we don't have the answer (yet) to the question of how to organize the cloud-native ecosystem, we do have an approach for guiding our choices. We turn things around and start from the non-functionals: how secure, available, scalable, interoperable, maintainable, transferable, ... do we want the cloud-native software to be? This is the topic of another article. 

 

This results in our Cumundi blueprints, which implement these non-functional requirements, using our in-depth knowledge of the tools in the CNCF landscape and best practices for building and running cloud-native software. Contact us at hello@cumundi.cloud if you want to know more.

Contact us