Amazon EventBridge — Decouple Services with Event-Driven Architecture
In this article, we are going to learn Amazon EventBridge — Decouple Services with Event-Driven Architecture.
Amazon EventBridge is a Serverless event bus service for AWS services, your own applications, and SaaS providers. By the end of the article, we will see Amazon EventBridge Main Features, Core Concepts, Use Cases and How it works?
I have just published a new course — AWS Lambda & Serverless — Developer Guide with Hands-on Labs.
What is Amazon EventBridge ?
Amazon EventBridge is a serverless event bus that makes it easier to build event-driven applications at scale using events generated from your applications, integrated Software-as-a-Service (SaaS) applications, and AWS services.
Amazon EventBridge is a serverless event bus service that you can use to connect your applications with data from a variety of sources. EventBridge delivers a stream of real-time data from your applications, software as a service (SaaS) applications, and AWS services to targets such as AWS Lambda functions, HTTP invocation endpoints using API destinations, or event buses in other AWS accounts.
Benefits of Amazon EventBridge
There are several advantages of Amazon EventBridge but we will summarized for important ones:
- EventBridge simplifies the process of building event-driven architectures. With EventBridge, your event targets don’t need to be aware of event sources because you can filter and publish directly to EventBridge.
- EventBridge ingests data from supported SaaS applications and routes it to AWS services and SaaS targets
- EventBridge makes it easier to connect applications. We can ingest, filter, transform and deliver events without writing custom code. The EventBridge schema registry stores a collection of easy-to-find event schemas.
How Amazon EventBridge works ?
EventBridge connects applications using events. An event is a indicator of system changed, for example a change in the status of a customer order status. Customers can integrate their own AWS applications with microservices, SaaS applications, and custom applications as event sources which publish events to an event bus.
You can find image on the above, I am going to explain this EventBridge architecture from receiving event to targets AWS Services.
EventBridge receives an event, an indicator of a change in environment,
and applies a rule to route the event to a target. Rules match events to targets based on either the structure of the event, called an event pattern, or on a schedule. For example, when an Amazon EC2 instance changes from pending to running, you can have a rule that sends the event to a Lambda function.
All events that come to EventBridge are associated with an event bus.
Rules are tied to a single event bus, so they can only be applied to events on that event bus. Your account has a default event bus which receives events from AWS services, and you can create custom event buses to send or receive events from a different account or Region.
You can define a filtering rule to filter events and route events to AWS service targets and API destinations. EventBridge schema registry stores schema generated by your organization’s applications, AWS services, or SaaS applications.
Amazon EventBridge Core Concepts — Events — Event Buses — Rules — Targets
When you build serverless applications that use EventBridge, it can be helpful to know the event pattern of typical events without having to generate the event. The event patterns are described in schemas, which are available for all events generated by AWS services on EventBridge.
Amazon EventBridge has 4 Core Concepts which's are
- Event Sources
- Event Buses
- Rules
- Targets
The basis of EventBridge is to create rules that route events to a target.
So lets learn our core concepts of Amazon EventBridge Events — Event Buses — Rules — Targets.
Event Sources
An event indicates a change in an environment such as an AWS environment, a SaaS partner service or application, or one of your applications or services. Event Sources publish events to the Event Buses.
Events are represented as JSON objects and they all have a similar structure, and the same top-level fields. The following event in Amazon EventBridge indicates an Amazon EC2 instance being terminated.
{
“version”: “0”,
“id”: “6a7e8feb-b491–4cf7-a9f1-bf3703467718”,
“detail-type”: “EC2 Instance State-change Notification”,
“source”: “aws.ec2”,
“account”: “111122223333”,
“time”: “2017–12–22T18:43:48Z”,
“region”: “us-west-1”,
“resources”: [
“arn:aws:ec2:us-west-1:123456789012:instance/i-1234567890abcdef0”
],
“detail”: {
“instance-id”: “ i-1234567890abcdef0”,
“state”: “terminated”
}
}Amazon EventBridge Rules
A rule matches incoming events and sends them to targets for processing. A single rule can send an event to multiple targets, which then run in parallel. Rules are based either on an event pattern or a schedule. An event pattern defines the event structure and the fields that a rule matches.
Rules that are based on a schedule perform an action at regular intervals.
Amazon EventBridge Targets
A target is a resource or endpoint that EventBridge sends an event to when the event matches the event pattern defined for a rule. The rule processes the event data and sends the relevant information to the target.
Amazon EventBridge Event Buses
An event bus is a pipeline that receives events. Rules associated with the event bus evaluate events as they arrive. Each rule checks whether an event matches the rule’s criteria.
Using AWS Lambda with Other Services — Amazon EventBridge
As you know that we will develop EventBridge with Lambda Basket microservices which publish the event in async way and this will consume by Ordering queue.
So our Basket microservices will communicate with Amazon EventBridge. So we will develop our Basket microservices according to this event json object. Because when we Basket microservices creates a basketCheckout event, it should publish event message with this format which includes detail-type, source, detail and so on.
Serverless Pattern: Fan-Out & Message Filtering with Publish/Subscribe Pattern
This is an asynchronous design, This communication is basically for performing one-to-many and publish/subscribe mechanisms that has multiple receivers.
The client service publish a message and it consumes from several microservices which’s are subscribing this message on the message broker system. The client sends a request and may get an acknowledgement that the event was received, but it doesn’t get a response that includes the results of the request.
It decouples Messaging between services. Asynchronous messaging is the foundation for most service integrations. It allows building loosely-coupled architectures that overcome the limits of remote service communication, like latency and unreliability. Asynchronous messaging enables services to announce events to multiple interested consumers without coupling.
In Publisher-Subscriber services publish events through a channel as messages. Multiple interested consumers listen to the events by subscribing to these channels.
Mostly this async communication is using in event-driven architectures.
In Asynchronous event-driven communication, microservice publishes an event when something happens. Example use case can be like a price change in a product microservice. Price Changed event can subscribed from SC microservice in order to update basket price asynchronously.
So as you can see that we have also understand how Lambda function trigger to Amazon EventBridge and examine example event json object structure. To see full developments of this hands-on lab, you can check below course on Udemy.
Step by Step Design AWS Architectures w/ Course
I have just published a new course — AWS Lambda & Serverless — Developer Guide with Hands-on Labs.
In this course, we will learn almost all the AWS Serverless Services with all aspects. We are going to build serverless applications with using AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon Cognito, Amazon S3, Amazon SNS, Amazon SQS, Amazon EventBridge, AWS Step Functions, DynamoDB and Kinesis Streams. This course will be 100% hands-on, and you will be developing a real-world application with hands-on labs together and step by step.
Source Code
Get the Source Code from Serverless Microservices GitHub — Clone or fork this repository, if you like don’t forget the star. If you find or ask anything you can directly open issue on repository.
