Curb Complexity

Over-the-Top Hype

The vast majority of features that K8s has seen added in recent years, or that can be retrofitted with external tools, are for the PaaS and SaaS deployment areas already described. Kubernetes is far less well suited for classic information as a service (IaaS), for example. This niche is where classic virtual machines (VMs) based on KVM or Xen play to their strengths.

In some ways, this insufficiency is the crux of the problem, although it has never stopped many Kubernetes service providers from selling K8s as a solution to life, the universe, and everything. Local setups, so the story goes, also benefit from Kubernetes because it becomes easier to handle applications. The fact that this only applies if the applications are suitable for operation in containers at all and, even then, that many conventional applications present their own challenges, is deliberately concealed by the advertising blurb. Most of the problems already described for containers without K8s also apply to containers in Kubernetes. Granted, some companies are using the move to containers and Kubernetes to make a clean sweep of their existing application landscape, and even rewriting some parts of it, but this is by no means possible or affordable in every case.

Kubernetes also is designed in the best possible way to scale seamlessly across the board (i.e., to provide the underpinnings of an eternally growing platform). However, you only really need this if you want to operate a platform that can handle any amount of data and services. If you have a clearly separated setup in mind with a defined target size (with some scope for fluctuation), you will be hard put to use most of Kubernetes' functionality in a meaningful way. In these cases, K8s quickly becomes a hyper-complex chunk at the end of the process, the complexity of which bears no relation to the actual needs and benefits.

Conclusions

Kubernetes is primarily of interest to enterprises that want to run arbitrary numbers of containers for SaaS or PaaS applications across large fleets of physical systems. Kubernetes can also be used for internal purposes. For example, if you are converting your production software to as-a-service principles, Kubernetes will serve you well internally. In this respect, operating a K8s platform is by no means tied to being a major platform provider.

If you're looking for a solution that rolls out individual applications in a neatly automated and scalable way, though, you'll have an easier life with a solution that is based on classic automation, just as you did with containers. If required, the automation can be combined with virtualization: The combination of VMware or KVM and Ansible is found in many places. Virtualization solutions such as Proxmox (Figure 5), which can be easily integrated with existing automation, are also helpful. Almost all of these pairings are far easier to handle and maintain than K8s, and accordingly offer less functionality.

Figure 5: Like other virtualization solutions, Proxmox Virtual Environment can easily team up with many automation tools, ensuring a kind of scalability. However, the entire setup is far less complex than a full-blown K8s environment. © Proxmox

For many companies embarking on the Kubernetes adventure without a clear roadmap, the functionality offered by classic automation will be completely sufficient: Containers and container automation are not just the continuation of virtualization by other means.

The Author

Freelance journalist Martin Gerhard Loschwitz focuses primarily on topics such as OpenStack, Kubernetes, and Chef. @IE