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