- 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.
So how it works?
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:
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:
Cloud Storage Client Library
but these are not:
For me personally the most painful is lack of Channel, Endpoints and Blobstore APIs.
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...