Follow Datanami:
October 20, 2020

The Biggest Reason Not to Go All In on Kubernetes

Chris Parlette


Kubernetes is hot. Everywhere you turn, you will see opinions about the container orchestration system from Google and why it will solve all your infrastructure problems – or at least, why you should take the time to learn it.

However, it may not be hot for long. Gartner’s Hype Cycle for Application and Integration Infrastructure 2020 has identified container management as “at the peak” – with only room to fall out of fashion from here.

That may not be such a bad thing.

The Cult of K8s

Kubernetes v1.0 was released in 2015, after being developed and used internally at Google since 2014. It quickly emerged as the most popular way to manage and orchestrate large numbers of containers, despite competition from Docker Swarm, Apache Mesos, Hashicorp’s Nomad, and various other software from the usual suspects at IBM, HP, and Microsoft. Google partnered with the Linux Foundation in 2015 to form the Cloud Native Computing Foundation (CNCF) and had Kubernetes as one of the seed technologies.

This public dedication to open-source technology gave Kubernetes instant nerd bonus points, and it being used internally at one of the largest software companies in the world made it the hot new thing. Soon, there were thousands of articles, tweets, blog posts, and conference talks about moving to a microservices architecture built on containers using Kubernetes to manage the pods and services. It wasn’t long before misguided job postings were looking for 10+ years of Kubernetes experience and every startup pivoted from their blockchain-based app to a Kubernetes-based app practically overnight.

Kubernetes provides automation for container management (2M media/Shutterstock)

Everyone needed to learn it – how to deploy containerized applications, scale those deployments, update software versions, and debug containerized applications. Altogether, this can be complex. The complexity may be part of the reason it comes with an insider mentality. You get a badge of honor once you’ve climbed the mountain and actually made this thing work in an automated and scalable way.

Of course, it’s also just… a really cool technology. The abstraction away from individual machine concerns toward an infrastructure as code model allows scalability and flexibility, while solving many dev and ops concerns.

Are the cult members delusional? No. Kubernetes solves real problems. But should all of us join the cult? Probably not.

Free Comes at a Price

Here’s the main objection: it’s expensive. I don’t mean the list price. Pure open-source Kubernetes is free, and managed versions are inexpensive – for example, Amazon EKS is currently priced at $0.10 per hour per cluster, which is reasonable.

Here’s the big thing that gets missed when a huge company open-sources their internal tooling – you’re most likely not on their scale. You don’t have the same resources, or the same problems as that huge company. Sure, you are working your hardest to make your company so big that you have the same scaling problems as Google, but you’re probably not there yet. Don’t get me wrong: I love when large enterprises open-source some of their internal tooling (such as Netflix or Amazon), as it’s beneficial to the open-source community and it’s a great learning opportunity, but I have to remind myself that they are solving a fundamentally different problem than I am.

The high level of technical complexity of Kubernetes is a drawback (o_m/Shutterstock)

While I’m not suggesting that you avoid planning ahead for scalability, getting something like Kubernetes set up and configured instead of developing your main business application can waste valuable time and funds.

There is a considerable time and overhead investment for getting your operations team up to speed on Kubernetes that may not pay out. Google can afford to have its teams learning, deploying, and managing new technology. But especially for smaller organizations, premature scaling or premature optimization are legitimate concerns. You may be attracted to the scalability, and it’s exciting. But, if you implement too early, you will only get the complexity without any of the benefit. That’s asking for operational pain.

If you can get the same effect from an autoscaling group of VMs with less headache, why wouldn’t you go that route? Remember: something like 60% of global AWS spend is on EC2, and with good reason. You can get surprisingly far using tried-and-true technologies and basics without having to rip everything out and implement the latest fad, which is why Kubernetes (or serverless, or blockchain, or multi-cloud) shouldn’t be your focus.

A side note: there is also an inherent assumption here that a microservices infrastructure is the correct design for everyone. However, you may have good reasons for your monolithic design such as language choices, the nature of your business, the design decisions you’ve already made, and your plans for the future. We won’t get into that debate here, but it may be that a microservices design isn’t right for your application anyway.

Kubernetes certainly has its place, and can be the tool you need. But most likely, it’s making things more complex for you without a corresponding benefit.

About the author: Chris Parlette is Director of Cloud Solutions at ParkMyCloud

Related Items:

Is Kubernetes Overhyped?

The Curious Case of Kubernetes In the Enterprise

The Cure for Kubernetes Storage Headaches: Break Your Data Free