Simple is not Easy in Serverless Architecture

Introduction

Good morning, I'm Kato. This article is for Day 5 of the AWS Lambda and Serverless Advent Calendar 2023 Series 1.

The claim of this article is that when developing with a serverless architecture, implementing a certain feature by solving it only with software is "Easy," but solving it with architecture is "Simple." However, this does not mean that Simple is always superior to Easy or should always be the choice. It is necessary to choose between Simple and Easy depending on your own context.

Case Study

Web API with Slow Responses

API Gateway and Lambda are frequently used when building Web APIs on AWS using a serverless architecture. Let's assume a certain endpoint calls an external API, and that response takes 25 seconds.

Since the maximum timeout for API Gateway is 29 seconds, it can barely be implemented as a synchronous process. While this is easy to implement, there are problems: (1) fluctuations in the external API's response time could cause it to exceed the timeout, making operations unstable, and (2) additional external API calls might be needed, causing the timeout to be exceeded.

Easy pattern

By putting the request received from the client into SQS and completing the process, then calling the external API with a Lambda function triggered by that SQS, you are freed from time constraints. However, in this case, the response must be saved. Additionally, the client needs to make a separate API call to retrieve the result. If the result needs to be communicated after the initial request without further user action, the client would likely need to perform polling.

Simple pattern

Many people might object to calling the latter "Simple." However, when considering both software and architecture, I believe the latter is Simple.

While the number of AWS resources has increased, the software has become simpler by an even greater margin. In the Simple pattern, three Lambdas appear, but each handles a single concern: (1) sending the request to SQS, (2) calling the external API and saving the result, and (3) retrieving the result from DynamoDB and returning the response.

In this case, I would choose the Simple pattern. However, choosing the Simple pattern is not always correct. If the development team has software development expertise but lacks knowledge or a point of contact for Web API development with API Gateway + Lambda, it is better to choose the Easy pattern and work hard on handling everything within a single Lambda function.

In the Simple pattern, if you need to share the same software model between the Create and Read Lambdas, To what extent should AWS Lambda deployment packages be constructed? is helpful.

Lambda Granularity Called from AWS Step Functions

I will add this later.

Temptation toward "Easy"

Those who are familiar with serverless may have looked at the examples introduced in the case study and thought they were unremarkable, typical serverless architecture patterns. That is indeed the case.

When developing from scratch, if the requirements are all there from the beginning, it is not that difficult to discover the Simple pattern. The problem is when requirements are added or changed while continuously developing the software after its release.

At such times, one is inevitably tempted to solve the problem with software alone. In some cases, you may not even realize that you are being tempted and may choose the Easy pattern without comparing it with others.

Furthermore, if we dig deeper, we may be focusing only on the added requirements and overlook a better architecture that could have been discovered if we had considered both the existing and added requirements together. (I often make this mistake.)

Afterword

I started writing this post thinking that I could write as much as I wanted about a problem I often face lately, but then I couldn't remember the details and couldn't make it into a good example, so it turned out to be a half-baked blog post. I'm sorry.

References

• Simple is not Easy