AWS Lambda — Steer Clear Of These Pitfalls

Serverless architecture has become one of the most efficient ways to manage variable workloads. The approach to build and run applications without having to manage the underlying infrastructure has to be a gift from heaven for Full Stack engineers to SREs and DevOps professionals. Even though there are many perks for serverless computing, there can be downsides to it as well. It completely depends on how you build your architecture.

AWS lambda plays a major role when it comes to serverless architecture in AWS cloud computing. There are must-dos and must-nots. Here are 7 common mistakes (must nots) that developers tend to make when orchestrating serverless workloads with AWS lambda.

1. Complex Application Architecture

If you are dealing with a lengthy project, the lambda invocation and execution time will take a considerable hit. And also, you will have to take care of the cold starts of your lambda functions (A cold start is a delay that is introduced from the cloud provider when executing a function that has stayed inactive for a period of time). This is one of the things that you need to steer clear of when dealing with AWS Lambda architecture.

Recommendations -

  • Divide large Lambda functions into smaller ones that contain less business logic.
  • Use the micro-service approach instead of the monolithic approach.
  • Keep the Lambda functions as focused as possible.
  • The choice of language matters with cold starts -
  • Less of a cold start — Python, NodeJS, Go
  • More of a cold start — Java, C#
  • Make sure to optimize your code if you are dealing with languages that have higher cold start times.
  • Pulling out shared clients from the handler function.
  • Keeping shared data in the /tmp directory.
  • Any external configurations and dependencies can be saved and referred to later after the initial execution of the function.
  • Use global variables, static variables, singletons, etc. to limit the reinitialization of variables and objects on every invocation.
  • Use AWS Step Functions. AWS Step Functions is a low-code visual workflow service that can be used to build serverless applications. You can easily manage the flow of several connected Lambda functions using AWS Step Functions.

2. Unwanted Packages and Dependencies

Recommendations -

  • Use the function’s deployment package to control your dependencies.
  • Minimize the complexity of the dependencies.
  • Remove unnecessary items such as unused libraries, documentation, and development-only dependencies.
  • Avoid using recursive patterns that cause run-away Lambda functions. Failure to manage recursive function calls can result in infinite loops.

Bad: Pulling in the entire SDK as a dependency

<dependencies>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk</artifactId>
<version>1.11.1000</version>
</dependency>
</dependencies>

Good: Select individual modules from the SDK that will be used in the application

<dependencies>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-s3</artifactId>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-dynamodb</artifactId>
</dependency>
</dependencies>

3. Reduced Scalability

It is wise to adhere to the following if you are integrating non-scalable services along with Lambda functions.

Recommendations -

  • Make use of the AWS queueing service — Amazon Simple Queue Service (SQS) — to implement a buffering message queue in front of the non-scalable services.
  • Decouple. Decouple. Decouple! Reduce and decouple your dependencies on non-serverless services as much as possible.
  • Use asynchronous function calls. This is discussed further below in the next topic.

4. Use of Synchronous Calls

As you know by now, serverless workloads can be cost-intensive in their nature if proper architectural considerations aren’t in place. If you use synchronous calls inside your lambda function, it will lead to longer runtimes and higher Lambda implementation costs. If the Lambda function has to wait for a long while after making a synchronous call, it will keep billing you for that extra wait time. This is something you should always try to avoid when implementing serverless workloads with AWS Lambda.

Recommendations -

  • Use asynchronous function calls as much as possible.
  • If you absolutely must use synchronous function calls, make sure to minimize the Lambda function’s idle wait time and configure the timeout conditions correctly.

5. Sharing is not Caring

When developers frequently use the same Lambda function code to base their own work on, it can lead to implementation inconsistencies and technical debt if someone modifies the shared codebase in different portions of their project at some point.

This form of functional dependency needs to be understood and eliminated with respect to Lambda functions.

Recommendations -

  • Use Lambda Layers — Consider creating a Layer and deploying code there if you want to reuse it in several functions.
  • If you are using a source code management system, the Lambda function source code needs to be very fine-grained. Always have a 1:1 relationship between Lambda functions and the code repository.
  • Use a shared API — Replace the common code base with a shared API. It can help simplify the codebase.

6. Lack of Cost Controls

Recommendations -

  • Rightsizing — Choosing the optimal memory size. Test your Lambda function at each of the available resource levels to determine what the optimal level of performance is for your application (Perf or Performance tests/benchmarks definitely help).
  • Avoid using recursive code. It can lead to infinite and/or I/O intensive loops if not configured correctly. This will increase your AWS billing with the never-ending function invocations.
  • Set up a daily spending limit using CloudWatch alarms. Configure the alarm to notify you when your limit is reached.
  • Deploy a CloudWatch Alarm that notifies you when function metrics such as ConcurrentExecutions or Invocations exceed your threshold.

7. Choose wisely — It’s not for everybody

Recommendations -

  • Gather all the requirements and functions needed before implementing your proposed architecture and figure out whether you certainly need to go for a serverless architecture.
  • Consider incorporating Lambda to assist Amazon EC2, Amazon ECS, and Amazon EKS, and other purpose-built services to manage long-running compute tasks.
  • Use purpose-built services for functions that act as orchestrators because they can result in idle time in the function.

Summary

References

  1. https://docs.aws.amazon.com/whitepapers/latest/serverless-architectures-lambda/serverless-architecture-best-practices.html
  2. https://aws.amazon.com/blogs/architecture/best-practices-for-developing-on-aws-lambda/
  3. https://wb.serverless.com/blog/when-why-not-use-serverless
  4. Diagrams by — PatchDuty

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store