Mirantis named a Challenger in 2024 Gartner® Magic Quadrant™ for Container Management  |  Learn More

< BLOG HOME

PaaS vs KaaS: What's the difference, and when does it matter?

image
Earlier this month I had the pleasure of addressing the issue of Platform as a Service vs Kubernetes as a Service. We talked about the differences between the two modes, and their relative strengths and weaknesses. If you'd like to see the full webinar, you can click this link, but there were several questions we didn't get to, and I promised to recap all of them in a blog.

Is it possible to have a PaaS that's also a KaaS?

Yes.  While a PaaS is designed to provide applications for developers to use without having to worry about deploying them, a KaaS is designed to deploy Kubernetes clusters for developers.  There's no reason that a PaaS can't offer a Kubernetes cluster as an "application" to be deployed, though not all do.

Can you deploy a PaaS on Kubernetes?

Yes. At the end of the day, a PaaS is just an application, and it needs to be deployed somewhere.  If it's already containerized, of course it can be deployed on Kubernetes. If not, it might take some additional work, but yes, it's possible.

If the applications are written for AKS or EKS or PKS will they be locked into that respective provider APIs?

Any time you're writing to a specific API, you're locked into that API.  If it's the Kubernetes API, or the OpenStack API, or any other open source API, your application can then be used anywhere that API is available.  If, however, you write to an API that's only available from a particular provider (such as AKS or EKS or PKS) then you're locked into that provider.

Are there open source KaaS solutions out there? Or do most people resort to Ansible/kubeadm automation to standup the clusters? This may only be relevant to organizations that run K8s on prem.

In general, most people do resort to a single-cluster tool such as Kubeadm, but once you get past a couple of clusters, a full-blown KaaS solution is generally more convenient.  There are some open source solutions, such as Kubespray, KQueen and Gardener, but so far, none that have really captured the market.

Can you talk more about why you consider OpenShift to be more PaaS than KaaS?

Most of my experience with OpenShift has been with OpenShift 3, which is definitely a PaaS; it's essentially a single Kubernetes cluster with an application catalog and a wrapper, oc, for OpenShift-specific commands.  A single tenant can deploy a "project" which is architecturally just a namespace. (Which leads to the interesting side-effect that every project has to have a globally-unique name, but that's just a side issue.) In to that project, OpenShift uses Operators to deploy applications of the user's choice.
The important thing to note here is that the user has NOT been provisioned a Kubernetes cluster; they're just squatting on the main cluster that is OpenShift.  So OpenShift 3 is definitely not a KaaS.
As another attendee of the webinar pointed out, OpenShift's original motivations were to provide easy access to CI/CD and Software Defined Networking; Kubernetes was an afterthought.  (In fact early versions of OpenShift didn't use it at all.)
I've been told that OpenShift 4 is more KaaS-like, which I assume means that it can deploy an independant Kubernetes cluster for you to use, but I've been unable to verify that through the documentation, and OpenShift Online still uses version 3.  (If someone has more information on this issue, I'd love to hear it.)

In terms of adoption, do we see more KaaS compared to PaaS?

That all depends on how you're defining each. KaaS is definitely going to take off in the next few years, particularly as Edge Computing becomes more important and the need for deploying multiple clusters becomes impossible to ignore.  That said, however, many KaaSes also include application catalogs, so while the function of PaaS will continue to be important, it's possible that stand-alone PaaSes themselves might begin to fall by the wayside.

Does KaaS provision nodes across a cluster or even multiple pods in a node?

Let's get straight where KaaS fits in in the "provisioning" world. KaaS provisions the actual Kubernetes cluster, and not individual pods.  For example, if I were using Mirantis KaaS, I might define 5 servers to be used, and then specify that I want 3 control nodes and 2 worker nodes, which would then be spread across those 5 machines.
Once the cluster itself had been provisioned, I could then deploy my pods on those Kubernetes nodes, but that's independent of the KaaS.

In the PDF you list Pivotal's PKS but not PCF. I thought PKS was still beta. Can you speak where PCF fits in? It is clearly (non-k8s) PaaS, but is there anything more to add?

By PCF I assume that you're referring to Pivotal Platform, which is not so much PaaS as an umbrella project for multiple things, including Pivotal Container Service (the KaaS), Pivotal Application Service, and Pivotal Function Service. Like OpenShift, it appears to be focused more on the CI/CD process.

If you know, what do you think about the EIRINI CloudFoundry project? Integrating Application Runtime & K8s. Is it a real convergence between PaaS and KaaS?

Yes, it does give CF KaaS capabilities. It only allows for CF Orchestration to be applied to Kubernetes Containers as well as VMs. They created a "plugin" to their CF Engine to call the same things, for example, that might be called in a KaaS.

Does OpenShift support Kubespray?

It doesn't appear to, and there's no mention of it in the documentation.

In your opinion, what is more cost-effective, KaaS or PaaS?

Like most questions that involve cost and technology, the answer is "it depends".  There are a number of different factors that matter, such as what you're trying to accomplish, your infrastructure, and your use case.  (Contact us and we'll be happy to help you take a look at your situation.)
 

Choose your cloud native journey.

Whatever your role, we’re here to help with open source tools and world-class support.

GET STARTED

Join Our Exclusive Newsletter

Get cloud-native insights and expert commentary straight to your inbox.

SUBSCRIBE NOW