AWS Lambda is a serverless computing service launched in 2014 .It brought to existence a new architecture paradigm that doesn't rely on servers.AWS Lambda has also enabled a faster development speed and experimentation comparing to server-based architectures.
This paper summerizes the AWS Whitepaper entitled 'Serverless Architectures with AWS Lambda' released in 2017 to shed the light on Lambda serverless compute concepts .We focus mainly on the compute layer of the serverless applications where the code is executed, as well as the AWS developer tools and services used for best practices.

What Is Serverless?

Serverless literally means: "without need to provision or manage any servers". A serverless platform is responsible for:
1.Server Management:
Provisioning, installing and patching software,OS patching,etc.
2.Flexible scaling:
Applications are scaled automatically or by adjusting the capacity through the units of consumption(throughput,memory,etc)
3.High Availability:
Serverless applications have built-in availability and fault tolerance.
4.No idle capacity:
There is no charge when your code isn’t running

Here is a list of AWS different services that can used in serverless application:

• AWS Lambda: Compute
• Amazon API Gateway: APIs
• S3 (Amazon Simple Storage Service): Storage
• Amazon DynamoDB : Databases
• Amazon SNS (Simple Notification Service) and Amazon SQS (Simple Queue Service): Interprocess messaging
• AWS Step Functions and Amazon CloudWatch Events: Orchestration
• Amazon Kinesis: Analytics

PS: Here is an additional list of AWS Serverless services that were not mentioned in the original document.

-AWS Redshift Spectrum: Analytics and interactive querying on S3
-Amazon Athena: interactive querying on S3 with read-on-schema technology
-Amazon Aurora Serverless: Databases
-AWS Fargate: Containerization
-Amazon QuickSight: Analytics and Visualization
-Amazon Cognito: Authentication ,authorization and user management
-AWS KMS: Key Management
-AWS Glue: ETL tool (Extract Transform and Load)
-Amazon EventBridge: Builds an event-driven architecture.
-Amazon AppSync: Create,publish and monitor secure GraphQL APIs and Subscriptions

AWS Lambda -the Basics

Lambda is a high-scale, provision-free serverless compute service . It is a (FaaS) Function-as-a-Service which scales precisely with the size of the workload .It runs more copies of the function in parallel in case of multiple simultaneous events to scale your code with high availability.AWS Lambda enables building reactive events as it works when triggered by an event .This reduces server's idle time and wasted capacity.
Each Lambda function contains:
-The Function Code that you want to execute
-The Function Configuration that defines how your code is executed.
-(Optional) The Event Sources that detect events and invoke you function as they occur. For example, an API Gateway(Event source) invokes a Lambda function when an API method created with API Gateway receives an HTTPS request.
You don’t need to write any code to integrate an event source with your Lambda function ,to manage infrastructure or scaling.Once you configure an event source for your function, your code is invoked when the event occurs.
Also ,it’s a natural fit to build microservices using Lambda functions thanks to the inherent decoupling that is enforced in serverless applications through integrating Lambda functions and event sources.

AWS Lambda- Diving Deeper

This section provides a further explanation of AWS Lambda's components mentioned above .

Lambda Function Code

It is the code you will run with AWS Lambda.AWS Lambda natively supports Java, Go, PowerShell, Node. js, C#, Python,PHP,SmallTAlk and Ruby code.It also supports libraries,artifacts and compiled native binaries.
AWS SAM Local: A set of tools used to compile and test the components you plan to run inside of Lambda within a matching environment .

The Function Code Package:

The Function Code Package contains all of the assets you want to have available locally upon execution of your code (additional files, classes, and libraries to be imported, binaries to be executed, or configuration files that your code might reference upon invocation.).
While creating the Lambda function (through the AWS Management Console or CreateFunction API) and even while publishing an updated code to existing Lambda functions (through UpdateFunctionCode API),you can upload the code package directly or you can refer to the S3 bucket and object key where the package is uploaded.
At minimum,the Function Code Package includes the code function to be executed when your function is invoked.

The Handler:

The handler is the code method (Java,C#) or the function (Node.js,Python) that is in your function code that processes events.It is the first thing that executes when a Lambda function is invoked.

The Event Object:

The Event Object is one of the parameters provided to the handler function.It includes all of the data and metadata that Lambda function needs.the event object differs in structure and contents, depending on which event source created it.

The Context Object:

The context object allows your function code to interact with the Lambda execution environment. It's contents and structure varies depending on the language runtime used by Lambda function.But at minimum it will contain:

• AWS RequestId :Used to track specific invocations of a Lambda function(important for error reporting)
• Remaining time :The amount of time in milliseconds that remain before your function timeout occurs (maximum 300 seconds)
• Logging :The information about which CloudWatch Logs stream your log statements will be sent to.

Writing Code for AWS Lambda—Statelessness and Reuse

While writing your code for Lambda ,it’s important to understand that your code cannot make assumptions that state will be preserved from one invocation to the next.
However, each time a function container is created and invoked, it remains active and available for subsequent
invocations for at least a few minutes before it is terminated. We can define :
-Warm container:When subsequent
invocations occur on a container that has already been active and invoked at least once before
-Cold start:When an invocation occurs for a Lambda function that requires your function code package to be created and invoked for the first time

Fig(1):Invocations of warm function containers and cold function containers

Lambda Function Event Sources

Event sources are the triggers that invoke your code on AWS Lambda function through the Invoke API.You don't have to write, scale, or maintain any of the software that integrates the triggers with your Lambda function.

Invocation Patterns:

There are two models for invoking a Lambda function:
-Push Model: Lambda function is invoked every time a particular event occurs within another AWS service.
-Pull Model:Lambda polls a data source and invokes your function with it.
A a Lambda function can be executed synchronously or asynchronously through the InvocationType parameter . This parameter has three possible values. RequestResponse to execute Synchronously, Event to execute Asynchronously and DryRun to test that the invocation is permitted for the caller, but don’t
execute the function.

Lambda Function Configuration

This section is about the various configuration options that define how your code is executed within Lambda.

Function Memory

Function Memory Helps to define the resources allocated to your executing Lambda function by increasing/decreasing function resources (memory/RAM).You can optimize the price and performance of Lambda function by selecting the appropriate memory allocation.

Versions and Aliases :

Versioning is possible for AWS Lambda functions.Each and every Lambda function has a default version built in: $LATEST that addresses the most recent uploaded code. Each version has its own Amazon Resource Name (ARN).
PS: When calling the Invoke API or creating an event source for your Lambda function, you can also specify a specific version of the Lambda function .Otherwise, $LATEST is invoked by default.
Each Lambda function container is specific to a particular version of your function. A different set of containers is installed and managed for each function version.

Invoking your Lambda functions by their version numbers is useful during testing activities. However, this is not recommended for real application traffic. This this requires updating all of the triggers and clients invoking your Lambda function with Lambda alias to point at a new function version each time you wanted to update your code .Lambda aliases can be used to represent your Lambda function version (live/prod/active),to enable blue/green deployment pattern ,and for debuging when an alias is integrated with a testing stack for example

last paragraph page 15

IAM Role

Lambda Function Permissions

Network Configuration

Environment Variables

Dead Letter Queues

Timeout

Serverless Best Practices

Serverless Architecture Best Practices

Security Best Practices

Reliability Best Practices

Performance Efficiency Best Practices

Operational Excellence Best Practices

Cost Optimization Best Practices

Serverless Development Best Practices

Infrastructure as Code – the AWS Serverless Application Model (AWS SAM)

Local Testing – AWS SAM Local

Coding and Code Management Best Practices

Testing

Continuous Delivery

Sample Serverless Architectures

Conclusion