AWS EventBridge Masterclass :: Introduction

Overview for this series

It's been over a year and a half since AWS EventBridge stormed into the scenes and revolutionized how distributed applications are built on AWS using serverless technologies. The list of benefits it introduced is plenty and will be the primary focal point in this first of several articles in this masterclass series. As new features are released, or I have new ideas worth sharing, I may update this series to include such content. As it stands today, the agenda of this series is:

1. Introduction
2. Basic principles
3. Comparing EventBridge to alternatives
4. Architectural patterns
5. Error handling and replay
6. Schema registry
7. Managing EventBridge through AWS CDK

Given you're reading about EventBridge, I will make an assumption that you're familiar with Event-Driven Architectures (EDA), where consumers like AWS Lambda are consuming and/or producing messages to create decoupled communications between services. If you'd like to learn more, here's a great video: Building Event-Driven Applications

Notable features of EventBridge

EventBridge is CloudWatch Events, commercialized. Yes, the same service that delivers the state changes for every AWS account on the planet has now been re-packaged with added functionality and delivered to you as service. That means you have an enterprise-ready Event Bus at your fingertips backed by AWS’s SLA (isn’t that nice?).

Before EventBridge, microservices communicated through a series of random triggers, messaging services, and queues. While it “worked,” it created several problems, such as:

• Loss of domain boundaries within your applications
• Hard for disparate teams to integrate since there's no central point of integration
• No sense of what messages are flowing through

By leveraging EventBridge, you can centrally manage all your events in one place and finally understand what communications are talking to each other.

On top of that, you can be more granular in your message subscriptions, transform the messages before they get to your subscribers, have a registry of all the messages flowing through the queue, and many more! Keep reading because, by the end of it, I'm confident that you'll be switching over to EventBridge for your next serverless project.

Event-source integration

EventBridge comes with three different ways for subscribers to consume messages off the bus:

1. AWS services
2. Custom events
3. SaaS partner

Let’s dive into each one a little more:

AWS services

Remember how I mentioned earlier that EventBridge is CloudWatch? In fact, the default CloudWatch Event Bus is created by default in your EventBridge console with a name of, you guessed it…default

That means you can start taking advantage of the many other benefits you’ll learn about EventBridge just by visiting the console!

Custom events

Why route the messages between your microservices through a myriad of services, such as API gateway, SNS, SQS, fill-in-the-blank, when you can have one central integration point. By leveraging custom events, your service can write directly to the bus, and any other service can start ingesting it right away.

SaaS partner

EventBridge provides you with an ecosystem of SaaS providers ready to integrate with your AWS environment out of the box. At the time of this writing, there are 33 integrations.

Previously, these types of integrations were possible through Webhooks from the SaaS provider with the combination of a service like AWS Lambda to handle the logic for various event types. By creating a separate event bus for your SaaS partner integrations, these events become cloud-native and available for your services to consume.

Event targets

As your EventBridge consumes events published from AWS CloudWatch Events API, custom applications, and SaaS partners, you will need subscribers, otherwise known as targets, to receive and act on these events. Commonly used services for messaging such as SNS and SQS have limited support for the targets that can be invoked. As of today, EventBridge supports 20 unique, cloud-native integrations.

You can view the full list of targets here.

Event pattern filtering

EventBridge enables you to define granular rules based on the event's content to ensure your applications are only triggered for the event types they care about or support.

This is a big difference from how a service such as SNS operates. With SNS, you're only able to filter on the message attributes (the wrapper around your event). That means that the publisher had to add these attributes when they posted the event. With EventBridge, the service will read the event and allow you to create content-based rules.

The rules supported today are:

1. Prefix matching
2. Anything-but matching
3. Numeric matching
4. IP address matching
5. Exist matching
6. Complex example with multiple matching

You can learn more about content-based filtering here.

Input transformer

This allows you to modify the source event into a new event before passing it to the subscriber. This is extremely handy when you want to integrate an existing service into the EventBridge to start consuming events but don’t want to update the application-side processing logic.

Schema registry

EventBridge comes with a repository of schemas that are used by every AWS service. You can imagine how helpful that is when you’re writing applications and don’t have to reference your Lambda logs to fetch the event’s schema. EventBridge allows you to discover custom schema from your applications and even lets you define and export schemas using OpenAPI or JSONSchema Draft4 specifications!

Error handling

If your event fails to get processed for whatever reason, EventBridge allows you to configure Retry Policies per target. By default, EventBridge retries sending the event for 24 hours and up to 185 times with exponential backoff and jitter (randomized delay).

If the event processing is still unsuccessful with the retry mechanism, then you can configure that message to be sent to an SQS DLQ to ensure you don’t lose that message for good. From there, you can have a Lambda listening to the DLQ to create a ticket in your ITSM, get alerted through CloudWatch for manual review, or whatever else your process may entail.

Archives & event replay

EventBridge has a nifty feature that enables you to archive events to replay them in the future. This could help you re-process your events after adding new functionality or if a lousy deployment caused you to miss a series of events.

Summary

EventBridge has been dubbed for “being the most important release for serverless applications since Lambda itself.” Hopefully, after reading about some of its features, you’re starting to see why developers across the world are switching to EventBridge to streamline their development of serverless applications. This was the first of several articles in this Masterclass series on EventBridge. Stay tuned in to learn more about how you can start using it in your applications, architectural best practices, and much more!

Until next time,

Onward and Upward