Why ‘PaaS Versus Containers’ Is a Nonsensical Comparison

By Atos Apprenda Support


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:

  1. You can use PaaS-enabling software like Apprenda, purpose built with an engine to allow operators to control and curate the service and tooling for developers to consume it.
  2. You can build a ton of IP around a cluster manager like Kubernetes at the core, fulfilling the use case needs that are captured by products in (1).
  3. You can build IP from scratch, including the cluster manager, to let you deliver a service to developers (this one is unreasonable and silly, in my book).

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.”

Atos Apprenda Support

View Comments
  1. Jorge CotilloJune 7, 2017

    While doing some research on comments about PaaS vs Containers to see what people opinions are, I found this post and was a little bit confused on what is mentioned here; I’ll focus on the following part of the post: “An application delivery model leverages one or more application encapsulation primitive types as units of work.”. Are you implying that PaaS can host one or more applications and containers no? Indeed, you can add multiple applications to your PaaS but you’ll get the same result if you add multiple applications to your single container (you’ll have to manage the ports though). I guess, and I might be wrong, that your comparison is referencing Microservices, which you can also implement in a PaaS model (i.e. Web applications, server less, etc.). In fact a Azure PaaS, if we talk about scalability, uses containers with an orchestrator behind the scenes and you get the same result as if you implement them yourself in a VM. I guess both solutions are similar (i.e. Uber vs Hertz) is a matter of which one you use, if you have multiple applications and you deploy them into a PaaS model, soon you’ll see thay your bill goes up versus if you have two or three VMs running your containers with an orchestrator. Price, server maintenance (patching) and latency are good reasons to pick containers vs PaaS. Going back to the car analogy, if you go somewhere else and it happens that you’ll stay for a month or two it might be better to rent a car vs using Uber, same applies here both offers the same, one does it for you (PaaS), the other you have to implement it yourself.

  2. Sinclair SchullerJune 8, 2017

    Jorge, thanks for the comment! No, the goal of that sentence wasn’t to imply that a PaaS could host multiple apps and a container can’t. The goal was to describe a PaaS’ duty: to host applications and surround those applications with the necessary capabilities to make it accessible to end users (e.g. load balancing, authentication, etc.) whereas a containers duty is to encapsulate and isolate one more apps.

    In fact, I refer to containers as encapsulation primitives and then specify that any app delivery model (including PaaS) leverages encapsulation primitives (containers) as a means for isolating apps that it will deliver. They are 100% complimentary to each other. I hope that helps!


  3. JMRFebruary 27, 2018

    I think a better discussion is “proprietary aPaaS” vs. “CaaS”. Containers vs. PaaS is nonsensical as you’ve outlined, but that’s not really what people are saying when they say “PaaS vs. Containers”. So, I would summarize your post as “sort of pedantic.” Technically it’s true, but practically it’s not useful. There *is* a meaningful comparison to be made between CaaS vs. PaaS. Nobody really gives a rip about *containers* per se. They care about the different deployment models offered by a proprietary aPaaS and the ecosystem offered by a CaaS.

Comments are closed.