Kubernetes is one of the hot technologies in cloud. But as many have learned, chasing after the hot technologies does not equate to more cost effect infrastructure, happier developers, or a better overall cost structure. I’m aware of numerous cases where making a change ended up costing more without seeing gains elsewhere leading to a worse total cost of ownership (TCO). This is exactly the kind of situation business decision makers want to avoid. Just because technology is hot doesn’t mean it’s useful.
With that in mind, let’s take a look at the business case for Kubernetes including being a little honest on the rough spots that could have a negative impact.
The Benefits
There are benefits to using Kubernetes that can shift the TCO in a businesses favor. These are guidelines and anyone considering the switch should look at how their workloads and case maps to these guides. Let’s take a look at a few of these benefits.
1. Higher Infrastructure Utilization
The way Kubernetes schedules containers can end up with a higher infrastructure utilization than typical virtual machines packaged workloads running under virtualization in VMware or a public cloud.
This is not to say that public clouds or VMware are bad. It has to do with the model. Kubernetes treats a cluster of servers as a single computer where Kubernetes is the operating system. Google, with borg – the precursor to Kubernetes, runs warehouses as computers. The containers are a small unit of work that is intelligently scheduled. Virtual machines are a larger unit of work and the way they handle space and spare cycles is different.
The difference in the model opens the door for scheduling more work on infrastructure leading to greater density. This leads to lower infrastructure needs.
Now, this is a general rule. It’s not perfect. There are exceptions due to how workloads run and their needs.
2. Workload Portability
Once you’ve started using a public cloud you quickly get locked in with the vendor APIs. Using AWS? You might be using cloud formation, AMIs, and scripts in your favorite automation system targeting their APIs. The same holds true if you’re in Azure or Google Cloud.
We could look at this the way we looked at Platforms of the past like Windows and Linux. It was a decision to pick one. But, wouldn’t it be great to be able to easily migrate workloads from one cloud to another? Wouldn’t it be great to be able to negotiate price with a public cloud and run workloads where it’s the most cost effective? And, to have a low cost to migrate from one place to another?
If you spend millions per year on cloud hosting, which many do, there is an opportunity to save plenty of money here. Money to re-invest back into the business. Money for profits. Money to fund new ideas. Money for some employee benefits.
A workload in Kubernetes can be run in clusters from varying providers. It’s not uncommon for me to run a workload in Kubernetes running in Google’s Cloud and then run the exact same workload in Kubernetes running in Azure. I do this today.
Now, there are times where you may want to tweak things in the config per provider. Tools like Helm and the logic it affords in templates let you do just that.
3. Fault Tolerant By Default
In traditional situations applications run on their set of hardware or virtual machines. If something happens to some hardware the workloads running on that infrastructure has issues. That’s because application workloads are assigned to infrastructure.
Kubernetes treats infrastructure, including numerous servers, a computer with hot swappable parts. For example, if a virtual machine running some workloads as containers fails then Kubernetes will schedule the work elsewhere.
As long as you run a multi-node cluster you get this fault tolerance out of the box.
The Risks
As with any system there are risks everyone should be aware of. These are the state of Kubernetes as of the writing of this post and they are being actively worked on.
1. Software Services
When we run applications we often will use a Software as a Service for things we need but are not our core competency. A common example is using a database such as MySQL. Why operate it yourself when you can get it via an API request where someone else makes sure it’s running?
There are many common services that all of the major public clouds offer. Yet, each of them does so with a different API. That means to get to that service you need to speak the API of the cloud provider before that common API, such as the MySQL one, is available.
This is a pain point for portability.
Kubernetes sought to solve that with the Service Catalog built on the Open Service Broker. This work does provide some portability. But, it lacks good support for all the major cloud providers, it’s development pace has slowed, and there are some cross cloud issues still open.
It does provide a means for some portable services use between providers.
Unfortunately, the current path – driving largely by the cloud vendors who have focused on their APIs – has not moved quickly enough for the users. Due to that it’s still an open risk and one we are working on new plans to mitigate. If you want to be involved please feel free to let me know.
2. Developer Tools and Documentation
Kubernetes is hard. If you’re used to Cloud Foundry, where you can have a few lines of YAML to describe an application, the hundreds you’ll need in Kubernetes can seem hard to grasp.
The Kubernetes project is not trying to directly address these. Instead, this is a space for the ecosystem of projects around Kubernetes. Developers have their own styles. That’s why we have Ansible, Chef, and Puppet. That’s why there are famous debates on Vim vs Emacs. The Kubernetes project can provide a kernel but it cannot make everyone happy.
This is a space where there are many ecosystem projects such as Helm, Telepresence, Draft, Kubeless, and many many others. You can learn about many of them in the CNCF Landscape.
This is a risk because the space is not mature. Many of the technologies still have a long way to go and the documentation around them is not all that great.
To mitigate this risk we need more tools by application developers for application developers and more documentation and books teaching people and making it easier. This is going to take more time.
Conclusion
This is where you need to draw your own conclusions. Will it be cost effective and useful to adopt Kubernetes? If you want to change people’s minds a good place to start is with a business case that highlights the value for your organization. Hopefully these points help you with that.