As I progress with my AWS cloud journey, Lambda remains an area of interest that I am still unable to concisely define better than the known phrase of ‘the ultimate abstraction layer’. Despite being able to explain what Lambda does; it is difficult to pinpoint what it actually is. So in this blog, I want to set out the facts and functions of Lambda in the simplest way possible in an attempt to demystify Lambda’s purpose and also highlight it’s success as a forerunner of the serverless phenomenon.
Firstly, what is serverless?
It does not take a genius to figure out that serverless means no servers! But architecturally, what does this mean and how can we visualise serverless architecture? In order to understand how serverless is different, we must first grasp the structure of traditional architecture which typically consists of: a load balancer, server (EC2) and SQL database:
Traditional:
ELB (elastic load balancer) —–> EC2 Instance ——–> RDS (relational database)
Whereas serverless:
API Gateway ——-> Lambda function ————-> DynamoDB (non-relational database)
What makes Lambda great?
Instead of deploying an EC2 Instance and having a load balancer to scale resources; with serverless you simply upload your code and Lambda automatically provisions everything needed for it to run.
Lambda is an event driven compute service. The best way to visualise Lambda is with Amazon’s ultimate serverless creation, Alexa. Amazon Alexa is Lambda personified: when you talk to Alexa, you are essentially talking to Lambda. Any question you ask Alexa acts as an event which triggers a Lambda function to respond to your request. Lambda scales automatically and runs code in response to each trigger. Each request is processed individually and runs in parallel: one event equals to one function.
Lambda is very cost efficient as it is priced on the number of requests and the duration of the execution of each Lambda function. The event driven aspect of Lambda makes it ideal for unpredictable and inconsistent workloads as no resources or compute power is wasted. In addition to invoking a function directly through the Lambda console or Lambda API, you can configure other AWS services to invoke your Lambda function in response to a trigger (such as an image being uploaded to S3), making Lambda an extremely low maintenance option. (remember: RDS cannot trigger a Lambda function!)
So we have established the benefits of Lambda as being efficient, highly scalable, highly available and cost efficient with the ability to automatically manage an application, removing the need to manually deploy and provision your resources. This all makes Lambda appear as an almighty compute power, but…. there are some use cases where Lambda, and serverless more generally, may not be the best option. For example, Lambda would potentially be unable to meet the demands of a compute intensive, consistent workload that cannot be broken down and run as parallel workloads. Before migrating to serverless, it is important to address the requirements of your application as well as weigh up the pros and cons of different architectures in order to reach a decision as to whether Lambda could transform your application for the better.
I hope I have given you a concise and comprehensive introduction to AWS Lambda and serverless architecture. The best way to understand anything with AWS is to practice hands-on in the console. I would recommend creating your own Alexa skill in the Developer console to see first hand how quickly and easily you can upload your notes in a JSON file and have Lambda read them back to you. Have a go, get your head in the cloud!
Ellie Woods 