GCP vs. AWS: A Manager’s Guide

This post is a follow-up to our summary of the differences between AWS and GCP. To summarize: AWS is more of an “ops engineer’s cloud”, GCP is more of a “software engineer’s cloud.” This post is meant to provide a real example you can follow along with. In fact, I strongly encourage you to follow along — you’ll learn more.

Before digging in, I want to be clear that you can build the same application on either platform. The approach you take will, and should, differ between the two. They have many similarities at a high level, but the differences start to emerge in practice. This is why we generally respond with “it is nuanced” or “it depends” when we’re asked which cloud someone should favor. The correct choice of cloud, to the extent there is a correct choice, will depend more on your team and their preferences.

In this post we’re going to use two similar services as a specific example: GCP’s App Engine Flex (marketing materials) and AWS Fargate (marketing materials). These are both container-as-a-service platforms, meaning they provide a managed solution for running your application’s containers. They’re similar enough in intent and marketing pitch that I would call them competitors. In fact, we have taken services designed for one and ran them on the other without any code modifications. The differences come in developer feel and operational overhead when working with the respective platforms. I will be referring to each provider’s “Getting Started” documentation to illustrate the differences.

Today we will be working to deploy the services each vendor uses in their getting started guides. This approach bypasses a lot of other steps required to deploy your own service to AWS Fargate, but the steps provided here are the same for manually deploying your own service to App Engine Flex. This post assumes you have both AWS and GCP accounts. If not, refer to the respective documentation on account setup for AWS and GCP.

AWS Fargate

Here we will summarize the high points from the Fargate getting started guide. You should follow that guide. It is important to note that the Fargate getting started guide does not actually cover all of the steps needed to get something working, so you’ll most likely need to follow a number of other guides as well. They start by assuming you are already set up to build and deploy services, and that you have an AWS account. You will also note that with Fargate, like most AWS services, you need to understand a number of underlying AWS services and concepts. Onto the steps to setup a new service:

1. In order to deploy something from your machine, you would need to build and deploy your own container to Amazon’s container registry. I’m going to skip over this step. Their tutorial does not explain any aspects of this either. They use an existing container that is publicly available, so to use your own application you’ll need to do more setup and work.
2. You start by creating an ECS cluster. This requires a series of steps that includes choosing the regions in which your service will run and setting up a VPC if you don’t already have one.
3. Create the “task” definition which is effectively your service’s name, type (Fargate in this case), and permissions (IAM). Then specify your memory and CPU requirements, configure the networking for this task, select the container you’d like to run (that you deployed in step 1), then more networking configuration (port mappings).
4. You now need to configure a load balancer for your service. You will want a high level understanding of availability zones and your networking configuration. Set up security groups and configure DNS settings.
5. Create an ECS service. This configures how (and if) our service will auto-scale and how fault tolerance will be handled. We also do the final networking configuration to connect everything created during the prior steps. You’ll assign the service to run within certain subnets that the load balancer will spread traffic across and then configure the DNS settings.
6. You can now hit your new service from your browser.

GCP GAE Flex

Now let’s work with GAE Flex. We generally refer to GCP as the “developer’s cloud,” and I think it will be apparent why we say that. Once again, I will explain this by referencing their getting started guide. It is definitely worth reading (or skimming), and you could realistically follow along because it covers all of the steps needed from setting up your machine to creating the GCP project. With that, let’s deploy a service (that we’ll even build!):

1. Google’s guide starts by explaining how to get your machine setup to develop for GCP, then walks you through creating and configuring your cloud project, and finally explains how to enable billing. It requires a handful of command line commands and a few clicks within their Cloud Console UI.
2. Next, you download an example application’s source code and get it running locally on your machine. If you have an existing app you could use that code instead. Note that the tutorial covers getting the app running locally before deploying.
3. For reference, this is roughly where the AWS tutorial starts.
4. Here’s the steps to deploy your application to Flex: gcloud app deploy. The networking, scaling, cluster management, load balancers, and basic fault tolerance are all managed and handled by Google. This is fully managed and has reasonable defaults. You just deploy your code. They build it, package it, and allow you to run it. If you want to tune those options later, you can.
5. You can now view your app by running: gcloud app browse.
6. The rest of the tutorial walks through the cleanup of the cloud project and explains all of their sample code and config files. The only portion of code unique to Flex is the app.yaml file. This file allows you to setup the desired scaling behaviors and specify how much RAM and CPU your service needs.

In other words, if I am a programmer writing an application, I can write my application and deploy it. It runs in a secure environment with fault tolerance, with little-to-no effort on my part. If you need more control you can tweak and tune most of the relevant settings, but you only need to if there is a reason to do so. The trade-off is that you need to adhere to a set of restrictions and expectations. The biggest items to be aware of are that fast instance startup times and a stateless architecture tend to fit best. Some codebases are a better natural fit for the Flex ecosystem.

Summary

We’ve now walked through running applications on both platforms. The experience and feel is quite different. In a real environment, you likely have some automation and a CI/CD pipeline to handle some of these concerns, but you still need to be aware of the underlying systems.

Our GAE Flex app automatically handles many concerns for us. It runs in a secure environment and handles fault tolerance and scaling with little effort on our part. We spend most of our time and effort working on our application code rather than managing our infrastructure. Mostly we’re writing application code and thinking about our application’s architecture. In other words: concerns a software engineer thinks about.

The AWS Fargate experience is much lower level. We need to have an understanding of networking, firewalls, load balancers, IAM roles, and even ECS clusters. The benefit is that we can fine-tune all of these settings when needed, even if that need is less common. Many of these tasks are more common for traditional operations teams to be concerned with than modern software engineers, hence why we often refer to AWS as the “ops engineer’s cloud” and GCP as the “software engineer’s cloud.”

Google’s new Cloud Run service is streamlining all of this even further. While App Engine Flex makes it straightforward to deploy a container, it can take several minutes before your application is actually running. This is because — similar to Fargate — Flex runs workloads on VMs and has to provision a load balancer for them. Cloud Run, however, uses gVisor which provides a lightweight container sandbox runtime which allows Cloud Run to deploy container workloads in seconds.

The big takeaway is that the set of concerns I’m thinking about are different. We’re going to invest much more in traditional operations tasks on AWS. On GCP, we give up some low-level control and focus on application code and our software architecture. You can build the same application on either, you’re just going to invest your time in different areas.

We specialize in helping companies ship microservice applications built using containers with confidence. Contact us to learn more.