Microservice architectures only work when they:

Are split into clear Services

Can be deployed independently

Only communicate with each other asynchronously

Master their own data

Service-Oriented Architecture (SOA), a term that preceded Microservices, has very similar tenants. SOAs often differ from what we see as modern Microservices in their communication mechanism.

One popular variant of the SOA approach is the Event-Driven Architecture (EDA) paradigm in which services consume and produce events, allowing a loosely coupled interaction between services. Such an approach to SOA often relied on an Enterprise Service Bus (ESB) to provide the transport of these “Events”.

An Example SOA using the ESB

What is an Enterprise Service Bus (ESB):

Enterprise: Implies use in large Enterprise organisation as often used to tackle complexity in these domains along with the historically large infrastructure investment needed.

Implies use in large Enterprise organisation as often used to tackle complexity in these domains along with the historically large infrastructure investment needed. Service: As this is providing a way for the different Services (logical self-contained representations of business processes) to communicate.

As this is providing a way for the different Services (logical self-contained representations of business processes) to communicate. Bus: Referencing the hardware element of computers that allows the transfer of signals between different components.

Event: “A significant change in state” — K. Mani Chandy

EventBridge

“Bridge over Troubled Architecture”

In 2019 AWS launched a new Serverless service, Amazon EventBridge, formalising the flow of Events through Serverless architectures. Before this, many people working in an Event-Driven paradigm had been “hacking” a Bus for events on top of the CloudWatch Events.

For a full understanding of EventBridge see the previous article, EventBridge: The key component in Serverless Architectures and watch James Beswick’s great introduction video.

In short, EventBridge is the biggest Serverless announcement since the release of AWS Lambda and is the key component to building state-of-the-art Serverless EDAs.

Example of Default and Custom Event Buses in Amazon EventBridge

The ESB is dead, long live the ESB

To contrast with typical ESB solutions, EventBridge is completely Serverless. It requires no management and integrates easily with all the existing AWS services. By default, all AWS cloud events from CloudWatch go into a “default” EventBus and you’re able to build your own Event Bus inside EventBridge for your custom application Events.

Avoiding the “Lambda Pinball”

The Lambda Pinball is a Serverless anti-pattern highlighted by ThoughtWorks, in which “we lose sight of important domain logic in the tangled web of lambdas, buckets and queues as requests bounce around increasingly complex graphs of cloud services.”

This is often the result of a lack of clear Service boundaries. Moving to an EDA and adopting EventBridge can help massively — but this is not a standalone silver bullet.

What is needed is a focus on Services, identifying clear Bounded Contexts (to borrow from Domain-Driven Design) and sharing Event Schemas, not code, API interfaces or Data.

“EventBridge Storming”

Event Storming is a workshop approach to defining the Events, Boundaries and Entities in your business domain created by Alberto Brandolini as an extension to Domain-Driven Design (DDD).

Full-on DDD can be a lot to earn and master, and can result in over-engineering for systems without huge domain complexity.

Event Storming though can be used in isolation.

The following guide will lay out the steps to Event-Storm towards a state of the art Event-Driven Serverless Architecture based on EventBridge.

This variant of Even Storming we’ve ended calling EventBridge Storming. The focus is less on formal DDD, but in pragmatically structuring Serverless architectures based on EventBridge.

“EventBridge Storming” can be used on Serverless greenfield or brownfield projects, ranging from the extremely simple to the scarily complex. I ensure a common language, maximum understanding of Events in business domain terms with a list of independent Services to create and a Schema to create in the EventBridge Schema Registry.

Benefits of “EventBridge Storming”

Reduced Coupling

Faster development speed in the medium to long term.

More adaptable architecture & reduced rebuild risk

Reduced code requirements

Better system ownership by teams

Improved availability

EventBridge Storming Guide

“EventBridge Storming”: A specific variant of EventStorming that reduces rework and tight-coupling for teams building state-of-the-art Serverless Event-Driven Architectures with EventBridge.

EventBridge Storming, based on Event Storming, starts with the business and technical members of a project conducting a whiteboard workshop to understand their systems. This is done, ideally in person, with lots of Post-It notes to hand. Typical Event Storming has particular guidelines around Post-It colours, though we’ll be focusing on Events and these rules are less important.

Following the whole team workshop (steps 1–5), the technical team will take the output of this session and continue to encode this into the architecture (steps 6–8). This whole process should be done in less than a week, with steps 1–5 done in a 1-day session. The exact timing depending on domain complexity and team cohesion.