The Pros and Cons of AWS Lambda

AWS Lambda revolutionized the serverless application landscape. Before, serverless implementations were limited to choosing a cloud provider for your application’s back-end functionality. With Lambda, Amazon pioneered a new development paradigm – Function-as-a-Service. In this post, we’ll give a brief overview of AWS Lambda, and then discuss advantages and disadvantages of using the service.

AWS Lambda is a service launched by Amazon Web Services in 2014 at re:Invent. It provides a stand-alone execution environment for individual functions written in Node.js, Python, Java, or C#.

Whereas a traditional web app needs to implement a server, which is constantly available over the web on an EC2 or other hosting instance, AWS Lambda removes the need for this by automating the provisioning and release of servers. Instead of hosting an entire application on a  server, you simply upload an individual function to AWS Lambda, and call it using one of the many triggers available to initiate a function call. This allows you to only call your function when needed, removing hardware maintenance from the equation entirely while leveraging AWS architecture to provide industry-standard availability and reliability.

Pro: Reduced Cost of Execution

One of the biggest strengths of AWS Lambda functions is the reduced cost of execution. In a traditional web application, with code hosted on – and accessible through – an EC2 instance in AWS, you need to pay for the server usage regardless of whether or not your API is actually in-use. This idle-time cost can be very expensive, depending on the particulars of the instance you are working with.

With AWS Lambda functions, you only pay for the computing costs that your code makes use of. AWS Lambda functions are billed by the millisecond of CPU time, instead of as a flat and scaling fee based on usage. You don’t need to worry about scaling your instance (for the most part – AWS does request that you inform them of any massive changes in scale), nor do you need to worry about spinning up an instance or web server. AWS handles all this for you.

If your code is only active for one hour, you only pay for one hour – greatly reducing your cost of execution. Furthermore, the first million (yes, 1,000,000) requests per month are free of charge. Meaning if you never exceed a million requests (with some transfer limits), you’ll never have to pay a dime!

Con: No Control Over Environment

For this ease of execution and reduction in cost, though, you do need to give up control of your environment. While AWS Lambda functions run on Amazon Machine Instances (AMIs), and thus use industry-standard tools for web and general development, you are not able to custom install packages or software on the running environment. If your code has extra OS needs, it may need to be adapted – or hosted with another service entirely!

Additionally, while AWS gives you some useful tools to maintain consistency of execution environment, you are not guaranteed to receive the same environment for each execution. In other words, even if you’re able to make use of the operating system, all of your changes could be wiped out in the next execution of your function.

Finally, you’re not given control over how the instance is maintained. Many Lambda functions operate in a hot-cold fashion, similar to containers. The first call to a function after a long idle period results in a brief delay as AWS spins up a machine instance for your function – this is called a “cold function”. While this instance is preserved for about 10 minutes after your code’s execution (making the function a “hot function,” meaning it is readily available without spin-up), after that 10th minute your function will be subject to the warmup period again. While there are some techniques to keep your functions “warm”, the spin-up costs cannot be avoided entirely

Pro: Improved Application Resiliency

Another benefit of AWS Lambda is that your code can now be more resilient when under load and in sub-optimal execution conditions. AWS specifies that Lambda functions should be stateless, and with some careful architecting you can also make each call idempotent. This frees you up to parcel out your application’s activities to any number of handlers, each of which can use Lambda to execute your application’s logic.

As your application is not hosted on a specific server, you also reduce your risk by not having to rely upon a single machine to perform all the tasks of serving your app and executing your code – if one machine goes down, AWS handles swapping it out automatically, and your code doesn’t miss a beat.

Con: More Complex Call Patterns

While improved resiliency and reduced cost are significant benefits, the design of AWS Lambda does have the potential to increase the design-time cost of your application. AWS Lambda functions are timeboxed, with a default timeout of three seconds (it is configurable up to five minutes). This means you need to spend more time orchestrating and organizing your functions, so that they can work in a distributed fashion on your data.

If you have a process that is easily chunkable, such as video processing, this isn’t a problem, but other tasks involving large amounts of data will have a tendency to exceed the runtime limits, creating significant effort for your developers that now need to rewrite the code in a different architecture. A traditional server-based application could handle this by launching another microservice, or by simply passing the object to the operating system to call a custom tool. These options are not available in AWS Lambda.

Conclusion

Serverless application development is all about tradeoffs. For some use cases, speed of execution is paramount, and the time lost to service marshaling is critical time that can’t be afforded. However, for more traditional web applications, more often than not, you simply need something that can respond in a “reasonable” amount of time (with the definition of “reasonable” varying based upon the chosen application).

AWS Lambda functions give you the flexibility to leverage this lack of restriction, allowing you to decouple your application’s code from your server architecture and create a more resilient, lower-cost application while sacrificing some control over the execution environment and execution length. Whether this approach makes sense for your application is a question you’ll need to answer on your own – hopefully, these pros and cons help guide your decision making effectively.