- Hi, my name is Talia Nassi,
and I'm a senior developer advocate here at AWS serverless.
This video is about getting started
with event-driven architecture.
In modern application development,
event-driven architecture is becoming
more and more prominent
because it can make building applications
in the cloud easier.
Event-driven architecture can allow you
to decouple your services
which increases developer velocity
and can make it easier for you to debug applications.
It can also help remove the bottleneck
that occurs when features expand across different teams,
which allows teams to progress more independently.
One way to think about how an application works is
as a system that reacts to events from other places
like from within your application.
In this approach, you focus on the system's interaction
with its surroundings as a transmission of events.
The application receives and creates events,
and the inputs to the application
and outputs from the application act as events.
In event-driven applications,
you have the event producer, the event bus,
and the event consumer.
The event producer is the event source
that the events come from.
This can be an AWS service, a custom event,
or an event that comes from a third party SaaS app.
The event bus acts as an event router to route the events.
The event consumer, or target, listens for events
and acts only upon the events they're interested in.
A common way of making components
of an application work together is through
an API-driven request response architecture
where you have requests and responses.
For example, you query a list of orders from an order's API
and the order's API response with a list of orders.
This is an example of synchronous architecture.
The system asking for the orders waits for the response,
and you cannot move on until the response comes back.
In this approach,
you send commands that are directed to a target.
For example, place this order,
or add this record to the database.
API thinking is synchronous thinking.
You can't move on until the API response comes back.
With APIs, you send commands, do this thing,
it has an intent and it's directed to a specific target.
An event is something that happened.
Maybe a new file has been created,
maybe an exception or error occurred,
maybe a new customer has been created in your system.
It tells you a fact.
Events are immutable, which means they cannot be changed.
So again, with events you describe effect
and others decide what to do with it
In a synchronous model shown on the left,
the client makes a request to service A,
service A call service B,
but then service A waits for service B to respond
before it continues on
and eventually responds to the client.
In a synchronous event-driven architecture,
there is no response path.
The service surfaces the event
and then immediately moves forward.
The trade off here is that there's no direct channel
for service B to pass back information to service A
besides confirming it received the event.
But in many cases, you don't need that explicit coupling
between the request and response channels.
An event is something that happened.
For example, a new record is added to a DynamoDB table
or an item is put into an Amazon S3 bucket.
Events are immutable, which means you cannot change them.
Once an event happens, you cannot undo it.
For example, if there is an event raised
when an order is placed,
there can be another event for an order being canceled.
Events can come from various places
such as messaging systems or databases
both within and outside of your application.
Events are JSON objects that tell you information
about something that happened in your application.
In event-driven architecture, events represent facts.
Each component of the application raises an event
whenever any anything changes.
Other components listen and decide what to do with it
and how they would like to react.
Events are observable.
Any service that is authorized can watch an event.
Consider a coffee shop example
where there is a barista who makes coffee
and a pastry chef who makes pastries.
When a customer enters the coffee shop
and orders a cup of coffee,
the barista starts to make the coffee
and the pastry chef takes no action.
However, if a customer comes into the coffee shop
and orders a chocolate croissant,
then the pastry chef starts making the chocolate croissant
and the barista takes no action.
The pastry chef is only interested
in orders relating to pastries,
and the barista is only interested
in events relating to coffee.
Here's an example of what an event could look like.
In the event above, S3 raises an event
when you put an item into an S3 bucket.
The event source is
an S3 bucket named sam-app-sourcebucket.
The object that's put
into the bucket is called brad.jpeg.
Many applications are built in a monolith
where the components are tightly coupled
and are highly dependent on each other.
This proves to be problematic when there's bugs,
and you are trying to pinpoint exactly
what part of the application is failing.
Decoupled architectures are composed of components
or services that are loosely coupled.
In an event-driven decoupled architecture,
you broadcast events without caring who responds to them.
This saves time because events can be queued and forwarded
whenever the receiver is ready to process them.
This allows for building scalable,
highly modifiable systems.
Decoupled applications enable teams
to act more independently, which increases their velocity.
For example, with an API based integration
if my team wants to know about some change
that happened in another team's microservice,
I have to ask that team to make an API call to my service.
That means I have to deal with authentication,
coordination with the other team
over the structure of the API call, et cetera.
This causes back and forth between teams
which slows down development time.
With an event-driven application, you can subscribe
to events that are sent from a microservice,
and the event router takes care
of routing the event and handling authentication.
Decoupled applications also allow you
to build new features faster.
Adding new features or extending existing ones is simpler
with event-driven architectures.
This is because you only have to choose the event
you need to trigger your new feature
and then subscribe to it.
There's no need to modify any
of your existing services to add new functionality.
When you build applications using event-driven architecture,
often you write less code
because you only need to consider new events
as well as which service is subscribe to those events.
For example,
if you're building new features for your application,
all you have to do is consider the existing events
and then add senders and receivers as necessary.
In this way, you speed up development time
because each functional unit is smaller
and there is often less code.
You also get better extensibility
with event-driven architecture.
Other teams can extend features and add functionality
without impacting other microservices.
Producers of events have no knowledge of event consumers
which can help simplify the microservice logic.
A common process to build applications is to work
with your product managers and business stakeholders
to gather requirements.
Developers then translate those requirements into code.
However, there may be a disconnect
between the product requirements and the code.
When you use events,
everyone in the business understands the logic.
You define the events in an application.
For example, a customer adds an item
to their shopping cart or a customer account is created,
and that becomes your product requirements.
Whenever that action happens, it produces an event
and whoever is interested can take action on that event.
For example,
a marketing manager could be interested
whenever a customer creates an account.
One way to choreograph this in event-driven architecture
is to have a marketing event bus
that listens for the new account event.
There could also be other teams
that are interested such as the analytics team
who could also subscribe to that event.
Each team and service can subscribe to events
that are relevant to them.
Event-driven architecture is a great way
for businesses to describe their business problems
and represent them.
To learn more about event-driven architecture,
head to serverlessland.com
where you'll find more content from me and my team.
I'm Talia Nassi, thanks for tuning in.