Introduction to Amazon EventBridge
- Authors
- Name
- Tomasz Łakomy
- @tlakomy
In the serverless world, everything revolves around events.
Your (micro)services are responsible for either producing or reacting to different kinds of events (e.g. API calls).
When you have an architecture where (for example) a single API call can trigger a Lambda function that saves something in DynamoDB which triggers an event in DynamoDB Stream which in turn triggers another lambda function which then... you know what I mean. Things can quickly become incredibly hard to control and reason about.
Intro to Amazon EventBridge on YouTube showcases an example of an architecture that starts nicely decoupled:
but quickly spirals out of control, once more and more services are added to the mix we essentially end up with a monolith. The reason it happens is that the order service needs to be aware of changes in e.g. the forecasting service
To sum up: choreographing APIs is hard.
Figuring out the happy path (that is - when every service 100% works as intended) is not the hard part - but what happens when something goes wrong? When one of the inter-connected services has a much longer reponse time or it's down entirely?
Managing that kind of complexity is not trivial (to say the least).
Events are observable, not directed
The idea is to move from directed events to observable ones.
What that means is that services are no longer giving commands to each other:
Hey, please create an invoice for account #123
instead, they inform (that is - send an event) others (by screaming into the void) that something has happened:
Customer #456 has ordered a Giant Rubber Ducky, don't ask me why, he just did
That is a major shift - the idea is that whoever sends an event doesn't need to be concerned with who's listening. Similiar to a radio broadcast, which is transmistted over radio waves regardless to whether you're listening to it or not.
An architecture like this leads to less coupling between services because they may not even be aware of each other's existence.
Here's where Amazon EventBridge helps, by providing an event bus:
Instead of calling each other directly, with EventBridge services produce events (that's why we call them producers) and have other services consume them (that's why we call them consumers).
The most important part of the puzzle is the fact that only the consumers that are interested in a specific type of event will get it.
So for instance, if a cancelNewsletterSubscription event gets sent to the EventBus, a service that doesn't care about this kind of event (e.g. invoiceService) will not receive it at all.
As such, EventBus takes away the complexity of ensuring that events end up being forwarded to consumers that are interested in them - allowing developers to build more predictiable interactions between services in AWS.
TL;DR
Amazon EventBridge is a serverless event bus service for SaaS and AWS services.
It's fully managed, using the pay-as-you-go model (1 USD, a single dollar, per million events put into the bus).
EventBridge doesn't support only AWS servies - multiple third party SaaS providers are supported as well.
You can check out the video that this post was based on here
I'd like to learn more about AWS, how can I do that?
Check out those resources to learn more:
Tired of switching between AWS console tabs? 😒
Cloudash provides clear access to CloudWatch logs and metrics, to help you make quicker decisions.
Try it for free:
