Let’s be honest. As InfoWorld recently humorously put it, “no one wants to manage Kubernetes anymore”. And with all frequent updates, it’s an ongoing one, too. You could go with a managed Kubernetes service from a cloud provider, but those are not for everyone. Because while the Kubernetes part is cloud-agnostic, the rest of their platform locks you in: log handling, monitoring, identity management, to name a few. But that’s the traditional way of consuming a managed Kubernetes service.
In this article, I list five reasons why it’s time to challenge that status quo, and what a cloud-agnostic managed Kubernetes service both can and should be.
Open source Kubernetes distributions, offered as managed services
First of all, what is a cloud-agnostic Kubernetes service based on? There are many open source Kubernetes distributions, most of which of course are sponsored by a company that makes a business around it. Such distributions typically include not just Kubernetes itself, but also come at least with systems for monitoring, logging, and authentication built into the platform. The companies that offer such distributions often also offer a managed service based on their platform.
What are the benefits of using a cloud-agnostic managed Kubernetes service? Great question, dear reader! Using a cloud-agnostic managed Kubernetes service comes with a whole slew of benefits, the main ones being that you:
1.
Ensure business continuity by letting a managed service provider handle your Kubernetes-based platform
Let’s think about this. How many Kubernetes administrators do you have? To offer a 24/7 service in a humane way, you need to rotate responsibility and on-call duties. This means that you either need a half dozen people, at least, so they can have something resembling a work-life balance. Many smaller organizations don’t even have that, but rather just one or two people that “know Kubernetes”. That is a liability and risk to your business. Instead, a managed service means you’re not dealing with these questions, and can instead focus on your application. Redundancy, staffing, and business continuity are all taken care of.
2.
Increase ability to target new markets, even ones that require you to run on-premise (or just not at a major cloud provider).
The GDPR and Schrems II kerfuffle could imply that you all of a sudden need to find an EU-based cloud provider for your application. Or, to win huge contracts in certain industries such as healthcare, you may have to deploy your application in a specific cloud or on-premise. And if you do, you certainly don’t want that environment to feel like a second-class citizen, from a deployment or operational standpoint. Choosing an open source cloud-native tech stack means you’re as agile as it gets. You can target new deployment environments, even on-premise ones, and even ones with smaller EU-based cloud providers.
3.
Increase process efficiency and minimize risk by reducing tool sprawl - in spite of deploying to multiple clouds.
The services you use inevitably require processes and supporting tools to manage. Cloud vendor specific ones means you have to learn the specific ways of managing your deployment using cloud provider X, Y, and Z’s tools. But with just a single Kubernetes-based platform that works the same regardless of underlying cloud, you are simplifying by unifying. Your tools and processes are the same, regardless of how many, and how different, cloud or on-premise environments you are deploying your application to.
4.
Make migration much easier, because not just your application, but also your platform, is cloud agnostic.
Being locked in to a particular vendor is never a good idea. Because when you look at it, it is a business relationship where the other side has all the cards. Your ability to migrate makes the relationship less one-sided. I know, perhaps you are not targeting multiple clouds today. But there is a reason why you chose Kubernetes and to containerize your application. That very same reason also applies to your platform. The CNCF Landscape is full of great software that helps you become truly cloud agnostic. You can even easily get highly scalable message queuing systems such as NATS or MySQL-compatible databases such as Vitess up and running, so you never need to feel like you’re missing something from the managed platform services of the major cloud providers.
5.
Contribute to the cloud native community by being the community.
There are close to a thousand projects in the CNCF Landscape, and the way we know what software is of interest to the community is by the community being active. So by using the software, reporting issues, adapting it to our use cases, we make sure that awesome software becomes available for everyone. In this way, we all benefit.
Summary
If you are deciding whether to “buy” or “build” the Kubernetes platform upon which your application is deployed, there are many strong reasons why you would want to buy. Have a managed service provider do it for you. Cloud providers offer managed Kubernetes services, but those inevitably lock you into the cloud provider’s other services. But by choosing a managed Kubernetes service provider not tied to a cloud provider, you get a platform that is more portable, able to cope with future needs, and is entirely cloud native. And it comes with all the benefits and awesome software from the community you would expect.
