Compare Google Cloud Run to App Engine for enterprise software

Although the term serverless computing is somewhat misleading, it is now commonly used to describe cloud services that do not require pre-provisioning or resource management.

Cloud providers like Google offer an extensive portfolio of serverless products, ranging from basic infrastructure to bundled AI environments. The founding of Google Cloud’s serverless offering are three computing services designed to accelerate application development, simplify deployment, and automate resource scaling and other operational tasks.

  • cloud features executes an event-driven act as a service (FaaS) of any size and without administrative effort. Users only pay for the execution time, measured at a granularity of 0.1 seconds.
  • 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, which is measured to within 0.1 seconds.
  • 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 meet changing workloads and works in tandem with Google’s monitoring, logging, and debugging services.

Compared to Cloud Functions, Cloud Run and App Engine offer more flexibility because most enterprise applications are not purely event-driven.

Cloud Run: Containers without Kubernetes problems

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. Therefore, Cloud Run does not work for applications that require a persistent file system.

The Cloud Run environment can handle any code and library packaged in a custom container. It natively includes runtime environments for Go, Java, Node.js, Python or .NET Core. It is particularly attractive to developers using these scripting languages, which are among the most popular languages ​​for web apps.

Cloud Run is based on the Open source Knative environment, which allows 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 working with frameworks such as Django, Ruby on Rails, Spring, and others. Cloud Run can shut down all instances when there is no demand. This makes the service efficient for stateless web apps with highly variable workloads.

Other features are:

  • the ability to split traffic across application versions to gradually roll out beta versions, or Blue/Green Test;
  • automatic redundancy with instances automatically replicated across multiple zones; and
  • Support for custom domains, mapping Cloud Run, and using a private TLS certificate instead of the certificate that’s automatically provided when using Cloud Run domain mapping.

Ideal applications and use cases for Cloud Run include:

  • dynamic websites using a framework such as Django or Ruby on Rails;
  • backend web services with REST APIs;
  • 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 like document conversion, which may involve converting Word documents or Excel forms to PDFs.

App Engine: The code-centric choice

App Engine predates Compute Engine and other Google Cloud infrastructure services, which provided a standardized development and runtime environment for web applications. App Engine has since expanded through App Engine flexible environment to support custom containerized runtimes. The flexible environment is something of a mix 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 especially true when using the standard environment, as it runs code in a secure sandbox and can deploy and auto-scale applications in seconds. App Engine uses container instances for each deployment. When using the standard environment, they are pre-configured with one of the following support periods:

  • Python (currently versions 2.7, 3.7, 3.8 and 3.9 are 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)
  • Lot (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 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, offers a 0.6 GHz vCPU with 256 MB of memory. The largest B8 instance offers an equivalent 4.8 GHz processor with 2048 MB of RAM.

Developers configure flexible App Engine environments through a similar YAML file, but the file requires a user-supplied runtime. It is possible to use any combination of CPUs, from one to 80 in powers of two; RAM subject to minimum requirements per application; and hard disk, from 10 GB to 10 TB.

Like Cloud Run, App Engine Standard Environments are billed by the number of instance hours used. Rates are set according to 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 egress network traffic.

Cloud Run and App Engine both target web-facing, stateless (unless using Flex environments) applications, particularly those developed using any of the standard runtime environments or REST backends with highly variable workloads. These include:

  • static websites and dynamic web services
  • Mobile backends
  • Protocol and data processing workflows

Cloud Run vs. App Engine: Choose the best service for the task

Cloud-native applications are ideally broken down into many components or microservices. These components rely on more than just code encapsulated in a single runtime or container environment. A key benefit of the cloud is access to a range of serverless data management, analytics and AI services. Therefore, whether you use App Engine or Cloud Run, a developer’s work will always 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 decision between Cloud Run and App Engine for custom code as a one-time decision. Instead, choose the service that best fits a specific microservice or application subsystem.

Publisher’s Note: This article is one of the last articles that 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 browse all of the articles he has written for TechTarget on his site Contributing Page.

Comments are closed.