PaaS vs KaaS: What's the difference, and when does it matter?
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.