Welcome to another episode of 'Back To Basics'.
I'm Peter, and today we'll talk about serverless integration patterns
to allow systems to talk to each other.
For certain workloads, you may need to pass information between systems.
Some can be external systems that you do not control.
So the question is, how do you enable communication between these systems
if you don't own the code?
Let's say, for example, you have an external application
that sends support tickets to your serverless AWS environment.
You may want to perform some sort of Natural Language Processing on a ticket
to determine its severity and run sentiment analysis.
What is the right pattern to build an event-based system
that integrates directly with third-party SaaS partners?
The best way to integrate applications together is to use Amazon EventBridge.
EventBridge is a flexible, fully-managed, event bus router.
You can directly connect with a growing list of SaaS application providers
and AWS services without traversing the Internet.
Using a logical connection between your SaaS provider
and your AWS account, traffic stays on the AWS network,
which helps keep your applications secure.
Let's take a look at the architecture.
From your partner application, you configure your SaaS account
to emit events and accept those event sources in EventBridge.
EventBridge automatically creates an event bus
that collects these events.
From here, you can configure EventBridge rules
to route the event to different targets, including AWS Lambda.
For instance, you can have Lambda process these events,
then start an Amazon Comprehend job
to use Natural Language Processing to analyze ticket sentiment
and determine its severity.
Events use a specific JSON structure.
All events have the same top level fields like event source, time stamp, and region,
followed by a detail field which is the body of the event.
Once these events are published to an event bus,
you set up rules that match something in the event.
Then you can route the event to a number of AWS services
as targets for processing.
You can also have multiple event producers
sending different events to a single event bus,
and simply use rules to route those different events to the appropriate target.
Another common pattern I've seen
is to use Amazon Simple Notification Service, or SNS,
for a publisher-subscriber, or pub-sub, architecture to process events.
This is a completely valid pattern to process events in parallel,
but EventBridge natively integrates with a number of third-party SaaS partners,
so you don't have to deal with the complexities of writing custom code
to ingest these events with SNS.
SNS allows you to filter based on message attributes,
but if you need more advanced filtering, you should use Amazon EventBridge.
In our example, you could filter events by IP address matches
within the message content
and send those messages to separate targets.
EventBridge also has a schema registry
that helps you identify inversion event schemas.
EventBridge has a limit of five targets per rule.
in the case where you want to send events to hundreds or even thousands of targets,
you can work around this limit by publishing to SNS first as a target
and then implement a fan-out pattern to have the message in SNS
be consumed by multiple services simultaneously.
This pattern allows you to deliver events to Lambda functions
in other AWS accounts and other AWS Regions.
If EventBridge fails to send an event due to client-side errors
like target unavailability or failed permissions,
EventBridge will retry sending to that target for up to 24 hours.
EventBridge also supports Dead Letter Queues
via Amazon SQS, or Simple Queue Service.
So with failed events, you can capture them in a Dead Letter Queue
and process them later, reducing the risk of data loss.
In this episode, we looked at how you can integrate distributed applications together
using Amazon EventBridge.
Check out the links below for more details.
See you next time.