Spend a few minutes with one of our Red Hat technical experts, Matthieu Rethers, as he discusses the advantages and disadvantages of managed clusters, as well as differences between them on various cloud platforms, when you should use them, alternatives to managed clusters, and how Red Hat OpenShift fits into the picture.
When should developers use managed clusters?
That’s a moot question for developers because, from their point of view, it’s always managed whether it’s by your organization or an IaaS vendor. But, I’d say that a developer’s main goal is delivery, so anything that helps them do that faster is golden. It’s the same reason why we don’t program in assembly anymore – we’ve built these abstraction layers so we can focus on differentiators and business value. Plus, I don’t think many developers under pressure want to spend weeks learning how to deploy a Kubernetes cluster, so for them, managed is definitely the way to go.
Many have already learned to trust IaaS vendors with their hardware for the infrastructure folks, so software is the next logical step. A managed service: 1) gives them the ability to get familiar with the technology and form their own opinion over time, maybe to the point where they would feel comfortable taking over; 2) reduces their capital expenditures; and 3) allows them almost immediately, to focus on other critical things like automation, security, reliability, etc.
As far as I’m concerned, I’ll always recommend the managed approach first and then evaluate it. But I’ll admit, there are times when having complete control is a requirement – but remember that managed doesn’t mean sealed either. You can still configure a lot of things on your own.
What are some pros and cons to leveraging a managed cluster on Amazon EKS, Google Kubernetes Engine (GKE), and Azure Kubernetes Service (AKS)?
Like with any managed service, you get many benefits right out of the box. An organization that’s new to Kubernetes can be productive immediately. If all you want to do is run a few Java services on your cluster, and you’re told it will take two weeks before you can actually publish them in a production environment, you might reconsider using containers for the time being. To be fair, installing Kubernetes has become much easier over the past couple of years, but any production workload will have requirements beyond basics, and you’ll lose that initial momentum.
If you’re new to the cloud, these managed services will allow you to skip a few steps and focus mainly on Kubernetes. If, on the other hand, you’re already using a cloud vendor, it will feel like using any other service. Now, if you’re wondering about a self-managed cluster on-prem, it’s going to be a bumpy ride – I wouldn’t even consider it an option if you’re trying to get into containers quickly.
Miscellaneous advantages of managed services include:
- Cluster upgrades
- Prescriptive approach
- Easy provisioning (EKS now integrates with Fargate but watch for limitations like storage)
- Integration with other vendor services
Now the big concern should be vendor lock-in. Because Kubernetes is very flexible, there are several choices that vendors have to make to deliver a production-grade service, so if you don’t like those choices in the future, it might not be easy to go back to a self-managed cluster or transfer to a different vendor. You’re also at the mercy of the vendor for upgrades and features availability – most of them will be behind and provide only the most common denominator, and that’s understandable. For non-greenfield situations, it might not even be a good fit, to begin with.
Are there major differences between how managed clusters work on these platforms?
Unlock Your Potential with Application Modernization
Application modernization is a growing area of focus for enterprises. If you’re considering this path to cloud adoption, this guide explores considerations for the best approach – cloud native or legacy migration – and more.
There are some differences, as vendors will try and set up Kubernetes clusters in a way that can integrate with their other services, and that’s a good thing – that way, it’s a one-stop-shop for all infrastructure needs. They run different versions of the engine and features and bundle features differently depending on the point of view and best practices. Make sure you’re comfortable with those choices because, as I said before, once you’re committed to a vendor, it might be difficult to change. Of course, if you’re currently running IBM or Microsoft products, they make it a lot easier to transition, so that’s certainly something that will weigh heavily in the balance. Most IaaS have free tiers – I strongly recommend trying before you buy, and sometimes, it just comes down to feelings.
What alternatives are available to managed clusters?
Kubernetes is becoming easier and easier to install and supports a wide array of deployment options from bare-metal to virtualized environments to the cloud, so self-managed is always an option.
For greenfield applications, you won’t have to deal with all the constraints of a pre-container era, and you should be able to get started quickly. If you have a lot of legacies to deal with, things might get a little dicey.
Now, if you’ve already invested a lot in your bare metal infrastructure, self-managed is a good way to leverage it and squeeze the last drop off of your machines. If you’re lucky and already have a solid virtualized environment, you’ll have a good head start.
Where does OpenShift, a container platform, fit into these other options?
OpenShift is an enterprise platform from Red Hat that runs Kubernetes at its core. I like to think of Kubernetes as Tony Stark and OpenShift as Iron Man. You have the awesome brain, but suit up, and now you can go and blow up giant alien ships in distant galaxies.
As I explained before, Kubernetes alone isn’t enough – you need security, networking, logging, monitoring, integration with your cloud infrastructure, etc. Most of the time, you get some form of that through the managed service in IaaS, but you’re confined to the vendor’s boundaries.
OpenShift delivers all of that and more but in a cloud-agnostic fashion. You can also run it on your own infrastructure on-prem or in the cloud. Because all of those features are encapsulated inside the cluster itself, you can easily move your entire infrastructure from one cloud to another, and you can do multi-cloud. The main advantage is you only have to learn it once and apply the same principles everywhere you go.
Remember that cloud providers are ultimately not in the software business. They typically use tools built by other people and package them in a way that helps them sell more infrastructure services. That’s great, but Red Hat’s focus, on the other hand, is to deliver a great tool regardless of your environment, and their long-term commitment to Open means no lock-in. As a matter of fact, many OpenShift enhancements make it back to the upstream Kubernetes project and eventually to EKS, AKS, and others. It’s very telling that all the major cloud providers now offer a managed OpenShift service as part of their catalog.
By the way, the reasons to go managed are the same as the ones listed above, but OpenShift comes with a lot of options right out of the box, so the learning curve isn’t as important of a factor if you decide to go self-managed. In the cloud, upfront costs will be higher than EKS, GKE, or AKS, but OpenShift licensing is probably a drop in the bucket for most organizations, starting at about $20k when you bring your own infrastructure. When you consider what you get in return, this should be a no brainer (one study shows ROI over 500%) – this is the enterprise platform.
Any final thoughts?
Just know that running any Kubernetes cluster at scale on your own is no walk in the park – don’t be fooled by the apparent simplicity of that “hello world” video on YouTube. Sure, you can get a cluster running anywhere quickly, but there’s a lot of stuff to consider to go from that first service to running anything in a production environment.
There’s a reason why vendors can charge a premium for these services. Unless you already have a team of experts in Kubernetes (and I’m assuming you wouldn’t be reading this if you did), count on spending a lot of time and money getting up to speed. It’s sure to be way more than a managed service subscription, and if things go wrong, you’re on your own.
So, if there is any chance you can go managed, please do. Our team of experts is here to help you.