Serverless allows developers to run application code in the cloud without worrying about managing any servers. It does not mean that there are no servers. AWS takes care of infrastructure management so that developers can only focus on writing code & deploying them. When I started reading serverless, it sounded like what I read about AWS, where you don’t need to manage any infra. But it is more interesting, Once I know the details.
Actually, we shall be writing & deploying functions. we do not need to manage / provision any servers or even see them. AWS takes care of patching the underlying operating system, Autoscaling & high availability and etc. Serverless applications are event-driven and we are only charged when our code is executed. This is something we have to note down. If you are running an EC2 instance, you have to pay even if our code is not really running or not serving any request.
Here are some examples of serverless technologies in AWS
- Lamda
- DynamoDB
- Cognito
- API GAteway
- Amazon S3
- SNS
- SQS
- Kinesis Data Firehose
- Aurora Serverless
If we deep dive into AWS lambda, we can get a better understanding of what serverless is.
Lamda
AWS Lambda is an event-driven, serverless computing platform provided by Amazon as a part of Amazon Web Services. It is a computing service that runs code in response to events and automatically manages the computing resources required by that code. We can run our code without worrying about servers. Lamda supports many programming languages like Java, Go, C#, Node.js, Python and Ruby.
Event Driven
Lamda is an event-driven and serverless application. Lambda functions can be automatically triggered by other AWS services or called directly from any web or mobile app.
- Triggered by Events – These events could be changes made to data in an S3 bucket, or DynamoDB table.
- Triggered by User request – We can use API gateway to configure an HTTP endpoint allowing you to trigger your function at any time using an HTTP request.
If we use EC2 instances, it will be continuously running. In case if it has to scale, we have to add more servers and it has its own RAM and CPU. It is just a virtual server running in the cloud. But when you use Lamda, it will run only when requests are being made. It will also auto-scale based on a number of requests. These are actually functions executed or run on-demand.
Lamda Versioning
Lambda functions are attached to a version called LATEST by default. Whenever you upload a newer version of code, that will become the LATEST version. We can create multiple versions of the code and can use aliases to reference. We can give alias names for both latest & older versions of our code.
Concurrent Executions
We can understand now that we can have many concurrent execution of our lamda function. It will scale based on the number of request received. we can also set limit for concurrent execution. Concurrent execution limit is for safety feature to limit the number across all functions in a given region per account.
Default is 1000 per concurrent execution per region. If the number of requests exceeded, we will get HTTP status code 429 & TooManyRequestsException
Step functions
Step functions are bit more interesting to read. It provide a visual interface for serverless applications, which enables you to build and run serverless application as a series of steps. Each step in your application executes in order. The output of one step may act as an input to the next.
It is a orchestration for serverless applications. We can manage the application logics such error handling, retry logic. Step functions also log the state of each step, so when things go wrong, we diagnose and debug problems quickly. Below are the example workflows using step functions
- Sequencial workflow
- Paralell workflow (Paralell tasks in a series of functions)
- Branching workflow (if-else)
Synchronous & Asynchronous invocation
We can invoke lamda function in both Synchronous & Asynchronous way. Synchronous is just straight forward. Client will send the request & get the response back. Asynchronous invocation will mostly be triggered by events. Event can be S3 event, CloudWatch event or any other event. Events will be pushed to Event Queue & Lamda function will pick & process the events.
Lamda intergration with ALB
The Lambda functions must be registered in a target group. ALB converts the HTTP/HTTPS requests into JSON & this json will be used to trigger the lamda function. Once lamda return the response in json format, it will again be converted into HTTP/HTTPS response by the ALB. This is one sort of Synchronous type invocation.
ALB can support multi header values. When you enable multi value headers, HTTP headers and query string parameters that are sent with multiple values are shown as arrays within the AWS lamda event and response objects.
example.com/profile?customer=retail&customer=priorityLamda integration with S3 event notifications & CloudWatch Events
This is an example of Asynchronous type invocation.
Lamda Permissions
Lamda Execution Role(IAM) : Grants Lamda function permissions to AWS service/resources. Below are some examples of managed policies for Lamda. We can also create our own policies for Lamda.
- AWSLamdaBasicExecutionRole – Upload logs to CloudWatch
- AWSLamdaKinesisExecutionRole – Read from Kinesis
- AWSLamdaDynamoDBExecutionRole – Read from DynamoDB streams
- AWSLamdaVPCAccessExecutionRole – Deploy Lamda functions in VPC
Lamda Resource Based Policies : Give other accounts & AWS services permission to use our Lamda resources.
Read more
Read more about monitoring , FaaS (Function as a service), external dependencies, container images, deployments and Pricing. When I am reading this, below is the pricing
Free tier of 1,000,000 AWS Lambda requests and 400,000 GBs of compute time
$0.20 per 1 million requests thereafter ($0.0000002 per request)
Pay per duration: (in increment of 1 ms)
400,000 GB-seconds of compute time per month if Free.
== 400,000 seconds if function is 1 GB RAM
== 320,000 seconds if function is 128 MB RAM
After that $1.00 for 600,000 GB-seconds