Compare Google Cloud Run and App Engine for enterprise software
Although somewhat of a misnomer, the term serverless computing is now widely used to describe cloud services that do not require pre-provisioning or resource management.
Cloud providers such as Google offer a broad portfolio of serverless products, ranging from basic infrastructure to packaged AI environments. The foundation of Google Cloud’s serverless range is three IT services designed to accelerate application development, simplify deployment, and automate resource scaling and other operational tasks.
- Cloud functions executes an event command run as a service (FaaS) at any scale and without management fees. Users only pay for execution time, measured with a granularity of 0.1 seconds.
- CloudRun 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 based on total execution time measured to within 0.1 seconds.
- Application Engine is a PaaS offering for web applications written in Node.js, Java, Ruby, C#, Go, Python, PHP, or any custom runtime environment in container form. As with Cloud Functions and Cloud Run, App Engine scales automatically to adapt to changing workloads and works with Google’s monitoring, logging, and debugging services.
Compared to Cloud Functions, Cloud Run and App Engine offer more flexibility, since most enterprise applications are not purely event driven.
Cloud Run: containers without the pain of Kubernetes
Cloud Run is an on-demand container service similar to Azure container instances and AWS Fargate. Unlike Google Kubernetes Engine (GKE), Cloud Run is designed for stateless web applications accessed through HTTP, WebSockets, or gRPC requests or streams. So Cloud Run will not work for apps that require a persistent file system.
The Cloud Run environment can handle any code and any library packaged in a custom container. It natively includes runtimes 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 applications.
Cloud Run relies on open-source Knative environmentwhich allows developers to push apps to on-premises systems or other Knative-enabled cloud services.
Knative also makes it possible to deploy Cloud Run code in seconds, as well as work with frameworks such as Django, Ruby on Rails, Spring, and others. Cloud Run can terminate all instances if there is no demand. This makes the service efficient for stateless web applications with widely varying workloads.
Other features include:
- the possibility of distributing traffic between versions of the application to gradually introduce beta versions or blue/green test;
- automatic redundancy with automatically replicated instances across multiple zones; and
- support for custom domains, Cloud Run mapping, and use of a private TLS certificate instead of the auto-provided certificate 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 API;
- event-driven data transformations such as converting a CSV file to a structured table for data warehouses like BigQuery; and
- scheduled batch jobs for tasks such as document conversion, which may include converting Word documents or Excel forms to PDF.
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 through App Engine flexible environment to support custom containerized runtimes. The flexible environment is something of a hybrid between the standard, code-centric App Engine and container-based Cloud Run and GKE.
Google targets App Engine for applications designed as microservices. This is especially the case when using the standard environment, as it runs code in a secure sandbox and can automatically deploy and scale applications in seconds. App Engine uses container instances for every deployment. When using the standard environment, they are pre-configured 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)
- Rubies (2.5, 2.6 and 2.7)
- Go (1.11-1.16)
Developers specify App Engine runtime and deployment configuration in a YAML file. You can deploy with a simple command:
gcloud application deployment
The configuration also identifies an instance class that determines the CPU and memory resources available to each application. For example, the smallest default instance, F1, provides a 0.6 GHz vCPU with 256 MB of memory. The larger B8 instance offers a 4.8 GHz equivalent processor with 2048 MB of RAM.
Developers configure App Engine flexible environments through a similar YAML file, but the file requires a user-provided runtime environment. It is possible to use any combination of processors, 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 based on the number of instance hours used. Prices are set according to the size of the instance. For example, standard App Engine B1 and F1 instances cost $0.05 per hour, while B8 instances run $0.40 per hour. Google Pricing flexible environments like a combination of vCPU hours, GB RAM hours, persistent disk size, and outbound network traffic.
Both Cloud Run and App Engine target stateless web applications (unless using Flex environments), especially 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 backends
- data logging and processing workflows
Cloud Run vs App Engine: Choose the best service for the job
Cloud-native applications are ideally broken down into multiple components or microservices. These components rely on more than just code encapsulated in a single runtime or container environment. One of the main benefits of the cloud is access to a range of serverless data management, analytics and AI services. So 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 should not view selecting Cloud Run vs. App Engine for custom code as a one-time choice. Instead, choose the service that best suits a particular microservice or application subsystem.
Editor’s note: This article is one of the last articles that longtime TechTarget contributor Kurt Marko wrote for us before his passing in January 2022. Kurt was an experienced IT analyst and consultant, a role in which he applied his broad knowledge and depth of enterprise IT architectures. You can explore all the articles he has written for TechTarget on his contributor page.