3 ms·
Bit of survivorship bias there! No-one is going to hire you to port off of serverless, if they're happy with it. Ergo you only see cases where it isn't working
by unusualmonkey 3y ago
Bit of survivorship bias there! No-one is going to hire you to port off of serverless, if they're happy with it.
Ergo you only see cases where it isn't working well.
- jpgvm 3y agoYeah that is fair. There is probably serverless chugging away fine in lots of places. Doesn't make it better than alternatives but still a valid point.
- unusualmonkey 3y agoI use serverless successfully - handing tens of millions of annual revenue. We do this in a handful of small services, none of which gets much traffic. The alternatives (e.g. app-engine, container in vm, or k8s) all require more infrastructure, would cost more (no scaling to zero), and are overall less suited for the kinds of problems we expect to see.
- slrainka 3y agoI too have a small team that built a greenfield application that generates about $100M annually for a large hotel chain. Serverless allowed us to get to market fast and everyone in the team is a feature developer — 0 infra folks. I think that’s the biggest value we have been able to derive from this compared all the other internal App teams who struggle with release cadences, experimentation and TTV. But I fully acknowledge this is not the ideal and optimal setup and we are paying more to AWS on the OpEx. However, we have gone 3 years without any downtime at full speed, and the fact that we were able to unlock net new revenue very quickly has made all project costs and OpEx very minuscule. But I think once the application boundaries stabilize and we are able to take a breather from full on feature development, hope to migrate some of this to simpler containerized infrastructure. To make this transition easier, we use Serverless-framework and decouple the app component architecture from deployment architecture, so developers don’t worry whether this is getting deployed to a lambda or container.