Flexible environment

To address this gap, in March 2014, Google released App Engine Managed Virtual Machines. Managed VMs gave App Engine the ability to run each App Engine instance on an individual Compute Engine instance. The underlying virtual machines were fully managed; developers didn't need to worry about things like security updates. Developers could still focus on the application layer, but the addition of a dedicated VM introduced much of the associated flexibility. In many ways, this was the best of both worlds.

As the platform progressed, Google introduced the App Engine flexible environment as a full-fledged, container-based alternative to the standard environment. This new flexible environment builds on and ultimately replaces App Engine Managed Virtual Machines. With container technology, the App Engine flexible environment gives developers the ability to take control of the environment their application runs in. Applications that need to access native libraries can be packaged in a container that includes those libraries. Applications with complex background threading have that power.

For many languages, the App Engine flexible environment is capable of behaving much like the standard environment—developers provide the application code and a configuration file and App Engine flexible understands how to package, deploy, and run the application. With the introduction of custom runtimes, developers can use virtually any language. Developers can assume control over the underlying infrastructure as needed.

So, why would anyone opt to use the standard environment over the flexible environment? For one thing, the flexible environment still introduces some level of complexity. The easy-to-use service integrations found in purpose-built App Engine standard APIs are not available. Instead, applications must rely on the Google Cloud Client Libraries, which are the same client libraries and APIs used outside of App Engine. The upside to this is that applications tend to avoid much of the vendor lock-in seen in the standard environment.

Because the App Engine flexible environment introduces more developer freedom, the platform is less able to make assumptions about the application, which can complicate service integrations, as seen in the need to use the general Google Cloud Client Libraries. Additionally, because each instance in the flexible environment is run on a dedicated VM, instance startup time is significantly longer than the standard environment. This can lower developer velocity and negatively impacts scaling speed. Additionally, the underlying resources in the flexible environment can result in higher running costs.

From the point of view of managing and integrating App Engine services, the standard and flexible environments are fairly similar. For many teams, the decision of which environment to use is better made on a per-service basis. For example, front-end services that experience widely fluctuating traffic loads are likely good candidates for the standard environment, while services that perform longer running tasks with relatively stable traffic may be better candidates for the flexible environment.

The following are the languages which are supported by the App Engine environment:

*At the time of writing, the Node.js standard runtime is available in beta. Node.js and Ruby flexible runtime versions are configurable, and the default values are listed.