Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The use case is lumpy work. You have some batch processes that are unpredictable. Could be hours without a call, then suddenly you need to scale up to 20 cpu to process a bunch of requests. One example is say processing pdfs in a crud app where people can generate pdfs on demand with large images.

I have used Azure Functions so I will talk to that: There are two options, one is a consumption plan where it is truly 'serverless' and they provide you with server time on demand. The other plan - app service plan - allows you to run these on your existing Azure resources. Another option is to get the runtime on a Docker image and run it on a container outside of Azure completely (but you lose a lot of the monitoring benefits).

Anyway the point is that at least in Azure you can sort of slide the dial to how 'serverless' you want to be - one extreme is the consumption plan, then you can go with the app service plan, then less serverless would be to run AKS (Kubernetes) with autoscaling, then to run VM's with autoscaling, then VM's with manual scaling, then finally perhaps rent a physical server in a data centre, then buy a physical server and stick it in a rack in your office.

The advantage of pure serverless over the less extreme ways is if you have wildly unpredictable loads going from 0 to high to 0 at different times, and don't want to (or can't) set up a reasonable scaling system to suit (or don't want to wait for the scaling to 'kick in').



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: