Why I (can not) choose AppEngine Flexible

[Attila-Mihaly Balazs]

Hello all,

I would like to kick off this discussion because I think the Google AppEngine team is missing an opportunity to differentiate themselves from the competitors.

First, a quick rundown of why I've chosen AppEngine many years ago and why I continue to use/recommend it:

- the free tier (important to try stuff out)
- managed services (like Memcache, Datastore, Taskqueues, CloudSQL)
- automatic scaling / failover
- automatic patching / updating / tuning of the instances

In short, I want to focus on delivering the solution to my stakeholders and I don't have the time to become ops (even though ops is very important). Also, I have confidence in the world-class ops team at Google that they will keep my app secure and well-performing.

Of course this is not to say that everything is rosy. One big painpoint was/is the lag of updating the runtimes (only recently did we get Java 8 - god knows when we'll get Java 9 - and Python 3 isn't even discussed - even though major libraries are dropping support for Python 2 soon). The other one is the inability to "bring your own libraries" if they require native code. And finally sometimes there is a general flakyness to AppEngine, but that's just a fact of life when running on such a large distributed system.

So the new AppEngine flex offering comes out which is basically "we run your docker image using the autoscaler". Which is great, but looses many of the advantages of AppEngine standard:

- free tier? forget it
- managed services? some yes, some no (like memcache), some in beta with limitations (like taskqueue - I think you can't submit push tasks with AppEngine Flex)
- the big one for me: NO automatic updating / patching / tuning / optimizing of your runtime environment (see the discussion at [1])

So basically: I'm paying more (since AppEngine flex is more expensive) and I get less performance (since Google engineers are not assisting me in tuning Nginx / the JVM / etc inside my container) and I have to play ops by following the security discussions for the different parts of my stack and diligently rebuild/patch my containers.

At this point I'm like: screw it, there is very little difference between running a bunch of docker images on the Google Cloud vs any other competitor.

But this could be very easily be fixed:

- offer a "no questions asked, here are $300 / month" tier on Google Cloud which the user can spend on anything (including running AppEngine flex instances, CloudSQL instances, etc). It could even be $10 / day to avoid the "because of a bug I just used up my monthly allowance" kind of situations
- allow flexible environments to scale down to 0 instances. The "it's slow to start up" seem bull, since a docker container is just like a process - isolated using namespaces, cgroups, etc. So it's not like you have to boot a VM to serve the first request
- have an official base image (based on Debian for example) and say: as long as your docker images are derived "FROM google-appengine-flex-base:latest", we promise to update/tune the underlying packages and apply it to your instances without you having to do anything
- commit to provide complete access to all the Google Cloud Services in a select number of programming languages (lets say C/C++ / Java - which covers the JVM languages / C# - covering the .NET languages / Python 3 / PHP - and the other languages can wrap the C library).

This is not some genius idea, so I guess the explanation for why this hasn't happened is internal politiking. Thus I would like to ask you: get off of that and make AppEngine a great PaaS again (currently it's just a good one).

Regards,
Attila

[1] https://groups.google.com/forum/#!topic/google-appengine/QulhjoBGlHc

[Jordan (Cloud Platform Support)]

I completely agree with your explanations on the current differences between App Engine Standard and Flexible, and why these differences of offerings between the two App Engine environments cause a desire for a type of feature unity to make Flex more like Standard (or vise-versa). 

We are very aware of all of the above mentioned discrepancies, and our teams are very hard at work on evolving the App Engine Environments into a state that posses these much needed solutions. 2018 will be a year of developing and evolving App Engine, as we focus on perfecting such features as the Google Cloud Client Libraries. Our engineers are also working hard on a possible scale-to-0 solution for App Engine Flexible, and are investigating possible solutions for Free Tiers for GAE Flex just to name a few (note that there is currently no ETA for these at this time).

Know that we listen very intently and are very aware of the much desired features for our products. We are constantly working hard to fulfill these desires and evolve App Engine and the Google Cloud Platform to be the absolute number one competitor in cloud computing. 

- If you would like updates on any of these feature requests it is recommended to officially request them in the Public Issue Tracker where the engineering teams responsible will be notified. 

[Steren Giannini]

Thanks for the detailed feedback. We value it a lot and it helps us orient the direction of our products.

Regarding managed services: A new API, currently in Alpha, called "Cloud Tasks API" allows you to submit push tasks from App Engine Flex.

Get whitelisted by filling this form: https://goo.gl/Ya0AZd

Thanks,

Steren

Product Manager 

Google Cloud Platform

[Handerson Contreras]

Hey Steren

How much time takes to enable the Cloud task api after fill in the form?

I already filled but i haven't received news

I am getting this error:

google.api_core.exceptions.PermissionDenied: 403 Cloud Tasks API has not been used in project <mi_project_id> before or it is disabled

I suppous the cause is because is not enabled yet, but i enabled it from here https://console.cloud.google.com/apis/api/tasks.googleapis.com/overview?project=myprojectid 

Or do you have an idea what could be the problem?

Thanks 

[David (Google Cloud Support)]

Hello Henderson,

I answered you in your thread.