Kubernetes has taken over the container orchestration world ever since its introduction in 2015. According to a 2020 CNCF survey, 91% of people are using Kubernetes, with 83% using it in production. For anyone still unsure: Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. The term has garnered so much buzz over the years that it seems virtually synonymous with containerization.
In another post, we outlined some of the biggest benefits of Kubernetes — including scalability, resilience and security. But it's not going to be right for every application or every organisation, no matter how big the benefits or the buzz.
To use Kubernetes or not use Kubernetes? That is the question…
Here are five of the clearest signs that the time isn’t right for your organisation to make the move to Kubernetes.
Kubernetes was created to solve a particular set of problems. Specifically, the automated deployment, scaling and management of containerized applications. It has a complex set of options aimed at one thing: high availability.
Redundancy is part of Kubernetes’ design. Even the minimum recommended configuration (more on this later) is built for high availability. Of course, you can always add additional layers of backup ... but Kubernetes already supplies you with a highly available architecture.
Properly administered, Kubernetes is exceedingly good at achieving high availability. For many applications that only see traffic during normal business hours, this isn’t really necessary. So if your applications do not need 'five nines' of uptime, Kubernetes could just be overkill.
What is meant by ‘monolithic’? Calling an app a monolith implies that there are multiple processes at work doing multiple tasks at the same time in the same executable code. It's a single executable unit that is indivisible. Code changes for one component mean the entire application is rebuilt and redeployed. It's simple to build and debug but doesn’t scale well, and it's also tough to make changes as the application gets more complex.
Kubernetes, on the other hand, requires application containerization. It is the opposite of monolithic. It means breaking large applications down into smaller services that work together. Each container is actually a package that includes everything needed to run that chunk of code (libraries, binaries and more). This allows the components to be developed, managed, and scaled individually. The most common containerization framework is Docker.
While it is possible to have a monolithic application in one container, the container would require multiple processes. This isn't considered good practice — one container should only house one process.
If you are not containerized, then Kubernetes is not for you ... yet.
Should you refactor your application to be containerized? Maybe. But ask yourself this: Do I need an entirely new infrastructure just for this one application? If the answer is ‘no’, then maybe you should consider alternatives to Kubernetes.
Kubernetes has a steep learning curve. Like, climbing-a-mountain steep.
You will have to conquer a metaphorical Mt. Everest of Kubernetes-specific learnings, from network and security policies to how to harness containers, to reach the summit of effectively leveraging its power.
Not only that, but it takes a village. You will need to cultivate a kind of priesthood in your organisation to fully take advantage of all of Kubernetes’ capabilities. If you’re unwilling or otherwise unable (we’ll get to that) to spend a lot of time re-educating your staff on all these things, you might want to turn around..
There should be a clear signpost: Your entire working culture has to change to adopt Kubernetes, and anyone making the move needs to be fully prepared for that change.
So there’s some learning to be done, but it’s relatively cheap to start playing with, right? Maybe we can learn along the way?
Wrong. While Kubernetes itself is open source, the process of adopting Kubernetes for your organisation will be expensive. Here’s what that looks like: All of the redundancy and resiliency offered by Kubernetes itself is accomplished by creating a large and rather expensive infrastructure as a starting point.
For example, if you want a fully redundant cluster, the minimum recommended requirement is six nodes (i.e. virtual machines). By definition, you will have a lot of capacity doing nothing but being a hot standby in case of failures. Are your applications important enough to justify that overhead?
There are also things like implementing solid CICD pipelines or supporting a multi-cloud if you’re using more than one cloud provider. It may be that it ends up costing so much, that it really doesn't justify running your applications on it.
If, for example, you only have a couple of applications that aren’t mission-critical then the cost of a Kubernetes infrastructure probably isn’t justifiable. On the other hand, if you have several containerized applications that are mission-critical, then Kubernetes could be the answer.
The need to upskill and educate your teams only teases the true complexity of Kubernetes. Lastly, the sheer complexity of Kubernetes is so overwhelming some organisations decide not to pursue it.
Cloud providers have attempted to mitigate the complexity of K8s by offering managed Kubernetes, which removes some of the heavy lifting and responsibility of setting up and maintaining Kubernetes clusters.
But the problem with leaning too heavily on the cloud providers is that managed Kubernetes offerings still require a working knowledge of the underlying cloud infrastructure in order to fully take advantage of them. If you’re lacking that integral knowledge in the team, you’re left with one complex system inside another. And if you’re using more than one cloud provider, it just compounds the problem.
We’re early adopters of Kubernetes and have been on quite a journey with it! Naturally, we’re big fans and have seen first-hand the benefits it brings [link]. But we also have experienced all of its complexities ourselves. It’s why we set out to make Kubernetes less complicated in the first place: to help enable enterprises to harness the power of cloud and Kubernetes without the pains.
Our Professional Services team can work with you to refactor and containerize your applications. And our flagship product, Wayfinder, is a cost-effective solution that automates the complexities of Kubernetes cluster management so that your teams don’t need to climb Mt. Everest of endless Kubernetes upskilling and education.
If you’re going to get into Kubernetes, know exactly what you’re getting into and how to make it as easy as possible.
Already using Kubernetes? Take our free Kubernetes Risk Assessment to make sure your implementation is secure.
