I would give Google a star for its simple naming strategy: Cloud CDN, Cloud Function, Cloud SQL, BigTable, Cloud Load Balancer, Datastore. On the other hand, AWS has products that no one can guess its name literally, such as Fargate, Beanstalk, Aurora, Neptune, Snow, Athena, Redshift, Kinesis, Macie, and Glue. This is my initial objective in writing this comparison article, and I will try my best to keep it up to date.
| AWS | GCP |
| EC2 | Compute Engine |
| Beanstalk | App Engine |
| Lambda | Cloud Function |
EC2 vs Compute Engine
EC2 can be configured with template AMI and attached with persistent block storage. It auto-scales vertically and horizontally within one region, where an unhealthy instance will be replaced with new. Its instance type includes:
- On-demand instance for short workload with a predictable price
- Reserved instance for long and scheduled work
- Spot instance for short workload, it is cheap but can be terminated
- Dedicated host for entire server with controlled placement
Compute Engine is created using either a boot disk image, snapshot, or container image. It auto-scales within a zone, region, or even across regions, but you must attach it with a managed instance group. Its instance type includes:
- E2, N1, N2, etc
- Preemptible VM instance is cheap but can be terminated at any time
In my opinion, there isn’t a huge difference between GCE and EC2, they both provide pretty much everything you need for day-to-day business. I just wish Google would one day provide a long-term permanent playground instance, similar to the EC2 micro, the current $300 deal runs out quickly.
Beanstalk vs App Engine
Beanstalk (first of all who reads Beanstalk as beansTalk instead of BeanStalk 🙋♀️🙋♂️) gives you the freedom to deploy and manage applications without the learning curve of the infrastructure underneath: load balancing, scaling, health check, and capacity provisioning. It took the declarative approach, that you tell Beanstalk what you want with a configuration file, and it handles everything for you, all you need is to upload the app code.
App Engine is a fully managed serverless platform, which requires zero server management to use. It comes with two environments:
- The standard environment allows an instance to run in the sandbox with supported language, it has limited CPU and memory options without persistent disk attached, moreover it doesn’t support SSH and VPN 🥺 . Sounds pretty disappointing right? but the primary goal of App Engine is to provide a hands-free setup for those who absolutely don’t want to care about the server management, so surprisingly App Engine standard is actually popular.
- The Flexible environment gives you freedom on programming language and computing power, it runs within a Docker container… wait doesn’t it sounds familiar? Yes, it remains me Cloud Run, and in fact, Google recommends flexible users to use Cloud Run instead. In the end, if you want to take control of the container images, why not go one step further.
Lambda and Cloud Function
Both Lambda and Cloud Function provides service with zero admin, it is even simpler to set up than App Engine or Beanstalk. In my opinion, these two products won’t be the decision-maker for one to choose between AWS and GCP. If you are an AWS user who needs a serverless event-driven solution, you would use Lambda and vice versa with GCP.
Some interesting use cases for Lambda and Cloud Function:
- Send email confirmation
- Generate image thumbnails
- Analytic logs on the fly
- Anything that you can deploy as an isolated function
| AWS | GCP |
| Fargate | Cloud Run |
| EKS | GKE |
| ECS | N/A |
Fargate vs Cloud Run
Both Fargate and Cloud Run are serverless container choices for AWS and GCP. If you want to compare them vertically, Fargate is Beanstalk on the container, while Cloud Run is App Engine with Docker image.
The step to set up Fargate is very easy and straightforward: build an image, define memory and compute resources required, run the application and pay for resources consumed. Fargate supports VPC and you will only pay for the compute time rather than the instance underneath. Cloud Run has similar features, and both of them can be scaled vertically and horizontally. Since Google ditched Docker in GKE, if you are a Docker lover, you will find Cloud Run easy to use, in fact, the setup is even simpler: create a Cloud Run service and insert a Docker image (hands-on step by step guide)
EKS (Elastic Kubernetes service) and GKE (Google Kubernetes Engine)
Amazon EKS is the managed Kubernetes service while GKE is a likewise product from Google. Although GKE feels more like the signature dish of Google, EKS isn’t the title track of Amazon, which is understandable. These two products might be the key decision-maker over GCP and AWS.
It is a bit unfair to compare GKE with EKS, it is like asking who provides the best chicken wings: McDonald's or KFC 🤷♀️. Not to mention the new Google Cloud platform Anthos, just GKE on its own is worth a brand new chapter of discussion, Google has bet all its money in Kubernetes technology and it does indeed integrate with all of its other cloud products everywhere. If you want to dig into GKE a bit further, I highly recommend this Coursera course — Architecting with Google Kubernetes Engine. My own take from it is that GKE is a self-contained mini-land of everything in the Google Cloud Platform.
There are multiple containers inside each pod, and multiple pods inside a Node, and multiple Nodes inside a GKE Cluster. Each Node is a VM on its own, and you can classify resources with node pool, namespace, and label. Moreover you need to look after the storage, ingress rule, load balancing, and deployment, etc, no wonder one could already be given up at this stage.
So if you have a medium-sized project with simple micro-service architecture, there is an alternative option to choose from AWS — ECS (Elastic Container Service), in simple words ECS is a managed service to use Docker within EC2 instance, some even call ECS the Kubernetes without a control plane. It is serverless by default with Fargate and can scale across multiple zone.
To Be Continued in Part 2: Database, Storage and Networking…
A full list of my comparison is here: