Before we start - I'm working on https://cloudash.dev, a brand new way of monitoring serverless apps 🚀. Check it our if you're tired of switching between 50 CloudWatch tabs when debugging a production incident.
In the serverless world, everything revolves around events.
Your (micro)services are responsible for either producting 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
One more thing
If you'd like to learn some AWS for free from yours truly, check out those free video collections on egghead.io:
I'm also launching an AWS Cloud Development Kit egghead.io soon and to sum up why you shoul...might be hyped to take it:
AWS Cloud Development Kit allows you to build the entire stack (frontend, serverless backend, AWS infrastructure) using a single programming language - TypeScript!
Top comments (1)
Exactly. :-)