You can do all of your use cases with serverless, as guitarbill and others have explained. My approach is: when starting from scratch, start with serverless, an

You can do all of your use cases with serverless, as guitarbill and others have explained. My approach is: when starting from scratch, start with serverless, and only when you hit its limits (I haven’t yet) go back to VMs. The rationale is that serverless will allow you to be production-ready quicker (at least from my perspective, seeing as I don’t have a strong sysadmin background), with less chance of shooting yourself in the foot security- or configuration-wise, for a fraction of the cost as long as your traffic isn’t huge. And you don’t have to get out of bed at 4am to fix a broken server :D Only when you start hitting performance issues, or you absolutely can’t make a feature work, or you can significantly lower your bill by using VMs (taking into account the cost of managing these VMs) should you try with a classic architecture. The closest analogy I can come up with is using a higher-level language (say Python) over a lower-level language like C. Unless you’re a C guru, you’ll end up implementing it faster and more safely in Python. And when/if you start hitting Python’s limitations (speed...), you can replace the critical parts with specific, highly tuned C code.