Event-driven architecture is not a must-have to get started building with serverless

Almost everyone in the serverless community accepts that serverless has a significant learning curve and the event-driven architecture (EDA) paradigm can be a large part of that learning.

But IMO, a lack of EDA knowledge should not be treated as a barrier to getting started building with serverless. Don’t get me wrong, I love EDA and I use it in some form in almost all of my serverless apps. But over the years, I have built up a deep understanding of the following concerns which EDA and async message processing introduces:

• Idempotency
• Retries
• Partial failures in batches
• DLQs
• Throttling
• Debugging chorographed event flows
• Writing automated tests for async event-based workflows

Pre-serverless, architectures which involved asynchronous messaging were very difficult to achieve in terms of infrastructure and therefore many developers will not have been exposed to these concepts before. They can be difficult to grasp and introduce painful bugs if not implemented correctly.

But in my experience, many early-stage greenfield products can get away without using event buses, streams, queues or orchestrations and instead just build a simple synchronous CRUDL-like API. So if you have a team of developers all new to serverless, they could still build a non-event-driven v1 of their application whose code quality, performance, cost-effectiveness and architectural scalability is greater than that of any server-based applications they previously built.

Will they be using serverless to the maximum of its abilities? Of course not. But these EDA concepts can always be learned and applied as the product grows without increasing the upfront learning barrier when their focus is on getting the first version of their product in the hands of users.