Decoding Application integration on AWS: EventBridge

Today, more and more enterprises are migrating to AWS. Migration to AWS requires some sort of application integration. Application integration can be tricky if you do not choose the right tools and frameworks.

Enterprises can either end up implementing a working application integration with lots of custom-coded boilerplate components Or they can choose the right tools and implement a clean application integration that is extensible, rule-driven and help them avoiding writing custom code for ingesting, filtering, transforming, and delivering integration payloads.

Before diving deep into application integration, let's understand what is application integration?

Photo by JJ Ying on Unsplash

Gartner's definition: "Application integration is the process of enabling independently designed applications to work together" [1].

IBM's definition: "Application integration enables applications and systems that were built separately to work together, resulting in new capabilities and efficiencies that cut costs, uncover insights, and much more"

AWS provides a lot of options for application integration and it's really hard to decide which mechanism will be a good fit for the given use-case.

This article focuses on EventBridge. We will try to understand what is EventBridge, how it works, and why you should think about considering EventBridge as a tool for integrating applications.

Let's analyze the basic functionalities of EventBridge and most important the heuristic rules which you should consider before choosing other mechanisms.

Amazon EventBridge is a serverless event bus for building event-driven applications. EventBridge enables you to define sophisticated routing rules for channeling events from event generators to multiple event processors. It can accept AWS native events, custom events (application generated), and events from SaaS applications.

image source:

How does it work?

To show how event bridge can be used for solving integration problems, the below diagram depicts an AWS cloud compliance framework implemented using EventBridge.

This framework monitors the AWS resources for in-secure config changes (via AWS Config service ) and can notify the operations team via email as and when those config changes were done in real-time.

A sample scenario can be an incidence where a malicious user/program is making S# buckets public.

Whenever there is an event on Eventbridge with source as aws.config and it matches the criteria specified in the below rule it will trigger an SNS notification. Below diagrams depicts a sample config event that contains details about AWS S3 configuration changes which the Config service is reporting as non-compliant.

When this event reached the event bridge it gets evaluated against rules. The below diagram depicts the rule. The rule is evaluated against the event and filtering is done. Once rule criteria are matched the event can then be transformed and forwarded to configured targets.

Hence without writing much code for ingesting, filtering, transforming, and delivering events we were able to achieve the results in a much cleaner and cost-effective way.

Key criteria's for using EventBridge

EventBridge should be used :

1. When you want to reduce cost by not writing custom code for ingesting, filtering, transforming, and delivering events among different applications.
2. When it is not possible to send an event to the target using SNS. SNS supports very few targets.

3. Event Bridge support almost 20 targets which can satiate almost all of the application integration requirements on AWS.

4. When your application integration needs to support AWS native events, as well as custom events.

5. When you want to handle the third-party SaaS service events. Following SaaS partner integration is supported out of the box.

6. When you want to perform the sophisticated routing of events to the array of services.

7. When you want to perform some input transformations on the incoming event before sending that to targets.

8. When you want the events to routed across multiple AWS accounts.

9. When your target is an API destination Or one of the below API destination partners

10. When you want to bridge the gap between your services deployed on AWS and the services deployed in a traditional on-premise datacentre.

Conclusion:

To save cost and operations overhead, avoid writing custom code/components for ingesting, filtering, transforming, and delivering events among different applications.

Use EventBridge instead, it will allow you to focus on what matters most (business use-case).

Powerd with content-based filtering/routing and the capability to set almost 5 targets per rule makes it a very promising tool in your application integration tool set on AWS.

With, Saas partner integration capabilities, the evolution of the partner eco-system, the possibilities are limitless and in the future, I can foresee that EventBridge will become a de-facto application integration mechanism.

References:

1.https://www.gartner.com/ en/information-technology/glossary/application-integration#:~:text=Application%20integration%20is%20the%20process,in%20independently%20designed%20applications)%20consistent.

2. https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc

3.https://aws.amazon.com/appflow/

4.https://d1.awsstatic.com/product-marketing/EventBridge/product-page-diagram-EventBridge_How-it-works_V2@2x.1a889967415e66231d0bb0bbfee14337d3fa5aa8.png

5. https://docs.aws.amazon.com/eventbridge/latest/userguide/user-guide.pdf