Since its inception in November 2014, AWS Lambda has been one of AWS’s most talked about products. It’s the industry’s flagship serverless computing product, allowing customers to run workloads without thinking about the server on which they will actually run. Lambda promises cheaper compute, easier architecture, and simpler development processes. But does it deliver?

Lambda and Lock-In

Lambda allows you to write code in relatively small chunks that tightly integrate with other AWS services that run for a limited period of time, and is billed at the microsecond level. This is why analysts often place it under the Function as a Service banner.

Lambda’s tight integration with other AWS services can result in a form of lock-in that is at the root of many of its limitations. If you take a step back and think about what Lambda does, it’s obvious that any code written for it will not be portable across other computing platforms, be they on-premises data centers or other cloud providers. Tight integration with services like IAM, Amazon S3, API Gateway, or Amazon EC2 means that switching to a different provider may be impossible. It’s AWS’s way or the highway, and your application may be hostage to AWS’s fortune.

Does this matter? Maybe. You might have a regulatory need for a credible plan to move to an alternative platform (especially if you work in the financial sector). But even if this isn’t a requirement now, it’s worth learning lessons from history.
Those who remember the database wars may be familiar with stored procedure lock-in. Stored procedures were similar to Lambda in that they were effectively free to deploy to, and only added to the compute load on the servers that had already been provisioned for the database. In that sense, stored procedures were a serverless platform that assumed the environment of the database they ran on. The downside was that it became very difficult to move away from a specific database provider, and, to this day, many businesses resent paying Oracle money to run their databases.

The time will likely come when AWS exercises a similar hold over your business. Is that something you are prepared to accept?

Development

At the other end of the strategic spectrum, what is it like to develop on Lambda? Because it’s serverless, Lambda can pose particular challenges to developers who are used to having environments ready to test their work.

A local environment running on your laptop can be difficult to arrange when it comes to AWS. Although options (such as LocalStack) do exist for local replication of AWS APIs, they are still relatively niche, and they are limited in their ability to accurately reflect and keep pace with the changes constantly being made to AWS.

Therefore, your best option for testing your new Lambda code is likely to set up a parallel AWS development environment. This can be costly to model and maintain, and, on top of that, you may need to develop a CI/CD infrastructure to support your Lambda lifecycle. 

Once in production, observability can be a challenge. Ironically, because you can’t log in to a server, you have to prod and poke the code from the outside to debug issues seen at runtime. The default option of Amazon Cloudwatch Logs can feel clunky and difficult to navigate. In particular, users complain that permissions and networking issues can be difficult to debug because you can’t access the server with a terminal in the traditional way to quickly figure out what the problem is.

Architecture

Before you consider using Lambda, it’s essential to determine whether your architecture is ready for it. It is very easy to fall into the trap of thinking that Lambda can solve all your AWS architecture problems—without realizing that there are still many decisions you need to make if your applications are not already running in a cloud-native way.

Using Lambda doesn’t mean that you can ignore questions about managing IAM roles and the fine-grained permissions needed to run Lambda functions safely. You will still need to think about how you use Amazon S3 or Amazon EFS if you need a persistent store for your application—and you’ll need to consider access control and networking architecture, just as you would with a non-Lambda application. The number of decisions required can be overwhelming and often reach far beyond the simplicity that Lambda seems to offer the architect at first glance.

Technical Limitations

In the context of architecture, it is also important to understand Lambda’s very real technical limitations. The maximum time a function can run is 15 minutes, and the default timeout is 3 seconds. Obviously, this makes Lambda unsuitable for long-running workloads. The payload for each invocation of a Lambda function is limited to 6MB, and memory is limited to just under 3GB. These are hard limits set by AWS, so you can’t change them.

Are you a tech marketing professional seeking AWS experts to contribute expert-based content to your company blog? Contact us to see about hiring this writer (or others) to create content like this for you!

What can be changed by sending a request to AWS support is the default 1,000 concurrent executions limit, as well as the 75MB function code storage limit. There are also some complicated rules around scaling that limit Lambda’s capability to act as a web server for any service that you may need to significantly scale in bursts. For example, it will take at least a minute to cope with an increase of 500 concurrent executions. In other words, Lambda may not match a traditional web server for speed of execution and ability to scale.

Cold starts of Lambda functions (the time taken to initialize the first run of a Lambda instance), along with the resulting latency on any response or work done for this first run, are other potential issues to consider if your workloads are time sensitive. Amazon has made improvements in this area, but your exposure to this issue depends on which language platform you use.

Cost and Scale

At first glance, one of Lambda’s most promising features is its seemingly low cost. However, working out what Lambda will cost you is not easy. There are several factors that determine the cost of your Lambda functions. The first two are the number of requests made and the number of gigabyte-seconds (GB-seconds) your functions use. (GB-seconds are the number of seconds multiplied by the number of gigabytes of memory allocated to the Lambda function.)

In terms of requests, the first one million requests to Lambda per month are free (even if you are no longer on AWS’s 12-month Free Tier period). Then, you pay just $0.20 per million requests. As for GB-seconds per month, the first 400,000 are free; after that, you pay $0.0000166667 per GB-second.

But that’s not the only factor to consider. If you try to run a standard web service on top of that, the costs of API Gateway, Amazon CloudFront, AWS WAF, CloudWatch, and any other service you decide to use along with your Lambda function will start to add up. For that reason, a key consideration when deciding whether Lambda is right for you is how much you expect your application to scale.

Conclusion

Since its introduction, AWS Lambda has been a very popular addition to the AWS product range. While it holds up to its original promise of freeing application developers from worrying about server provisioning, it doesn’t give you a free pass regarding all the other things that infrastructure normally takes care of. You’ll still need to think about the technical limitations of the product, security, identity and access management, application delivery pipelines, developer experience, general architectural considerations, and—last but not least—cost implications. Before you take the plunge and commit your architecture to Lambda, make sure you’re ready to use it with your eyes open to these limitations.