Boost your lambda serverless power using Powertools

There are many positive aspects to serverless technology, but how can you truly comprehend what is happening with your AWS Lambda functions in terms of performance, cold start effects, error handling, and tracing?

For the rescue- The AWS Lambda Powertools libraries built to compliant with the Serverless Lens-Well Architected Framework. The Python version of AWS Lambda Powertools was the first to emerge and rapidly achieved broad adoption. Currently AWS Powertools is available for Java and Typescript-recently launched.

In this post, I'll talk about different patterns available in AWS Powertools to construct metrics, tracing, and standard logging.

Why do we need AWS Powertools
The Serverless Lens in AWS Well Architected Tool, [specifically the Operational Excellence (OPS) Pillar] covers the critical topics of observability, troubleshooting, logging & monitoring.

The OPS pillar mainly talks about three components:

• Structured logging

• Metrics and alarms

• Distributed tracing

Instead of investing time to search solution over internet/forums to satisfy best practices regarding afore mentioned components, AWS Lambda Powertools provide an efficient, easy, optimise, readymade recipe to directly adopt into your lambda functions. In this blogpost, I'll show Python based code snippets to show the real power of Powertool library.
AWS Lambda Powertools make this more easily, since we just need to add an library and use a few decorators to provide a good level of observability into our lambdas.

How to enable/use powertools library
Add the following layer on Lambda function:
arn:aws:lambda:{region}:017000801446:layer:AWSLambdaPowertoolsPython:37

Alternatively, use the PyPi approach- pip install aws-lambda-powertools

Logging
Lets first understand the different type of structure logging first:

Normally, we use default logging in the lambda function as follows:

Powertools offer a simple, standardized log formmater, that can be enriched with important informations, simply using decorators:

Now, we can see a detailed structured logs by just adding 2 lines of code!

Metrics
The requirement is to have a metric to count how many Carts have been checked out. All it takes to log metrics is the log_metrics decorator.

With a few lines, we can get one of the most important metrics when working with lambda functions: the cold start metric. The cold start happens every time that your container isn't waked up, and it can became a big problem to your architecture.

Tracing
Similar to non-serverless applications, anomalies can occur at larger scale in distributed systems. Due to
the nature of serverless architectures, it’s fundamental to have distributed tracing.

Active tracing with AWS X-Ray should be enabled to provide distributed tracing capabilities as well as to
enable visual service maps for faster troubleshooting. X-Ray helps you identify performance degradation
and quickly understand anomalies.

Powertools offer multiple decorators to work with tracing. Please remember, in order to have it operational, we need to have the previous step done (previous article in this tutorial), which means proper setup in the SAM template:

Tracing needs to be enabled for Lambda function: Tracing: Active

And variable POWERTOOLS_SERVICE_NAME set, like in our example: POWERTOOLS_SERVICE_NAME: shopping-cart

@tracer.capture_lambda_handler
def lambda_handler(event, context):
    path_params = event["pathParameters"]
    game_id = path_params.get("product_id")

    logger.info("Retrieving product_id%s", product_id)

Using @tracer.capture_lambda_handler, we can automatically capture the metadata information about our handler, and see this information in Xray service map.

@tracer.capture_method
def get_product(product_id, dynamodb=None):
    table_name = os.getenv("TABLE_NAME")

    if not dynamodb:
        logger.info("Initializing DDB Table %s", table_name)
        dynamodb = boto3.resource('dynamodb')

    table = dynamodb.Table(table_name)

Logger Tracer Metrics All in one
Use all three- Logger, Tracer and Metrics component in all of your lambda functions:

Conclusion
Avoiding the circumstance where each service, or even each Lambda function, takes a slightly different approach to achieving the objectives of a well-architected architecture is the problem in applying best practises for observability. Sure, it's simple to create your own lightweight libraries for monitoring, tracing, and logging, but as your application develops, you'll need more functionality and bug fixes. What was once lightweight might rapidly turn into an unwanted maintenance burden for teams. To assist teams in writing less boilerplate code to fulfil these non-functional needs, Lambda Powertools were created. These concepts formed the foundation of the AWS Lambda Powertools packages, which concentrate on the Well-Architected Framework Serverless Lens.