Compare Google Cloud Run vs. App Engine for enterprise software
Google's Cloud Run and App Engine both aim to accelerate app development and simplify deployment. Developers will want to choose between the services on a case-by-case basis.
Despite being somewhat of a misnomer, the term serverless computing is now widely used to describe cloud services that don't require pre-provisioning or resource management.
Cloud providers such as Google tout an extensive portfolio of serverless products, spanning basic infrastructure to packaged AI environments. The foundation of Google Cloud's serverless lineup is three computing services designed to speed application development, simplify deployment and automate resource scaling and other operational tasks.
- Cloud Functions executes an event-driven function as a service (FaaS) at any scale and without management overhead. Users pay only for the execution time, measured with 0.1-second granularity.
- Cloud Run is a managed runtime environment for containerized applications. The service supports images written in any language. It is integrated with Google's other cloud development services, including Cloud Code, Cloud Build and Artifact Registry. Like Cloud Functions, Cloud Run is billed by total execution time measured to the nearest 0.1 second.
- App Engine is a PaaS offering for web applications written in Node.js, Java, Ruby, C#, Go, Python, PHP, or any custom runtime packaged as a container. As with Cloud Functions and Cloud Run, App Engine automatically scales to accommodate changing workloads and works with Google's monitoring, logging and debugging services.
As compared to Cloud Functions, Cloud Run and App Engine offer more flexibility, given that most enterprise applications aren't purely event-driven.
Cloud Run: Containers without the pain of Kubernetes
Cloud Run is a container-on-demand service similar to Azure Container Instances and AWS Fargate. Unlike Google Kubernetes Engine (GKE), Cloud Run is designed for stateless web applications accessed via HTTP, WebSockets or gRPC requests or streams. Thus, Cloud Run won't work for applications that require a persistent file system.
The Cloud Run environment can handle any code and libraries that are packaged into a custom container. It natively includes runtime environments for Go, Java, Node.js, Python, or .NET Core. It is particularly appealing to developers using these scripting languages, which are among the most popular languages used for web apps.
Cloud Run is built on the open source Knative environment, which enables developers to port applications to on-premises systems or other Knative-compatible cloud services.
Knative also enables Cloud Run code to be deployed in seconds, as well as work with frameworks such as Django, Ruby on Rails, Spring and others. Cloud Run can shut down all instances if there isn't demand. This makes the service efficient for stateless web apps with highly variable workloads.
Other features include:
- the ability to split traffic across application versions to gradually introduce beta releases or blue/green testing;
- automatic redundancy with instances automatically replicated across multiple zones; and
- support for custom domains, mapping Cloud Run and using a private TLS certificate in place of the certificate that is automatically supplied when using Cloud Run domain mapping.
Ideal applications and use cases for Cloud Run include:
- dynamic websites that use a framework like Django or Ruby on Rails;
- back-end web services with REST APIs;
- event-driven data transformations such as converting a CSV file into a structured table for data warehouses like BigQuery; and
- scheduled batch jobs for tasks such as document conversion, which could include converting Word documents or Excel forms into PDFs.
App Engine: The code-centric choice
App Engine predates Compute Engine and other Google Cloud infrastructure services that provided a standardized development and runtime environment for web applications. App Engine has since been extended via App Engine flexible environment to support custom containerized runtimes. Flexible environment is something of a hybrid between the standard, code-centric App Engine and the container-based Cloud Run and GKE.
Google targets App Engine for applications designed as microservices. This is particularly the case when using the standard environment, since it runs code in a secure sandbox and can deploy and automatically scale applications in seconds. App Engine uses container instances for each deployment. When using the standard environment, they are preconfigured with one of the following support runtimes:
- Python (versions 2.7, 3.7, 3.8 and 3.9 are currently supported)
- Java 8 and Java 11
- js (versions 10, 12, 14 and 16)
- PHP (5.5, 7.2, 7.3 and 7.4)
- Ruby (2.5, 2.6 and 2.7)
- Go (1.11-1.16)
Developers specify the App Engine runtime and deployment configuration in a YAML file. You can deploy with a simple command:
gcloud app deploy
The configuration also identifies an instance class that determines the CPU and memory resources available to each application. For example, the smallest and default instance, F1, provides a 0.6 GHz vCPU with 256 MB of memory. The largest B8 instance delivers a 4.8 GHz equivalent processor with 2048 MB of RAM.
Developers configure App Engine flexible environments via a similar YAML file, but the file requires a user-supplied runtime. It's possible to use any combination of CPUs, from one to 80 in powers of two; RAM, which is subject to minimum requirements per application; and disk, from 10 GB to 10 TB.
Like Cloud Run, App Engine standard environments are billed according to the number of instance-hours used. Rates are set according to the instance size. For example, standard App Engine B1 and F1 instances cost $0.05 per hour, while B8 instances run $0.40 per hour. Google prices flexible environments as a combination of vCPU hours, RAM GB hours, persistent disk size and outgoing network traffic.
Cloud Run and App Engine both target web-facing, stateless (unless using Flex environments) applications, particularly those developed using one of the standard runtime environments, or REST back ends with highly variable workloads. These include:
- static websites and dynamic web services
- mobile back ends
- log and data processing workflows
Cloud Run vs. App Engine: Choose the best service for the task
Cloud-native applications are ideally decomposed into many components or microservices. These components rely on more than just code that's encapsulated in a single runtime or container environment. A main benefit of the cloud is gaining access to a range of serverless data management, analytics and AI services. Thus, whether using App Engine or Cloud Run, a developer's work will invariably connect to other Google Cloud services. Some examples would be BigQuery, Bigtable, Pub/Sub, Cloud Storage and the Vision API.
Developers shouldn't consider the selection of Cloud Run vs. App Engine for custom code as a choice they make once. Instead, pick the service that's best for a particular microservice or application subsystem.
Editor's Note: This article is one of the last pieces longtime TechTarget contributor Kurt Marko wrote for us before he passed away in January 2022. Kurt was an experienced IT analyst and consultant, a role in which he applied his broad and deep knowledge of enterprise IT architectures. You can explore all the articles he authored for TechTarget on his contributor page.
