What's your take on serverless architecture?

[amirkav]

HN community, we've gone serverless at my startup for the last 2.5 years, and I've seen its advantages on scalability, dev velocity, and cost efficiency. Like any other new technology, it's not a cure-all solution and may not be the right fit for some applications. But I'd argue that in the long-term it will be the de-facto solution for a vast majority of cases.

I've published a write-up on serverless architecture, and plan to write more. I'd love to get HN community's take on serverless. Do you use serverless components in your organization? In what capacity? Do you have any gotchas or things you'd do differently if starting over?

https://blog.altitudenetworks.com/serverless-architectures-are-good-for-business/

[bquinn]

Yes here too, and I think it's great and it's the way forward, but as with anything it requires some changes in thinking and approach. Re-composing everything into small functions, queues, and asynchronous events takes some getting used to. And there are some patterns that can help (e.g. using "job queues" can sometimes be the answer, rather than having a different queue for every type of action), when to use FIFO vs unstructured queues, and lots more.

Books like https://www.manning.com/books/serverless-architectures-on-aw... might help. And of course many consultants, good and bad, will cash in on the new trend, and there will be some high-profile disasters which should never have chosen serverless in the first place.

[amirkav]

Thanks for the link. Anything by Yan Cui is definitely worth a read!

I'd argue the most important value prop that serverless has had for us was to force us think of everything in terms of an event-driven process, with small batches of job being done at every invocation. This is such an underrated benefit of going serverless/event-driven: together with job queues, this has enabled us to maintain control of our jobs from outside the code, without a need for re-deployment. We can fast-forward, pause, stop, rewind our long-running jobs simply by changing the event triggers or sending a new message to the queue.