Containers - AWS vs GCP part 3
Containers were and are a game changer in shipping applications.
In cloud native development there is no way around Containers.
Containers famously solve the problem of “it works on my machine” because they allow you to package not just the application but the entire runtime and OS environment.
Before starting to work on GCP I was expecting Containers to be one of the strong suits of GCP because Google has been using Containers before Docker was a thing and was also the birthplace of Kubernetes.
Let’s dive in and see how AWS and GCP compare when it comes to containers
First of all, I want to distinguish between the services and tools that help you orchestrate and run containers because those are only part of the equation. The tools for building, deploying and maintaining container based applications are just as important.
Container orchestration
When we compare the orchestration stack there are 3 main layers:
- DIY (on a VM)
- Cluster
- Serverless
There’s nothing much to say about the DIY approach except that you’d really need a good reason to choose it compared to the other options.
Cluster
For clusters there is a Kubernetes offering from both. GKE Standard and EKS are comparable as the Kubernetes master nodes are managed but you control the worker nodes. This allows you to install other agents or software on your worker nodes for complement your Kubernetes workload.
AWS additionally offers ECS a simple and integrated cluster for running docker containers as an alternative for Kubernetes. In my opinion you would most likely use ECS only with Fargate for serverless workloads. If you need more control you’d likely choose EKS.
Serverless
The main serverless container service in GCP is Cloud Run. It’s a really simple orchestration service with minimal necessary configuration to get you up and running. AWS` initial serverless offering: Fargate, still requires you to configure a vpc, cluster, service, task and load balancer, etc. I think AWS or AWS` customers saw what Google was doing and decided to build App Run to have a comparable service to Cloud Run.
Other than Cloud Run GCP has an “Autopilot mode” for GKE along with a serverless plugin to support the Knative tool which in combination can be considered serverless.
AWS has Fargate for EKS where the nodes are managed for you. You can also get Knative to run with AWS as EKS is based on the opensource Kubernetes. However, you should note that AWS doesn’t directly support Knative. Hence, there is no official AWS documentation available to make it work with AWS.
AWS Lambda also supports Containers for serverless functions which Google Cloud Functions don’t.
There are a few more services that are based on Containers like Google’s Deep Learning Containers, AWS Batch, Sage Maker, etc. However, these are for special use cases which I won’t cover here.
Tools
As for tools, both GCP and AWS support the most important one: a container registry to privately store your images and even scan for vulnerabilities: Container Registry / ECR. Both also have a Cloud IDE with docker preinstalled for you to develop containers: Cloud Code / Cloud 9. For monitoring you can deploy a managed Prometheus on both platforms.
All other tools differ from platform to platform
GCP tools
Kubernetes applications: Via the Google Cloud Marketplace you can deploy prepackaged container applications with consolidated billing via the google billing.
Jib: Jib is a tool to build, package and pushes a JVM based application as a docker container to a container repository with ease. In your Maven or Gradle configuration you can import the plugin and create a task that you can execute.
The advantages of Jib are that it’s fast, because it uses smart caching of the individual docker steps. It also abstracts a lot of knowledge about docker syntax and commands. It even emits the need to have docker installed because it creates the image via tar archives without the docker daemon.
Jib also doesn’t just work with GCP. It was developed by Google but works with any standard docker registry, including Amazon ECR.
AWS tools
AWS Cloud Map: is a service discovery service that helps you define names for resources that helps with connecting microservices and components. Cloud Map exposes names for resources with health checks that other resources can connect to.
AWS App Mesh: is a service mesh that orchestrates application level networking for EC2, ECS, EKS and Fargate.
AWS Copilot: is a CLI that helps you interact with Amazon ECS. It simplifies deploying and managing containers on ECS from your command line.
AWS App2Container: is a CLI for Java and .Net applications that run on servers or VMs. It will analyse the environment and identify applications that you can then package into a container and deploy via a pipeline. This is useful for migrating existing applications.
This overview obviously doesn’t cover all the open source and commercial offerings that exist around containers which you could use or integrate with AWS and GCP.
However, as you can see both providers offer many options for running and building containers as part of the platform.
Also, you don’t need to be a Kubernetes expert to run container workloads in production, as both clouds offer serverless options that are production ready.
