Key Considerations for AWS Lambda on production

AWS Lambda is an indispensable component of modern cloud architectures. Its serverless nature, low infrastructure requirements, and pay-as-you-go pricing have made it a cornerstone of production workloads. However, while the benefits of AWS Lambda are undeniable, it is crucial to be aware of certain considerations to ensure its successful implementation.

Monolithic or Individual Lambda

First choice we often faced with how much code should be there in one lambda. AWS best practice is against having a monolith lambda See here but if we separate out each functionality to separate lambda wouldn’t we end up in an explosion of lambdas? From pricing perspective it might not be a problem but what about code organization ? do developers jump around in repos for relevant code ? how to handle code duplications ?

One approach I find out useful for me is to have a single repo for related functions but deploy them as separate lambda. In this way we can keep the common code together and reuse in all the functions.

Pros -

  • From readability perspective it will feel like a single application.
  • It will still be deployed as separate functions so we are not introducing monolithic lambda.
  • We can keep the common code together hence less duplicity .

Cons -

  • Complex CI/CD, we need to understand which part of code has changed and act accordingly.

More fragmented infra

Continuing from above, if we break down a service into individual lambdas we need to essentially take care of automated deployment for each lambda. Decision that we need to take here is whether we have one infra code or separate infra code for each lambda. It will be benefecial to separate out the infra code for each lambda so that we are not unecessary building or updating all lambdas.

One problem often arises here is about which lambda owns a particular infra . We can use a tagging to assign the ownership.

But overall we are now managing from one services to multiple functions so it is a challenge nonetheless.

Cognitive load

Because it is so easy to integrate lambdas with other service we often feel lile adding lego like block and before we realise we end up with numbers of different component that working with each other.

As developer what we need here is an overall visibility what event generated by which service consumed by which lambda which in turn trigger other service it soon become a cognitive load.

Create an overall architecture diagram updated and handy we will often need that. I would personally love to have a tool that can visualize the whole topology.

Testing

AWS Lambda is an AWS offering and it often integrated with other service so a question arise how to test that. There is a whole section in AWS doc about testing. However one thing that I differ slightly from here is usage of simulator. I personally like usage simulators like localStack. This gives me the mych higher confidence than mocking out relevant parts. The doc talks about testing by actually deploying on AWS , which is absolutely fine but if devs can test locally that will be much faster. Localstack alongside testcontainers can speed up the process.

Tracing

Most of the times Lambdas are part of an overall architectue and not in a standalone way. Which means we need tracing, logging, metrics to work seamlessly when service to lambda interactions are happening.

for tracing While X-Ray is a great tool often orgs do have an existing tracing mechanism or cost of X-Ray becomes an issue. We need to come up with an unified tracing solution. One option is to depend on standard library like opentelemetery to programatically propagates tracing info. Another option is to run the same logic but using AWS lambda Extension API. In the second, we can make the tracing part language agnostic and run as a separate process than lambda.

Beware about quota

AWS Lambda by default has a quota of maximum 1000 concurrent executions in an account. Initially this might not be an issue. But as the environment grows we will start to see throttles. Beware of any scenario that can cause unbounded execution of lambda that might eat up quota from other lambdas. If the event producer produces large number of events considering having an upper bound of how many concurrent lambdas can be spawned at max. One example configuration for SQS mapping can be found here

In conclusion, AWS Lambda is a powerful and valuable tool for building scalable and cost-effective cloud architectures. However, its adoption requires careful consideration of various factors. With thoughtful planning and the adoption of best practices, AWS Lambda can significantly enhance scalability, reduce TCO, and drive successful deployments in production environments.