The managed VM hosting environment
When your App Engine application is running in the cloud, Google provides a scalable number of instances of your app's modules. Each instance runs in its own hosting environment. From the beginning, the App Engine hosting environment has been a sandbox, containing your code, a webserver, and a language runtime. Aside from your application code, the other components in the App Engine hosting environment are immutable and managed by Google. The language runtime is modified in order to enforce the sandbox constraints, disabling some of the usual language APIs (such as access to the file system).
App Engine now offers a second hosting option: Managed VMs. The managed VM hosting environment lets you run App Engine applications on configurable Compute Engine Virtual Machines (VMs). The VM hosting environment offers more flexibility and provides more CPU and memory options.
Google manages the underlying VM hosting environment, ensuring that:
- instances are health-checked, healed as necessary, and co-located with other module instances within the project
- critical, backwards compatible updates are automatically rolled out to the underlying operating system
You can choose the hosting environment (sandboxed or managed VM) separately for each module in your application. This means an application can contain a mix of modules that use different hosting environments. For instance, you might use the sandbox environment for your client-facing frontend, and use a module running in a managed VM for backend processing. Note that every instance of any specific module will run in the same type of environment.
The following table summarizes the differences between the two App Engine hosting enviroments:
|Feature||App Engine sandbox||Managed VM|
|Instance startup time||Milliseconds||Minutes|
|Maximum Request Timeout||60 seconds||24 hours|
|Background threads||Yes, with restrictions||Yes|
|Scaling||Manual, Basic, Automatic||Manual, Automatic|
|Writing to local disk||No||Yes, ephemeral (disk initialized on each VM startup)|
|Customizable serving stack||No||Yes (built by customizing a Dockerfile)|
|Automatic in-place security patches||Yes||Yes|
|Network access||Only via App Engine services (includes outbound sockets)||Yes|
|Supports installing third party binaries||No||Yes|
|Pricing||Based on Instance hours||While in beta, based on Compute Engine Pricing for each VM. Pricing will change in the future.|
Also, note that Managed VMs differ from Compute Engine VMs in the following ways:
- Managed VMs are restarted on a weekly basis. During restarts Google’s management services will apply any necessary OS and security updates. Your application's image will remain the same across restarts. (This behavior is disabled if you switch a VM to user-managed.
- Users always have root access to Compute Engine VMs. SSH access to managed VMs is disabled by default. This ensures that the fleet of compute instances is homogenous and manageable. If you choose, you can enable root access to managed VMs; see Accessing VMs.
- Managed VMs are automatically located by geographical region according to the settings in your project. Google’s management services will ensure that all the managed VMs for a project are co-located for optimal performance.
Managed VMs use software containers to run multiple user spaces in one Google Compute Engine instance. A container is portable and isolates the runtime environment from the target machine. This means you can develop an application in a container that you test locally, and then deploy the identical environment to the cloud.
Managed VMs build and run Docker container images, which are specified by a Dockerfile. The file includes all the system and application software necessary to run your app, along with dependency rules that keep everything up to date. You use Google Cloud SDK commands to run this container on your local machine, or deploy it to App Engine in the cloud.
In order to use managed VMs, you must install Docker on your development machine.
You can build a managed VM application on a standard runtime, which is based on a Google-supplied Dockerfile (which can be modified and extended), or a custom runtime, which is based on a Dockerfile that you write from scratch.
A standard runtime is defined by a docker image that is preconfigured and created by Google. Every standard runtime contains a complete language implementation, with no sandbox constraints. A standard runtime has built-in support for the managed VM life-cycle and health checking requests, and also includes APIs that support these App Engine services:
Using a standard runtime in a managed VM requires minimal setup. You only need to add a few lines to your app's configuration file.
Each standard runtime uses a default Dockerfile, which is supplied by the SDK. You can extend and enhance a standard runtime by adding new docker commands to this file.
If you'd like to use an alternative implementation of Java, Python, or Go, or write code in any other language, custom runtimes are for you. Custom runtimes allow you to define new runtime environments, which might include additional components like language interpreters or application servers.
To create a custom runtime, you supply a Dockerfile with a base image of your choice, and add other docker commands as needed to build the desired runtime environment. Remember that with freedom comes responsibility. You must ensure that the components you've included in your Dockerfile are compatible, and are configured to deliver the desired performance.
When you use a custom runtime, you must write the application code to handle certain managed VM life-cycle and health checking requests. Read about custom runtimes before you start developing.
Applications using custom runtimes can take advantage of many Cloud Platform services using the public REST APIs, or client libraries, when they are available.
The following table compares the two kinds of runtimes.
|Feature||Standard Runtime||Custom Runtime|
|Dockerfile||Default file supplied automatically by the SDK||Hand-written by the developer|
|Dockerfile modifications permitted||Yes||Yes|
|Languages||Python, Java, and Go||Any software that can service HTTP requests|
|Configuration file||Python and Go modules use
|Start/Stop Request||Requests are handled automatically by default. You may optionally write your own handlers.||Your app will receive these requests but does not need to respond to them. You may optionally write your own handlers.|
|Health Checking||Requests are handled automatically by default. You may optionally write your own handlers.||You must write your own handlers or disable health checks.|
|App Engine Service APIs||Some API support is baked in. Read the Python, Java, or Go page for each runtime.||You must use the publicly available REST APIs for cloud services.|