When kale first hit the supermarket shelves, it was hailed as the king of healthy eating and consumers immediately flocked in large numbers to buy kilos of the superfood to incorporate into their diets. However, without other ingredients or the right recipe, what ends up on the plate can be pretty underwhelming, and in some cases just plain inedible. Recently, I’ve been thinking about the hype around Kubernetes – the superfood of tech infrastructure – as something that followed a very similar trajectory.
Container technology was once the domain of developers. Now, IT operations are taking control, and Kubernetes is out in front. According to VMware’s The State of Kubernetes 2020 report, although it’s early days for enterprise adoption – more than half of respondents (57%) operate fewer than 10 Kubernetes clusters, and 60% run less than half of containerised workloads on Kubernetes – momentum is increasing. Spending on containers is up too, with one in four enterprises now allocating more than $250,000 a year on these technologies.
Global container management software to see major growth — Gartner
So what’s the deal with Kale?
As the adoption of Kubernetes moves beyond the experimental phase, it’s imperative for IT teams to be fully aware of the value added by adoption, before investing millions in container technologies. This can be likened to the hype surrounding superfoods, with Kubernetes often being seen as a ‘fix all problems’ product with massive potential. Similar to superfoods though, such as kale, it’s about how you use it that really counts.
It’s important for IT teams not to rush into buying kilos of Kubernetes – assuming naively it’s the only solution for achieving agility, positive customer experience and innovation. Defining business outcomes before investing time, energy and money is the best approach to maximise investments.
The secret ingredient
It requires more than just Kubernetes to achieve business outcomes, and hype surrounds the technology and term Kubernetes. A lot of false expectations exist too. Some companies may have heard on the IT grapevine that Google, AWS, Netflix, and Microsoft bet on Docker as a container format and Kubernetes as the orchestration engine – that the technology can scale and provide infrastructure at the same level as the big players. Simultaneously they may not be aware that the whole business model of such companies focuses on making infrastructure fluid and immediately available. Regular customers have a very different business model, with solutions based on trusted platforms by trusted partners that have solved virtualisation in the past, and those partners now have solutions to achieve the same outcomes with containerisation.
Of course, Kubernetes technology also has its benefits. Businesses can become more efficient in their use of IT and achieve better results, faster, from development life cycles. They’ll produce better software via more automation and standardisation. Organisations can then use software to explore new business opportunities, experiment with the best ways to profit from ideas, and evolve accordingly. In contrast, a ‘non-K competitor’ will have a harder time evolving software quickly, and the software supply chain will become a bottleneck for helpful ideas they have.
Five DevOps lessons: Kubernetes to scale secure access control
A perfect recipe for Kubernetes
Kubernetes, for all its hype, is still a maturing technology which needs a degree of handholding to ensure successful deployment. It’s useful to build efficient platforms, because it can be extended, and gives good abstractions to interact with containers, scheduling them in an efficient way. But if you think you can simply install it and be productive, you’ll find yourself on a rocky road. You have to train and enable teams. Everything is different in Kubernetes, starting from the declarative definition of how you want your systems to be run, to the way you enable logging and routing on pods.
To make things easier, organisations may want to look at certain tools and existing systems that reduce complexity overall, rather than jump on every bandwagon that, in an architectural context, only adds complexity to an already complex world.
Once large organisations switch over to a cloud native platform for instance, developers can get more productive and create more sustainable streams of software updates. This means that these organisations can start to explore new features and approaches to solving business problems with software, every week. While a week’s worth of code might seem small, it adds up over time to major changes. Best of all, because organisations are testing features out with real-world feedback, changes are validated with data: software is only getting better.
How to design software for remote working
Cloud native platforms also put in place self-service options for development teams and standardise how infrastructure is created and managed. This not only removes a tremendous amount of time-consuming manual work, but also leads to better production resilience and security, because developers can follow a set path and it’s harder to deviate from best practice.
Adopting Kubernetes technology may well be the right way forward for your company – just like incorporating kale into your diet may be better for your health. However, it is imperative to keep in mind that there are many traditional ways to design and run software. This variability adds extra expense, time, and risk to the software process – as years of over-budget, over-schedule, and under-featured software shows. Kubernetes puts in place a way to design and run software, removing waste for you to focus on the actual software, eradicating the hassle of managing it whilst worrying about ever-extending timelines. But tread carefully before you take the first bite!
