So, Why Kubernetes?

The hidden reasons that drive technology adoption. #

Kubernetes has become popular as an all-in-one solution for managing microservices by including essential components such as service discovery, network policies, horizontal scalability, secrets management, and so on in the same place. For many organizations, all of these fancy features may not be essential, and in many cases, their current stack already covers most of their needs. However, for many companies, the adoption of Kubernetes is rarely driven by business needs or the need to solve scalability issues, but rather for less expected use cases.

I worked for a company that was happy with their existing stack, which was a monolithic application running on a few EC2 instances. However, in order to accelerate their end-to-end testing, they needed to automate the creation of ephemeral environments for each pull request. Achieving this with a classic virtual instance model would require dynamically provisioning EC2 machines, ensuring that code is deployed in a systematic way, and automatically setting up communication with other services such as load balancers. Orchestrating this can quickly become a challenging task, and other platforms are better suited to cover these scenarios.

Among the existing solutions that could achieve this, Kubernetes was the most pragmatic, mainly due to its large community that has proven the solution to be effective in a variety of contexts and has also produced a large amount of online documentation. That said, it’s plausible that a different and less popular container orchestrator might be better suited, and following the hype isn’t always a valid argument for adopting a technology. But in the case of Kubernetes, having a large community can dramatically improve learning time and reduce the amount of effort required to deliver an operational solution. In addition, from a hiring perspective, using a widely adopted technology weighs heavily in the decision, because in many cases, not being able to scale your engineering department due to a lack of competency can be even worse.

An important caveat to using Kubernetes is the significant operational cost, which is often overlooked. Many organizations underestimate the amount of work required to define full-stack observability, configure the network component, and manage cluster upgrades, not to mention knowledge transfer. In some cases, a portion of these technical aspects can be abstracted away with even more highly managed solutions, but this trade-off often comes at the expense of a solution that ultimately fails to solve the original requirements due to the limitations that come with oversimplification.

Kubernetes is far from the only example of organizations adopting cutting-edge technologies, only to end up using a small portion of their functionality. However, the underlying reasons for adopting Kubernetes don’t always align with what the product is intended to solve from a technical perspective. Sometimes, migrating a monolithic application to a more complex architecture, even if it doesn’t fundamentally add value in terms of scalability of business needs, can still be more effective than solving a specific technical challenge with the legacy architecture by reinventing the wheel, and from a hiring perspective, the value of using a widely popular product is often dismissed.