I am writing this article out of my own personal experience working with GAE Flexible environment (more precisely one case where it didn't work out so well).
Note April 2017: I've written two more articles about Google App Engine Flexible since this one became kinda obsolete and some things changed during period: Reflections on Google App Engine Flexible going Beta and latest Google App Engine Flexible (with example)
Google announced Google App Engine Managed VM (called at that time) in March 2014 https://cloudplatform.googleblog.com/2014/03/bringing-together-best-of-paas-and-iaas.html. Idea is simple. When looking at the Google Cloud Platform offerings, you have two extremes if I can call it like that:
- Google App Engine, which is Platform as a Service: Supports 4 languages (Python, Java, Go, PHP). All languages have limited use of their libraries but on the other hand you get platform were everything is managed for you: servers, database, deployment, scaling
- Google Compute Engine, which is Infrastructure as a Service: basically bare metal with operating system, and it's up to you how you gonna use it. This of course gives more flexibility but also requires more work, configuration, administration.
Managed VMs (or GAE Flexible Environment - GAE FE) should fall somewhere in between: keep good automatic stuff (scaling, deployment, monitoring etc.) and provide more flexibility regarding software that can be used.
With few lines in GAE config (app.yaml) file you can set Flexible Environment and run/deploy it. All runtimes are basically Docker images that are deployed to Google Compute Engine (GCE) instances. There exists Docker images for Python (both 2.7 and 3.4), Go, Java, Node.js, Ruby runtime, but it should be possible to run "whatever" (don't take this literally) Docker image. If you use provided runtimes you don't mess with Docker images explicitly, they are created during deployment. It's praise worthy that there is possible to run "compat" runtimes, i.e. runtimes that are compatible with standard GAE runtimes in other words when using those, you get everything (in terms of GAE services) as in standard GAE.
Since instance(s) are GCE Virtual Machines, it means that they start slower than native GAE instances but on the other hand we have more flexibility to choose from GCE instance types and also price is more favourable for GCE than GAE instances.
This last feature (price) is what attracted me to try GAE FE, so let's see price comparison:
For GAE table obtained from https://cloud.google.com/appengine/docs/about-the-standard-environment (as of July 2016)
| Instance Class | Memory Limit | CPU Limit | Hourly Price |
|---|---|---|---|
| B1 | 128 MB | 600 MHz | $0.05 |
| B2 | 256 MB | 1.2 GHz | $0.1 |
| B4 | 512 MB | 2.4 GHz | $0.2 |
| B4_1G | 1024 MB | 2.4 GHz | $0.3 |
| B8 | 1024 MB | 4.8 GHz | $0.4 |
It's not possible to compare GAE and GCE instance types directly since they don't have similar properties so I am including GCE types that are close to GAE. Full reference and more explanation is here https://cloud.google.com/compute/docs/machine-types
| Instance Class | Memory Limit | CPU Number | Full Price | Sustained Usage Price |
|---|---|---|---|---|
| f1-micro | 600 MB | 1 CPU shared | $0.008 | $0.006 |
| g1-small | 1.7 GB | 1 CPU | $0.027 | $0.021 |
| n1-standard-1 | 3.75 GB | 1 CPU | $0.05 | $0.038 |
| n1-standard-2 | 7.5 GB | 2 CPU | $0.1 | $0.076 |
| n1-standard-4 | 15 GB | 4 CPU | $0.2 | $0.152 |
It's also worthy saying that in case of GAE instance numbers represent resources those are available for app, whereas in GCE some part or resources are consumed by operating system etc. (can find anywhere written to confirm this, but I think that's how it works).
So for lowest GAE instance type 0.05$ with 128MB and 600MHz we get on GCE 3.75GB and 2.5GHz. Several times more resources for the same price.
One client of mine has website running on GAE. Not sure how many pageviews he has per month, in GAE dashboard it displays between 10 and 20 requests per second, and such load produces bill around 150$ just for GAE instances. Since websites traffic is relative boring (stable), no need for super scaling, my goal was to deploy it as GCE custom environment and use n1-standard-1 or -2 which should cost 26$/50$ per month.
So I dug in docs and app.yaml to properly configure python-compat environment, but then I run into this article: Migrate and existing app. Here is described what is necessary to take into account when migrating. One thing though that surprised me unpleasantly is the fact that not all GAE services are supported (which I would expect from "Compatible" environment).
So as of this day following Services are supported:
but these are not:
For me personally the most painful is lack of Channel, Endpoints and Blobstore APIs.
Good news though (and one thing that is not so obvious is that Flexible environment is in Beta and compat runtime in alpha (which explains current situation). Based on discussion here, Google is working on this https://groups.google.com/forum/#!topic/google-appengine/KYFyfWDeZ4I so sometimes in near or far future we will have fully compatible compat environment. Here is link for github repository of python-compat runtime https://github.com/GoogleCloudPlatform/python-compat-runtime
Main takeaway I guess is for creation of new applications (with GAE services) and deciding regarding architecture, which libraries to use etc. and having in mind that if you want to do it in Flexible environment or start first with Standard and then to migrate to Flexible this can be issue, so think about some different way to do it :) Migrating existing (old) GAE standard applications can be even more problematic (depending on the type of Services in use). I would say, the most important Services are working, which in many cases can be enough: NDB, Memcache, Task Queues, URL Fetch...