App Engine Flexible Environment for Users of App Engine Standard Environment

This guide provides an introduction to the flexible environment for those who are familiar with the standard environment. It explains the similarities and key differences between the environments and also provides general architectural recommendations for applications that use both environments.

For a mapping of services available in standard environment to their analogues in the flexible environment, see Migrating Services from the Standard Environment to the Flexible Environment.

Similarities and key differences

Both environments provide you with App Engine’s deployment, serving, and scaling infrastructure. The key differences are the way the environment executes your application, how your application accesses external services, how you run your application locally, and how your application scales. You can also refer to choosing an environment for a high-level summary of these differences.

Application execution

In the standard environment, your application runs on a lightweight instance inside of a sandbox. This sandbox restricts what your application can do. For example, your application can not write to disk or use non-whitelisted binary libraries. The standard environment also limits the amount of CPU and memory options available to your application. Because of these restrictions, most App Engine standard applications tend to be stateless web applications that respond to HTTP requests quickly.

In contrast, the flexible environment runs your application in Docker containers on Google Compute Engine virtual machines (VMs), which have fewer restrictions. For example, you can use any programming language of your choice, write to disk, use any library you'd like, and even run multiple processes. The flexible environment also allows you to choose any Compute Engine machine type for your instances so that your application has access to more memory and CPU.

Accessing external services

In the standard environment, your application typically accesses services such as Cloud Datastore via the built-in google.appengine APIs. However, in the flexible environment, these APIs are no longer available. Instead, use the Google Cloud client libraries. These client libraries work everywhere, which means that your application is more portable. If needed, applications that run in the flexible environment can usually run on Google Kubernetes Engine or Compute Engine without heavy modification.

Local development

In the standard environment, you typically run your application locally using the App Engine SDK. The SDK handles running your application and emulates the App Engine services. In the flexible environment, the SDK is no longer used to run your application. Instead, applications written for the flexible environment should be written like standard web applications that can run anywhere. As mentioned, the flexible environment just runs your application in a Docker container. This means that to test the application locally, you just run the application directly. For example, to run a Python application using Django, you would just run python runserver.

Another key difference is that flexible environment applications running locally use actual Cloud Platform services, such as Cloud Datastore. Use a separate project for testing locally and when available, use emulators.

Scaling characteristics

While both environments use App Engine’s automatic scaling infrastructure, the way in which they scale is different. The standard environment can scale from zero instances up to thousands very quickly. In contrast, the flexible environment must have at least one instance of your application running and can take longer to scale up in response to traffic.

When to use the flexible environment

The flexible environment is intended to be complementary to the standard environment. If you have an existing application running in the standard environment, it’s not usually necessary to migrate the entire application to the flexible environment. Instead, identify the parts of your application that require more CPU, more RAM, a specialized third-party library or program, or that need to perform actions that aren’t possible in the standard environment. Once you’ve identified these parts of your application, create small App Engine services that use the flexible environment to handle just those parts. Your existing service running in the standard environment can call the other services using HTTP, Cloud Tasks (beta), or Cloud Pub/Sub.

For example, if you have an existing web application running in the standard environment and you want to add a new feature to convert files to PDFs, you can write a separate microservice that runs in the flexible environment that just handles the conversion to PDF. This microservice can be a simple program consisting of just one or two request handlers. This microservice can install and use any available Linux program to aid in the conversion, such as unoconv.

Your main application remains in the standard environment and can call this microservice directly via HTTP, or if you anticipate the conversion will take a long time, the application can use Cloud Tasks (beta) or Cloud Pub/Sub to queue the requests.

What's next

Map the services your app uses in the standard environment to their analogues in the flexible environment.

Was this page helpful? Let us know how we did:

Send feedback about...

App Engine flexible environment for Go