4 ms·
>The biggest selling point that seems somewhat legitimate is a bunch of these have scale to zero capability. This is pretty useful for on-demand code that is re
by AlienRobot 3y ago
>The biggest selling point that seems somewhat legitimate is a bunch of these have scale to zero capability. This is pretty useful for on-demand code that is required very infrequently and for which cold-starts are a non-issue.
I don't quite understand this. You can pay for 1 physical/virtual server and have apache serve 2 different domain names, right? Can't you just drop your infrequent app there so it shares resources with, I don't know, your more regularly accessed website?
The only scenario I can imagine this would be useful is if you own zero servers or the code is incompatible with the server you do own for some reason.
- jpgvm 3y agoWell you do understand it, enough to work out how to live without it. :P That said there are some key things a scale to zero serverless app has that solution does not. 1. Isolation. Your infrequent function may very well be infrequent but it's execution could then impede other code executing on that box (if it's computationally or I/O intensive for instance), or expose other code on the box to security vulnerabilities. 2. Independence. Similar to above but more addressing logical segregation. Once you are sharing a server or say piggybacking on a monolith as an extra endpoint there is now a lot of conflated concerns. For instance auto-scaling algorithms etc may not work well with the sort of intermittent/infrequent execution and it would be much better living in it's own context for that reason. Other things that end up all jumbled up: Cost accounting, IaC/deployment/CI/CD, ownership, observability, etc. Generally all of this still isn't enough to justify serverless but sometimes it could be... but in most of those cases just eating the cost of 1 replica and autoscaling on k8s is usually better.
- AlienRobot 3y agoThanks for the explanation, I really appreciate it!