Why Amazon EventBridge will change the way you build serverless applications
Last week, AWS announced Amazon EventBridge which is, in my view, the most important announcement in serverless since the release of AWS Lambda in 2014.
We were lucky enough to have the amazing Chris Munns give us a talk on EventBridge at ServerlessDays London just after the announcement, and I sat there with a huge smile on my face while he was giving the talk, because I could see how big it was.
EventBridge may not seem that important, if you look from the outside, but it has a huge significance when it comes to building serverless applications. In essence, it is simply an “event bridge”, allowing one part of an application to send an event (data) to another part of an application via an “event bus”.
But… we’ve seen events and event buses before haven’t we?
Yes, we have.
There is nothing particularly new here is there?
Don’t other cloud providers have something similar?
This is partly a rebranding of CloudWatch Events (which has been around a while) but with added features. So many people who have been using that service will be relatively aware of the kinds of use cases you can use this for.
However, one big addition is partner event sources. There are some partners on the platform already, and those partners can trigger an event in EventBridge.
That’s really big.
A partner can have something happen on their system, and automatically trigger something happening in your system on-demand, without the need for a webhook.
The security implications of partner integrations are the first thing that springs to mind. It’s almost certainly going to be easier to secure an integration with a partner in this way, than via a webhook, as AWS is the mediator rather than HTTP. The speed implications will almost certainly be improved as well, with those partners almost certainly using AWS events at the other end as well.
But what about application design? Isn’t that what this blog is all about?
How does EventBridge affect serverless application design?
Where EventBridge really comes into its own is how you build and architect serverless applications.
The majority of mature and successful serverless applications, tend to follow only a few patterns. A large number of the principles behind these are captured in a couple of other blog posts:
The architecture pattern that comes out of these principles is to split up the larger application into separate modules, with modules joined by an output “custom event source” and an input lambda function.
Lambda functions are triggered by an event. An event in the AWS ecosystem is simply data in a specific format that is sent as an “invoke” packet. Lambda waits for an event to “invoke” it, and then executes using that data as the “event”.
If you split up a big application into a series of modules, that each generate events, then you can more easily test and atomically deploy each module without affecting the overall application. (Yes, there will be some end to end testing at times, as module outputs may need to change, and therefore will affect other modules inputs, but that’s slightly out of scope for this conversation)
So you have modules, with custom event sources. How do you join them up?
Lambda functions are triggered by events, so you have an input lambda for each module. That is triggered by an event.
So each module then has an input lambda, and custom event source.
Note: This is not microservices. If you build this with a microservices architecture, you get into some trouble, as most people build microservices in a request response architecture. Each module in this scenario should be unidirectional.
How does EventBridge help here?
Well, these modules have “custom event sources”, which could be something like DynamoDB Streams, or SNS, or anything in AWS that can trigger a Lambda function. The other module would have to “know” about that custom event source to be able to use it.
If you have to “know” about something, you have to manage that collaboration between events. Modules become coupled, and refactoring becomes complex. You have to either build a management layer (there are names for these kinds of layers, that I don’t want to use, because then it would have assume the architecture is analogous to others) or simply accept that coupling.
EventBridge helps by being that management layer.
Simply put, if each module deploys and owns an EventBridge “event bus” as it’s output then instead of the module sharing its AWS event source, it simply shares its event bus.
Other modules then can be targets for the event bus for any another module.
Which makes EventBridge a very simple way to coordinate between modules of a serverless application.
This allows the modules to decouple even further than before, and make testing much easier as well.
Building modules in this way also allows for something else:
EventBridge allows for much easier monitoring of events.
If you build applications with EventBridge as the way of coordinating events, then you can easily add in an event watcher, that can observe, monitor and rapidly identify issues within your wider application more quickly.
Building serverless applications just got even more powerful
EventBridge has become a central pivot to a serverless applications on AWS.
While it may seem like a relatively small release, and an iteration of CloudWatch Events, it is actually a massive step towards building the next version of cloud applications.
Maybe serverless isn’t “cloud native” or at least not “cloud 1.0 native”
Maybe serverless should be more “event native”
EventBridge is, in my opinion, the most important release for serverless applications since Lambda.
