Why would you autoscale more computation to wait for the database. Let’s be clear here. The database is the thing doing MORE computations. It makes more sense to autoscale the thing carrying out the task.
It makes zero sense to autoscale the thing simply waiting for the task. The only thing where I see this making sense is if your database already has massive compute resources allocated to it and your server has so little resources it can’t wait on the database. In that case autoscaling cpus on the requester side makes sense but this is rare. It’s so rare it’s minuscule that you’ll have more than 10k concurrent connections.
>But you also create clearer language/runtime independent code encapsulation.
I don’t understand why a folder isn’t clear? Why must it be an entirely new repo and a new deploy process and an entirely new allocation of cpus to wait for the database? Guys. You want to organize your code? Consider folders. Don’t use new repos. Don’t use new deploy processes. Infrastructure exists to scale not to organize code. Adding new infrastructure makes code complexity, organization and accessibility worse while increasing scalability. Don’t use infra to organize code. Use infrastructure to scale performance. That’s a rule of thumb. There are exceptions but those exceptions are rare af.
You want other services to touch this function? You can then make it an http route as well: So the server can trigger a coroutine in the handler OR the handler itself (which is also a coroutine) is the database call that reacts to other services calling the http route. Same effect as a lambda.
>It's a little bit like the difference between writing a monolithic piece of software and writing a bunch of command-line utilities and scripting them together using the shell.
Highly disagree. Imagine one of those command line utilities is “ls”. This overreliance on lambdas is akin to adding new Computers to the cluster in order to call ls.