Python 3 on Google App Engine flexible environment now in beta

I think you misread it. Unfortunately it looks like Python 3 is not going away. You did say big fat blemish, right?

> Anybody has a reasonable theory for why this took so long, despite users asking for it for years?

Well, initially, their investment in more runtimes was covering additional languages, not covering more versions of languages they already had. (IIRC, AE started with Python 2, added Java first, and then later Go and PHP.)

As that was happening, they gradually shifted focus from building out the old, fairly limited model of App Engine to building out other parts of the cloud platform, including (particularly relevant to future App Engine work) Compute Engine, to have a more robust cloud offering covering more use cases.

Then, they went back and returned to improving App Engine -- leveraging the now-broader cloud platform, and particularly Compute Engine -- shifting from the old model for new runtimes to the Flexible Environment (originally called "Managed VMs") model (built on Compute Engine, and which, in addition to including some additional Google-provided runtimes, means people can package up their own runtimes for App Engine).

Since doing so, they've released official Google runtimes for Python 3, Ruby (which people have been asking for longer than Python 3), and Node built on the Flexible Environment.

Especially amusing was that Guido was working on the GAE team for a while, and even that wasn't enough to get them to support Python3.

I think this is my main problem with Google services. It takes them forever to listen to people. And I don't think other cloud services listen any better but at least it seems they give you what you want faster. So they have a better mechanism to know what works and making a product of it.

On lowish traffic apps, it's way way more expensive as you have to pay for the VM's to be permanently running. AFAIK you also need to have 2 app servers running as they get restarted once w eek (at least thats how it is for Java apps I believe)

If you have very little traffic then what you are saying is true, flex GAE requires you to keep one VM running.

For our our app (Streak) we run 100's of instances, we moved some of our services from standard GAE to flex GAE and saw a HUGE reduction in costs. Depending on workload we saw 5x-10x reduction in cost. To see why this is possible, look at the price of a standard GAE instance and the price of a default flex instance. For roughly the same price you get a way more capable machine.

You just have to have enough traffic where you'd like to keep at least one instance running all the time. Enough traffic in this case is a really small number. If you're traffic is lower than that number than who cares about optimizing costs, its gonna be cheap no matter what.

We use a combination of both at my company. We use the standard environment for the majority of our services, doing things like proving APIs, serving webpages, performing datastore interactions, etc. The flexible environment starts to make a lot of sense when you're doing heavier weight processing, text analytics in our case. App Engine instances are relatively cheap when you're using the smallest instance sizes, and have even more benefits if your application has idle time when they can spin down completely, but costs start to go up very quickly if you need to move to the bigger instances in the standard environment [1]. The flexible environment is current billed at the rate of the machines you're using, so is much cheaper for bigger instances [2].

[1] https://cloud.google.com/appengine/pricing#standard_instance...

[2] https://cloud.google.com/compute/pricing#predefined_machine_...

You can absolutely use Postgres or Redis. If you spin them up on GCE you can connect to it from GAE Flexible. The only support lacking is a managed Postgres or Redis service like Cloud SQL does for MySQL.

You can use Postgres and Redis. :) I'm working on writing new tutorials for both of those, but in the meantime:

You can host your own Postgres on Compute Engine [1] or use a hosted provider like ElephantSQL [2]. You can use whatever client library you want to connect to postgres in App Engine flexible.

Same story for redis - you can host it on Compute Engine [3] or use something like redislabs.

[1] https://cloud.google.com/solutions/set-up-postgres

[2] https://www.elephantsql.com/

[3] https://cloud.google.com/launcher/?q=redis

[4] https://redislabs.com/

Note: I'm in Developer Relations for Google Cloud Platform

I wish there were a clearer delineation between developer downloads on PyPI and automated builds, since it seems there's been a bit of a cultural sea change over the past year or so in favor of Py3. I'd love to know which version humans are downloading.

> if/when ruby is supported

Ruby (and Node) are supported on the Flex Env the same way Python 3 is. JRuby may also be usable on the standard environment's Java runtime (ISTR seeing a how-to in the past, but I also seem to recall at one point seeing that there were some issues.)

Note that Django has worked on App Engine standard for many years now and in fact the App Engine SDK still distributes a Django build.

More info on the different Django+AppEngine options here: https://cloud.google.com/python/django/ https://code.djangoproject.com/wiki/AppEngine

Disclosure: I'm an engineer at Google.

I felt Google was much easier to get started in than AWS. And it's easy to forget that it's quite possibly the most complicated system most people who use it interact with. It probably has a few magnitudes more expressive power of a, say, a webpack+babel+package.config (yeah, hard to measure, I know). And that's a competition it easily wins.

Developer Relations team exists so that doesn't happen so sorry to hear. Part of the problem is some of our feedback mechanisms need work. If you go to:

cloud.google.com/python

You'll see we have a lot of tutorials that link to Github repos . If you file issues there you are more likely to get help. The caveat is we are not a support team and have no guarantees (just a likelihood), so if you need paid support look into our options for that instead.

Have you compared it to AWS?