Serverless computing is a topic that has been brewing quite a lot of buzz in the industry. But something extraordinary happened when Serverless computing met Event-driven computing. It led to the birth of Lambda. Now wait a second. What are all these buzzwords? What the heck do they even mean?
To understand Lambdas, it’s important to know more about its foundations so let’s start off with Serverless computing. Contrary to what the term might imply, technically, the servers are still there. The server suddenly appears when you need it, then disappears when you’re done with it. You just don’t need to manage them anymore. You’re only bothered about the functionality. You don’t have to care about code backup, downtime, spinning up servers, server maintenance, security updates or anything else. AWS (Amazon Web Services) does all of that for you. In event-driven computing, the application is programmed to respond to actions generated by the user or the system. These actions can range from mouse-clicks and key-presses to reacting to sensor outputs or messages sent from other programs.
So, what is it again?
Simply put, Lambda is a compute service that executes code in response to events and automatically manages other resources required by your code. Instead of having a provisioned EC2 instance (a virtual server capable of running applications on the AWS infrastructure) configured to run a few functions, we can simply upload only the code we want to execute without having to worry about any of the resources.
Okay, why should I care?
For starters, it’s very easy to deploy and administer functions as you do not need to worry about selecting or configuring EC2 instances to run your code. This is, in my opinion, one of its biggest advantages as it takes the burden of server management away from the developer. Amazon manages the servers for you allowing you to focus more on writing code rather than spending time on the infrastructure. In addition to this, it also limits cost to execution unlike EC2 instances where you would still get charged for idle resources. Lambdas are ideal for infrequent, quick operations that do not require constant run time. An example of this would be building a simple RESTful API – just create a Lambda function and expose it via the AWS API gateway. No need to create any fancy EC2 instance or Elastic Beanstalk applications.
Lambdas are available to both new and existing accounts. Now here’s the awesome bit – the 1st million requests are free, and you can get up to 3.2 million seconds per month depending on memory allocation. At the maximum memory of 1GB, the free tier allows 400,000 seconds per month or alternatively, you can get 3.2 million seconds using the lowest memory setting of 128MB. That’s a heck of a lot processing that can be done before you get charged anything. You can find out more about pricing over here.
Can I use it in..?
The obvious trade-off for having ease of execution and reduction in cost, is that you need to give up control of your environment. If your code has additional OS needs, it may need to be adapted or hosted with a different service. There are also known issues with cold starts affecting latency of requests, though there have been large improvements in reducing both the time and frequency of cold starts.
AWS Lambda offers an easy way to accomplish many activities in the cloud. AWS Lambda is about getting the job done with least effort—and little cost. If laziness is a habit of a great developer, then AWS Lambda is like a pot of gold for the developer.