It’s right there in Amazon’s tag line for Lambda, what I would argue is one of the most interesting cloud services they’ve released to date: “Run code without thinking about servers – pay only for the compute time you consume.” Let’s have a look at those claims, and especially let’s look at them in relation to EC2, their older and more traditional IaaS cloud offering, because, hey, hasn’t Amazon made those same claims before? If Lambda just offers the same thing as EC2, why is it a separate service? Or did EC2 not really offer those things, but Lambda really does?
Let’s start with the idea that you don’t need to think about servers. In fact, Amazon (and Microsoft and Google with similar offerings) uses the new word “serverless” to describe Lambda. That language has been rightly criticized because Lambda does still run on servers, of course. You just don’t need to specify them to use the service the way you did with EC2, since Lambda is just about running functions. No more choosing instance types from the dizzying array in the AWS catalog. You simply tell the service how much memory your function needs to run, as well as a “timeout period” after which they will terminate an execution if it is taking too long. That’s important, since it protects you from getting a huge bill if your function doesn’t work as expected. Once you select your memory requirement, Lambda allocates “proportional” CPU power, network bandwidth, and disk I/O to a Linux container for your function, and the CPU power allocated is in the same proportion as a general purpose EC2 instance. Your function also receives 500MB of non-persistent disk space in a temporary directory. If you need persistent storage, then you go outside Lambda and use another service like S3.
In short, Lambda is simply about running code, and so it removes as many of the infrastructure planning and management tasks as it possibly can, to a much greater degree than EC2. That includes handling redundancy across multiple availability zones, so you don’t need to manage disaster recovery, as well as automated backups of your code. It also includes continuous horizontal scaling, so that whatever server instances are needed to run your code as your functions are called more and more frequently are simply added to the service automatically. All of this is great for developers, because running code is all you really want to do while you’re developing – the less infrastructure hassles you have the better. Some have begun referring to Lambda and its competitors as “Function as a Service,” and I certainly find that to be much more accurate and descriptive than “serverless.”
I should mention, and this is very important, that while it’s true that Lambda removes the need to “worry” about servers, there is still one IT management task that you will need to worry about: security. Security is handled via AWS Identity and Access Management. You need to specify the IAM role required to run each Lambda function, and of course you still need to make sure your users (or other event sources) are properly authorized to have that role, and that your Lambda functions are authorized to access any required resources outside of the Lambda containers. This isn’t all that different from the security requirements around any application that you design, but you may need to think about them a little earlier in the process than you would if your development platform was all on your own premises.
Pay Only for What You Use?
EC2 charges for on-demand server instances on a per-hour basis. As we’ve discussed in previous posts, that’s not true usage-based pricing because you may not need every instance for more than an hour. If your application runs for 1 minute each hour of the day, you’ll pay for 24 hours just as if it ran continuously. Lambda pricing, in contrast, is based on sub-second metering. Amazon says “you don’t pay anything when your code isn’t running.” Unfortunately, that’s not quite true. As with EC2, Lambda has a minimum interval that you will be charged for, and it’s 100 milliseconds (ms). For context, 100 ms is a tenth of a second. I’m sure Amazon’s marketing department prefers saying 100 ms because, well, it sounds smaller, right? “But 100 ms is nothing” you say! In fact, it’s the most granular pricing we’ve seen in the cloud thus far… but it’s not nothing.
Remember that each Lambda charge is for a single execution of your function. Some functions take less time to execute than 100 ms. Some take more. If your function takes 101 ms to execute you will be charged for 200 ms. It’s just a fraction of a penny you say? Well true, but when your function executes millions of times the charges add up. This situation, where usage under the minimum interval generates profit for the provider, exists for both Lambda and EC2, and Amazon is quite aware of it. Add to this the fact that Lambda can take several times longer to execute your function the first time it’s called than it does for subsequent executions. This is called a “cold start,” and it takes longer because Lambda is getting all your resources “ready” to execute your function quickly. It’s not completely clear how long Lambda will wait after an execution before you need another cold start, but while one execution per minute may be enough to avoid cold starts completely, one every 10 minutes may not be (see this post for an example).
So, my first law of cloud cost optimization holds true for Lambda every bit as much as it did for EC2:
“Know Thy Application!”
In this case that means knowing your function. If your function’s performance is CPU or memory-bound, increasing the memory might decrease the execution time, thus giving you much better performance for the same or even a lower price than you got with less memory. If the performance bottleneck is somewhere else, then you may want to decrease the memory allocated to the function to save money if you can do it without losing performance. Optimizing your Lambda pricing is always going to be a game of choosing just enough memory for your function but not too much.
My conclusion is that Lambda, along with similar FaaS offerings from other providers, does require you to think less about servers than EC2 does. It also has more granular pricing, but we’re still not quite paying only for “what we use.” Now that we’ve covered the basics, next time we’ll look at Lambda pricing in detail (complete with pretty charts), how it compares to EC2, and what that means for when you should use Lambda… and when you shouldn’t!