Kubernetes is a red flag signalling premature optimisation.

Issue No. 8

It feels bizarre saying this, having spent so much of my life advocating for and selling a distribution of Kubernetes and consulting services to help folks get the most of out it, but here goes! YOU probably shouldn't use Kubernetes and a bunch of other "cool" things for your product.

Most folks building software at startups and scale-ups should avoid Kubernetes and other premature optimisations. If your company uses Kubernetes, you are likely expending energy on something that doesn't take you towards your mission. You have probably fallen into the trap of premature optimisation.

Please don't take this post to be only aimed against Kubernetes. It is not. I am directing this post at every possible bit of premature optimisation engineers make in the course of building software.

Here are a few examples I've seen:

• Companies using Kubernetes for an application that is a web app.
• More than one language for your application. For example, a backend in Golang, Ruby, PHP etc. and a Frontend Web App in React, Vue etc.
• Not using a cloud service to host your app. Examples are Heroku, Vercel, Netlify and Fly.io. Most product teams will have over-architected their solution if they have to have an ops or infra team.

Imagine spending a lot of time and money picking out the best possible gear for a hobby before actually starting the hobby.

Some of this is subjective, of course. Perhaps you know you will stick with your new hobby for a long time, and you have a friend who is an expert at your new hobby who can help you pick the right gear. I have to admit I'm good at justifying the elite-level equipment for myself, even though I might never really notice the difference.

Your organisation needs engineers to create an impact on the mission.

If you are in a place where you think you need Kubernetes, then you are probably in a place where you are trying to optimise for the future prematurely. A future that probably won't happen. If you adopt any technology, you are making a multi-year commitment for your organisation that will increase the surface area of your product and the cognitive load on your developers. Eventually, you will have to create a dedicated team to maintain it. All of this takes resources away from your core mission.

It is easy for engineers to slip into this trap. We are all magpies distracted by the new shiny. We want to learn and grow, and the best way to do that is to incorporate the latest tech into our product. Then, we can come up with all sorts of reasons that justify our decisions.

Let me tell you some stories of how I have fallen into this trap.

I remember a discussion when I joined OCUS and discovered we were using Kubernetes. I said something to the tune of, "oh, that is great. One day, we might want to leave AWS and having Kubernetes will help us with that". Can you see how crazy I was at that moment?

Another time our Data Science team told us that they needed an orchestration tool for their data pipelines. I steered the selection process towards Argo Workflows (which runs inside Kubernetes) instead of Prefect (a SaaS offering), which they already used for a PoC. There were all sorts of justifications in my head for this decision. Unfortunately, they were all based on premature optimisations. In the end, our team needed to build a new set of Terraform and Helm charts to automate the deployment of Argo Workflows and integrate it into our SSO etc. I regret this decision. I think we lost weeks or even months shipping something to end-users because of this decision. Premature optimisation!

If we can dodge premature optimisations, we will move faster than our competitors, please our users and increase our chances of building a sustainable and viable product.

So how can we break out of this thinking?

Did users ask for this?

Solve problems as they arise, not in advance. The work we do should solve the user's issues. Ask yourself, what is the human behaviour I'm trying to impact with my work?

If you can remain laser-focused on impacting user behaviour and only solve real problems when they come up, you will surprise yourself with the impact you can have. You might also surprise yourself with how many assumptions you make about users because you haven't talked to them in a long time.

I believe that companies that stick to this approach rigorously will create greater leverage and more value for their users and shareholders.

I will know what I need if I spend all my energy doing my new hobby instead of researching equipment. In the beginning stages, I will not need the most "Gucci" gear, and I might even look out of place if I had the best equipment and no clue how to use it. It would be better to smash others with my entry-level equipment down the line because I spent all my energy learning my new hobby. Then when I did upgrade to the "Gucci" gear, it would make a real difference.

Do more with less.

Thankfully the Tech world is going through a massive course correction. As interest rates increase, cheap debt and Venture Capital is starting to dry up. Now that startups can't access crazy money, they must focus even more on their mission. The companies that survive will be the ones that have solid fundamentals.

Products will have to be built by smaller teams that can deliver business outcomes at an increasingly faster pace.

I can't see a place for Kubernetes in a lean organisation until they have grown to a massive scale. Even then, I think Kubernetes is a stretch. Most organisations should consider some of the higher-level building blocks available via cloud providers.

Remember that when Facebook bought WhatsApp for $19 billion, it had 35 developers and 450 million users!

If there is one takeaway from reading this, it is to be hyper-focused on what you need to achieve your organisation's mission. Don't get distracted by stuff you want to learn like Kubernetes or Golang - save that for the homelab.

If you can remain hyper-focused on making changes in your product that impact human behaviour that impacts business results, I have no doubt you will smash it out of the park.

That is all for this week folks, have a great week!

Jeremy (he/him)

Don't ignore your dreams, don't work too much, say what you think, cultivate friendships, and be happy.

📌 Follow me on LinkedIn and Twitter.