Serverless Microservice Patterns for AWS

Date: 11/18/2021

I've come across many wonderful blogs that cover various AWS topics that greatly helped me in my path to become an AWS solutions architect. As my LinkedIn page has been getting noticed, I've been receiving emails from people around the world on how to get certified and what will help them grow to be a better SA. Instead of reaching out one by one, I decided to blog my knowledge to share with everyone and hope it helps others as much as other AWS blogs has helped me. Not only that, this will help me review my own knowledge! I will be creating my own diagrams which is a great practice for me as well!

My first ever blog post will cover the serverless microservice patterns for AWS. I will try to be as detailed but yet simple(?) as possible to make it easy to understand.

---

Simple Web Service

The most basic and yet common pattern. Client interacts with API Gateway, which then interacts with Lambda to interact with the back-end (In this case, DynamoDB was used but this can be changed to other services such as S3, RDS databases, Amazon Redshift, ElaticCashe Nodes, and etc).

---

Scalable Webhook

First, what is a webhook? A webhook (also called web callback or HTTP push API) is a way for an app to provide other applications with real-time Information. When developing a webhook, the traffic might be unexpected. This is OK for Lambda, but if you use a "less-scalable" backend like RDS, you may have problems. There are methods to manage this, but since Lambda includes SQS triggers, we can limit our workloads by queuing the requests and then working through our queue with a throttled (low concurrency) Lambda function. In most cases, your throughput should be near real-time. If there is a significant demand for an extended length of time, you may notice some minor delays as the throttled Lambda chews through the messages (be aware that Lambda function has 15 minutes max per execution).

---

Internal API

The Internal API design is similar to a web service but lacks an API Gateway frontend. If you are developing a microservice that will only be accessed from within your AWS infrastructure, you may utilize the AWS SDK to directly use Lambda's HTTP API. When you use a RequestResponse of InvocationType, a synchronous request is delivered to the target Lambda function, and the caller script (or function) waits for a response. HTTP requests from inside microservices are common (and often required) activity, so don't worry if some people say functions calling other functions is an anti-pattern practice! Whether you're calling DynamoDB (http-based), an external API (http-based), or another internal microservice (http-based), your service will almost certainly have to wait for HTTP response data in order to complete its function.

---

Strangler

The Strangler replaces parts of an application with new and/or updated services. Back in the days I read that people develop a Strangler Facade which can route the functional transactions to legacy or modernized microservices. But with emergence of API Gateway to handle this for us using the "AWS Service" and "HTTP" integration types, Strangler Facade is no longer needed. An existing API, for example, can be routed over API Gateway utilizing a "HTTP" integration (front-ended by an Elastic Load Balancer). You may have all requests routed to your legacy API by default, and then direct particular routes to new serverless services as they are added.

---

State Machine

Serverless architectures are frequently required to offer some form of orchestration. Without a question, AWS Step Functions are the finest approach to manage orchestration inside your AWS serverless environment. State Machines are excellent for organizing several operations and ensuring that they are completed correctly by utilizing retries, wait durations, and rollbacks. They are, however, entirely asynchronous, which means that you cannot wait for the outcome of a Step Function and then react to a synchronous request.

Step Functions are recommended by AWS for orchestrating complete operations, such as synchronizing several microservices. This may work for some asynchronous patterns, but it will not work for services that must offer a synchronous response to customers. I want to isolate step functions within a microservice to reduce code complexity and provide robustness while still keeping my services independent.

---

This is it (for now)! I will be blogging more often to give back to the community and to take this opportunity as a review session. Doing this first blog has taught me how time consuming and difficult it is to write blog and draw clean diagrams. It certainly has made me appreciate more on what others do for the community out there.

Till next time!