Able to land a function in the environment in about 1ms.
What developers really want to focus on is the application code.
And you want to be sure that when your application code is running, you will get the resources needed automatically without having to provision your infrastructure.
The infrastructure is automatically scaled up and down on your behalf by the system when a event gets to process –> very good for micro services.
Event driven scale: Lambda will match the rate of events for you. No provisioning, the event is the trigger for the provisioning happening underneath the service.
Sub-second billing: no worry about what to do when the application is not running. Pay for what you use. 100% utilization
Security at each steps along the way!
Bring your own code.
Simple resource model: only one thing that needs to be configured -> memory. CPU and Network is allocated proportionately which means tha t a 256MB function will have twice the CPU and Network as a 128MB one.
Flexible use: trigger or invoke synchronously or asynchonously. Hook up with many othe other AWS services
Use IAM roles under the hood. So you can very fine grain security so you can for example say my lambda function can access only one particular S3 bucket. VPC integration makes it even more control over what your lambda funciton can and cannot do.
Build your function the same way you would do in your standard enviroment (threads.. )
Deploy using existing tools and plugins, cli tools and frameworks (demo)
Lambda function are stateless so you need to use S3, elasticache or dynamodb to persist the state so you can excahneg data betweene functions.
Use Amazon Cloudwatch for monitoring
The first thing we want to look at is the standard flow of an API call, including all components in the system
First, a request comes in from a client, this could be a mobile device, a web application or a backend service
The requests arrives at one of our CloudFront PoP locations, it’s accepted and routed through to the API Gateway in the customer’s region
The API Gateway receives the request, then checks for records in the dedicated cache (if it is configured). If there are no cached records available then it will forward the request to the backend for processing
The backend can be a Lambda function, a web service running on Amazon EC2, or any other publicly accessible web service
Once the backend has processed the request the API call metrics are logged in Amazon CloudWatch and the content is returned to the client
verify data formats, audit out-of-range values, filter and copy data to other tables
verify data formats, audit out-of-range values, filter and copy data to other tables
verify data formats, audit out-of-range values, filter and copy data to other tables
The first thing we want to look at is the standard flow of an API call, including all components in the system
First, a request comes in from a client, this could be a mobile device, a web application or a backend service
The requests arrives at one of our CloudFront PoP locations, it’s accepted and routed through to the API Gateway in the customer’s region
The API Gateway receives the request, then checks for records in the dedicated cache (if it is configured). If there are no cached records available then it will forward the request to the backend for processing
The backend can be a Lambda function, a web service running on Amazon EC2, or any other publicly accessible web service
Once the backend has processed the request the API call metrics are logged in Amazon CloudWatch and the content is returned to the client
verify data formats, audit out-of-range values, filter and copy data to other tables
AWS SAM is a new specification that extends CloudFormation, and is optimized for serverless.
It allows you to define 3 resource types commonly used in serverless applications, in a simpler and cleaner way: Lambda function, API Gateway APIs, and DynamoDB tables.
It’s worth noting that SAM in its core, is a CloudFormation template. That means you can define any CloudFormation resource in your SAM template, to go along with your serverless resources.
Let’s go over a SAM template to understand the specification better:
First, we are defining a serverless function, which is transformed into a Lambda function under the covers.
The first property specified is CodeUri. This property receives a URI that points to an S3 object. When CloudFormation creates my Lambda function it refers to this URI to retrieve the function’s deployment package.
The next property I’d like you to pay attention to, is policies. The managed policies that you specify here will be included in the execution role that CloudFormation will generate for your Lambda function.
Next, we are defining the function’s event source, which in this case is an API. Notice that I don’t need to explicitly define an API as a separate resource. Specifying an API as my function’s event source is sufficient for CloudFormation to generate an API with the specified characteristics for me.
Lastly, I’m defining a DynamoDB table using the simpleTable. This shortcut will generate a DynamoDB table with a single attribute primary key, with a provisioned throughput of 5.
The key piece that makes all of this possible, is the transform capability CloudFormation introduced.
When you specify the serverless transform, then under the covers, CloudFormation turns this template into a regular CloudFormation template. CouldFormation then uses that template to generate my resources.