Welcome, everyone! are you ready to improve your approach for application development?
In this series I will cover how to use serverless and event driven architecture in your applications.
I will explain the concept and how to use AWS services in this architecture, and I will add hand-on guides if you are like me love to learn by doing.

Let’s start by some concepts first:
Serverless advantages
Cloud computing main advantage is removing the need to manage data center components by yourself and leaving this to the cloud provider.
In a serverless environment you don't even manage servers, of course there are servers that run your applications, but you don't need to manage and maintain those servers, and AWS will take care of it, allowing you to focus on your code which reflects on your client's experience.

AWS Lambda
AWS Lambda is a serverless compute service that lets you run your code without the need to manage servers. It runs on a highly available infrastructure, and it handles scaling, code monitoring, and logging.

To cut short we can say that lambda has the following Benefits

• Serverless operation
• Event-triggered functions
• Automatic scaling
• Integrated monitoring and logging

If you are new to AWS Lambda, and you need to learn by doing, then please read my previous post on how to use AWS Lambda

Event-driven architectures
Event-driven is an architecture where your application is decoupled to many services and these services communicate events to each other and services can make use of events and run code in the context of the event.
but what is an event?
An event reflects some change, user request, or update, like adding an item to a shopping cart on an e-commerce site. Once an event happens, the data is sent to be used by other services. In this architecture, the main way to exchange information between different services is by sending those events.

Producers, pathways, consumers
There are many AWS services that produce events, which we can call an event sources for AWS Lambda. In response to events, Lambda executes the code, which is crafted to handle those events, and when executed, Lambda functions can trigger additional actions or subsequent events.

The following diagram illustrates how services work together in a serverless architecture

Notice: An event is a state change in what you're monitoring, such as an updated shopping cart or a new file uploaded to Amazon S3.

After covering the fundamentals of serverless architecture and AWS Lambda, let's dive into the details of how AWS Lambda operates through event sources and triggers.

How AWS Lambda Works?
To understand event driven architectures and services like AWS Lambda, you need to understand the events themselves. This section dives into how events trigger Lambda functions.

Invocation models for running Lambda functions
Event sources can trigger lambda functions with three different invocation models, and each model suits specific requirement.
We have 3 invocation models:

1. Synchronous invocation
2. Asynchronous invocation
3. Polling invocation

Now let’s learn about each invocation model

Synchronous invocation
In this model you wait for the function to process the event and return a response. when the function completes, Lambda returns the response from the function's code with additional data.

The following diagram illustrates clients invoking a Lambda function synchronously. Events go directly to the function, and the function response returns directly to the invoker.

The following AWS services invoke Lambda synchronously:

1. Amazon API Gateway
2. Amazon Cognito
3. AWS CloudFormation
4. Amazon Alexa
5. Amazon Lex
6. Amazon CloudFront

More information about Synchronous invocation in the AWS Lambda Developer Guide.

Asynchronous invocation
Several AWS services, such as S3 and Amazon SNS, invoke functions asynchronously to process events. When you invoke a function asynchronously, you don't wait for a response from the function code. You hand off the event to Lambda and Lambda handles the rest. You can configure how Lambda handles errors, and can send invocation records to a downstream resource such as Amazon SQS or EventBridge to chain together components of your application. More about destinations is coming below.

The following diagram illustrates clients invoking a Lambda function asynchronously. Events are queued before being sent to the function.

Destinations
Destinations sends records of asynchronous invocations to other services. You can setup separate destinations for events that fail processing and events that succeed.
Destinations provide a way to handle errors and successes without requiring additional code.
More information about Configuring destinations for asynchronous invocation in the AWS Lambda Developer Guide.

The following diagram shows a function handling asynchronous invocation. If the function responds successfully or exits without errors, Lambda sends an invocation record to an EventBridge event bus. In case of repeated processing failures, Lambda forwards an invocation record to an Amazon Simple Queue Service (Amazon SQS) queue.

Asynchronous AWS service integration
The following AWS services invoke Lambda asynchronously:

1. Amazon SNS
2. Amazon S3
3. Amazon EventBridge

More information about Asynchronous invocation in the AWS Lambda Developer Guide.

And one last type of invocations:
Polling invocation
This invocation model is designed to allow you to integrate with AWS Stream and Queue based services with no code or server management. Lambda will poll the following services on your behalf, retrieve records, and invoke your functions.
The following are supported services:

1. Amazon Kinesis
2. Amazon SQS
3. Amazon DynamoDB Streams

With this type of integration, AWS will manage the poller on your behalf and perform Synchronous invokes of your function with this type of integration. The retry behavior for this model is based on data expiration in the data source. For example, Kinesis Data streams store records for 24 hours by default (up to 168 hours).

Event source mapping
The configuration of services as event triggers is known as event source mapping. This occurs when you configure event sources to launch your Lambda functions and then grant these sources IAM permissions to access the Lambda function.

Lambda reads events from the following services:

1. Amazon DynamoDB
2. Amazon Kinesis
3. Amazon MQ
4. Amazon Managed Streaming for Apache Kafka (MSK)
5. self-managed Apache Kafka
6. Amazon SQS
7. Amazon DocumentDB

More information about Lambda event source mappings in the AWS Lambda Developer Guide.

In conclusion, we've explored the principles of serverless architecture and dived into the how to use lambda in such architecture, we explored its functionality through event sources and triggers.
By understanding the different invocation models, such as synchronous and asynchronous approaches, and the seamless integration with AWS streaming and queuing services using polling, you're ready to get in and start using serverless computing.
AWS Lambda's ability to abstract infrastructure layer, and with its diverse invocation options, it helps developers to focus on crafting code that drives unique and innovative business solutions.
Stay tuned to the upcoming articles in this series for more fun with serverless!