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

Serverless is a piece of cake for anyone if they are dealing in a lower testing environment with fewer microservices and smaller chunks of code. But when it comes to a real-life production environment scenario, the architecture and the code base get a lot more complicated. AWS Lambda usage can vary from serverless websites to real-time data transformation to building a serverless IoT backend for your application. The more complex the architecture, the more complicated the lambda workflow will get.

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 -

<Diagram — Monolithic approach vs. Micro-service Step Functions approach>

2. Unwanted Packages and Dependencies

As mentioned earlier, the bigger the deployment, the slower the function will start. Generally, Lambda functions require a number of code libraries and dependencies for a function to operate as intended. According to AWS documentation, Lambda will periodically update these libraries to enable the latest set of features and security updates. These updates can change how the function will work. Using complex dependencies might also make the function code more complicated.

Recommendations -

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

AWS Lambda is best known for its high availability and flexible scaling. You can automatically scale your application or alter its capacity by controlling consumption units rather than individual server units. That being said, the same scalable solution can be overwhelmed quickly if it is not built correctly. If you have non-scalable and/or non-serverless services integrated downstream of your Lambda function, the Lambda function can easily crush the non-scalable services. Oftentimes, these limited-throughput, non-scalable services will be bottlenecks in your architecture. It is important to recognize these early on.

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

Recommendations -

4. Use of Synchronous Calls

If you are a developer, you must be familiar with synchronous and asynchronous function calls. A synchronous function call is where service A makes a function call to service B to perform its own task, and waits until service B finishes. In an asynchronous function call, after the function call is made by service A, it does not wait until service B replies. Service A can go perform some other tasks without having to wait until the first function call is completed.

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 -

5. Sharing is not Caring

In a standard application architecture, code sharing is commonly practiced by developers allowing them to build their features quickly (eg. Copy the same caching middleware built by someone else on the team). This is not ideal when developing on AWS Lambda.

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 -

<Diagram — Lambda layers>

6. Lack of Cost Controls

Lambda charges are simply based on function execution time and the resources allocated. Since Lambda functions can scale extremely quickly, it can result in billing you a fortune by surprise. The following lists a few preferable recommendations that should be considered when building cost-optimized serverless architectures.

Recommendations -

7. Choose wisely — It’s not for everybody

According to AWS documentation, there are some common use-cases for Lambda functions. Some of them are file processing, data and analytics, hosting websites, and mobile applications. But in certain situations, you may have other alternatives that can improve performance. As the sub-topic depicts, serverless architecture is not for everybody. It does not have solutions for everyone.

Recommendations -

Summary

AWS Lambda is a popular choice among today’s developers and solutions architects to implement serverless workloads. You can build faster while focusing your development efforts on what makes your app unique and thereby reducing time to market when basing AWS Lambda as your serverless compute layer. In serverless, there are recognized patterns that can aid in the management of larger and complex systems. This article aims at explaining the seven most frequent pitfalls to avoid when architecting serverless workloads on AWS Lambda.

References

Smart cloud diagrams. www.patchduty.com