All signs are pointing to Kubernetes becoming the defacto standard for container orchestration platforms. Let’s say you’ve done your research, and you know you want to use Kubernetes as your container management system. All well and good. You also know you have two main cloud hosting options: Amazon Web Services (AWS) and Google Cloud Platform (GCP). Amazon’s the obvious choice, as many developers have limited exposure to and experience with GCP and Google Container Engine (GKE).
However, if you want to run Kubernetes on AWS, you have a lot of work ahead of you. If you’re looking for container-based workflows, GCP will make Kubernetes a lot easier to manage and keep up to date. Since Google created Kubernetes, GKE basically gives you a Kubernetes cluster out of the box. In other words, rather than setting up Kubernetes on AWS there’s a better option: letting the people who built Kubernetes also host it.
Let’s start with the premise that it’s better to run Kubernetes on GCP than on AWS. A reasonable question to ask is why – what’s the difference?
The easiest answer is that Google has a hand in developing Kubernetes, so Google supports new Kubernetes features automatically and faster – sometimes much, much faster – than other cloud providers. Google Container Engine (GKE) supports the latest and greatest versions of Kubernetes sooner than other cloud providers.
If you know you want to use Kubernetes, then you’ll probably spend less time and money setting it up on Google than on AWS. Let’s look at what this means in real terms.
Closed vs. Open Source
Amazon EC2 Container Service (ECS) is basically Amazon’s attempt to build a container cluster. It’s entirely closed source, whereas Kubernetes is entirely open source. You can see who’s developing Kubernetes (and what they’re developing), and you’re not locked into a cloud provider (AWS or Google).
Uncommon vs. Familiar Paradigms
Amazon has home-baked their own container cluster software, and the skills you’ll need to build when using ECS are different than those used on other platforms. ECS is basically a hodgepodge of Amazon’s other services glued together, meaning it’s neither robust nor architected in a way that makes it easy to use on production workloads.
The skills you develop with Kubernetes can be applied to a number of other products and systems, whereas the skills you build using ECS are very specialized and not applicable to most of the other work you do. As a result, running either ECS or Kubernetes on AWS will require a lot of manual effort, and you’ll need to jump through quite a few hoops.
Automation vs. Manual Effort
Along those lines, if you want to use Kubernetes, GKE shortens the learning curve considerably because Google sets up its baseline functionality for you. With GKE, you can turn on a Kubernetes cluster and be up and running in 10 minutes, whereas on AWS you have to do a lot of work to understand how to set up the cluster, what tooling to use and how to build the new cluster when you’re ready. You’ll also have to troubleshoot any issues that arise and then be able to assess if the cluster is up and running the way you expected.
GKE eliminates these time-consuming steps. Just tell GKE some basic things about your cluster, and it will automagically bootstrap your cluster for you. GKE saves a ton of headache and time in the actual creation of the cluster, and you can actually start deploying applications on the cluster quickly without the overhead of having to keep the cluster running in the first place.
Simple vs. Complex Integration
AWS doesn’t have a managed Kubernetes installation like GKE does. GKE, on the other hand, has Google backing and integrates with all of Google’s other tooling. It comes with built-in logging, log management and monitoring at both the host and container levels. Unlike AWS, it can give you automatic autoscaling, automatic hardware management and automatic version updates. It generally gives you a production-ready cluster with a more batteries-included approach than if you were building everything by hand on AWS.
Community support for containerization clusters is solidifying around Kubernetes. Because Kubernetes and GKE both developed internally within Google, Google engineers are paid to support all Kubernetes features sooner (and better) than other cloud services. Amazon isn’t paying their engineers to make Kubernetes run better on Amazon.
With GKE, you get a production-ready Kubernetes cluster with all the necessary tooling, along with ongoing support needed to make sure your packages and versions stay current. GKE takes care of security defaults for you and integrates with other Google services. This combination requires less overhead in managing the cluster and makes it more seamless to use in the long run.
To be clear, Fairwinds can handle Kubernetes on AWS and GCP. Either solution works just fine for us. However, if you have the political capital and ability to choose (if, for example, you’re not already an Amazon shop), GKE will make your life easier.
Simply put, Kubernetes is better on GKE than on AWS. Running Kubernetes on GCP will save you time and money, as well as give you a shorter learning curve, more synergies and an all around better experience.