Luiz - Fotolia
An overview of how AWS changed Lambda for the enterprise market
Learn how AWS Lambda has been updated over the years to address shortcomings in its serverless computing platform, and how enterprises have become savvier about when to use it.
When Amazon introduced Lambda in 2014, it captivated users with the promise of great scalability without the need for excessive capacity-in-waiting.
AWS Lambda brought about the notion of "serverless cloud" hosting, by which applications could be available to run 24/7 but only accrue charges while in use. The majority of my clients that use AWS have adopted Lambda, though it only represents a small fraction of the average enterprise's cloud commitment. Despite this, nearly all cloud users make it a focus of their cloud application planning, and it's surely changed our conception of "cloud-native" applications.
In this AWS Lambda overview, we'll examine how the service's capabilities and use cases have evolved through upgrades and ancillary services. We'll also look at how enterprises continue to adapt to the serverless computing platform and what comes next for this important cloud technology.
The dualism of Lambda
In two key ways, Lambda is illustrative of what makes cloud computing different from the data center. Lambdas, also called functions, are infinitely elastic and agile, a true model of software power on demand. A parallel -- and perhaps less lofty -- goal of this service is to deliver cloud hosting without users having to worry about server operations. This tension between the sublime and the simple economics still pulls Lambda in different directions, as does the ultimate force -- commercialism.
Prior to Lambda, enterprises never had a platform that could support "tactical hosting" -- compute that's there only when needed. So it makes sense that they never developed software to support the model. On top of that, Lambda had its share of practical limitations when it was first rolled out. In fact, enterprises that took an early look at Lambda found it difficult to work into their IT operations, and its principles were far from obvious to development teams.
And while users liked the pay-as-you-use structure, they quickly learned that the Lambda model of on-demand code execution was best suited for handling events that happened at irregular intervals and required less processing per event. There is a delay in loading and running a Lambda, and the total cost for running Lambdas continuously could be higher than the cost of traditional hosting.
Five years of making Lambda more functional
Overall, true functional computing is highly restrictive in terms of what you can do. You can't store data in a Lambda instance because it's not persistent between steps. In fact, you can't really have "steps," because Lambda doesn't recognize the state of processing. This made Lambda primarily an event-handling tool early on. That might work for IoT, but not for business transaction processing, which makes up the majority of IT projects.
AWS Step Functions, introduced two years after Lambda's initial release, has been the most consequential move toward Lambda's commercialism. In fact, it is arguably more important to AWS than Lambda itself. Step Functions integrated two critical concepts of transaction processing: the notion of a workflow as an ordered sequence of steps and the notion of state as an indicator of where things are in a multi-step process. Most enterprise applications built on Lambda today use Step Functions.
In 2017, Amazon announced Fargate, a quasi-serverless model for container hosting. Though not directly related to Lambda, Fargate provided a pathway for enterprise applications that required more persistence, one that preserved low-touch -- or no-touch -- server operations support.
At first blush, users and analysts might have seen this as an effort to supersede Lambda, nullifying its usefulness and eventually eating into its adoption. Instead, Fargate has merely served workloads that never should have been considered for Lambda in the first place and, in effect, has lowered the number of disappointing or failed projects executed through Lambda.
By 2018, shifts in app development -- another external force -- also began to influence Lambda usage. Enterprises, in need of improved web and mobile app interfaces, adopted a cloud front-end and data center back-end model. The front-end portion of these applications was considerably better suited to Lambda implementation, and it's at this point in Lambda's evolution that enterprise adoption began to ramp up significantly.
Around the same time, AWS began to improve event-based integrations with other services and hosting models. With these features, organizations could use Lambda to process software and application events, rather than focusing on external events, such as the ones IoT devices would generate. This opened the door to more operations and management automation. For example, Amazon CloudWatch Events, combined with Lambda, can automate application responses to load changes, manage resource and app failures and even cloudburst or scale application components that aren't themselves Lambda functions.
In 2019, Amazon introduced AWS Lambda Destinations, which IT teams can use to monitor their functions by defining an event path for success/failure notifications. This is a major step forward in detecting issues with Lambda invocations and taking remedial action. It can also synchronize Lambda invocations with traditional Amazon cloud services.
A clearer perspective on where AWS Lambda fits
AWS Lambda has advanced significantly since it was first released, but the industry's understanding of serverless and cloud-native techniques has advanced even further. This has given users a better understanding of what serverless and AWS Lambda can and can't do. It's clear through this AWS Lambda overview that serverless isn't a panacea, despite some early projections that it would eventually be the destination for all applications.
Going forward, AWS Lambda will succeed if Amazon recognizes the service's limitations and accommodates them appropriately; in many cases, users' problems can be better addressed with alternative services that tackle problems Lambda never could have in the first place.
However, Lambda likely belongs in many cloud front-end applications today and should play a role in most of these types of applications in the long term. Lambda isn't the answer to all transactional processing and core business needs; VMs, containers and bare metal are here to stay. However, expect Lambda to increasingly play a role alongside those technologies in the future.
