Serverless and Microservices

Is there any conflict between Serverless & Microservices?

To answer this question we need to understand what both?

What the definition of Serverless ?

Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform.

What the definition of Microservices ?

An architectural style that structures an application as a collection of services that are Highly maintainable and testable - Loosely coupled - Independently deployable - Owned by a small team.

SO we will talk about serverless from AWS Platform and how the AWS make the component they have as microservise with serverless.

Serverless Building Blocks for a Web Application

The above diagram shows, a collection of serverless technologies available in AWS to build a full-stack serverless web application. Let’s go through them one by one to understand the functionality each of them provides.

AWS CloudFront — This service works like a proxy as well as a CDN for application requests. CloudFront can route it to Amazon S3 and serve the static content. CloudFront forwards it to the backend of the application.

AWS API Gateway — This works like the event listener for API resource requests received over the web and triggers Lambda functions as required.

Amazon S3 — We use S3 for static file storage like images and other frontend assets.

AWS Lambda — The application code that handles the API backend functionality is uploaded here.

AWS DynamoDB — This is a NoSQL database service offered by AWS to store and retrieve data.

AWS Cognito — A fully managed, identity solution where it allows user authentication and authorization using OpenID Connect.

Can we use serverless for Microservices?

Let’s assume the application has grown over the years introducing services with different business capabilities. If we go along with the same technology stack, we can implement each of the Microservice using APIGateway, Lambda, and DynamoDB. However, the actual technology stack might vary depending on the exact business requirements.

But is it that simple to introduce Microservices to a growing application as shown in the diagrams? The answer is a big NO!.

In the real world, these Microservices need to interact with each other to provide business functionalities. On the other hand, these distributed systems introduce further challenges for the application.

So how the microservice will interact with each other ?

• Microservice API calls

This approach is the easiest way of interactions between Microservices, where one Microservice calls the other through its API interface. However, this approach tends to fail when there are more than two services involved in single business functionality.

• Microservice communication using Messaging by AWS SNS

This approach is the easiest when it comes to propagating data changes across various Microservices. The best thing with this approach is that it doesn’t require one Microservice to know about the other. They only need to add a listener for the data changes within each Microservice.

• Transnational behavior between microservices

The best option at hand is to implement SAGA pattern across the Microservices involved in for the transaction.When using AWS, you can model the transactions using AWS Step Functions to implement SAGAs. This approach reduces the complexity by allowing to define a state machine to handle the transaction. The AWS Step Functions are quite capable of coordinating the transaction as well as rolling it back if anything happens unexpectedly.

Summary

As you have seen, building full-stack applications using serverless is already becoming a reality. When it comes to Microservices, serverless goes further by providing a set of middleware to support Microservices interactions. These are crucial to implementing even the basic communication patterns for Microservices.