What I never get with these is: one has to really go out of their way to run the same code on a vm and serverless. So why even bother building the thing twice?
Do people really consider putting a server app in a function?
Do people really consider putting a server app in a function?
I'd put a server app up behind a cloud run endpoint, sure, as long as it can fit in a few GBs and start in a few 100 ms. The scale-to-0 aspect is nice, and the scale up aspect is nice too.
For GCP cloud functions, AWS lambdas, Azure cloud functions you must fight somehow against the environment (that's the reason frameworks like Zappa exist).
If you want/need to use compute instances, you can use KNative in your K8s cluster and enjoy a "similar" scaling experience.
Thanks, good to know it’s a common technique.
Time elapses. What makes sense today may not tomorrow. It's fine to adapt designs when the economics point that way. Also fine to leave things as they are when the economics point that way.
It’s “interesting”
To prevent 404s hitting your function you have to define your routes in both your code and in api gateway. This starts to marry your code to your deployment.
Observability is now harder and you need yet another thing. We’re using X-ray with datadog.
To “safely” talk to Postgres you should use an rds proxy. It’s still unclear how much is different from pgbouncer or similar but in any case it’s pretty easy to knock over your db with runaway lambda invocations.
I could go on about the mistake we made of using SAM and how it ends up not supporting everything you need but I guess my main point is it’s easy to get sucked in by the idea of it being easy but you are trading that for service / operational complexity with a healthy dose of platform lock-in.
I need to spend some more time playing with Cloud Run because I wasn't aware of the concurrency bit you are mentioning.