When Using Kubernetes Does (and Doesn’t) Make Sense

Kubernetes is so ubiquitous that it almost feels like a given when containers are involved. Having a standard method to orchestrate containers is a huge win for DevOps at scale, but is Kubernetes really necessary for every container project?

Ideally, the benefits of new technology should outweigh the time and resources required to support it. And, there is usually a threshold at which introducing a new DevOps tool into the mix becomes viable. Projects operating above that threshold experience a net economic and efficiency return. On the other hand, smaller projects working below that threshold might waste resources in the end.

Reaping the benefits of Kubernetes is often a moving target amid rapidly changing trends and a company’s need to build a foundation for future scalability. Yet too often, unnecessary tech adoption can lead to technical debt, holding back momentum. So, where is that threshold with Kubernetes? When is adoption worth it? Is it simply a matter of deployment size?

Below, we’ll attempt to answer these questions to help you gauge if Kubernetes is right for your project. To inform this piece, I met with Jake Warner, CEO, Cycle.io. According to Warner, many of the solutions in the market chase enterprise use cases, leaving startups out of consideration. These smaller companies often use containers but are nowhere near the size needed to justify using Kubernetes.

When K8s Does Makes Sense

It’s good to remember that Kubernetes emerged from Google; it’s made to service enterprise needs at an enormous scale. Using it makes sense if you are a Fortune 500 company with massive container deployments, says Warner.

Kubernetes also is designed to serve stateless workloads across distributed nodes. Using Kubernetes to automatically scale applications across nodes and roll out updates can be very helpful. The features it provides—deployment, rollback, health monitoring, elastic scaling and networking—are features DevOps needs to solve anyway.

That being said, Kubernetes is complex. “You must continually fix security and performance issues,” explains Warner. Maintenance is an ongoing hurdle, and many organizations aren’t up for the task. As evidence, A Datadog study found that the average Kubernetes deployment is about 17.5 months out of date. But if your company has a dedicated DevOps team for support, using Kubernetes makes more sense.

Even then, achieving DevOps is a large target. Another way to frame it is that Kubernetes becomes necessary “when your application reaches a stage where deployment and scaling it is becoming a job of its own,” says Ron Powell.

When K8s Doesn’t Make Sense

For many scenarios, Kubernetes is overkill. “If you are hosting a blog, you probably don’t need Kubernetes,” says Warner. If you are a startup with no developers or a single DevOps engineer, Kubernetes is probably not worth it.

Another area of should-you-or-shouldn’t-you debate is stateful development. Kubernetes was designed to cater to stateless, impermanent container life cycles. Hosting databases on short-lived containers isn’t exactly a recipe for data stability, although some inroads have been made to enable stateful Kubernetes development, this adds additional overhead.

Just because you can run something in Kubernetes doesn’t mean you should. Kubernetes doesn’t guarantee better application performance—legacy applications will not necessarily run better on Kubernetes. In fact, “most implementations suffer runaway complexity,” writes Ben Morris.

Also, reconsider Kubernetes if cost is a concern. Maintenace costs aside, the computing resources required to run Kubernetes are high. For context, take Kelsey Hightower’s Kubernetes the Hard Way walkthrough. Merely setting up this tutorial exceeds the use requirements of GCP’s free tier.

To Reiterate, Kubernetes is A Commitment

Kubernetes is a way to deploy images and containers and manage the scaling, deployment, resource balancing and traffic for cloud services. This is becoming essential as teams build microservices and package them into containers. However, it also brings significant complexity.

“If you’re throwing too much at maintaining a complex solution, you’re wasting a huge amount of resources,” says Warner. The result for startups is that developers end up playing too much of a DevOps role—an engineer could end up spending 40% to 50% of their time maintaining infrastructure, even though they’re not specifically trained to do so, he warns. “Now they have to swim in a lake of technical debt,” he says.

With nuances between Kubernetes versions, stacks start to lack consistency, making it harder to automate deployments. He also notices companies trying to make Kubernetes solve other use cases it was not explicitly designed for, like stateful development. “You should never have a platform autoscaling or replicating that data underneath a container,” he says.

Other Solutions

“Managing and deploying containers should not be that difficult,” says Warner. So, what are some other options? Well, managed Kubernetes like GKE, Amazon EKS or Azure’s AKS help you avoid the pitfalls of running it from scratch, alleviating some burden. In fact, 90% of Kubernetes deployments use managed Kubernetes options, according to Datadog.

Companies can certainly scale a microservices strategy by other means, too. With a solid CI/CD pipeline, you can get pretty far with serverless configuration management and provisioning tools like Chef, Ansible or Terraform. There are also solutions on the market that handle the difficulties of container orchestration, like Heroku, Google Cloud Run or Cycle.

Startups Need DevOps, Too

If you are hosting a blog, you probably don’t need Kubernetes. If you’re managing a platform that deploys thousands of different blogs across various nodes, though, you just might.

There is a noticeable urge to associate Kubernetes with every container-based project by default. “A mindset develops where if it can be shoe-horned into a container then it can be shoe-horned onto Kubernetes,” explains Morris.

The truth is, it may not be the best option for every container deployment scenario. Whereas some DevOps teams will desire granular control, Warner advocates for a simpler approach to encompass smaller and medium-sized companies. “Developers are looking for ways to get back to writing code,” he adds.

A more managed solution will not solve everyone’s problems, but a good portion of the market out there just wants to maintain a platform that works, Warner says. “Startups need DevOps, too.”

Bill Doerrfeld

Bill Doerrfeld is a tech journalist and analyst. His beat is cloud technologies, specifically the web API economy. He began researching APIs as an Associate Editor at ProgrammableWeb, and since 2015 has been the Editor at Nordic APIs, a high-impact blog on API strategy for providers. He loves discovering new trends, interviewing key contributors, and researching new technology. He also gets out into the world to speak occasionally.

Bill Doerrfeld has 105 posts and counting. See all posts by Bill Doerrfeld