Why Kubernetes Doesn’t Fit in All Scenarios?

Kubernetes is like a colorful elephant. It has so many colors. It’s complex, having so many layers. Everything comes with a price tag; Kubernetes is no different. You need to articulate everything with precision to ripe the exact same fruits you are dreaming about.

There is literally a race to migrate workload into Kubernetes in all scales of teams and companies nowadays. Without taking any measures into account, some companies are migrating all of their products (including the internal one) to Kubernetes irrespective of its user base, team strength, future plans, etc. which seems dangerous. Let’s see why Kubernetes doesn’t fit all situations and what those scenarios are.

Immaturely Chosen

The following are some of the reasons I could think of choosing Kubernetes even if it doesn’t fit the solution.

In the name of global strategy

Most of the company’s global strategies are defined by top architects, technical team and/or CTO team. I have seen many companies declare to migrate everything to Kubernetes in the name of global strategy. They don’t care about anything beyond that, although it’s not beneficial for all of their products to be migrated to Kubernetes.

I think most of the companies are mad behind Kubernetes :). The fruits at the end are more cost, complexity and less benefits out of it.

Blind Modernization

Sometime, in the name of modernization or want to take advantages of Kubernetes without understanding the usage scenario some are migrating to Kubernetes.

After wasting considerable time, they realize it’s not their cup of tea.

Follow the herd

Like famous actor/actress is having fan following, Kubernetes too have fan followings. Because everybody is migrating to Kubernetes, there must be something good everybody is getting out of Kubernetes. Why are we not migrating to Kubernetes?

And the migration proves bizarre. Realized after some time (wasting efforts and money) that, you ended up paying more with no benefits taken out of it.

Considering de-Facto Option

Many architects and developers choose Kubernetes as default option. Of course, regretting later.

Take advantage to compete with the competitor

Sometimes you migrate to Kubernetes to just raise your bar against the market competitors.

And then you start selling those specs to customers/end users, that ohh we are using Kubernetes to make our app/product high availability, do orchestration, fail-safe, scaling, lahb lahb lahb.

But practically it’s not required at all. You can easily run it in VMs or in some other alternatives.

Relying too much on the service provider (consultant/vendor suggestions)

When you consulting a third-party company or consultant, they provide wrong ideas/suggestions/consultancy to migrate to Kubernetes.

Just because they want to look ahead of time, or sell their skills or sell their resources having Kubernetes competencies.

However, in the actual scenario it is absolutely not required at all.

When it doesn’t fit?

You can also take these scenarios as measures to consider before migrating to Kubernetes.

Small team, small product

When the team is small, let’s say 5-15 people and the product is also small it is absolutely unnecessary to migrate to Kubernetes.

When the scope of product is growing you can consider Kubernetes if it keeps growing.

Small and fixed User Base

If the user base of the product is small and fixed, then there is no need to migrate to Kubernetes. If the user base does not grow beyond a certain limit i.e. 2k-5k then serving small traffic doesn’t require Kubernetes.

No scope of growth

If there is no scope of growth, or there is no plan of growing application (in terms of complexity, scale, users, etc.) then it’s worthless migrating to Kubernetes.

Save Cost and Complexity

Kubernetes is no fun, proves complex and costly. So, to avoid it, you can choose other options available. Teams could have built applications with fewer and less expensive tools.

No Expertise

If you don’t have an absolute skillset in your team, it’s preferable not to mess with it. Sometimes, when projects fail postmortem shows wrong tools and plugins chosen to work with Kubernetes.

When to migrate

• When team is growing and is the complexity of application/product
• When user base is growing rapidly, or there is speculation of user growth
• When there is plan to launch app/product in multiple geography or making product global
• When you have existing clusters, and workforce to manage it
• When starting from scratch with big product plans
• When in absolute need of orchestration and ready to deal with cost and complexity
• When you have expertise to manage it

Alternatives

• Nomad by HashiCorp (nomadproject.io)
• Going to serverless options like GCP Cloud Run, App Engine, etc.
• Other fully managed options provided by various Cloud Providers
• Deploy Virtual Machines or GCP Instance Groups
• If you so crazy about Kubernetes but not sure what to do, start with GKE Autopilot mode