stewart27

I think you can force cold starts between your tests by re-deploying your function/container. You could (optionally) leave a small buffer (<1 minute) after the deployment to ensure that traffic has fully migrated.

+1

You can also set up Cloud Scheduler to push to Pub/Sub, which can trigger your function. This is helpful if you don't want your function to be available via a public HTTPS endpoint.

Cloud Functions PM here.

Your intuition around concurrency is correct: Cloud Functions has "per instance concurrency" of 1. Cloud Run lets you go significantly higher than that (default 80). This means that our infrastructure will generally create more instances to handle a request spike when using Cloud Functions vs. Cloud Run.

Creating an instance incurs a cold start. Part of that cold start is due to our infrastructure (generally this is small) but the other part is in your control. For example: if you create a client that takes X seconds to you initialize, your cold start will be at least X seconds. The initialization time will manifest as part of your cold start.

This has a few practical implications:

* writing code for Cloud Functions is generally more straightforward as single concurrency solves many problems regarding shared variables. You may also see some benefits in terms of monitoring/metrics/logging since you only need to think about one request at a time.

* you will likely see a higher incidence of cold starts on Cloud Functions during rapid scale-up, such as in response to a sudden traffic spike

* the impact of a given cold start will depend heavily on what you're doing in your container

* though I haven't validated this experimentally, I would expect that the magnitude of any given cold start (i.e., total latency contribution) would be roughly the same on Cloud Run as Cloud Functions IF you're running the same code

Indeed. If you want to compile the binary yourself/don't want to upload source code, we have a serverless containers product currently available as an early preview (sign up at g.co/serverlesscontainers). This would allow you to compile your binary locally, write a simple Dockerfile and then build/deploy the resulting container.

If you're interested in something along the lines of the latter, you can sign up for an early access preview here: g.co/serverlesscontainers

It's definitely something that we've discussed.

Would you consider running a container that could be run like Cloud Functions? This container could run the binary that you create. It's not something that we support today but I'm curious whether this would meet your needs.

> I'm curious how the implementation of Go has affected the ease of integrating other languages.

In some ways, it helps. You start to see similar issues arise and know what to look out for when you're launching a new runtime. In other ways, every language has its peculiarities and its own set of design considerations.

Launching/polishing a completely new language still takes a decent amount of work. Launching a new version of an existing language tends to be much quicker.

While I can't share details publicly, I can confirm that we're actively working on new runtimes and performance improvements.

Which ones would you like to see? We're always looking for new use cases to support.

Cloud Functions PM here. I can give some insight:

* We've been running a private early access preview/alpha since last August.

* This was our first compiled language on Cloud Functions, which came with its own set of challenges.

* It took us a while to find the right approach for supporting dependencies (both Go Modules and vendoring are supported). Unlike other providers, when you deploy your source code, Cloud Functions will automatically install dependencies listed in your go.mod file.

* Our testers gave us a ton of feedback that helped us polish the developer experience -- we identified and fixed many rough edges related to error messages during deployment/build and errors at runtime. Serverless products can be a bit opaque (since you can't just ssh into a machine), so getting this right is important.

I'd like to say that there was one big, interesting challenge that we had to tackle. But the reality is that we worked through many small details that only became apparent during testing. We wanted to address these so that we could offer a high quality experience for our public beta launch. We owe our alpha testers major credit for helping us find and solve issues.

Speaking of testers -- if you have feedback on the runtime, we'd love to hear from you in our Cloud Functions Beta Tester group [1].

[1] https://cloud.google.com/functions/docs/getting-support#beta...

You're not wrong. Cloud Functions Product Manager here. We've been running a private early access preview since we first showed this at GopherCon in August. I'm really happy to see this first step but we have a lot of work ahead of us.

The Google Cloud client libraries [1] are fully supported. You can use these to access services like Datastore, Spanner, Natural Language, and many other Cloud services. They work on this new runtime, on the flexible environment, on a VM, your local machine, etc. In my opinion, this is the most Pythonic way to integrate Cloud services in your app while maintaining portability.

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

Hi optimusclimb -- just want to make clear that using Cloud SQL to connect to PostgreSQL should work using Python 3.7 on the App Engine standard environment. Your earlier comment accurately pointed out a gap in our docs. We're going to address that -- thank you.

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.

Yes, Django and Django 2.0 (which only supports Python 3) should work.

Sure, feel free to send it to me directly. stewartr at google.com.

They're both available as early access previews. You can request access via the sign up forms.

Thanks for noticing this. We'll get this updated.

This is supported today! https://cloud.google.com/functions/docs/writing/

You would use Cloud SQL to access PostgreSQL.

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.

We're working on suitable replacements for these services. In some cases, e.g., Cloud Tasks, we're pretty close. Others will take a little longer. We'll share updates as we make more of these services available.

I'm not aware of this issue. Can you point me to a public bug/GitHub issue?

There are no changes to the free tier[1] or to apps running using the existing Python 2.7 runtime in the standard environment.

[1] You can use the free tier with the new Python 3.7 runtime.

Long story short: security is hard.

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.

[1] https://github.com/google/gvisor

Yes, this runtime supports arbitrary dependencies specified via a `requirements.txt` file. If you find a library that doesn't work, please let us know. In general, anything that works using an open source Python 3.7 distribution should be supported.

Hi all,

Product Manager for App Engine here. Happy to answer any questions about Python 3 on the App Engine standard environment.

Python 3.7 on the App Engine standard environment was announced today but not yet released to the public. We'll have more to share soon.

Hi lazypenguin -- in case you're still interested in Python 3 support on App Engine -- we're working on it. If you'd like to be included in a private alpha test, please complete this form: https://docs.google.com/forms/d/e/1FAIpQLSfLXViTUmtY6Ed_Gm9H...

Hi, I'm a Product Manager on the App Engine team. We're actually (finally!) gearing up to offer Python 3.

Would you like to be an alpha tester? Here's the sign-up form: https://docs.google.com/forms/d/e/1FAIpQLSfLXViTUmtY6Ed_Gm9H...