So, what’s the deal with Serverless? Everybody is excited about it, a majority feel that they don’t need servers to run their code/application, but only a few know what it actually means. So, let’s talk about Serverless and see if we can at least peel a layer or two and try to understand what it means to use Serverless services and deploying code without deploying servers to run that code.
To start the discussion, let’s define the term Function-As-A-Service (FaaS). FaaS enables developers to upload their code and not worry about deploying servers in the cloud to run that code. The cloud provider will take this code, spin up compute resources when it receives an event trigger and shut those resources down once the code has completed its execution. This is basically what Serverless computing is. Phew.. Now we know that serverless actually has servers, but it’s just the cloud providers who are managing the resources that your code needs. All the three leading cloud providers have their own FaaS offering.
Out of the three, I picked AWS Lambda and decided to get my hands dirty. AWS Lambda enables you to run your code without provisioning servers and the best part is that you only pay for the time that your code is actually running. So, if you don’t get any requests, you won’t pay a dime. Also, Lambda will take care of everything starting from server and operating system maintenance, capacity provisioning and automatic scaling, code monitoring and even logging. Lambda supports Node.js, Java, C# and Python as languages that you can use to write your code. You can configure Lambda to run your code in response to a plethora of events, including changes to your S3 bucket(e.g. Someone uploads a new photo to your bucket), updates to DynamoDB Table or integrate with Amazon Kinesis, CloudTrail, API Gateway etc.
Now let’s talk about how it actually works. When you upload your code, you specify configuration information, such as the amount of memory and maximum execution time that you want your code to run. When the Lambda function is triggered, AWS will spin up a new Container based on the configuration information that you provided with your code. Once the code is executed, AWS will delete the container. So keep this in mind while writing your code. “Lambda is completely stateless”, and it won’t retain any information between different invocations of your function. But, if you get one request after another, Lambda is smart enough, to keep say for eg, your DynamoDB connection active so that it doesn’t have to do it for every request. This helps to reduce the latency, but it’s not recommended by AWS to consider this while writing code. So plain and simple, every time your function is invoked, Lambda will spin up a new container to service that request and kill the container once its job is done. And as we all know, containers are easy to scale, which means that if you receive a whole bunch of requests at the same time, you won’t have to worry about anything, Lambda will scale up and will provision resources that will be needed to service those requests. Now, just to contrast, imagine if you had to manage your own instances or autoscaling groups, how much overhead would be added to your work. Cumbersome, right!
So, be like Mario! and level up. If you are considering moving to the cloud, include Serverless in the design, and if you are already up and running on the cloud, re-architecture your applications to run serverless.
Other cool links to check out around AWS Lambda:
- acloud.guru (Their entire website runs on AWS Lambda)
- How to build powerful back-ends easily with Serverless