Exploring AWS Serverless Architectures & Patterns

Serverless architecture is a way to build and run applications and services without having to manage infrastructure. The approach helps the teams to focus on the actual business value add and forget about the Infrastructure management. There are many other advantages with Serverless based architecture and you could find blogs covering the same.

The focus of this blog is to cover some of the Serverless Architecture patterns that I have used in real life projects. Let’s take a look at them —

Pattern 1This is the simplest architecture pattern that you would come across the moment you search for Serverless based architecture.

Serverless Architecture Pattern 1 — Backend API Service

A backend service with AWS API Gateway acting as the Proxy layer for the Lambda based business functions. Lambda functions are invoked by API Gateway in a synchronous fashion. Data is saved or retrieved from AWS DynamoDB, a Managed NoSQL Serverless service from AWS.

API Gateway comes with lot of additional features like Caching, Rate Limit, etc. which can be leveraged as per the business need.

Single Lambda function for all the business functionalities or one Lambda per business functionality is a typical question that I am generally asked? Well, to keep it simple and secure — Use Single Responsibility Principle and have one Lambda function per business functionality. Club all related Lambda functions to have high cohesive ness and form a Microservice for the specific domain. And follow Least Privilege principle — Each Lambda function has an execution role with only those permissions required for it to achieve the business functionality.

Pattern 2If you are dealing with multiple Microservices in your product, with each service owned by a different team, how do you deploy these services is a very important question that needs to be addressed?

Well, one of the approaches is depicted below —

Serverless Architecture Pattern for Hosting Microservices

Key Points —

  1. Each Team manages and owns end to end service deployment — API Gateway, Lambda functions and DynamoDB.

  2. Each service gets deployed in a different AWS account (managed by the service team). It inherently increases the TPS of the overall product because API Gateway and Lambda functions concurrency limit are at the Account level. These limits are off-course soft limits and can be increased by raising a case via AWS Console, if you plan to host the services in the same AWS account

  3. Each s