Concepts: Serverless and AWS Lambda

Serverless computing (or serverless for short), is an execution model where the cloud provider (AWS, Azure, or Google Cloud) is responsible for executing a piece of code by dynamically allocating the resources. You will only get charged for the time that your function executes. The code is typically run inside stateless containers that can be triggered by a variety of events including HTTP requests, database events, queuing services, monitoring alerts, file uploads, scheduled events (Cron jobs), etc. The code that is sent to the cloud provider for execution is usually in the form of a function. Hence serverless is sometimes referred to as “Functions as a Service” or “FaaS”.

Principles of Serverless
1. Use a compute service to execute code  on demand
2. Write single-purpose stateless functions
3. Design push-based, event-driven pipelines
4. Create thicker, more powerful front ends
5. Embrace third-party services

Tenets of Serverless

• You bring the code, provider brings the infrastructure
• Scale seamlessly with demand
• Pay as you go, but never pay for idle time

Serverless Patterns

• Compute as Back End
• Compute as Glue
• Command pattern
• Messaging pattern
• Priority queue pattern
• Fan-out pattern
• Pipes and filters pattern

Serverless Components

• Lambda: Functions as a Service (compute)
• API Gateway: HTTP endpoints as a Service (connectivity)
• DynamoDB: Managed NoSQL (storage)
• S3: Managed object store (storage)
• Cognito: User management & authentication (security)
• Certificate Manager: free, automatic SSL certs (security)

Use Cases of Lambda

• ETL jobs
• APIs (with API Gateway)
• Mobile backends
• Infrastructure automation
• Data validation
• Security remediation

Under the hood, when you are using Lambda, you are using containers that are running on EC2 instances, which are not accessible by you in terms of administration and management. They download your code from Lambda and run it inside of an isolated container. So it looks to you like you have an isolated machine even though there may be many lambDa functions executing at the same time on that machine. These containers enforce resource isolations so you are only allowed to use the amount of RAM that you have configured and they enforce 100ms execution limit for the purpose of billing and also for timeouts. At the end of the timeout, the container will be killed regardless of the state of your process.

Your application is composed of

• the code that you provide and any dependencies of your code such as external libraries.
• the event that comes in from the external service
• the output is what your function sends back whether it sends to an external service or returns it as the output of the function

Event sources

• Schedules: similar to a cronjob
• S3 events: which hands the information about a new/deleted/changed file into Lambda
• DynamoDB streams:  when a change is made in DynamoDB
• Kinesis streams
• SNS topics: simple notification service, messages that come in from webhooks or any other sources
• API Gateway: mapping between HTTP request that might be coming in and events being sent to your Lambda functions
• AppSync
• CloudTrail logs
• EC2 Lifecycle events
• SDK invocation: language SDKs for different languages like Perl, PHP, JS, Python; from any of these, you can invoke your Lambda function and just let it run async or wait around for the result