Python 3 is now available on App Engine standard environment
cloud.google.com
cloud.google.com
We still maintain a docker-based environment on AWS EBS which we were able to port over as well. Overall a fantastic experience. The App Engine Standard team provided stellar support too.
We did notice pure CPU performance on AE standard to be less than dedicated AE Flex instances, but on a price/performance ratio AE standard is 10X better for infrequently accessed micro-services which will allow us to migrate some of these to standard for great cost savings - as well as ramp up auto-scale to handle spikes automagically.
With Python 2 becoming officially deprecated in 2020 this means App Engine Standard just got a huge boost in long term relevance. Great for developers who want to deploy without having to deal with infrastructure.
Good to hear that AE standard - i.e. this vision of a 0-effort Python deployment support - is still relevant after all the Kubernetes-related announcements at Google Next.
PS: Regarding automagically handling spikes I have a warning that might be useful for you. The way AE load balancer works is that it:
0. A request comes.
1. AE checks for available instance. If none available:
2. Spins up new instance.
3. !!! Assigns the request to that instance.
4. Waits for /_ah/warmup to finish.
5. Adds that instance to its serving pool so other requests may be routed there as well.
Note that step 4 is after step 3, so at least one request will wait for /_ah/warmup. So occasionally you will see requests with high latency (if your warmup is slow, of course). Our latency requirements were quite high, so we ended up switching to manual scaling and heavily over-provision to handle spikes. That costed us good money, though.
But yeah, you should definitely do your own load testing. GKE or Flex are probably better choices if you need more control.
(I work for GCP)
Yes. this will allow us to offload async tasks & other non-critical tasks to standard. It will also allow us to keep lots of various staging environments available for testing / unit testing, and deploy dedicated instances that are fully contained without 24/7 costs for each instance.
Re - latency - absolutely, we've seen times where it can take 10-15 seconds to serve an initial request. Things are snappy afterwards.
This means that if you already have a significant app running on Appengine Standard, none of the built-in APIs are supported (memcache, images, search, task queues, email, etc). That's a significant blocker to anyone wanting to upgrade their existing Standard 2.7 app to 3.7.
The third category (Existing 2.7 Standard customers wanting to just upgrade to 3.7 -- which is me unfortunately) are going to be disappointed and stuck in a hard place, I think.
> We are progressively evolving the original App Engine APIs to make them accessible across all GCP platforms.
So I think they're planning a solution for you.
It uses the gVisor sandbox, allowing sandboxing at the process level. This in turns allow for fast turning up and scaling of apps.
Disclosure: I work for Google, on the App Engine Runtimes team.
Product Manager for App Engine here. Happy to answer any questions about Python 3 on the App Engine standard environment.
pandas and numpy
(I work for GCP)
> This new runtime allows you to take advantage of Python's vibrant ecosystem of open-source libraries and frameworks. While the Python 2 runtime only allowed the use of specific versions of whitelisted libraries, Python 3 supports arbitrary third-party libraries, including those that rely on C code and native extensions. Just add Django 2.0, NumPy, scikit-learn or your library of choice to a requirements.txt file. App Engine will install these libraries in the cloud when you deploy your app.
We have a python2.7 standard app in production. It would be a considerable re-write if we had to move away from ndb and taskqueue.
it doesn't.
"The ndb ORM library is not available for Python 3. You can access Cloud Datastore through the Cloud Datastore API. You can use the Google Cloud client libraries to store and retrieve data from Cloud Datastore."
Also I did find that someone wrote a ndb-like wrapper around the cloud datastore API. https://github.com/Bogdanp/anom-py I haven't tried it out yet.
Although i think any reasonable path to upgrading to 3.7 might need atleast some wrapper like that around the datastore(even if it's not 100% compatible), otherwise forcing people relying on that to re-write the entire data layer. At this point i might just start re-writing the app, to move to something with less lock-in like Mongodb. But i'd love to hear what other people's plans are for this.
[1] You can use the free tier with the new Python 3.7 runtime.
Here's how you configure your App Engine standard environment project to use Cloud SQL: https://cloud.google.com/appengine/docs/standard/python3/usi...
The Cloud SQL for PostgreSQL docs contain code samples to get you started: https://cloud.google.com/sql/docs/postgres/
This should all work with SQLAlchemy.
https://cloud.google.com/sql/docs/postgres/connect-app-engin...
Note that only node and Java are listed under non-Flex.
I got burned by this and had to start over with MySQL.
It is possible on the new (beta) Python 3. 7 runtime on AppEngine standard:
https://cloud.google.com/appengine/docs/standard/python3/usi...
If you try Cloud SQL and find that it doesn't work with PostgreSQL on this new runtime, that's a bug and we need to fix it.
Edit: Holy shit this is so bittersweet. I was relying heavily on the batteries included user management, logging, admin only handlers, and especially the super easy cron job definitions.
IDK what to think about this. It kinda takes away all the things that made App Engine worth it for me as a programmer who doesnt want to do dev ops.
All those things you mentioned in the edit should be supported in the new runtime.
Edit: I see what you mean. The deeply integrated services are removed in favor of more portable solutions, like Logging moving to Stackdriver Logging (though stdout is still logged automatically), Users moving to Firebase Auth, etc. Cron should still work fine though.
(I work for GCP)
Also according to this they are not supported directly anymore except logging might still work but the wording is unclear. https://cloud.google.com/appengine/docs/standard/python3/pyt... .
In short, it looks like you have access to the main GCP gRPC libraries. You don't have access to the GAE-only service libraries.
Disclaimer: was former GCP customer support.
[1] https://github.com/GoogleCloudPlatform/google-cloud-python -- small caveat, the repo currently states that they're not supported on App Engine standard environment. That will be updated soon to clarify that the Python 3.7 runtime on the standard environment is supported.
One Q: Does Google Cloud IAP work with this as an option for user auth? Would one follow the App Engine flexible environment pattern in their docs? The Cloud IAP docs still mention the Users API as the recommended approach for the App Engine standard environment without an exception for the Python 3.7 runtime.
In the context that it's taken them a decade to upgrade, just seeing "Python 3" makes me wonder if they're only supporting some ancient version like 3.4 or even 3.2.
Of significant interest to people who are stuck/like writing Python would be the async changes in 3.5 and 3.6. There have also been constant type annotation enhancements made throughout the 3.x releases.
Also, old appengine was built with nacl (remember that?) sandboxing. Anything that couldn’t be built under the nacl sandbox couldn’t run in app engine. Google realized this was a problem long ago but it takes time to rebuild your whole platform to eliminate such a fundamental dependency. That may have taken most of their focus, leaving little for other projects. and of course their new arch makes python 3 free so it’s difficult to have a parallel engineering effort that will be rapidly deprecated.
Launching these new unmodified Second Generation runtimes required us to develop new security and isolation technology (based on gVisor [1]). This allows us to securely run arbitrary code on shared data centers with isolation guarantees. This took us significantly longer than expected. The good news is, now that we have this new stack in place, we should be able to deliver runtime updates significantly faster.
https://cloud.google.com/blog/products/gcp/open-sourcing-gvi...
That said, they don't quite go into the details of what type of isolation is missing from standard containers - I'm curious. It does seem like it would have been ideal for everyone if LXC would have had better isolation, rather than having to run a userspace kernel emulator thingy for each container, but c'est la vie!