[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.