I’ve had a good number of cloud taxonomy conversations as of late. Those conversations have focused on properly categorizing containers and how they compare to other cloud infrastructure pieces. One thing I’m finding is that some people attempt to place containers on a cloud continuum.
You’ll see diagrams with virtualization on the far left, and containers on the right. Some of these diagrams place PaaS on the same continuum and conversations end up something like, “So what about PaaS versus containers?” or “Now that we have containers, where does PaaS fit in?”
It’s an awkward conversation because it attempts to compare two things that can’t be compared. Why not? Because PaaS is an operational model—an application delivery model to be more precise—while containers are a technical architecture primitive, and more specifically, an application encapsulation primitive. An application delivery model leverages one or more application encapsulation primitive types as units of work. Let’s dig in to better understand.
PaaS isn’t a technology type or a technical architecture. It’s a method of delivering a capability. Specifically, PaaS is a mechanism for one party (a service provider) to deliver application deployment, hosting, and execution capabilities to another party (the customer – usually a developer).
Software (like the Apprenda Cloud Platform) exists to power these sorts of services, hence the categorization of PaaS-enablement software. In the enterprise, many IT departments are looking to create and manage a new service to offer their developers – they want to deliver an application Platform as a Service. This operational model has a significant number of implications since the service provider that operates the PaaS offering needs to be able to manage the offering, including the on(off)boarding of end users, controlling how the service behaves, etc. It does not imply anything about the technology primitives used to assemble the PaaS other than the requirement that it host and deliver applications.
Containers are a technical consideration and an architectural primitive defining the packaging and execution space for an OS context. A PaaS model can accept containers as input and run them, or can simply use them “under the hood” as an execution space for apps that are provided in a raw binary artifact form by developers. The existence of containers doesn’t somehow magically invalidate the need for PaaS since containers are one of a PaaS application encapsulation primitive options. Traditional VMs, unikernels, and even “serverless” can be considered other types of application encapsulation primitives. A PaaS can deliver platform capability to developers and use any one of these encapsulation primitives, albeit it with consequences on what sort of value it can deliver.
If you are an enterprise, there are a number of ways to create a PaaS offering:
The point is that there are numerous technical architectures that can be used to manifest a PaaS offering, but PaaS is not a technical architecture itself. If we can wrap our heads around this, it’ll make it easier to understand that PaaS is a use case, not a “thing.” More importantly, if we acknowledge that PaaS is an operational model, we’ll realize that it’s perfectly compatible with containers since it’s the model by which an operator like IT can deliver container capabilities to developers.
Remember this post when you see or hear something like “PaaS versus containers” and remember that it would be equivalent to the nonsensical comparison of “Uber versus car engines.”