On the Original Definition of PaaS

Platform-as-a-Service (PaaS) is a much misunderstood but still overused cloud term. It doesn’t help that different technology/cloud vendors define it differently. There are also mini variants of PaaS like application PaaS (managed compute services for hosting applications), integration PaaS (for providing integration services between disparate applications and systems), communication PaaS (for providing communications services like voice, SMS, email, etc.), and many others. Many core services such as managed databases (DBaaS) are also sometimes referred to as a kind of PaaS. Effectively every service, API, etc. that reduces the burden of infrastructure management or provides an easy-to-use abstraction over repetitive tasks is now referred to as PaaS.

In this article, however, I want to focus on the original definition of PaaS — managed compute environment that just takes the code (or built executables) from developers and runs it for them, removing the need for VM management. This is sometimes referred to as application PaaS (aPaaS) and is an area that has gone through some interesting cycles. Initially touted as “this is what cloud should be”, it lost steam as infrastructure-as-a-service (IaaS) still provided the easiest and most friction-free vehicle for both lift-and-shift workloads as well as new applications. Many said PaaS was too restrictive, or required too much change to application architecture or deployment workflows, did not provide enough control over underlying resources, etc.

Many of us have might have seen diagrams similar to this one talking about the compute continuum with control on one end and convenience on the other. This is what the original version looked like:

In recent years, however, two new hotter compute trends have dominated the narrative a lot more than PaaS — Kubernetes and Serverless. Both sit on either side of PaaS on the compute continuum. Kubernetes makes infrastructure management easy. Serverless has multiple definitions depending on which cloud vendor you talk to but the most common one is event-driven, pay-per-use, autoscale compute provided via a Functions-as-a-Service (FaaS) model. This makes the updated version of the cloud compute continuum look like this:

A while ago, I even waxed eloquent about the virtues of serverless .

However, the reality is that most of these technologies (Kubernetes, PaaS, Serverless) come in various flavors and depending on the flavor, fall at different places on the continuum. This means that the cloud compute continuum now contains multiple axes. For simplicity, let us consider only two:

• Whether a compute solution solves for infrastructure or for application workflows
• Whether the underlying machinery needs to be managed by the user or is managed by the cloud provider

• 
  

Let us also make a third simplifying (although potentially controversial) assumption that things like Serverless/FaaS are just a subset of PaaS, at least based on the original definition of PaaS (focus on apps, not infrastructure).

With these in mind, this is what the continuum begins to look like:

Let us look at all of these stops on the continuum:

(1) IaaS: This is easy. Virtual Machines that you need to manage yourself. Install application runtimes, perform patching, etc. all yourself. These are popular, even among developers. I talk about some of the reasons .

Examples of IaaS:

(2) VM Marketplace: Most cloud providers these days offer virtual machine images that come pre-packaged with application stacks so that developers can just start writing or deploying code immediately after spinning up instances of these VM images. I prefer to call them “starter templates” for IaaS instead of calling them PaaS. They do solve for some application workflows but still leave too much infrastructure maintenance work for developers. Examples:

(3) Self-hosted Kubernetes: Kubernetes allows you to manage your infrastructure better but lacks the concept of an “application”. Managing it yourself can be complex but many experts prefer to do it. The appeal for doing this can be understandable especially for those who choose an infrastructure-centric technology like Kubernetes in the first place.

(4) Managed Kubernetes: Almost every serious cloud provider these days has a managed Kubernetes offering that does a certain set of Kubernetes management. While most of these offerings do not help with application-centric concepts, they do reduce the burden of operating Kubernetes itself. Examples:

One common misunderstanding is that containers and Kubernetes go hand in hand. This is not entirely true. While Kubernetes works great for containerized workloads, containers are useful in other contexts also. I talk about this topic in .

(5) Self-hosted PaaS: This is an area I never understood the need for. In my mind, someone who is looking for a PaaS solution has already made the decision that they want to focus on application development rather than infrastructure management. If so, then why get into the business of self-hosting a PaaS solution where you are still responsible for the underlying infrastructure? Anyway, there are solutions that do this for you — also referred to as DIY PaaS. The idea is that a “platform team” does some initial setup (and maybe a little bit of ongoing maintenance) for this PaaS on their own infrastructure (VMs or Clusters), and then the experience that everyone else (folks building apps within the same organization) gets is that of a PaaS. They just get to focus on their applications. Examples:

(6) Managed PaaS: This is true PaaS that truly brings the “aaS” piece into meaning. In my mind “as a Service” means something I can expect and consume as an entity without worrying about how that entity was built or is being delivered to me. This is what fully managed PaaS offerings begin to provide — freedom from infrastructure management. Examples:

(7) Managed PaaS on Kubernetes: Wait. What? Didn’t I say earlier in this article that Kubernetes is an infrastructure-centric technology? Then why would I bring that into a discussion about fully managed PaaS solutions supposed to be all about applications? Well, the truth is that any serious managed PaaS solution needs to be built atop some kind of an orchestration layer that manages multiple instances of compute underneath. And right now, Kubernetes is the de facto standard for compute orchestration in our industry. The amount of mindshare, resources, focus, and energy it is getting, is ensuring that its quality continues to improve. Here are some thoughts from experts:

So, although it might sound like an implementation detail that the developers may not care about, but the reality is that a managed PaaS built on Kubernetes will always be more flexible and “future-ready” than the alternatives. Examples:

(8) Managed PaaS with autoscale: And yes. Finally, that thing about scale. In order for a solution to truly be application-centric, it needs to be able to handle scale — both up and down — without requiring the app developer to worry about how to add/remove infrastructure. Some serverless FaaS solutions do this today but then they are limited to the Functions programming model thereby requiring a little more work to bring existing applications into this fold. We need more PaaS solutions (even classic aPaaS) to move in this direction. I suspect even here, Kubernetes and many of its associated projects such as  would prove to be the trusted technologies to build on. Examples:

Hopefully, this article gives you a clearer picture of various types of compute solutions available to you along with examples, and how to think about various alternatives depending on your appetite for infrastructure management.

Also published