Couple of Minutes: Serverless Microservices Decomposition
The microservice architecture structures an application as a set of loosely coupled services. With Monolithic architecture, all of the code reside in the same code base (probably grouped as modules in different sub packages). Now the question is — How do we decompose the application into multiple loosely coupled services?
We introduced our serverless microservices architecture in one of the earlier posts. In this post, we will be exploring how we have decomposed the same application into microservices.
Before looking at how we have decomposed our application into microservices, we should first understand the standard patterns followed to decompose applications into microservices. There are 4 standard patterns followed. They are Decompose by business capability, Decompose by subdomain, Self-contained Service, Service per team.
Below is a picture that depicts how we have decomposed our application into microservices
If you look at the picture above, you should be able to guess the pattern used to decompose. We have used Decompose by business capability pattern. Let us see how.
Decompose by business capability recommends to define services corresponding to business capabilities. A business capability often corresponds to a business object. What are the business objects in our application? Media (Photos), Metadata and Ads are the key business objects in our application. So we have 1 service corresponding to each business object as listed below —
photo-service is responsible for photos (Microservice# 1 in green),
metadata-service is responsible for metadata (Microservice# 2 in blue),
ad-service is responsible for recommending ads (Microservice# 3 in red).
You should be disappointed if you were looking for each lambda function to be listed as a microservice. We may probably call each function a nano service in our case. While every function performs a single responsibility, each of them aren’t delivering a business capability on their own. A few functions cohesively/collectively are delivering a business capability and that’s how we have grouped them as microservices.
Let us explore a different microservices pattern used in our application in the next post.
Click on individual microservice names to access their respective git repos —
photo-service
metadata-service
ad-service
Note: We have focused on decomposition patterns to use when you are dealing with greenfield projects. If you are working on migrating a monolith to microservices, you should be interested in exploring Strangler pattern.
