AWS App Runner VS Google Cloud Run

With the adoption of containerized services, the vast majority of companies started using container orchestration platforms like Kubernetes, AWS ECS, Hashicorp Nomad… However, these platforms have many complexities, they are hard to learn and they are costly to manage. 

That’s why Google offered a service called Cloud Run which is a serverless container platform. Cloud Run deploys your applications to a containerized production environment and abstracts most of the operational components such as:

• Scaling your container instances
• Load balancing
• TLS management (you do not have to worry about your TLS certificate expiration; Cloud Run renews certificates for you)
• Managing the servers behind this platform
• Log/metrics collection
  
  

Sounds great, right? Cloud Run does not stop there, it also uses Knative API. 

With the adaption of Google Cloud Run, AWS wanted to get into this serverless container platform game and launched the AWS App Runner service. In AWS’s words: “AWS App Runner is a fully managed service that makes it easy for developers to quickly deploy containerized web applications and APIs” 

At a glance, both services look similar. Let’s compare these services by looking at their similarities and differences:

Similarities

• Both services can deploy a containerized web application from a Docker Registry  (ECR or GCR)
• Both services work well with build tools of their Cloud Platform and build Docker images from Dockerfile, or deploy from source code if the language/framework is supported.
• Both services create and renew TLS certificates automatically for the load balancer they use. 
• Both services scale their container instances automatically based on concurrent requests served.
• Both services collect logs/metrics without agents or exporters. 
• Both services provide an HTTPS endpoint which you can point to a custom domain of yours.

Differences

Now let’s do some demo on both services to deploy an application:

Google Cloud Run Demo:

Let’s start by creating a Google Cloud Run service.

We continue with naming our service and picking a region.

After that, we need to provide a Container image URL or pick build from the source code option. In our demo, I’ll be picking a container image as a source.

In Advanced settings, we can provide options like container port  (which is required), container start commands, specify secrets from Google Secret Manager, and so on.

Now we need to define Capacity, and autoscaling options for our service to size and scale it’s containers.

Now, we pick the access preferences from both auth and networking. With recent updates, now we can deploy a private service that would only be accessible from it’s VPC.

AWS App Runner Demo:

On App Runners Dashboard, we start by clicking Create Service.

After that, we have to pick a source for App Runner. Here I pick container registry as a source and provide a container image from ECR. 

App Runner has options to manually deploy whenever you want, or it can redeploy itself whenever a new image with the tag you chose is pushed to the ECR. Here I pick automatic deploys. App Runner also needs an IAM role to pull images from ECR. I’ve already created that role so I’ve picked that role in its tab.

Now here, we need to specify capacity options to size the App Runner Services containers like CPU and Memory.

In the last tab, we can provide options for autoscaling  (concurrency), we can provide an IAM role so that this service can access other AWS services without the need of access keys.  

Summary:

Google Cloud Run is a great service to run your containerized workloads  (or any workload if the runtime is supported). It’s currently used by a lot of companies and it has great integrations with GCP services. It is also supported by the community. For example,  a project called “Runsd” brings service discovery ability to Cloud Run services.

From my point of view, although it is lagging in some areas right now, AWS App Runner is a better solution to run your workloads. While AWS App Runner is still lacking features like private services, secrets manager integration, canary deployments with revisions, the AWS community already opened issues for these features. I anticipate a short period for these features to materialize to the point where there is feature parity between the two solutions.