Don't (always) use Kubernetes!

One more controversial topic! Is Kubernetes always right? Or always wrong?

Well…always is a pretty strong word so I’ll refrain from using that. But I don’t think anyone believes a blog should be hosted on Kubernetes…what if it’s Techcrunch size though or has complex business and/or data logic under the hood?

Let’s see some examples.

Solo dev, hobby project, low use

Hard pass :)

Solo dev, hobby project, high use

High use can be large traffic, many concurrent users, ML workloads, or a very good growth potential.

In that case I’d say yes, for learning and experimentation. Under any other scope, no.

Small team

Getting started phase

No, use something managed, preferably a PaaS where you’ll get lots of goodies (eg. CDN, storage, etc) included.

Growth phase

Consider it. If your workloads warrant it, there is a handful of services and new one pop up frequently, there might be unpredictable traffic or spikes and you have at least one team member (or at least a consultant) feeling comfortable with managing and configuring your Kubernetes cluster, give it a shot.

At this phase, don’t look further than Managed Kubernetes Providers.

Scale up product

Small team

Consider it. Assuming your workloads are a good fit and considering you’re a small team, I can see how Kubernetes might be able to help you take scalability off your mind for a second. However please be mindful of the upfront investment this step might need, meaning training, configuration and experimentation until you’ve standardized this process.

Multiple teams / larger engineering org

Chances are you have lots of services coming out of many domain teams, each one having kind of separate scaling needs depending on their product. My recommendation here would be look into building a platform team which will invest into an internal developers platform. Kubernetes is a really good candidate in that case.

Thinking on moving away from Kubernetes?

This might make sense but it is not a decision to be taken lightly on an exec level.

Points to consider:

  1. Org will lose the in-house expertise it has built and grown up to this point. Kubernetes is difficult to understand and configure initially than to maintain.
  2. Is this done for the right reasons? What were the factors that lead to your decision once you made the move to k8s?
  3. Can your org stay compliant/scalable if you do so?
  4. Think of the security and reliability blast radius.
  5. Hiring difficulties. Depending on where your org might move to, it can be difficult to find enough competent people to hire for something that’s totally not trending.

After all, it’s always the tech supporting the business and not the other way around.

See also