Microsoft recently started providing Kubernetes-as-a-Service with AKS (Azure Container Service) much like Google does with GKE (Google Kubernetes Engine). In the near future, Amazon may well be following in their footsteps. Amazon’s anticipated entry into the Kubernetes-as-a-Service arena is important for a number of reasons, not the least of which is the fact that it signals the possibility of better Kubernetes support across the board.
With that thought in mind, I’d like to take a deeper look at what’s happening with Kubernetes cloud services – and what these developments mean for the industry.
Kubernetes-as-a-Service Fits into the Cloud Services Paradigm
Setting up a Kubernetes cluster used to be hard. Really hard. While all the concepts and components were present, Kubernetes was initially a do-it-yourself project with lots of manual steps. Many complicated decisions were (and are) involved – you have to generate certificates, spin up VMs with the correct roles and permissions, run an etcd cluster, choose a CNI provider, install packages, and then build configuration files with cloud provider settings, IP addresses, DNS entries, etc. Add to that the fact that not everything worked as expected, and it’s no surprise that many in the industry were hesitant to use Kubernetes at first.
With tools like kops and kubeadm maturing quickly, getting a highly-available, secure Kubernetes cluster running by yourself is getting easier every day, but as-a-service is the natural evolution of any popular technology. Building custom servers has given way to racks of identical hardware, owning hardware has given way to using hardware, running hypervisors has given way to using hypervisors, and installing software has given way to using software. With the introduction of GKE, Google became the first major player in the transition to offering a Kubernetes cluster as a tool instead of a project. Amazon following suit just confirms this transition is in full swing.
Tools Simplify Processes but Don’t Solve Problems
Having a reliable, manufactured hammer that doesn’t break is objectively better than building a new custom hammer for each nail. Using Kubernetes-as-a-service eliminates the need to manually perform some repeatable front-end core processes.
At ReactiveOps, our core competency is managing cloud infrastructure. We’ve defined standard best practices and in-between tooling, and we’ve open sourced our tools that make use of cloud services to create cohesive, reliable solutions. For the same reason we rely on Google Cloud SQL or Amazon RDS for relational databases, CircleCI for continuous integration and deployment, and PagerDuty for alert and response organization, we embrace Kubernetes-as-a-service implementations like GKE as another excellent tool to help us reliably solve DevOps problems.
However, just as you can’t build a house with a hammer alone, no one cloud tool can solve all your business problems by itself. For example, monitoring and understanding problems and reacting when your app isn’t working the right way are critically important tasks that require expertise. Kubernetes helps you monitor your app, but it doesn’t set up monitoring and alerting for you and it doesn’t know anything about the rest of your infrastructure outside Kubernetes.
Using Kubernetes the right way also requires a hard-earned expertise like any tool, as Kubernetes has its share of esoteric processes and elements. That’s why setting up Kubernetes is only a small part of what a DevOps-as-a-Service team does. You have to be able to get your app into Kubernetes, automatically scale it, and update it with zero downtime. You have to be able to use the tools the way they were meant to be used so that you’re not hammering screws or sawing nails.
A Word of Caution
Amazon’s upcoming release is a good thing for the entire community, and we at ReactiveOps are excited about the possibility of having better AWS tooling. It’s important to remember, though, that the transition won’t necessarily be a smooth one. For a while now, Amazon’s ECS container service has been trying to do some of the things Kubernetes does – with mixed success. ECS use has posed significant challenges for DevOps teams to date. Beyond that, those who are unfamiliar with Kubernetes don’t always know what hiccups to look out for.
At present, AKS isn’t as robust as GKE, and in all probability, Amazon’s product won’t be either. (I’m sure that comes as no surprise, as Kubernetes is Google’s technology, and they know it best.) At ReactiveOps, we know how to support not just GKE but also AKS and Amazon. We’ve been running Kubernetes on Amazon and Google for a long time. We know what to expect from a Kubernetes as a service offering. This expertise enables us to make key decisions to support both the technology and the teams that use it. More to the point, our tools and expertise can and will compensate for any functionality that’s not built into Amazon’s Kubernetes offering while also optimizing the functionality that is included.
The Continual Evolution of DevOps-as-a-Service
Back in the day, ReactiveOps did DevOps work using a variety of different tools. As Kubernetes has quickly matured, we recognized its exceptional capabilities. Today, all of our DevOps processes take advantage of the capabilities Kubernetes offers. However, the truth is that the technology and tools may change in the future. And when they do, you’ll still need to get code into production reliably and monitor it while it’s in production. That’s where a DevOps-as-a-Service partner comes in.
With GKE and AKS in the picture and Amazon’s tool coming soon, DevOps-as-a-Service will play an even more critical role than ever before. While you may not need your DevOps partner to stand up Kubernetes for you, in today’s fast-paced marketplace you can gain substantial benefits by working with a partner that can move your apps to Kubernetes, manage the complexities of deploying apps in Kubernetes and monitor continuous integration and deployment.
The better Kubernetes services get at automating foundational cluster setup, the more intricate the business problems we at ReactiveOps get to solve. That means everybody wins.