Why Should You Take Kubernetes Seriously In 2024.
Realisations after ignoring it till now.
I have always believed in the power of Kubernetes when it comes to managing large workloads for large organisations. However, I am a natural critic, and this virtue drove me toward other directions where I started searching for “options”. And there indeed are a few other ways to do what Kubernetes can do. So after travelling the world, I have come to the conclusion that Kubernetes is here to stay and it shines different. Here, I elaborate on a few factors of my personal analysis on why you should take Kubernetes seriously if you haven’t yet.
How to skip Kubernetes and the guilt.
I have always been fond of exploring new technologies. Thus, when I came across K8s in 2016 for the first time, I did attempt to explore it then. Soon I found out there were so many concepts, features, and strategies to learn. Moreover there were things beyond documentation, which we could only grasp with experience. I liked the technology then, but it did not make sense for me to invest time dedicated only for Kubernetes.
In the following years, I did work on few more projects involving Kubernetes but the same attitude was carried forward. During this time the serverless domain had started to heat up. The buzz around “how cost-effective the serverless technology is” had just begun. There came a point where I thought why can’t we do the deployments the serverless way? Why do we have to be good at K8s?
Being good at Kubernetes is not a joke. It does require dedication. You may work full time on provisioning and managing Kubernetes clusters for a couple of years, and still feel lost.
Or even better, if money is not a problem, then why not stick to the basics? Let’s spin up auto-scaling capabilities and buy a few reserved EC2 instances with load balancers, and we are good to go right? So with such thoughts, I only learnt Kubernetes “when required” in the projects, and focused more on alternatives instead.
It was only in the 2nd half of 2023, I could conclude that nothing beats Kubernetes and had to dedicate my time to learning the same in greater details and more focus. At the same time, I have been thankful to all the “when required” learnings, which in my opinion are significant and unorganised.
What’s wrong with non-Kubernetes methods?
Generally, a lot depends on the kind and scale of the workload you want to run. Based on this information there are a couple of options as mentioned above.
Deploying the workloads on EC2 instances in an auto-scaling group, behind a load balancer is a traditional way to do it. But it comes with it’s own complexities with respect to provisioning of EC2 instances, making them part of the auto-scaling group, placing them in appropriate subnets, paying for the unused capacity, and not being able to go multi-cloud.
Agreed, that Kubernetes has a steep learning curve and setting up a cluster can be a bit of a complex task. Additionally adopting containerisation and the associated DevOps practices can add up to this initial effort.
But once done, its abstraction offers flexibility and scalability with minimum efforts. It abstracts away the cognitive load required while thinking about managing new workloads with varied resource requirements.
On the other hand, serverless sounds quite promising in theory. You may even feel the same way for initial few weeks when traffic is limited. But the cost-effectiveness fades away during peak traffic, when compared to Kubernetes. Serverless also has other not-so-minor issues like cold starts, and there has hardly been any ideal solution around for them.
Writing web applications for serverless architecture also involves utilizing multiple other services, which require learning. More services also mean more elaborate pricing model. If not given enough attention, it can cause unintended cost implications.
Why does Kubernetes make sense?
To answer this simply - Kubernetes provides the much needed optimisation on all fronts at higher scale.
Working with traditional methods or serverless is completely fine, but with conditions. In terms of cost, if the incoming traffic is not very high, a serverless setup can be very very cost-effective and efficient. The same amount of traffic if served with EC2 instance will accumulate a lot of unnecessary EC2 instance costs.
On the other hand, serving high traffic on serverless deployments will soon reach the billing limits and will tend to uncover hidden costs in an unpleasant way. One should remember - refactoring serverless apps to containers or executables, and vice versa also involves some effort. Auto-scaling group might sound a better option for high traffic, but it is not the most optimum solution either.
With the experiences I have had, I can say for sure that all the capabilities offered by Kubernetes make the most sense in these contexts. Kubernetes might not be the right choice at the beginning, but I will always choose the same for it’s long term management and maintability aspects.
When does it make sense to use Kubernetes?
The previous sections highlight the fact that it might not be right for small applications and might not financially make sense at the beginning. Kubernetes is definitely not a solution if you are looking at a couple of USD 1000 in monthly revenue. In such cases, I would still stick to which ever non-K8s approach I have been using till now.
It is important to understand the relationship between the revenue and the costs associated with running a Kubernetes cluster. With this understanding we get a better clarity of the pivot point. Now, depending on how you run your business, you may have this clarity from day 0, and if thats the case and you are sure you will generate enough revenue that overshadows the costs to run K8s - then by all means, go for K8s from day 1.
However, for smaller applications, applications with lesser traffic, non-critical applications, there is either no revenue model attached, or has a very small revenue. Then K8s might not be the right choice here.
Lets assume that you are not sure about how a specific application/business would grow, and you decide to go the non-Kubernetes way. First, this is completely fine. Second, keep an eye on economics related to Kubernetes. Periodically ask this specific question to yourself - How much would it cost to run all of this on K8s? vs. How much is it costing you right now? That would give you an idea about when to make a switch with a sufficient runway.
Industry demand and influencing factors
Lastly, I am not the authority to preach all of this. Looking at the industry, the job openings, the fact that every major and minor cloud platforms offer Kubernetes as a service - it is clear that Kubernetes has proven its importance time and again.
Some of the crucial factors to think about Kubernetes success are listed below. Feel free to read further on these topics.
Strong community support
Rich ecosystem of K8s related products
Benefits offered by containerisation
CI/CD flexibility
Microservices architecture
Ease of scaling
Reduced operational overhead
Vendor lock-in
Conclusion
So 2024 indeed is the 2nd best time to dedicate some time to learn Kubernetes and add this valuable skill to your Cloud and DevOps resume.
Sumeet N.