Kubernetes is a standardised, open-source program for managing containerised workloads and programs. It is claimed to be many things – and has a great many fans in the tech space, and for good reason.
It has a whole raft of benefits. It is incredibly efficient, improving workloads and response times across broad IT infrastructures, and ultimately resulting in more portability (although not a cure), shortened software development cycles, and reduced cloud-data consumption. Naturally, this in turn leads to quicker and cheaper IT projects.
According to a 2021 study by VMWare, 95% of respondents reported clear benefits from using Kubernetes, with 56% choosing resource utilisation (56%) as the main advantage, and 53% pointing to shortened software development cycles.
Despite this clear show in confidence in this open-source tool, not every business will find it a cure-all solution it is hyped up to be. Kubernetes architecture is a good fit for web-scale organisations, and there is no doubt about that – trust me, I am certainly an advocate. However, to recommend it all businesses is not fair or accurate – it may simply be overkill. After all, there is a reason that Google, Spotify, Airbnb, Tinder, Reddit, and many other giant web-based organisations use it.
It favours large deployments
It is not easy to configure manually, monitor or optimise. Its preferred and default settings are automated, and doing things any other way is not easy. These setting favour larger scale deployments who wouldn’t configure individual workloads manually anyway. This again becomes an issue when it comes to monitoring.
For example, if servers in a cluster were running at 25% capacity, it wouldn’t tell you – meaning you are wasting money on an over-provisioned infrastructure. Again, as this is an issue that gets more problematic the smaller your organisation and IT system is, it favours the bigger players.
It is very complicated
Firstly, it is fractured, and comes with many parts that aren’t considered simple to put together and utilise. Although a slightly chaotic development may be characteristic of open-source projects, this one, unlike others, lacks a streamlined way to control it. Your typical Linux distribution consists of many different pieces of software too, but unlike Kubernetes, you can install and manage all of them in a more centralised way.
Furthermore, these different parts in other open-source softwares are more similar than they are different. For example, Red Hat and Ubuntu are different, but similar, whereas if you wanted to go from OpenShift to VMware Tanzu (both within Kubernetes) you’d face a significant amount of learning to do. Not ideal for a one-man-band IT team.
Secondly, it runs purely on code. Every input need unique code written, specially augmented for each purpose. Again, this isn’t an impossibility, it is just a lot of effort, skill and time spent – so naturally benefits large-scale uses and users that have time, expertise (and ideally a whole team) dedicated to it.
Do you see a pattern here? Ultimately, Kubernetes requires a certain level of dedication that is just not worth it unless the pay-off is significant, or the infrastructure impacted expansive. This means that its complex nature can cause problems concerning one’s local development environment, which could then impact productivity throughout the business.
Yet, it is a brilliant thing
However, by no means are these limitations a criticism of its brilliance. In fact, Kubernetes, when used in the appropriate context, and with realistic and relative aims, can work wonders for businesses looking for cost-effectiveness,
If you were to look back three or five years ago it would have been a bold move to thrust Kubernetes into operations. Back in those times, it was an unknown with a lot to prove, but today, this could not be further from the case – with hundreds of thousands of IT teams using Kubernetes daily within their operations.
