Download our Free AWS Pricing Calculator Spreadsheet. Download Now
In last week’s post, we discussed the history of compute, storage, and the “serverful architecture” approach leading up to the game-changing emergence of serverless technology. But now that we are officially in a serverless era, let’s discuss some of the benefits and challenges of a service like AWS Lambda.
Lambda enables decomposition of your application into very small, discrete functions. Compute costs tie directly to specific application code, which means you will very easily be able to understand which functions are inefficient and costing your organization too much money. With serverless technology, you can identify and help incentivize targeted optimization, and refactoring of application code. Ultimately, AWS Lambda helps developers justify refactoring with direct financial impact.
With “serverful” architectures, idle or under-utilized VMs are common to ensure availability. Conversely, AWS Lambda functions remain available, but are not always on, so you only pay for what you use. AWS Lambda enables the closest mapping of resource usage to demand ever.
With servers and containers, you control the execution environment, which requires management and administrative overhead. With AWS Lambda, all of these issues are negated as this service delegates the majority of administration and management of the execution environment to AWS.
AWS Lambda functions natively support event-driven execution in massive parallel so you can tie executions to a variety of event triggers, such as requests from the Amazon API Gateway, the creation of objects in an Amazon S3 bucket, or even to process records in an Amazon Kinesis data stream.
Amazon EC2-based workloads require sophisticated, resource-based auto-scaling mechanisms, which result in a lumpy mapping of usage to demand. Container workloads scale more transparently, but require complex orchestration platforms. AWS Lambda makes scaling more transparent than ever.
I’m a big fan of AWS Lambda, but it definitely isn’t perfect. Let’s talk about some of the challenges.
The first is that it’s not standardized, and it feels to many people like vendor lock-in. Personally, I believe this is a feeling more than a fact. Fundamentally, it’s really just your code, you don’t have to build a lot of lock-in into how you utilize Lambda.
The second challenge is cold starts, which I view as an incremental “day five” bump. If you have a Lambda function that you don’t call on a regular basis, the first time you call it there could be a pause or a delay, while that function is copied into the execution environment and spun up and made available. This is not just for functions that are underused, it also applies to functions that are massively used. If you’re calling a function in massive parallel, that function may need to be continuously copied out to more and more execution environments to provide the capacity necessary to actually run those Lambda functions. Again, I view this as a “Day 5” bump. There are remediation techniques, and I believe that this is an issue that will be solved. But it is a reality of Lambda today, and it is something you should plan for.
With AWS Lambda, patterns are still emerging. As a global community, we are still working to figure out best practices. This is a very innovative category and area, and that means things are going to change quickly. Frameworks help significantly with this problem. There are frameworks like AWS Amplify, and the Serverless Framework that provide a lot of guardrails and best practices to make sure you can keep track of large, complex apps. If you’re going to be building out a large, sophisticated application, I would encourage you to look at those frameworks, because they really do help.
This is a strength and a challenge. The strength is that it’s a black box execution environment that you don’t have to control. You don’t manage the operating system, or the environment, or anything about it, really. The downside is that you have less control. You are giving that up to AWS and that means if you have an issue that falls outside of this, it creates challenges for you. Again, I think this is largely a shift in thinking, as every execution environment has its limitations. So if you’re just aware of this, and plan for it, you can really do some incredible things leveraging AWS Lambda.
Now that we’ve explored the benefits and challenges of AWS Lambda, check out our third and final installment in the “Making Sense of Serverless” series next week, when we discuss several AWS Lambda use cases.