Wednesday, October 9, 2019

Kubernetes is a feature not a product: SuSE drops out of OpenStack

SuSE discontinues OpenStack

It's interesting that SuSE decided to get out of the OpenStack business. However, I disagree that they do so because Kubernetes eats its lunch. The notion that Kubernetes would somehow replace OpenStack is comparing apples to oranges, or in this case, comparing a feature with a product.

The ability to manage workloads is a completely different use case than the ability to manage infrastructure. It is no wonder Kubernetes has gotten the larger number of supporters because, simply, there's more developers compared to SREs.

Containers, much like VM images, application packages, or source code repositories, are artifacts that can be characterized by their ephemeral nature, and their delivery mechanism via an active publishing pipeline. They are inherently different to the host operating system, hypervisor management, network configuration or server security. In contrast, Kubernetes helps schedule and maintain a controlled set of containers across a compute cluster, and intersects with infrastructure only inasmuch it connects to software defined (or host-provided) storage.

I should probably point out that I do not consider this in any way shape or form a flaw of Kubernetes; in fact, I would argue that Kubernetes should stay away from infrastructure as much as possible, in order to focus on what it does best: coordinate containers, and interact with infrastructure as a service as a client, not a provider.

It is also true that of course almost anything can be done if one sets ones mind to it, and if you so desire, can make your Kubernetes look very much like an infrastructure management tool. But the argument that "design a tool to do one thing well" so absolutely not lead one to the natural conclusion that Kubernetes management should be done by adding the feature of Kubernetes cluster management to Kubernetes. It might be a great idea, and hey - it might even work, but to me, that argument is inherently flawed.

This is also not an apologist post for OpenStack. OpenStack is flawed, severely so, by its complexity, unnecessary performance issues, and multi-tenancy that ignores years of industry learnings around domains, RBAC and directory management such as with LDAP or AD. But, restricted to the core competency of what OpenStack is supposed to deliver - compute, network, storage, with a little bit of load balancing and DNS sprinkled in - one can't help but note that it does this remarkably well. The stable subset delivering this core functionality can be run, managed and upgraded with relative ease, won't interrupt network connectivity, and represents an excellent alternative to virtual machine management tools such as VMware.

In fact, when one considers that today's workloads should be cloud-native ... wait a second, isn't that what Kubernetes is supposed to deliver? Cloud native applications running containerized on an IaaS?

To me, running Kubernetes on OpenStack is a perfect use case, and a great alternative to proprietary systems. Why throw out the baby with the bathwater?

No comments:

Post a Comment

Privacy

I usually am very open to new technology, even at the cost of some privacy. For example, my home is as smart as I am able to afford it; and ...