Developers looking for a way to speed up the production of Kubernetes applications have several options, including platform as a service (PaaS) and Kubernetes as a service (KaaS). They can be pretty similar, but in some ways, they couldn’t be more different.
PaaS abstracts away hardware and software deployment, enabling developers to mix and match components for application creation. For example, you might specify that you want a database and a web server, and all you need to do is enter configuration options and the PaaS sets it all up for you. These are systems such as:
- Cloud Foundry
- Google App Engine
- Apache Stratos
KaaS enables developers to deploy and/or manage Kubernetes clusters in a self-service manner. Developers deploy apps to the created clusters as usual. KaaS is a newer field, but there are still multiple products, including:
- Mirantis KaaS
- VMware Kubernetes Management Platform
- Rackspace KaaS
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Azure Kubernetes Service (AKS)
If you’ve used any of these systems, you know that there is some overlap. OpenShift is based on Kubernetes, so it’s often mistaken for a KaaS, but it’s really a PaaS (with some KaaS features). Rancher offers an application catalog—the hallmark of a PaaS—but it offers the ability to create new Kubernetes clusters and operate them independently of the control plane, so it’s really a KaaS. It doesn’t really matter which is which, but it’s a matter of what you need and establishing that the software you choose can give it to you.
Let’s look at the differences and see how they tip the scales in one direction or the other.
PaaS systems include features that are both assets and liabilities.
The primary feature of a PaaS is the application catalog, which enables you to create a project by hooking together components rather than deploying and configuring them individually. Some PaaSes may have dozens or even hundreds of components from which to choose.
On the other hand, because a PaaS assumes that you’re only going to create applications by putting together those pre-provided components, you’re locked into both the applications and the versions of applications that are provided. For development, this may not matter, but for production systems, it may be a much bigger deal. Also, you have to ask whether these applications and versions are going to be supported and/or upgraded.
Some companies delete the existing catalog and replace it with a catalog of production-approved applications. It’s extra work, but you get the benefit of having the catalog without potentially exposing anything due to security issues.
Developer Experience vs. Operator Control
PaaS simplifies the developer experience because you don’t have to think too hard about what pieces to use. You need a database, you grab one. On the other hand, not thinking too hard about what you’re using isn’t necessarily a Good Thing.
Another PaaS strength is that it gives the operator a large amount of control. It’s the operator who makes the architectural decisions for the PaaS, which in many ways makes decisions for the applications being built. It’s the operator who does all of the installation and maintenance and upgrading. The operator also controls access to the PaaS. So that’s great if you’re an operator-centric organization.
On the other hand, if you’re not an operator-centric organization, developers who may be used to making a lot of decisions suddenly find that those decisions aren’t available to them.
It’s a good thing that somebody is thinking about security because it’s usually something that’s handled as an afterthought. So a lot of these PaaS frameworks make various security decisions for you.
And you probably saw this coming, but that also can be a problem, because you don’t necessarily have any control over those security policies and restrictions. For example, some versions of OpenShift don’t let you use an image that must be run as root, which sounds fantastic until you realize that it prevents you from running lots of images, including official images for some projects. That may or may not work fit your plans, but you should be aware that you may run into it.
Similarly, KaaS has its plusses and minuses.
As you probably guessed, where operators are the last word in PaaS, KaaS gives more power to developers. Because KaaS just provides a way for you to spin up (or manage) a cluster, it’s up to the developer to decide what applications to run, when to upgrade or update the cluster and so on, which sometimes can be done through the KaaS itself. (Some KaaSes also update the clusters automatically. In addition, upgrades and updates affect just a single cluster, not the entire system and every application on it.) It’s also the developer who controls security, so you don’t run into a situation in which they’re hamstrung by overly restrictive environments.
But of course, there’s always the flip side to that, especially if you’re an operator who may be horrified at the idea of developers making all those choices. Developers may use applications that aren’t approved, create cluster sprawl or neglect cluster updates. Also, when it comes to security, it’s unfortunate, but most developers just are not as versed in it as they should be.
Vendor Neutrality and Multi-cluster Apps
Another advantage of a KaaS is that you’re just using it to create or manage your cluster and then the actual application uses the Kubernetes API, not a non-Kubernetes API.
And that brings us to one of the biggest advantages of KaaS, which is that you can create apps that span multiple clusters or even multiple clouds. (This isn’t necessarily impossible with PaaS, but it’s a lot more natural with KaaS.) You can build your application on multiple clusters, then move those clusters wherever you want. Most of the time, KaaS will even go ahead and create clusters for you on multiple Kubernetes providers.
How To Decide Between Them
Unfortunately, deciding isn’t a simple task. As you know that every case is different, but also every PaaS and KaaS are different, too, so you need to ask yourself some questions and then look at the specific product you’re considering to see whether it does what you need. These questions include:
- What are you trying to accomplish with your automation? If you already have applications and the focus is on deployment, then a PaaS might not be right for you and you are probably looking for KaaS.
- How much of a guardrail do your developers need/want? If you are dealing with developers who may need more help in getting things set up, then you’re more likely to want a PaaS.
- How are you going to handle upgrades/updates? If your developers are more savvy and want more control over their actual Kubernetes cluster, then you need a KaaS—or, at least a PaaS that enables them to have their own cluster.
- How many tenants/applications do you have? If you’re talking about hundreds or thousands, you probably don’t want a system that puts everything into one big cluster with separation by namespaces.
- How much flexibility do you need in choosing your architecture? Do you have internal systems you want to tie into? Are you married to a specific networking infrastructure? You need to make sure that whatever system you choose enables you to do what you need to do.
- Do you anticipate needing different clouds? Multiple clouds? If there’s even a chance that you may need to move to another provider at some point, you need to make sure that that’s possible. And these days most apps are multi-cluster in some form, so that’s a really big deal.
- How predictable are your plans? Where do you think you may need flexibility in the future? Make sure that that flexibility is there.
PaaS and KaaS are both great for their own use cases. Just make sure the one you choose does what you need.