Multiple stops on the cloud compute continuum - all with their own merits

Platform-as-a-Service (PaaS) is a much misunderstood but still overused cloud term. It does not 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. A 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.

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. And developers want to code. Hence Serverless.

However, the reality is that most of these technologies (Kubernetes, PaaS, Serverless) come in various flavours and depending on the flavour, 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 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).

Let us look at all 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 here:

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.

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.

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, some solutions 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.

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.

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 computing underneath. And right now, Kubernetes is the de facto standard for computing orchestration in our industry. The amount of mindshare, resources, focus and energy it is getting, is ensuring that its quality continues to improve.

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.

8. Managed PaaS with autoscale

And yes. Finally, that thing about scale. 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 PaaS) to move in this direction. I suspect even here, Kubernetes and many of its associated projects such as knative would prove to be the trusted technologies to build on.

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

The article is written by Raman Sharma- Product Marketing Leader DigitalOcean.