AWS Lambda is Amazon’s serverless compute service. You can run your code on it without having to manage servers or even containers. It’ll automatically scale depending on how much work you feed into it. You can use it in data pipelines or to respond to web requests or even to compose and send emails. It’s the jack-of-all-trades way to execute code in the AWS cloud.
Although intended for use in the cloud, you can absolutely run Lambdas locally during development. When you do run Lambdas in the cloud, you’ll only pay for what you use. In some cases, this can save significant sums of money compared to the cost of running VMs or containers. While I’ve already touched on some of the reasons you’ll benefit from using AWS Lambdas, I want to focus on seven specific reasons in more detail.
1. Most Major Languages Are Supported
AWS Lambdas can be used today to run Node.js, Python, Java, Go, C#, and even PowerShell. Although you might be used to writing statefully in these languages, you do have to remember that Lambdas are stateless. They just run your function once, then dispose of everything. You’ll be able to persist state in your database and rehydrate it of course, but for transactions, you’ll make it all happen in one go. If you’re used to stateful object-oriented programming, you might have to shift your style a bit to utilize the Lambdas.
For you functional programming lovers, this is what you’re used to. The only thing is there aren’t any true functional languages supported at this time. Still, you have a nice selection of languages to choose from, each with their own ability to be written using the functional style.
2. You Only Pay for What You Use
As mentioned in the introduction, you’ll only pay for what you use. Billing for functions is based on 100 ms intervals. Interestingly, this creates an incentive to use more efficient code if you’re considering the costs. Also, you can tune the maximum resource usage of each Lambda, which affects the base price for your function executions.
To give you a quick idea of what it might cost, consider a function that simply logs an Amazon Cognito authorization. With a minimum memory setting of 128 MB, this Node.js function simply does the following:
This logs to an AWS S3 bucket. It runs in under 100 ms, so the execution time charged for each run is 100 ms. The estimated charges for 10 million executions of this Lambda function per month is around $2. And that’s only part of the cost savings. Lack of infrastructure maintenance is the bigger story here.
3. There’s No Infrastructure to Manage
Managers like this benefit, but there are plenty of reasons for developers to like it too. How many times have you turned a server upsidedown to resolve an issue with a server patch? As a developer, would you want to spend a good portion of your time managing servers? Or would you rather be coding up some cool stuff that matters?
Sure, it’s a fun engineering project to fine-tune a cluster of containers or a VM using shared resources, but you can still have that if you’d like. AWS Lambdas are simply another tool in your toolset. You can use them in many applications, but not every situation is right for a Lambda.
The benefit of having no infrastructure to manage is that you can spin up a new Lambda without having to add a new resource to your infrastructure. It’s a good way to extend your existing infrastructure or deploy new services in a microservices architecture. And for some services on AWS, Lambdas are the only real way to perform certain tasks such as logging Cognito login requests.
4. You Can Edit Directly Online
Don’t get me wrong. You can still create and edit functions locally and deploy them using various deployment methods. It’s just that you might come across a situation where it would be handy to create a function when you aren’t quite able to get to your favorite IDE. You can still download the functions you create in the web console and add them to source control if you choose. It’s just nice to have options.
5. It Uses Environment Variables
You might be inclined to use configurations with your code in AWS Lambdas. The good news is that they’ve got environment variables that you can set. The environment variables can be plain text or encrypted for protection of sensitive information such as passwords and keys. These environment variables are available to your function code using various methods depending on your programming language.
Environment variables are great, but what about having different values per environment? For example, in the test environment, you’ll want to connect to the test database instead of the one in production. The good news is you can do this. You can simply publish a new version with the correct variables. Each published version gets its own set of immutable environment variables. The trick is to set them before you publish.
Your Lambda will remain versioned as “$LATEST” until you publish. So what you’ll do is work on this version and test it. (You can use the built-in test feature in the web console.) When you’re ready to move it to a different environment, you’ll set the proper environment variables and publish. The Lambda will get a version number. You can alias the specific version to give it an environment name such as “test.” This version is still just a snapshot of the latest version. Once you’ve tested it, you can update your variables and publish a new snapshot for production.
6. It Connects to API Gateway and Other Connection Points
In a manner of speaking, the API Gateway is the portal to your microcosm within AWS. It’ll connect to many of the cloud services directly, but when you need flexibility, Lambda is your go-to. See, it’s where you put custom code to process requests that come in through the API Gateway. Use a Lambda when you need to access several services or do custom processing.
And besides, Lambdas can connect to so many of the other AWS services. It basically operates as an interlink between those services. As data flows through services, you use Lambdas to run custom code on that data stream. This is useful in a Kinesis Pipeline that’s receiving data from things like IoT devices. It’s useful when you want to send text messages via Amazon SMS based on a trigger. Or you can use Lambdas to create tables in DynamoDB. They can connect to Code Commit or even process your Alexa Skills and drive your home automation system via Alexa Smart Home.
At this point, you’re probably wondering how you might end up developing Lambdas locally. Let’s take a look at how you might do this.
7. You Can Run AWS Lambdas Locally
Recently, AWS introduced the SAM (serverless architecture model) CLI. This is the tool for running serverless architectures, the core of which are Lambdas, locally. With SAM, you create a CloudFormation template to define the application. The template is written in YAML, which makes it about as clean as you can get. Then you can invoke the Lambda locally using the SAM CLI. You’ll pass to the Lambda either through the output of a SAM CLI “generate-event” command or by passing a JSON file with static data. SAM requires Python, Docker, and AWS CLI.
Another option to run Lambdas locally is the serverless framework. The serverless framework emulates AWS using Node.js. It has some limitations when it comes to Lambdas: it can only run Node.js, Python, and Java functions. Another thing to keep in mind is that the emulation isn’t perfect. There are some contextual things that won’t quite translate, especially when invoking nested Lambdas. But for the most part, and for cross-cloud interoperability, it has its benefits compared to AWS SAM.
Key Takeaways and Benefits
Whatever way you choose to run Lambdas, they might just be the way to go when it comes to developing serverless applications. You can write them in different languages, you can connect several AWS components together, and you only pay for what you use—all without managing any infrastructure. All you have to do is code the function, configure them, and deploy them. These seven reasons should be more than enough to inspire you to consider using AWS Lambdas in your near future. You could even start right now by pulling down the AWS SAM CLI and running it locally. Give it a try!
This post was written by Phil Vuollet. Phil uses software to automate processes to improve efficiency and repeatability. He writes about topics relevant to technology and business, occasionally gives talks on the same topics, and is a family man who enjoys playing soccer and board games with his children.