Kuberentes is all the rage. All the cool kids are doing it. It’s the hot newness for scaling enterprise-scale applications to unbelievable heights.

But does it make sense for smaller teams?

In the words of every professional consultant everywhere:

“It depends.”

Kubernetes absolutely can be a big win for many small teams (even solo projects). But that doesn’t mean it’s right for everyone.

Here I touch on the most important drawbacks to Kubernetes, as well as the most important benefits, to help you weigh the decision for your own team.

Reasons to Pass on Kubernetes

Steep learning curve

When I decided to dive into Kubernetes, I read at least two full books (on Kubernetes, and Helm), and still didn’t feel I had a good understanding of it until I just started using it. I’ve heard many others express similar sentiments. For anyone completely new to the technology, there’s not a really graceful way to “get started”, without just diving in.

Complexity of debugging

Kubernetes has a lot of moving parts, and there are even third-party extensions that are desirable to use sometimes. This makes it inherently complex to debug. What might be a simple matter of grepping /var/log/syslog on a more traditional installation, can require poking around multiple services to find the right logs. And even then, understanding the interactions between various deployed services, and various kubernetes components, can add to the complexity. Log aggregation can help with some of this complexity, but not all.

More infrastructure to maintain

Kubernetes is, naturally, another piece of infrastructure to manage. This adds (or in some cases moves) complexity. So unless the benefits apply to you (spoiler alert: at least some of them likely do), don’t just flock to Kubernetes because it’s shiny.

Using a managed Kubernetes solution, such as Google’s GKE, or Amazon’s EKS, can mitigate the majority (but never all!) of this concern, too.

Challenging for stateful services

Managing stateful services, like the prototypical example of a database, in Kubernetes is possible, but comes with unique challenges.

More broadly speaking, Kubernetes is a challenge for services that depend on global state. This could be state stored on a disk, or the simple assumption that only one instance of a service is ever running at a given time.

Reasons to Embrace Kubernetes

Kubernetes is ubiquitous

Although Kubernetes has a steep learning curve, it’s also the de facto industry standard. This means that it has excellent community support, and finding people with relevant experience is becoming easier all the time.

Less infrastructure to maintain

I know I said Kubernetes gives you more infrastructure to maintain. But it can also reduce the infrastructure you maintain, due to the fact that many important features are effectively built-in. For many common uses, Kubernetes replaces the need for traditional configuration management (i.e. puppet or Ansible), a load balancer, and an internal DNS server.

Kubernetes is vendor-neutral

Changing hardware infrastructure is an increasingly rare thing these days, and it’s never easy. But if you’ve built your system on Kubernetes, it’s at least less difficult. Switching between AWS and Google, or from public- to private-cloud, or maybe even expanding to a second cloud provider for additional reliability, are all within the realm of possibility for many companies. Avoiding as much vendor lock-in as possible helps reduce this friction.

Upgrading and scaling made easy

Of course these are two of the most touted benefits of Kubernetes. Rolling upgrades (and downgrades), horizontal scaling, and even automatic scaling under load, are all super sexy. Kubernetes isn’t the only option for these features, but if you’re not already using Heroku, Amazon’s Elastic Beanstalk, or one of the other many tools that provide some or all of these features, the switch can feel like a night-and-day difference.

Declarative infrastructure-as-a-service

Kubernetes (and many related tools such as Helm, and even Terraform), approach configuration with a declarative programming paradigm. Again, Kubernetes isn’t the only show in town, but if you’re not already using one of the other many declarative IaaS tools on the market, making the switch can provide some serious simplification!

Encourages many best practices in application design

If you have the luxury of designing (or re-designing) an application or service to work well with Kubernetes, you can end up with a much better application, in terms of performance and stability. Broadly speaking, any app designed with The Twelve Factors in mind, will work well in Kubernetes. Even when not using kubernetes, adhering to these principles will usually lead to a more robust, easier-to-maintain app.

Kubernetes or Not?

I’ve had good experiences with Kubernetes on both one-person projects, as well as small teams, to large teams of teams. So in my view, it always deserves consideration.

I’ve also passed on Kubernetes for some teams, where the technology the team was using didn’t fit well into the Kubernetes paradigm.

What may be interesting to note is that while team size is often touted as the deciding factor for when to use Kuberentes, this is virtually a non-consideration for me, when deciding whether or not to use Kubernetes on a given project.

So is Kubernetes right for you? Of course only you can ultimately answer that, based on your own situation.

I’d love to know what decision you made, and why. And if I’ve overlooked some key factor relevant to your decision-making process, please leave a comment and let me know.