App Engine is one of the fully managed, serverless platforms fordeveloping and hosting web applications at scale. You can choose from severalpopular languages to develop your apps, and then let App Engine takecare of provisioning servers and scaling your app instances based on demand.A newer and better alternative to App Engine isCloud Run, which is thelatest evolution of Google Cloud Serverless. If you are a new Google Cloudusers, we recommend using Cloud Run for developing and hosting webapplications.

Components of an application

An App Engine app is made up of a single application resourcethat consists of one or moreservices. Each service can be configured to usedifferent runtimes and to operate with different performance settings. Withineach service, you deployversions of that service. Each version then runswithin one or moreinstances, depending on how much traffic you configured itto handle.

Your App Engine app is created under your Google Cloud project when youcreate an application resource. The App Engine application is atop-level container that includes the service, version, and instance resourcesthat make up your app. When you create your App Engine app, all yourresources are created in the region that you choose, including your app codealong with a collection of settings, credentials, and your app's metadata.Learn more about "application resources"(standard |flexible ) and inwhich regions you can create them.

Each App Engine application includes at least one service, thedefaultservice, which can hold many versions, depending on your app's billing status.For more information, seeLimits below.

The following diagram illustrates the hierarchy of an App Engineapp running with multiple services. In this diagram, the app has two servicesthat contain multiple versions, and two of those versions are actively runningon multiple instances:

Other Google Cloud services, for example Datastore, areshared across your App Engine app. For more information, see"Structuring web services"(standard |flexible ).

Services

Useservices in App Engine to factor your large apps into logicalcomponents that can securely share App Engine features and communicatewith one another. Generally, your App Engine services behave likemicroservices.Therefore, you can run your whole app in a single service or you can design anddeploy multiple services to run as a set of microservices.

For example, an app that handles your customer requests might include separateservices that each handle different tasks, such as:

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

Each service in App Engine consists of the source code from your app andthe corresponding App Engine configuration files. The set of files thatyou deploy to a service represent a singleversion of that service and eachtime that you deploy to that service, you are creating additional versionswithin that same service.

Versions

Having multiple versions of your app within each service allows you to quicklyswitch between different versions of that app for rollbacks, testing, or othertemporary events. You can route all traffic to a specific version of your app by"migrating traffic"(standard |flexible ) or routeto multiple versions of your app by"splitting traffic"(standard |flexible ).

Instances

The versions within your services run on one or moreinstances.By default, App Engine scales your app to match the load. Your apps willscale up the number of instances that are running to provide consistentperformance, or scale down to minimize idle instances and reduces costs.For more information about instances, see "How instances are managed"(standard |flexible ).

In the App Engine flexible environment, instances are backed by Compute Engine resources.Some of the resources used by instances in the App Engine flexible environment, such as disk, CPU,and memory, count towards theCompute Engine API quotasof your project. For more details on how App Engine uses Compute Engineresources, see theApp Engine flexible environment overview.

Application requests

Each of your app's services and each of the versions within those services musthave a unique name. You can then use those unique names to target and routetraffic to specific resources using URLs, for example:

https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

Incoming user requests are routed to the services or versions that areconfigured to handle traffic. You can also target and route requests to specificservices and versions. For more information, see"Communicating between Services"(standard |flexible ).

Logging application requests

When your application handles a request, it can also write its own loggingmessages tostdout andstderr.For details about your app's logs, see "Writing Application Logs"(standard |flexible ).

Limits

Both the flexible environment and the standard environment sharethe same limits for services and versions. For example, if you have standardversions and flexible versions in the same app, those versions count towards thesame limit. For details, see "Quotas and limits"(standard |flexible ).