
What's your take on serverless architecture? - amirkav
HN community, we&#x27;ve gone serverless at my startup for the last 2.5 years, and I&#x27;ve seen its advantages on scalability, dev velocity, and cost efficiency. Like any other new technology, it&#x27;s not a cure-all solution and may not be the right fit for some applications. But I&#x27;d argue that in the long-term it will be the de-facto solution for a vast majority of cases.<p>I&#x27;ve published a write-up on serverless architecture, and plan to write more. I&#x27;d love to get HN community&#x27;s take on serverless.  Do you use serverless components in your organization? In what capacity? Do you have any gotchas or things you&#x27;d do differently if starting over?<p>https:&#x2F;&#x2F;blog.altitudenetworks.com&#x2F;serverless-architectures-are-good-for-business&#x2F;
======
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...](https://www.manning.com/books/serverless-architectures-on-aws-second-
edition) 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.

