Key Takeaways

• AWS Lambda is a key ingredient of many cloud-native applications and use-cases
• The nature of AWS Lambda requires special care for observability
• Distributed tracing is all but necessary to succeed in running complex, Lambda-based applications
• The distributed tracing needs of Lambda emphasize the need to comprehensive, drop-in, low-maintenance distributed tracing

AWS Lambda is probably one of the defining technologies of the cloud-native shift in software development of the past few years. According to the official site:

“AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume.”

Initially starting in 2014 with support for Node.js, AWS Lambda now supports development and deployment of functions in a variety of programming languages including Go, Java, Python, Ruby and C#.

LaunchDarkly Feature Management Platform. Dynamically control the availability of application features to your users. Start Free Trial.

The launch of AWS Lambda introduced us to Serverless Computing (with Function-as-a-Service as the “compute” aspect) as a mainstream cloud-native paradigm. Similar offerings have since been provided by the other major Cloud platforms, such as Google Cloud Functions and Microsoft Azure Functions, as well as by open-source projects like Knative and Apache OpenWhisky.

More than half a decade after its launch, AWS Lambda is arguably still the most known and adopted serverless platform and, despite the dearth of precise figures on its adoption, it seems fair to say it has matured beyond the “early adopters” phase.

Nevertheless, AWS Lambda is still somewhat at odds with one of the other defining topics of the past few years of cloud-native: observability. Despite Lambda’s integration with CloudWatch for metrics and logs, and X-Ray for distributed tracing, it is still a considerable challenge to understand what is wrong with a function in production.

With an emphasis on distributed tracing, this article discusses best practices for gaining and leveraging observability into AWS Lambda functions, based on the use-cases that AWS Lambdas are leveraged for in today’s computing landscape.

Why is Lambda Seeing so much Growth?

With AWS Lambda, users define functions that are executed synchronously, for example to serve an HTTP request, or asynchronously, to react to events generated by other AWS services. The list of events that can trigger AWS Lambda functions is extensive and keeps growing, with some of the most adopted event types being:

• CloudWatch events, which can be defined using simple rules that describe changes in AWS resources
• S3 events, which are emitted when objects are created or deleted in S3 buckets
• SQS events, which pass messages queued in SQS to Lambda functions for processing

But beyond what AWS Lambda can do, its defining characteristics are what its adopters no longer need to deal with:

• No more infrastructure management: AWS Lambda automates the management of infrastructure allocated to run functions, scaling up and down of computing resources. As the load your application needs to serve grows on Monday morning, with people going back to their desks, AWS Lambda will automatically, behind the scenes, increase the amount of instances of your function. And when the load goes down, at the end of the working day, under-utilized instances are automatically decommissioned. And the promise of AWS Lambda is that none of this is really something that should concern you as a developer.
• No more fixed costs: Users pay only for the workload when functions are served up in terms of how much CPU time and memory is allocated, and incur no costs when there is no workload.

#aws #cloud #aws lambda #cloud computing #serverless #development #architecture & design #article