Five reasons to use Kubernetes

Issue No. 9

I didn't expect last week's post about Kubernetes to blow up on Hacker News (HN), a major tech news site. It ended up at number one on the front page and provoked a storm of over 500 comments, and was shared all over the Internet.

The post had 34k views and counting, and I'm thrilled that so many folks who read it signed up for my newsletter.

The debate on HN was interesting (it is HN, after all), with some folks disagreeing with my article, others in complete agreement and some providing a more subtle point of view.

So when should you use Kubernetes? In this week's post, I will share five reasons you might consider using Kubernetes.

As I said last week, I think many folks can save their companies a lot of time and money by avoiding Kubernetes. I don't think you should use Kubernetes for a whole lot of use cases. It has a steep learning curve (installation is easy today but running it is a whole other thing). Adoption of Kubernetes involves a high cost. It takes time to set up correctly, requires skilled people to operate and if you already have a large legacy estate, the time to migrate everything can be high (even if you don't need to re-write everything to be "cloud-native").

That said, some organisations could and perhaps even should use Kubernetes. So how to tell if your organisation is one of them?

Let's dive in.

#1 You are concerned about vendor lock-in or need to run multi-cloud:

Kubernetes is a great solution to avoid vendor lock-in. It is open source, has decent governance and has excellent participation from (most) of the vendors that support it.

Kubernetes is also great if you need to run your applications in multiple locations, either in different clouds or a combination of on-premises and cloud (hybrid cloud).

Nowadays, many people know Kubernetes. It has an active community and a massive ecosystem around it.

The Kubernetes APIs are becoming an unofficial open standard. An open standard with an open source implementation is powerful.

Some of the reasons organisations might need to run their workloads in different environments include:

• Regulation - companies might need to run their workloads in completely different clouds, for example, between the USA, the EU and China.
• Competition - I worked for one SaaS company with a retail customer who stipulated in our contract that we were not allowed to run in AWS because they were considered competitors.

You could use Kubernetes to solve vendor-lock-in in the same way you could use multi-cloud to solve vendor lock-in. So again, it is a solution to the problem, but is it the right solution for your company?

I would argue that companies that need to architect these use cases might be in a niche. Typically these are massive global companies like Banks with the resources to be able to pay the tax for this sort of flexibility (see point #4).

Vendor lock-in is one of those things that folks talk about a lot and try to avoid. But unfortunately, I would say that it is usually part of the premature optimisation trap.

Focus on what your users need first - do they need you to remove vendor lock-in or be multi-cloud?

#2 You have to run on-premises and in the cloud:

Some organisations have to run their applications in their own data centers on-premise due to cost, regulatory or security reasons.

An example of this could include organisations that operate a huge number of workloads. They might choose to open up new regions of their business in the cloud but move to on-prem when their business in a region reaches a specific scale.

It is much cheaper to run on-prem rather than in the cloud, and when you have reached this sort of scale, you are likely to tick the box for point #4.

We successfully used Kubernetes when I worked at Traveldoo because we were stuck running our production environment on-premise. As a result, we could migrate our services to run inside Kubernetes and host our dev and test environments on Amazon EKS while keeping them consistent with our production Kubernetes cluster running on-premises. This work gave us tremendous flexibility and agility and a clear ROI on the extra investment needed to maintain Kubernetes. In addition, it was what allowed the company to move from quarterly releases to many on-demand releases a day in a few years.

There was a clear benefit for our users at Traveldoo, and if there is a clear benefit for your users, then this could be a good reason for you to consider Kubernetes.

#3 You are transitioning to microservices or have a specific use case:

First, I hope you have thought through why your organisation needs to use microservices. If you need to embrace this architectural style, then Kubernetes could be a good choice.

Cloud providers already provide good building blocks for hosting microservices without needing to run Kubernetes through building blocks such as serverless or AWS Fargate/Google Cloud Run/Azure Container Instances.

These, and other similar building blocks, should be good enough for most organisations to adopt microservices without Kubernetes. However, there might be circumstances where your specific use case won't work, and you need more control.

For example, when I worked at Red Hat's Open Innovation Labs, we helped Volkswagen build a virtual test bench environment that allowed them to wire the virtual components of a car together inside Kubernetes and have them drive a car in a virtual environment. It would have been virtually impossible to achieve this use case without Kubernetes.

Another use case for Kubernetes could involve the easy migration of code into environments that are air-gapped for security.

Telecom companies, cloud or managed hosting providers and other companies that work on the glue or infrastructure of the Internet might have use cases for Kubernetes because they provide infrastructure.

Again, organisations in this category usually have significant resources (see point #4).

#4 You have the people, money, time and resources to run Kubernetes:

Building your Kubernetes infrastructure in your own data center might be one of the worst decisions you can make.

Or it could be one of the best decisions your business ever made because you have specific use cases where you will have to do it, or it is your core business.

Compared to other approaches, you will need to invest in dedicated people with the skills to build and operate your environment (even in the cloud) or on vendors that will do it for you. In addition, your developers will have to spend time learning and understanding Kubernetes. Even if you can abstract away some of this for your developers, some folks will have to understand things like container building and the complexities of Kubernetes networking.

Your users might need you to invest this level of resources to provide the service they expect!

#5 You have a homelab:

A homelab is the perfect environment to run Kubernetes. A lab is a playground where you can safely run experiments, break things, learn and grow.

A homelab environment is perfect for playing with and learning how to use Kubernetes. You can build a "production" environment at home and learn what it takes to operate the infrastructure.

The beauty is that you cannot over-architect your homelab (within your budget limits, of course!).

You might even use the Kubernetes cluster you have built to run services for your home, such as home automation (I use Home Assistant), a media player (I use Plex) or cloud storage (I use Nextcloud).

I have learned much about networking, servers and automation by playing in my homelab.

And believe me, when your entire home can break because of something in your homelab, you will soon hear from your "users". Homelabs are great for learning what works and what doesn't in a mostly safe environment.

Writing a future post on my homelab and its evolution over time might be a fun and geeky exercise.

Of course, your mileage might vary with this advice.

These are my opinions. They won't work for every situation. Furthermore, these opinions sit on other underlying beliefs, such as "focusing most of your resources on trying to provide value to your users" or "picking one cloud provider and going 'all in' on them".

Some of you might disagree or feel I didn't do this subject justice. I would love to hear why Kubernetes was an excellent choice for your organisation.

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.