KaaS vs PaaS: Mirantis Kubernetes-as-a-Service vs OpenShift
Nick Chase - August 19, 2019
Many companies who use Kubernetes today do it using Red Hat's OpenShift distribution, so one question we often hear from users asking about the Mirantis Kubernetes as a Service beta is "How is KaaS different from OpenShift?"
The short answer is that OpenShift is a Platform as a Service (PaaS) and Mirantis KaaS is...well...a KaaS. These two concepts are different. Let me explain.
OpenShift is a Platform as a Service, or PaaS, that just happens to use Kubernetes as its underlying substrate. But just because a PaaS uses K8s, that doesn’t automatically make it a KaaS.
PaaS enables developers to easily create applications without having to worry about setting up the underlying platform components. So if a developer wants a database, they just check a box, or make an API call, or use whatever mechanism that the PaaS provides to get one. They don't have to install the database, they can just use it. OpenShift, Cloud Foundry, and Heroku are examples of a PaaS.
KaaS systems, on the other hand, assume that the K8s API is the highest level of abstraction exposed to the developer. As such, its focus is to make it easy to create, scale, and manage many distributed Kubernetes clusters, whether on premises or across multiple cloud environments.
OpenShift has implemented some KaaS functionality in its new version, OpenShift 4, but most folks using it are still on the more PaaS-y OpenShift 3 version, so to get very specific about how KaaS differs from PaaS, let's compare KaaS with the most commonly used OpenShift (version 3.x), with respect to key use cases and implementation approaches.
Conversely, under the hood Mirantis KaaS partially relies on KubeSpray - a set of validated Ansible scripts maintained by the K8s community - to perform work required for a cluster upgrade. However, from the end-user standpoint, all of the complexity is hidden behind Mirantis’ implementation of ClusterAPI - a Kubernetes-native API standard for cluster lifecycle management - to perform any procedure (such as an upgrade) on a cluster. As such, from an end user standpoint, a cluster upgrade is a single ClusterAPI-compliant API call. The process is similar for other KaaS implementations, such as Rancher and Platform9.
For OpenShift, the process consists of four basic steps, which are similar to those used for installing OpenShift in the first place:
If developers need the ability to scale their own clusters, they will need a KaaS environment, which enables them to scale a cluster with an API call or through the UI; OpenShift is fine as long as developers are not going to need to scale the cluster on which they’re doing their work.
An OpenShift PaaS instance is a single instance of K8s running in a single location.
A KaaS instance is many K8s instances running across many locations, but centrally controlled.
Because in OpenShift all developers use a single Kubernetes instance, OpenShift has created the additional concept of a "project", which uses Kubernetes namespaces to isolate users from each others’ resources within a single K8s cluster. Keep in mind, however, that when K8s was initially built, it wasn’t designed to be inherently multi-tenant, and its architecture mostly assumes that a single cluster represents a single tenant. While there are many efforts in the community to implement multi-tenancy, there isn’t an agreement on a single "correct" approach, and upstream is far from an ideal solution here.
KaaS, on the other hand, doesn't add any additional hacks to implement multi-tenancy, because resources can be isolated by cluster, with multiple clusters per user or per project. (Note that this is also the approach currently implemented in public cloud implementations such as Google's GKE.)
OpenShift PaaS (as with most other PaaSes) is a self-contained, all-inclusive and opinionated implementation of all things necessary for developers to build an app. As such, it comes with its own pre-integrated artifact repository, continuous delivery engine and even an SDN. Therefore, once a user is authenticated into an OpenShift instance, there is limited need to interact with any services outside. An OpenShift end user is not going to be deploying K8s embedded in OpenShift on more nodes in the cloud and, therefore, doesn’t need access for it. Similarly, they won’t be using an external artifact repository (such as JFrog) or CD engine (such as Spinnaker or Argo). Because of this, in OpenShift users authenticate via LDAP or Active Directory to get access to their own “projects” mapped to Kubernetes namespaces, but if they also want to include access to other external resources, such as artifact repositories or external storage devices, operators can configure that access via a bespoke manual procedure.
Conversely, KaaS generally assumes that an enterprise will have a diverse ecosystem of external “best-of-breed” systems that a Kubernetes cluster (and consequently its end users) needs to interface with, so the Mirantis KaaS beta is implemented as a Single Sign On system using the community KeyCloak project. This approach enables a single user to have access to multiple clusters, artifact repositories, physical machines, and so on, through a single configuration.
For artifact repositories, OpenShift comes with its own, fairly sophisticated system, which is an augmented implementation of Docker Registry. It gets installed automatically via the same Ansible playbook as the rest of OpenShift, and is designed to interact with a single instance / K8s cluster. This option is best when development is centralized to a single (OpenShift-based) Kubernetes cluster. With some minimal work, it is also possible to bridge multiple OpenShift instances to a third party artifact repository such as JFrog.
The Mirantis KaaS beta does not implement its own registry, but assumes that a user already has a registry in mind. If not, KaaS offers the option to co-deploy a Harbor registry with the Kubernetes cluster. Note that in KaaS, this registry is not typically tied to a single cluster, so you can use a single instance of Harbor to store artifacts from across multiple, geo-distributed K8s clusters. This method is a good choice when development spans multiple Kubernetes clusters.
For CI/CD, OpenShift implements its own system based on Jenkins, enabling developers to build applications with a proper CI/CD workflow. Mirantis KaaS doesn’t specify a CI/CD engine, and is designed to integrate with whatever the customer is already using.
That doesn't mean the catalog can't be useful, but most large enterprises end up turning off most of these services and re-populating it with their approved, validated, and tested set of services.
While OpenShift focuses on making life easier for developers, KaaS focuses on making it simple for operators (and by extension, the developers they support) by exposing a self-service, developer-facing interface for deploying, scaling and upgrading multiple K8s clusters, distributed across public and private clouds.
Ultimately, the choice between PaaS and KaaS is going to depend on where you want to draw the line between devs and ops in your organization. If you (like most enterprises today) need substantial and strict guardrails and training wheels for your dev teams to adhere to, with an experienced, third-party vendor providing and managing the complete catalog of application building blocks, you should opt for the OpenShift and the PaaS route. On the other hand, if you believe that the Kubernetes API is that line of separation, you should go with KaaS, particularly if you are engaged in multi-cluster or multi-cloud development.
Is Kubernetes as a Service the right solution for you? Request access to the private beta of Mirantis KaaS and find out.
The short answer is that OpenShift is a Platform as a Service (PaaS) and Mirantis KaaS is...well...a KaaS. These two concepts are different. Let me explain.
OpenShift is a Platform as a Service, or PaaS, that just happens to use Kubernetes as its underlying substrate. But just because a PaaS uses K8s, that doesn’t automatically make it a KaaS.
PaaS enables developers to easily create applications without having to worry about setting up the underlying platform components. So if a developer wants a database, they just check a box, or make an API call, or use whatever mechanism that the PaaS provides to get one. They don't have to install the database, they can just use it. OpenShift, Cloud Foundry, and Heroku are examples of a PaaS.
KaaS systems, on the other hand, assume that the K8s API is the highest level of abstraction exposed to the developer. As such, its focus is to make it easy to create, scale, and manage many distributed Kubernetes clusters, whether on premises or across multiple cloud environments.
OpenShift has implemented some KaaS functionality in its new version, OpenShift 4, but most folks using it are still on the more PaaS-y OpenShift 3 version, so to get very specific about how KaaS differs from PaaS, let's compare KaaS with the most commonly used OpenShift (version 3.x), with respect to key use cases and implementation approaches.
K8s Cluster Upgrades
Because the emphasis of a PaaS is on application development vs. Kubernetes cluster lifecycle management, the process to upgrade an OpenShift PaaS instance (and its embedded K8s version) is not necessarily straightforward. It is generally assumed that a PaaS is used by developers, but is operated by a trained operations team. Because OpenShift consists of multiple frameworks on top of Kubernetes, upgrading an OpenShift cluster is a bespoke procedure consisting of a series of manual Ansible script runs.Conversely, under the hood Mirantis KaaS partially relies on KubeSpray - a set of validated Ansible scripts maintained by the K8s community - to perform work required for a cluster upgrade. However, from the end-user standpoint, all of the complexity is hidden behind Mirantis’ implementation of ClusterAPI - a Kubernetes-native API standard for cluster lifecycle management - to perform any procedure (such as an upgrade) on a cluster. As such, from an end user standpoint, a cluster upgrade is a single ClusterAPI-compliant API call. The process is similar for other KaaS implementations, such as Rancher and Platform9.
Ability to Scale Kubernetes Clusters
Continuing on the cluster lifecycle management thread, another area in which OpenShift and Kubernetes as a Service differ is when it comes to scaling Kubernetes clusters.For OpenShift, the process consists of four basic steps, which are similar to those used for installing OpenShift in the first place:
- Create VMs with Red Hat Enterprise Linux installed on them
- Add access to Red Hat subscription manager repositories on those nodes
- Add these nodes to an OpenShift deployment Ansible playbook that lists IP addresses / DNS entries and tweak any other playbook settings as necessary
- Run an Ansible playbook and wait for execution to complete
If developers need the ability to scale their own clusters, they will need a KaaS environment, which enables them to scale a cluster with an API call or through the UI; OpenShift is fine as long as developers are not going to need to scale the cluster on which they’re doing their work.
Multi-tenancy
KaaS and OpenShift achieve multi-tenancy in two different ways, and much of that difference has to do with the inherent logic and resulting architecture behind the two solutions.An OpenShift PaaS instance is a single instance of K8s running in a single location.
A KaaS instance is many K8s instances running across many locations, but centrally controlled.
Because in OpenShift all developers use a single Kubernetes instance, OpenShift has created the additional concept of a "project", which uses Kubernetes namespaces to isolate users from each others’ resources within a single K8s cluster. Keep in mind, however, that when K8s was initially built, it wasn’t designed to be inherently multi-tenant, and its architecture mostly assumes that a single cluster represents a single tenant. While there are many efforts in the community to implement multi-tenancy, there isn’t an agreement on a single "correct" approach, and upstream is far from an ideal solution here.
KaaS, on the other hand, doesn't add any additional hacks to implement multi-tenancy, because resources can be isolated by cluster, with multiple clusters per user or per project. (Note that this is also the approach currently implemented in public cloud implementations such as Google's GKE.)
IAM Authentication
While both KaaS and OpenShift can integrate with authentication systems such as LDAP and Active Directory, the key difference is in just what you're controlling access TO.OpenShift PaaS (as with most other PaaSes) is a self-contained, all-inclusive and opinionated implementation of all things necessary for developers to build an app. As such, it comes with its own pre-integrated artifact repository, continuous delivery engine and even an SDN. Therefore, once a user is authenticated into an OpenShift instance, there is limited need to interact with any services outside. An OpenShift end user is not going to be deploying K8s embedded in OpenShift on more nodes in the cloud and, therefore, doesn’t need access for it. Similarly, they won’t be using an external artifact repository (such as JFrog) or CD engine (such as Spinnaker or Argo). Because of this, in OpenShift users authenticate via LDAP or Active Directory to get access to their own “projects” mapped to Kubernetes namespaces, but if they also want to include access to other external resources, such as artifact repositories or external storage devices, operators can configure that access via a bespoke manual procedure.
Conversely, KaaS generally assumes that an enterprise will have a diverse ecosystem of external “best-of-breed” systems that a Kubernetes cluster (and consequently its end users) needs to interface with, so the Mirantis KaaS beta is implemented as a Single Sign On system using the community KeyCloak project. This approach enables a single user to have access to multiple clusters, artifact repositories, physical machines, and so on, through a single configuration.
Plug-Ins: CNI, Artifact Repository, CI/CD
As outlined in the section above, PaaS and KaaS different greatly in their philosophy as to what’s in and out of scope. While it’s not entirely black and white, OpenShift mostly follows the “all-inclusive, full-stack” approach in which everything is defined, whereas KaaS mostly follows the “batteries included, but optional” approach, in which almost everything can be defined, but can also be changed if necessary. Let’s take a closer look to make things more concrete.For artifact repositories, OpenShift comes with its own, fairly sophisticated system, which is an augmented implementation of Docker Registry. It gets installed automatically via the same Ansible playbook as the rest of OpenShift, and is designed to interact with a single instance / K8s cluster. This option is best when development is centralized to a single (OpenShift-based) Kubernetes cluster. With some minimal work, it is also possible to bridge multiple OpenShift instances to a third party artifact repository such as JFrog.
The Mirantis KaaS beta does not implement its own registry, but assumes that a user already has a registry in mind. If not, KaaS offers the option to co-deploy a Harbor registry with the Kubernetes cluster. Note that in KaaS, this registry is not typically tied to a single cluster, so you can use a single instance of Harbor to store artifacts from across multiple, geo-distributed K8s clusters. This method is a good choice when development spans multiple Kubernetes clusters.
For CI/CD, OpenShift implements its own system based on Jenkins, enabling developers to build applications with a proper CI/CD workflow. Mirantis KaaS doesn’t specify a CI/CD engine, and is designed to integrate with whatever the customer is already using.
Application Catalog
Perhaps the most significant thing OpenShift has that KaaS doesn't is the Application Catalog. After all, that's what makes it a PaaS in the first place! This catalog comes populated with over a hundred services, such as MySQL, MongoDB, JBoss, RabbitMQ, and so on, but there's one very important caveat to keep in mind: these pre-packaged services are there just to get your developers started. They don't come with support, most won't be upgraded, and most important to keep in mind, they're not meant to be used in production.That doesn't mean the catalog can't be useful, but most large enterprises end up turning off most of these services and re-populating it with their approved, validated, and tested set of services.
Multi-Cloud K8s Management
Just as the application catalog is key to OpenShift's identity as a PaaS, the ability to deploy multiple Kubernetes clusters is primary to KaaS.While OpenShift focuses on making life easier for developers, KaaS focuses on making it simple for operators (and by extension, the developers they support) by exposing a self-service, developer-facing interface for deploying, scaling and upgrading multiple K8s clusters, distributed across public and private clouds.
Summary
Bringing it all together side-by-side, we get the following picture:| Typical KaaS | OpenShift 3.x | |
| K8s Cluster Upgrade | Automated | Manual |
| K8s Cluster Scaling | ClusterAPI or UI | Bespoke Ansible Playbooks |
| Multi-tenancy | Per K8s cluster | Per K8s namespace |
| IAM Authentication | KeyCloak | Proprietary |
| Artifact Repository | Harbor Plug-In option | Implementation of Docker Registry with external plug-in option |
| Access to CNI | Calico | OpenShift SDN |
| Built-in CI/CD | No | Jenkins |
| Application catalog | No | Yes, 100+ apps |
| Multi-Cloud K8s Management | OpenStack, AWS | No |
Ultimately, the choice between PaaS and KaaS is going to depend on where you want to draw the line between devs and ops in your organization. If you (like most enterprises today) need substantial and strict guardrails and training wheels for your dev teams to adhere to, with an experienced, third-party vendor providing and managing the complete catalog of application building blocks, you should opt for the OpenShift and the PaaS route. On the other hand, if you believe that the Kubernetes API is that line of separation, you should go with KaaS, particularly if you are engaged in multi-cluster or multi-cloud development.
Is Kubernetes as a Service the right solution for you? Request access to the private beta of Mirantis KaaS and find out.
