In this video, we are going to learn a lot of the best practices and event driven architectures.
So we will follow the design principles and the best practices when developing our lambda based, event
driven serverless applications.
Lambda is very good fit when we are working with the event driven architectures because the nature of
the Lambda executions trigger from events.
Events can come lots of resources and able to trigger lambda functions.
So lambda is a complete service that runs custom function code and return response to the events.
Most services generate events for communicating each other, and most of the services are event sources
for a lambda.
LAMDA always handle all interactions with the Lambda API and there is no direct invocation of functions
from outside to the service.
We can see the image on the slide Lambda Handle event with the Lambda API.
The main purpose of lambda function is to handle events when a function is triggered by an event.
This is called an invocation.
Lambda function are limited to 15 minutes in duration, but on average most of the calls take less than
a second across all the customers in some compute incentive operations.
It may take several minutes to process a single event, but in most cases, the time is short.
And even triggering a lambda function could be almost anything.
You can see the image on the slide from the rest API.
A HTTP request with Amazon API Gateway as scheduled task managed by the Amazon Event Breach Cloud Watch
Logs Rule or an Amazon S3 notification like object uploaded into the bucket.
Even the simplest lambda based application used at least one event.
So that's why we said lambda is very good fit for the event driven architectures because the fuel of
the lambda is immense.
So the event is a JSON object that contains all information about what happened.
Events are represents a change in the system state they are immutable.
You can see the example event json to trigger a lambda function in the image of the slide.
The first parameter of every lambda handed function contains the event JSON object so you can find the
example event JSON object that triggered the lambda function and you can see the function image that
takes event parameter into lambda handle method.
So at that stage, the event parameter is very important when developing our lambda function.
If you look at the Lambda Handle method, you will see that the first parameter is event into lambda
handle method.
So with using this event JSON object, we can access the event parameters into lambda function.
For example, let's look at this slide image we have.
We have a naive order event triggers to lambda function.
So if I would like to get the order that details attribute value into lambda function, basically I
can take the information with the event that source or event that detail into my Lambda 100 function
because lambda triggered this event json object with passing parameters in the handle method.
So an event could be custom generated from other microservices such as the Neve or the generated in
an e-commerce application.
We will have exactly the same use case into our serverless e-commerce application.
The event also can be generated from the existing sources like Amazon in case when a new message is
available in the queue, it can go to Lambda with pulling queue records from the Amazon queue.
So even event architectures rely on the creating event into all the application state chains that are
observable by other services.
But the event publisher system is unaware of which consumers are subscribing that event.
We call that there are loosely coupled services.
Most lambda based applications use a combination of services for different requirements about storage,
API management and integrating with the other systems and services.
In these applications, Lambda is a connecting between services, providing the business logic to transform
data that moves between the services.
So now we can talk about design principles and the best practices by developing LAMDA based, event
driven applications.
So we set that solar applications mostly using a combination of services that integrated with the custom
code run in the Lambda functions.
So we can think we can find the most integrated services which using advanced lambda functions, you
can see the image on the slide.
These services are mostly commonly using in service application with a lambda function.
You can see the category and also the services.
We will also use these services into our service hands on projects.
Also, there are some design patterns in distributed architectures that we will follow when we implement
applications using the ADA services.
ADA Services has already implement some of the distributed architecture design patterns that we can
use easily without investing time to develop these patterns from scratch.
When your application is using these patterns, we can basically use corresponding services.
That is the table in the slide.
So here you can see the patterns and here you can see the available services that we can use for that
patterns.
These services and patterns are designed to integrate with ADA Lambda functions, and we can also use
infrastructure as code to create and destroy resources in the ADA services.
We can use any of these services with using ADA SDK without needing to install applications or configure
servers.
So these are the best practices when designing well-designed serverless applications that we will follow
when developing our services.
Hands on labs.
As a summary in serverless word, Lambda is core services for building any event based architectures.
That means we will also follow these lambda design principles and the best practices when developing
our Lambda Base event driven serverless applications.
Basically, we will group these events as a bounded context in order to develop boundaries of our microservices
in the service applications.
That means we will develop lambda function as a microservices into our event driven microservice architectures
in the service hands on labs.