![](\"https:\/\/i0.wp.com\/d1v1e13ebw3o15.cloudfront.net\/data\/91172\/pool_and_spa_logo\/..jpg?ssl=1\")
<\/p>\nIn a recent text exchange with a colleague, autocorrect changed \u2018Kubernetes\u2019 to \u2018Uber Eats\u2019. At first, this was amusing, but then it got me thinking that there are many parallels between the food delivery service and the container orchestration platform.<\/p>\n
For one, the popularity of Kubernetes has skyrocketed in the last few years. And, like Uber Eats, it has become the platform of choice. Kubernetes is now the go-to for deploying new enterprise applications, including the current surge in AI apps only expected to increase in the coming years. This future state is just around the corner, but while we prepare, enterprises will continue to run existing apps atop existing virtual machine architectures. The golden ticket will be finding a way for Kubernetes and virtual machines to co-exist.<\/p>\n
In just over a decade, Kubernetes has gone from a pioneering, almost experimental container orchestration platform into the leading deployment method for new applications in enterprise IT. According to the Cloud Native Computing Foundation\u2019s 2024 survey, four out of five organisations already use Kubernetes. Among these self-identified Kubernetes adopters, about 40% of their new apps are using Kubernetes; a figure that\u2019s expected to increase to 80% within three years.<\/p>\n
That\u2019s as close to universal as you\u2019ll find in the enterprise IT industry. But unlike other industries, even new technologies have to compete with the ones that came before them. After all, Uber Eats still has to compete with in-house delivery services. For Kubernetes, the number one rival remains the virtual machine (VM).<\/p>\n
Virtual machines are a 2000s baby, coming onto the scene to separate the operating system from the underlying hardware, enabling workloads to move and scale independently of the hardware. VMs gave organisations operational advantages at the server level, but they didn\u2019t fundamentally alter the way applications were developed and shipped. Developers still frequently require manual labour for testing and deployment.<\/p>\n
Later, containerisation came in and changed the game. It allows developers to build a standard environment only once \u2014 testing it to ensure compatibility, keep code changes, then clone it for repeated downstream use and relieving developers from the manual task of creating separate environments.<\/p>\n
Once developed, these containers can then be copied and deployed, while running within a management system. For developers, this significantly reduces the time needed for integration and testing work, simplifying the process of scaling applications. Some of Silicon Valley\u2019s darlings were Kubernetes adopters: the likes of Google, Twitter and Airbnb could innovate faster and scale further than they could have using VMs.<\/p>\n
While cloud-native computing is considered the default for most organisations today, it is sometimes at odds with existing tools, including VMs. Over the past 20 years, enterprises have invested billions of dollars into developing enterprise apps in VMs. Unsurprisingly, they\u2019re not going to rip them out immediately and replace them with cloud-native computing \u2014\u00a0at least not without considering how the depth of investment can be repositioned.<\/p>\n
This doesn\u2019t mean they won\u2019t use cloud-native architecture for new developments. It simply means that existing applications are likely to continue running on VMs, which means that VMs and containers will have to work together \u2014\u00a0just like Uber Eats has to coexist with other delivery partners, even if it is the most popular platform.<\/p>\n
Kubernetes and VM architectures need to coexist in order for modern enterprises to function efficiently \u2014\u00a0and they can. With the right platform choice, Kubernetes and VMs can actually both live on the same industry-standard x86 machines.<\/p>\n
Many organisations run each environment on separate physical machines, but if you can run them together, why wouldn\u2019t you? VMs and Kubernetes can coexist on the same hardware, and this actually brings several benefits. This includes better hardware utilisation, improved management, integration, security and easier troubleshooting.<\/p>\n
There are two ways to combine virtualised and containerised workloads on the same hardware: either run Kubernetes within VMs, or run VMs with Kubernetes on bare metal using unified development platforms.<\/p>\n
For organisations considering a coexistence strategy, it\u2019s important not to rush the process. A gradual transition enables IT personnel with VM skills to continue managing environments while upskilling for Kubernetes. Running Kubernetes in VMs gives companies the benefit of having an enterprise solution for VMs alongside a pure, cloud-native solution for containers. It also opens the doors to the full scale of Kubernetes features.<\/p>\n
| \n The benefits of Kubernetes are clear \u2014\u00a0so obvious in fact that they evidently represent the future of enterprise IT. Companies continuing to build Kubernetes environments need to take the time to consider the right approach for their enterprise, because it may be the difference between being compressed by the Kubernetes-VM transition or leading the way to more efficiency, using existing clusters.<\/p>\n While Uber Eats didn\u2019t invent the concept of food delivery, it did revolutionise it. Likewise for Kubernetes: those who don\u2019t embrace it will be left behind by their competitors.<\/p>\n<\/td>\n | ![\"\"](\"https:\/\/i0.wp.com\/d2emomln4apc0h.cloudfront.net\/assets\/620405\/web_image_article\/Daryush_Ashjari_-_Oct_2023_-cropped.jpg?ssl=1\") <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n |