If you have experience working in Agile and Scrum teams, we will size our user stories based upon t-shirt sizing, based upon how complex the user story is, we are going to assign one of the t-shirt sizes for the user story.

The same applies for the microservices as well.

Challenge

The challenge is about how to right size and identify service boundaries of microservices.

So this is the most challenging aspect of building a successful microservice system inside any organization. Because without proper sizing and identifying the boundaries of microservices, we can’t build a good microservice network inside any organization.

For example, any organization or any project who wants to migrate to microservice from monolithic or who wants to develop microservices from scratch, first they need to identify what is the right sizing (or) what are the service boundaries for their microservices.

When I say right sizing, I mean your microservices should not be so big where you are not able to grab all the advantages that we have with the microservices and at the same time they should not be so small and they should not have very less business logic due to which we will end up having more number of microservices inside the organization.

If you onboard more microservices which are very small in nature, then definitely there will be some operational overhead to make sure all these microservices are interconnected. There’s going to be lot of operational overhead.

→ That’s why as an architect, as a developer or as a technical lead or as a manager, it’s our responsibility to make sure our microservices are following the right sizing based upon the business needs.

How to derive sizing for my microservices ?

There are 2 most commonly followed approaches or standards in the industry.

• Domain-Driven Sizing
• Event Storming Sizing

Domain Driven sizing

The very first approach is Domain-Driven-Sizing. 

Since most of our business logic are enhancements driven by the business needs, we can size (or) define the boundaries for our microservice that are closely aligned with the domain driven and business capabilities.

When I say domain driven, for example, inside the EasyBankApplication, we have various domains like Accounts, Cards, Loans, and very similarly, there can be other domains inside the easy bank.

In other words, we can call these domains as departments or different verticals inside an organization. We can build microservices based upon these domains.

–> We should discuss with all the business people, technical people, architects inside the organization who have the domain knowledge. There might be some people who might be working in the organization for many decades.

We should take inputs from all those leaders and experienced people to understand what a domain is doing on day to day operations, because no single person will never know all the business happening inside the organization.

That’s why we need to talk with the domain experts and talk with these domain experts, business leaders, along with the technical people, clients, business analysts, product owners, so this is going to be a super time consuming process.

Definitely, It is not going to happen in 1 or 2 days. At least, it will need 3 to 6 months of time where you will gather all the domain related information.

• What are the operations that are being handled by each domain?
• What is the team size?
• What are the existing applications?

Once we have all this information, there will be a good brainstorming happen and inside these brainstorming sessions you will involve all the business people, technical people, business people, client people, and accordingly, a right sizing will be identified for the microservice.

When you start with a size for microservice, it is obviously not going to be the right size for many organizations.

Initially, they will start with some assumptions and with some sizing of the microservice. Once they get started with the microservice development and deployments, if they see a lot of operational overhead is required, that means they might have identified a lot, many microservices, which is a operational overhead in such scenarios, then definitely they will revisit their sizing and they will try to club some microservices to a larger microservice.

This way this is going to be a continuous process where business will try to see if the current sizing of the microservices is fine. If not, they will try to fine tune it either by splitting the existing microservice or by clubbing the microservices.

So this is one of the most common approaches and this has its own advantages and disadvantages.

→ One of the primary disadvantages is, it is time consuming and it also need a lot of people who has good understanding on the business and domain.

Event Storming sizing

In this scenario, a facilitator is going to conduct an interactive session among various stakeholders like product owners, developers, testers, clients, business owners, business leaders.

Inside these fun sessions, everyone will be provided with some sticky notes. On top of those sticky notes, they will be asked to think about an event that is possible inside a business.

Once all the possible events are identified by the stakeholders as a next step, they are going to identify what are the commands and reactions.

Command is a process which will initiate the event. For example, for the completed payment event, the customer has to click on a button to initiate the payment. So that is going to be a command and the reaction can be the amount will be deducted from his account post the completion of the payment.

Once all the events, commands reactions are identified, they will be separated and segregated based upon the domain.

For example, all cards related events, commands and reactions, I can move to the cards domain. Similarly for Loans and Accounts.

→ Anyone who is using your product on a day to day basis, who is testing your product on a day to day basis, they can provide their inputs, like this is the event that I can perform inside the application.

And since this is going to be a super interactive and fun session with many stakeholders, you can gather a lot of information with a very few meetings. Maybe you can conduct 5 to 6 meetings in a month and within a month you will have all the event information along with that domain mapping.

Once you have all this information, it is going to be super, super easy to rightsize your microservice.

→ The facilitator will try to invite all the right people, including the clients, developers, testers, managers, architects, and business leaders. Post that they are going to provide unlimited modeling space, which means using sticky notes or any other approach.

You need to give a freedom to the stakeholders that they can mention any number of events.

• First, we need to provide the sticky notes to the stakeholders.
• Once the sticky notes are provided, all the stakeholders will provide their inputs like what are the possible events that can happen inside an application?
• Next step, we need to identify commands for each domain event. Once the commands are identified, We should also identify the reactions that may happen because sometimes a reaction can act as a command for the next event.

Once all these events commands reactions are identified, you can try to segregate them based upon those domains or based upon the business or based upon the departments.

→ Once you have these domain specific events, this is going to be input for your right sizing of the microservice.

This process is going to be engaging with all the stakeholders and it is going to be more effective compared to the Domain-Driven Sizing.

Right sizing – Use case with EasyBank application

Let’s try to take an example of a BankApplication that needs to migrate or be built based upon a microservices architecture.

So whenever someone is trying to migrate or built based upon a microservices architecture, definitely first, they need to identify the appropriate sizing for the microservices.

The CEO or the CTO of the bank, he or she formed 3 different teams for this analysis and he or she asked them to come up with their own sizing for the microservices.

Let’s try to see what these three different teams are trying to come up with, based upon their understanding of the BankApplication.

They might have used the Domain-Driven Sizing or Event-Driven Sizing. It’s up to them, but let’s try to see what they come up with.

The very first team, they came up with a sizing saying that saving account and trading account related business logic can be separated as a single microservice.

So this bank application, they support both saving account and trading account. Using a savings account you can save or you can store your money digitally. And similarly, with the help of a trading account, you can buy and sell the stocks mutual funds. So they’re trying to club both the savings account and trading account into a single microservice.

And similarly, the bank also provides cards and loans related products to the end customers. They’re trying to club both these cards and loans as a single microservice. So this is what team1 came up with.

Team2 recommended having a separate microservice for the savings account and trading account. And very similarly, they also recommended separate microservice for cards and loans.

So Team2 came up with four different microservices, whereas Team1 came up with two different microservices.

Team3 came up with so many microservices like one for savings account, the second one for trading account, which is very similar to team2. Now coming to the cards, since the bank application supports both debit card and credit card, they are recommending a separate microservice for debit and credit card. And inside loans also, the bank is going to offer many types of loans like home loan, vehicle loan, personal loan for all these types of loans.

Team 3 recommended separate microservices.

With the approach team1 suggested, there is a tight coupling between cards and loans and saving accounts and trading account. In future when a cards team they want to enhance the microservice for their own needs, then definitely there will be some issues from the loans team.

The team2 recommendations look most reasonable and correct sizing to me because all the business domains they are recommending as independent modules or microservice. So there is a loose coupling and at the same time, this sizing gives flexibility to the different teams inside the organization to have their own enhancement life cycle. And on top of this they can choose their own language, their own database.

The team3 approach also makes sense, but in order to go for this service, you should have huge functionality that separates between debit card and credit card and home loan and vehicle loan and personal loan. If the functionality is very similar, then this is not a right sizing because you will end up having too many microservice which will attract lot, many operational overheads.

→ No sizing is the right sizing. Initially, and if there are some issues you should continuously follow sizing your microservices till you reach to a safer and correct sizing.

In fact, the expectation also is not to identify the right sizing on the day one itself. Companies are organizations, they will have their own learnings with their own microservices sizing, post that based upon these learnings, they will always try to rightsize and identify service boundaries for their microservices.

Right sizing – E-Commerce application – Migration use case 

Let’s try to consider a migration use case where a e-commerce startup, they’re trying to migrate from monolithic architecture to the microservices architecture.

Let’s try to imagine an e-commerce startup. In the initial days, they used to have a monolithic server. Inside the monolithic server, they used to have APIs which can be consumed by client applications like mobile applications. 

And very similarly, they also have MVC style web application exposed to their website. From their website a web app MVC Path will be invoked and the same will be redirected to the backend monolithic server. Inside this monolithic server, there are many modules that are clubbed and deployed inside a single server.

They have a single relational database inside their database layer.

→ Now let’s try to see what are the problems that they are facing with this setup. In the initial days, everyone is happy because the team is very small and the traffic and volume that is coming towards a website and mobile application is very small.

So they’re able to manage with the monolithic application because building, testing, deploying and troubleshooting an issue is very easy with only a single server.

→ But later on, after a few years, this e-commerce application became super famous, and they started receiving a lot of traffic, a lot of data. And at the same time they’re also facing a lot of competition from the other competitor website. So with all this setup, they are facing a lot of challenges.

Let’s try to understand what those challenges are. The very first challenge is the application becomes super complicated and no single person understands the entire application. Because over the years a lot of business logic was added inside the same application. And many people, they left the organization and at the same time there is a lot of tight coupling between the multiple modules.

Making any change will attract a lot of bugs and regression issues, so they cannot really make any changes within a short period of time. Any change that they want to do, it requires months of time because along with the development, you should do a lot of testing, regression testing, performance testing.

→ If they make a small change inside the invoice module, they need to redeploy their entire application, which is unnecessary and time consuming, and any single unstable component can crash their entire system.

Since the application is not separated and loosely coupled based upon the business logic, definitely the organization cannot build isolated small teams by following agile delivery methodology.

They can’t have different, different scrum teams focusing on different, different functionality because everything is tightly coupled.

→ So with all these challenges e-commerce team, they decided to migrate their monolithic application to microservices network.

The technical team, they have built this architecture and the client side, there will be a mobile application and a website which is built based upon the latest UI stack like Angular or React.

What they have done – 

With this, both my mobile client and Angular are react based web application, they can try to consume my REST APIs or microservices.

I can simply expose all my business logic with the help of REST APIs and that’s why my client applications, they can communicate with my backend with the help of API gateway. All the microservices, including the API Gateway, deployed with the help of containers.

On the backend what the team has done is, they have separated all the modules into independent microservices.

Anyone who wants to communicate with my microservice, first they need to talk with my API gateway. Using API Gateway, my client application, they can invoke my REST APIs or microservices, and all these microservices, including API Gateway, is deployed as a Docker container inside a Kubernetes cluster.

→ The beauty of this microservices implementation is each microservice can have their own supporting database, they can follow their own programming language or framework.

Now this e-commerce organization, they can also have different agile teams, different Scrum teams focusing each of these microservices and they can travel with their own enhancement life cycle, with their own defects and with their own deployment lifecycle.

Here also, right sizing of micro services is important.