Google App Engine Flexible Environment status

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 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. 

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:

For GAE table obtained from (as of July 2016)

Instance Class  Memory Limit  CPU Limit  Hourly Price
B1128 MB600 MHz$0.05
B2256 MB1.2 GHz$0.1
B4512 MB2.4 GHz$0.2
B4_1G1024 MB2.4 GHz$0.3
B81024 MB4.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

Instance Class  Memory Limit  CPU Number  Full Price  Sustained Usage Price
f1-micro600 MB1 CPU shared$0.008$0.006
g1-small1.7 GB1 CPU$0.027$0.021
n1-standard-13.75 GB1 CPU$0.05$0.038
n1-standard-27.5 GB2 CPU$0.1$0.076
n1-standard-415 GB4 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.

My story

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:

  • App Identity
  • Cloud Storage Client Library
  • Datastore (ndb)
  • Logging
  • Mail
  • Memcache
  • Multitenancy
  • Search
  • Task Queue
  • URL Fetch
  • Users

but these are not:

  • Blobstore
  • Capabilities
  • Channel
  • Datastore (db)
  • Endpoints
  • Images
  • Logservice
  • OAuth
  • Remote
  • XMPP

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!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


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...

blog comments powered by Disqus