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.
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 Kubernetes Engine or Compute Engine without heavy modification.
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 manage.py 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.
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 alpha, 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 alpha or Cloud Pub/Sub to queue the requests.