An Overview of App Engine

Services, versions, and instances

At the highest level, an App Engine application is made up of one or more services, which can be configured to use different runtimes and to operate with different performance settings. Services let developers factor large applications into logical components that can share App Engine features, such as Memcache, and communicate in a secure fashion.

A deployed service behaves like a microservice. By using multiple services you can deploy your app as a set of microservices, which is a popular design pattern.

An app that handles customer requests might include separate services to handle other tasks, such as:

  • API requests from mobile devices
  • Internal, admin-like requests
  • Backend processing such as billing pipelines and data analysis

Each service consists of source code and configuration files. The files used by a service represent a version of the service. When you deploy a service, you always deploy a specific version of the service. Having versions for each of your services allows you to roll back with a single click in the Cloud Platform Console, or to use traffic splitting to gradually increase traffic to the newly deployed version of a service.

Each service and each version must have a name. A name can contain numbers, letters, and hyphens. It cannot be longer than 63 characters and cannot start or end with a hyphen. Choose a unique name for each service and each version. Don't reuse names between services and versions.

While running, a particular version will have one or more instances. App Engine by default scales the number of instances running up and down to match the load, thus providing consistant performance for your app at all times while minimizing idle instances and thus reducing cost.

Hierarchy graph of services/versions/instances

Features, such as Memcache, Datastore, and Task Queues, are shared by all the services in an application. Every service, version, and instance has its own unique URI (for example, Incoming user requests are routed to an instance of a particular service/version according to URL addressing conventions and an optional customized dispatch file.

Instance scaling

While an application is running, incoming requests are routed to an existing or new instance of the appropriate service/version. The scaling type of a service/version controls how instances are created. Scaling settings are configured in the app.yaml file. There are two scaling types:

Manual scaling
A service with manual scaling runs continuously the exact same number of instances irrespective of the load level. This allows tasks such as complex initializations and applications that rely on the state of the memory over time.
Automatic scaling
Automatic scaling is based on request rate, response latencies, and other application metrics.

Monitoring resource usage

The Instances page of the Cloud Platform Console provides visibility into how instances are performing. You can see the memory and CPU usage of each instance, uptime, number of requests, and other statistics. You can also manually initiate the shutdown process for any instance.


When you write to stdout or stderr, entries appear in the Cloud Platform Console Logs page.

Communication between services

Services can communicate with other services and external applications in various ways. The simplest approach is to send HTTP requests to a service by including its name in the URL: <service-name> If you require secure communication between services, you can authorize requests.

Services can also communicate via Google Cloud Pub/Sub. Pub/Sub provides reliable asynchronous many-to-many messaging between processes, including App Engine. These processes can be individual instances of your application, services, or even external applications.

Services and external applications can also share data stored in databases such as Cloud Datastore, Cloud SQL, or third-party databases. Additionally, all the services in the same project share a single memcache instance, but this is not directly accessible from outside of the app.


The maximum number of services and versions that you can deploy depends on your app's pricing:

Limit Free app Paid app
Maximum services per app 5 20
Maximum versions per app 15 60

There is also a limit to the number of instances for each service with manual scaling:

Limit Free App Paid App US Paid App EU
Maximum instances per manual scaling version 20 200 25

Send feedback about...

App Engine flexible environment for Java docs