Introduction to Google Cloud Functions
ncona.com
ncona.com
Consider checking the following: - Number of CPUs. The number of CPUs is not CPU cores but Kubernetes millicores. 1 vCPU on CR = 400m (4/10 of a CPU core). - Background processes - not recommended [https://stackoverflow.com/questions/61154349/google-cloud-ru...] - Container size on disk. Google Cloud is fast. However they need to cap the moving container images around as they can't use all the network capacity for moving a 400MB Docker image. If you're not already, use multi-stage builds with tiny final images.
> Limits and requests for CPU resources are measured in cpu units. One cpu, in Kubernetes, is equivalent to 1 vCPU/Core for cloud providers and 1 hyperthread on bare-metal Intel processors.
(code is here BTW https://github.com/futurice/terraform-examples/tree/master/g...)
However you can set the minimum instance count now. That feature was opened up for Cloud Run managed a few weeks ago.
There is a cost for doing so as instances kept running in this way do incur billing costs [1].
I've done some work with Ruby in the past, and based on my experience, you might not be able to take advantage of Cloud Run's best feature, concurrency[2], which is another way to reduce cold starts by routing concurrent requests to the same container instance. Ruby maybe blocking in flight requests and forcing us to fire up another instance to handle it. Once the first request has completed there is a chance the container instance processing that request will be spun down, this is something minimum instances can help with. You might need more than one minimum instance to compensate for the lack of concurrency if you really want to see improvement in overall latency.
[1] https://cloud.google.com/run/docs/configuring/min-instances
AppEngine has been around for a long time, 12 years to be exact, and in my mind it's a completely different product, and still one of our most successful. While Cloud Run competes with AppEngine on some fronts, customers really appreciate AppEngine's deep integration with other GCP managed services. It's a full blown PaaS.
I expect Cloud Run to improve over time and gain more features that will no doubt match the requirements of many AppEngine customers, some may switch to Cloud Run, but we are not forcing them to.
Cloud Functions already shares a lot of underlying infrastructure with Cloud Run, which shares a lot of underlying infrastructure with AppEngine, and that's by design. These days I like to think of Cloud Functions as a simplified developer experience on top of Cloud Run focused on task orientated workloads backed by events and triggers.
Can we continue to support 3 somewhat overlapping Serverless platforms going forward? I believe the answer is yes, thanks to the shared infrastructure, and the fact we truly believe all three platforms offer a unique set of developer experiences worth preserving. Maybe there is future state where one product satisfies all use cases, but that's not today, so we plan to keep listening to customers, and invest across the board.
One recent example of investing across the board: you can now leverage global load balancing[1] across all three Serverless platforms.
[1] https://cloud.google.com/load-balancing/docs/negs/serverless...
Though I will say I dearly miss the days of first generation GAE standard, when things like memcache, taskqeue, datastore, auth and logging were all baked in as first-class citizens and Just Worked™.
I wouldn’t call JVM application servers legacy. If you are referring to WebSphere and Weblogic, then maybe. But the open source JVM application servers like tomcat,jetty, netty etc., are widely used in modern applications
Pro: - They are stupid fast to develop, deploy, and update. - Firebase tooling emulators makes local dev much easier. - Simple enough a developer can build, deploy and monitor; Cost less then hiring another person to handle devops. - Now has decent IAM restrictions - Baked in access to almost all other GCP tools.
Con: - Like any google product could be deprecated at any time. - They have poor versioning compared to App Engine or Cloud Run. No rollback, A/B, or multi-version deployments - Cold starts are slow. - Like any google product could be deprecated at any time.
I think my team will be shifting to use java more, just out of sheer familiarity, but golang works nicely for functions.
1) The pricing is listed as per invocation however it is also billed for the CPU seconds and It happens that on a low volume function usage I exceed the free quota exactly on that as the invocation numbers remain very low.
2) The functions take about 10s-15s to execute on cold start. Every execution that happens between something like a minute is a cold execution. It is also billed as 15s execution even if the actual script runs for 200ms.
3) The CPU second are calculated according to time and VM memory, so if your function happens to make a call to another API and sits idle for 5s for response to arrive, you are still billed as 5s full memory usage.
Which makes me wonder why I would't spin a DO droplet instead. Maybe it's good on very high volume but from experience I know that a 5$ NodeJS droplet can handle hundreds of concurrent request. That would probably cost a lot on Google Cloud Functions. On low volume DO droplet performs much better anyway.
This may be a bit of an exaggeration, and may vary depending on your deployment (from experience, it takes up to 5s at most), but I agree. There is a very noticeable cold start time which makes it not ideal for any business critical services. It is probably only good for things like document conversions.
There is some latency in the infrastructure but I have found that most of the delay is puling the image and actually starting the app. So small images with few layers and fast boot up will help a ton.
Wait, you get billed for cold starts?
Cloud functions: when you need a endpoint to run, don't need fast response times, don't have more than a few hundred lines of code in a contained class, that don't often run. Think image resizing, async email calls, etc.
Cloud Run: when you have a simple docker file that can run your code, don't mind paying a higher cost, can't take the bootup time of Cloud functions, light or no database connections, need specific os'es or hardware AND you consider k8s confusing. Think wordpress, microservices, or demo software that come self contained in docker,
k8s: when you are an k8 expert
vms: for anything else.
At least kubernetes has defined for you what the orchastration and configuration files should look like. With VMs you have to figure all that out yourself, unless you are happy just installing everything manually via SSH and apt-get.
I wouldn't advise someone to spin up a key part of their infrastructure on Cloud Functions if they're not already using GCP for other things. But once you're there, it's a very useful part of the ecosystem.
I feel the monitoring/instrumentation around errors/performance is not great, but could be.
If Google could ever lift these restrictions, GCF would be perfect for auto-scaling ML models.
I don't think I had any issues loading larger files from Storage either.
Generally speaking, you want it to do something simple and quickly
I have a few workloads that execute only very infrequently, which makes them suitable for functions, except when they do run they sometimes exceed the 10 minute timeout.