When Kubernetes Isn’t the Right Choice

A previous version of this post ran on The New Stack. 

Contrary to popular sentiment, Kubernetes isn’t always the right choice for your business. Not every business has a need to adopt Kubernetes, or indeed any container orchestration tool. Containerization isn’t something that everyone needs to be good at, to use, or even to know something about. Kubernetes isn’t a one-size-fits-all solution for every problem, so it might not be right for your business.

Now that we’re past the bare sophistry of saying that no technology is a perfect solution for everything, I want to share some observations that have become fairly standard for Kubernetes users and those working in a similar containerized architecture. The consensus I’ve seen is that, especially for smaller organizations, an orchestration tool is a big solution to specific problems; so in some cases, it may not make sense to make the investment in it.

Kubernetes Costs Something

Open source tools are free of licensing fees, and running your own container orchestration means you’re not paying a cloud provider for the service. That means Kubernetes is free or very cheap, right?

A recent Twitter thread debated whether the cost of Kubernetes was a million dollars. Some low estimates were around $80,000, and others a bit higher. I won’t settle on any specific number, but suffice to say that beyond the cost of hosting your cluster, Kubernetes costs a lot of money because it must be maintained by experts. Both the time and expertise are relatively expensive in the current labor market.

One pernicious issue is that these costs are often well hidden for executives at the top. Just because your SRE’s, Ops engineers, and Security engineers are run ragged maintaining your new cluster, their stress and extra work aren’t necessarily displayed in red on this quarter’s balance sheet. Without honest and well-informed management to tell executives the upfront real cost of such a team, the focus may remain on the "free" price tag of the software itself.

Surely all this automation means that eventually there will need to be very little maintenance, so the costs will fall—right? There may be some teams out there that don’t have to do much to maintain their cluster, but looking at a ‘troubleshooting flowchart’ that many were sharing earlier this year, I can say that Kubernetes certainly doesn’t erase complexity.

This is not to say or imply that Kubernetes is more expensive than any other option! Merely that it isn’t free and much of that cost is upfront. Unlike a container service like Heroku or a serverless function on any cloud platform, you can’t spend your first year of Kubernetes spending $75 a month and slowly ramping up. To do it right, you need experts and they cost both time and money.

Kubernetes Needs Experts

We’ve all seen the ads: “DevOps Ninja needed: 10 years Kubernetes experience required.”

And while recruitment teams may have unrealistic expectations about our ability to use a tool for longer than it has existed, the fact is that many organizations trying to adopt Kubernetes may have their own unrealistic expectations. The first question for anyone adopting Kubernetes is, “How will we build the team we’ll need?”

In the previous section, I mentioned teams not identifying the cost in hours and training of adoption. Just as it’s not possible to run a cluster without taking extra time out of your day, it’s also true that those who maintain Kubernetes will need to specialize in Kubernetes. Kubernetes is not a cloud service you can learn fully at a weekend workshop, and maintain by filing support tickets. You need experts within your organization to keep things running and expand what Kubernetes can do for your team.

While it’s true that it’s currently very difficult to hire Kubernetes experts, I would submit that this is a cost and not a barrier—since you can and should build this expertise within your team. Kubernetes resources are readily available, and you should take the time and resource commitment to create the team you need. As Sheen Brisals put it in a recent article: great teams aren’t hired, they’re grown.

Do You Want to Be the Best at Servers?

If you want to differentiate on uptime, reliability, and possibly cost efficiency, Kubernetes may be part of the solution. If you are much more focused on solving a business problem in a unique way, expertise in container orchestration probably isn’t part of the solution.

If you’re a shoe company that sells to tweens, and everyone is trying to get virtual versions of your shoes in Fortnite, it’s unlikely that "we deliver more 99.999% availability than Amazon Web Services" is a key part of your strategy.

It’s tempting, especially when you’re a team of engineers, to try to be the best at everything. But your job in an engineering team is to help make your business be the best at solving specific problems. No one is looking for you to write the best email server, e-commerce suite, and online chatroom for shot-putting athletes.

For many teams, Kubernetes is a part of the solution or a part of their near future for a number of reasons. Cloud-hosted clusters handle some problems with self hosting, which makes adoption easier. Users on all kinds of services have extremely high standards for performance, so in-house expertise might be necessary. And Kubernetes is often a draw for some extremely smart engineers, meaning that using older technologies might make hiring harder.

But the reality is that no tool works for every single team, and Kubernetes is no different!

If you're interested in learning the fundamentals of effectively monitoring Kubernetes deployments, check out our eBook.