Lambda - To the rescue ...... When to use Serverless

In my last post, I have discussed the details with the pros and cons of serverless architecture. This post is in continuation of the serverless computing service offered by AWS with the use of AWS Lambda.

AWS Lambda allows the developers to operate software without provisioning or maintaining the servers. This eliminates the need for traditional compute services, which in turn will reduce the operational costs and overall system complexity. It is pure no operations, compute service that can execute the application code using AWS infrastructure. It helps in aligning our focus to more on the business logic with cost-friendly solutions.

Lambda has a PAYG (Pay As You Go), pricing model, which means that it is billed based on memory usage, number of requests, and execution time.  When code starts running in response to an event, AWS Lambda counts a request. It will charge the total number of requests across all of the functions used. Duration is calculated by the time when your code started executing until it returns or until it is terminated, rounded up near to 100ms. The AWS Lambda pricing also depends on the amount of memory that the user used to allocate to the function. So, you will not end up paying for something that you might not use at all.

Scalability is another benefit provided by AWS lambda, as it can scale up to a large number of parallel executions ( this limit is controlled by setting the concurrency in lambda configuration). Downscaling will happen automatically as the lambda function finishes code execution and terminating it.

It's event-driven (run when invoked), allowing you to set specific parameters that trigger Lambda to run the required code automatically. You can trigger the code to run from a database action, an API query, a metric in CloudWatch, a 3rd party monitoring app, an IoT device, an SQS event. Even though a Lambda’s max timeout is 15 minutes, it can trigger another Lambda.

There are benefits and challenges of serverless as well, so in order to decide if the serverless approach is suitable for your architecture or not, there is a list of questions that we should ask ourselves before proposing a solution via serverless.

Decision tree for opting serverless :

Lambda comes with native support for a number of programming languages: Java, NodeJS, and Python. Leading organizations are leveraging Lambda to change how they build and deliver applications. Amazon Case Study shows how Lambda is being used by its customers.

Popular Use cases of Lambda includes

• Serverless-Website: The web frontend can send requests to Lambda functions via API Gateway HTTPS endpoints. Lambda can handle the application logic and persist data to a fully managed database service(RDS or DynamoDB).
• Real-Time-Data-Transformation: The raw data acquired from various inputs can be normalized and restructured before writing to the destination. This may include simple data transformation, adding metadata to record data, or combining data from other data sources.
• Serverless-Chatbots: Lambda function with a code logic is setup trigger when user commands are sent to the bot. The commands are API requests (from Slack, Messenger, etc) routed through API Gateway to Lambda function. Lambda runs only when the event is received and thus saving cost and resources for implementing chatbots.
• Automated /scheduled backups: Scheduled Lambda events are great for resource management within the AWS accounts. Can be used along with AWS Config. Creating backups, checking for idle resources, generating reports and other tasks that frequently occur can be implemented in no time using lambda.

There can be many more useful lambda serverless use cases. But you need to wisely decide considering the pros and cons of this architecture style fits in your use-case or requirements.