Are Kubernetes days numbered?
…and if so — what is the future for containers?
Introduction
As a sequel to my earlier “Are Terraform’s days numbered?” post, today I want to address a different question that Julio Ortega posed in the comments on that post. Are Kubernetes days numbered? For those who aren't familiar with Kubernetes, it has become the leading container orchestration system. If you want further explanation I quite like this tongue-in-cheek Kubernetes for kids video:
For those who are familiar with VMware, the analogy I tend to like is that Kubernetes works quite like vCenter, controlling the placement of workloads (containers rather than VMs) across a distributed cluster of nodes (or hosts in VMware parlance). But under the hood how does Kubernetes actually work?
The ‘Guts’ of Kubernetes
As per the diagram above, Kubernetes has multiple components that form its control plane along with small node-based components which coordinate networking and local monitoring of ‘pods’. I won’t go into more detail than that but needless to say, there are a fair few components that potentially require management. Indeed, if you have been in the Kubernetes ecosystem for a while you have probably heard or even tried Kelsey Hightower’s ‘Kubernetes the Hard Way’ repository, which gives step-by-step instructions on how to bootstrap Kubernetes manually.
Managed Kubernetes
The reality, of course, is that the vast majority of Kubernetes clusters are run in a ‘managed’ way, with the largest hyperscalers having their own flavour, i.e. Google’s Kubernetes Engine (GKE), AWS’ Elastic Kubernetes Service (EKS), and Azure’s Kubernetes Service (AKS). From here on I am going to focus on Google, firstly because I am most familiar with it as a Google Cloud Architect, and secondly because as the original co-authors of Kubernetes, I would argue GKE is probably the strongest managed Kubernetes offering (though I fully appreciate my bias).
Google’s Container Offerings
So at my count, Google has five options for running containers which are:
I’m going to ignore the last two options, personally, I think App Engine Flex has been more or less completely superseded by Cloud Run. GCE with Containers meanwhile is only really appropriate for very small deployments.
GKE Standard vs Autopilot
Right off the bat, there are now two different flavours of GKE. The main difference between these is that Autopilot applies a level of Google opinionation to the cluster and makes node management their responsibility. For a more detailed comparison of the differences, I highly suggest reviewing the documentation. Interestingly Google has recently made autopilot the default option when provisioning new clusters, recommending it for the majority of workloads with a potentially lower TCO as per the diagram below.
I think this is an interesting development where Google is actively encouraging further abstraction and reduced engineer involvement in the operation of the cluster — which leads me nicely to the next offering.
Cloud Run
Cloud Run is Google’s ‘serverless’ container offering where all you need to do is to deploy your container image to the service and Google takes care of everything else. Under the hood, this is all based on the open-source Knative framework that Google has again developed. It must be said that not every workload will function properly within Cloud Run with containers having to abide by a runtime contract. This being said, there have been several recent developments to make it an increasingly attractive environment, such as Startup CPU boost, Always on CPU Allocation, Sidecar Containers, Cloud Run Jobs, Request Concurrency, and no doubt many more things I have missed. In all, the capabilities within Cloud Run make it an increasingly attractive option for a number of services.
Further to all the above Google’s 2nd Gen Cloud Functions make no secret of the fact that they too run on top of Cloud Run (along with Eventarc), with what I can only assume is a Google opinionated container image to run each language runtime that is supported.
So which should I choose?
With this variety of choices, the question quickly becomes what should I choose? As a general rule of thumb, I endeavor wherever possible to push workloads into the most highly managed tier.
Sometimes though I appreciate there is a technical, commercial, or organisational reason why this isn’t possible and workloads may need to be placed into a less managed platform. Increasingly though I think the technical barriers are diminishing with constant improvements being made to GKE Autopilot and Cloud Run especially.
Conclusion
Circling back around to the original question I posed at the beginning of this post:
Are Kubernetes days numbered?
The simple answer is “no”, but I believe with more nuance than that. Increasingly I think the direction of travel is towards an increasingly managed Kubernetes. The reality is that running a cluster as efficiently as possible is unlikely to be a good use of many people’s time; people don’t really want to deal with the additional complexity or get certified as I have previously. None of us should really be surprised - if I want a VM in the cloud I frankly don’t want or need to care how my GCE, EC2, or Azure VM is served from the underlying hardware and hypervisor — why should container platforms be any different?
Anyway, I hope that you found this post interesting and I am genuinely interested to hear your thoughts, it might even spur me to write another post. But until next time keep it Googley :)
About CTS
CTS is the largest dedicated Google Cloud practice in Europe and one of the world’s leading Google Cloud experts, winning 2020 Google Partner of the Year Awards for both Workspace and GCP.
We offer a unique full stack Google Cloud solution for businesses, encompassing cloud migration and infrastructure modernisation. Our data practice focuses on analysis and visualisation, providing industry specific solutions for; Retail, Financial Services, Media and Entertainment.
We’re building talented teams ready to change the world using Google technologies. So if you’re passionate, curious and keen to get stuck in — take a look at our Careers Page and join us for the ride!
