AWS Lambda is among Amazon’s cutting edge services designed to allow you to build microservices using serverless architecture. It’s an exciting technology (I’ll get to why in a second), but like being an early adopter of anything, it does require some patience. I’ve encountered a number of gotchas while working with AWS Lambda that I thought I’d share in order to save you some time and trouble.
Introduction to AWS Lambda
First, what is Lambda? Lambda allows you to run discrete functions in the cloud in reaction to events. It allows you to place a function call in the cloud in a single file, and the function runs in reaction to a specific event, such as someone hitting your website or uploading an object to an S3 bucket.
Perhaps the biggest benefit of using Lambda is how stupidly cheap it is. In EC2, you’re basically paying for provision capacity by the hour. If you launch an EC2 instance for 30 minutes, you pay for an hour of execution time. If you run it for one hour and five minutes, you pay for two hours of execution time. With AWS Lambda, however, you only play for the time the code itself executes. If your function runs for 300 milliseconds, you’re charged for 300 milliseconds of compute time. You only pay for actual CPU compute time, which is a radically different way of billing for compute capacity.
Okay, so onto the gotchas…
Lambda Gotchas
Gotcha #1: The “Deploy API” button
After every change you make in the API Gateway, you have to click on the blue “Deploy API” button. This isn’t a big deal — once you know to do it. I spent about three hours talking to myself in the AWS forums trying to figure out why none of my changes were visible and it was simply because I wasn’t hitting this button.
Gotcha #2: If you need the latest version of boto 3
Lambda executes in a container that’s provisioned with a set version of boto — the library for Python. When I was playing around with Lambda, I ran into a situation where I needed a newer version of boto. The way you do that is you package it up in a third-party library and you integrate the code (as you can seen below), which tells Lambda to use that function in your own code rather than defaulting to the system library version.
Gotcha #3: By default, log retention is indefinite
When you’re doing a lot of debugging and testing, CloudWatch logs all of your executes, debugs and dumps. By default, it’s set to never expire. It’s dirt cheap, so cost really isn’t an issue. But I found that it was getting gummed up with a lot of logs, and they were difficult to sort through. So I recommend that you change the expiration to something a little more sane.
Gotcha #4: Maximum execution time is five minutes
This really isn’t much of a downside, as long as you’re using Lambda appropriately. Lambda isn’t designed for massive batch processing. It performs better as a piece of glue that ties together larger orchestration pieces. Just be aware that if you have a logic error that causes Lambda to run indefinitely, it will terminate at five minutes.
Gotcha #5: No SLAs
Lamba is a relatively new service, so there are no SLAs. Use it at your own risk.
Gotcha #6: No Python 3 support
Python support, where Lambda really excels in my opinion, was released in October 2015. But it currently only supports Python 2.7.
Gotcha #7: No autoversioning or off-the-shelf CI/CD toolchain
This gotcha, as well as several of the others, reflects the fact that Lambda is so new, there aren’t a whole lot of best practices built around it. When you have three dozen developers all developing microservices using Lambda, how do you coordinate that? How do you do deployment? How do you do testing? Those are all issues you have to work through.
Gotcha #8: Performance at scale is unproven
Lambda runs on AWS, so we trust that it can scale to a billion requests if we needed it to, but I haven’t had the opportunity to test that yet.
No doubt there will be some bumps and bruises along the road if you’re interested in taking the first step and being amongst the initial group of developers who are learning all this stuff. We’re undergoing our first internal microservices project at RightBrain, and we’ll attempt to answer these questions and hopefully share them with some of our clients. I’ll also be blogging about my lessons learned in the future. In the meantime, if you’d like to learn more about Lambda, I give a demo in my presentation “Building Microservices with AWS.”