21/180: Designing a Microservice Architecture

In my previous blog I have discussed the problems caused by Monolith and SOA. Microservices solve these problems.

19/180: Microservice & Architecture | by Navneet Ojha | Apr, 2021 | Medium

Single Technology Platform

With monolith all the components must be developed using the same development platform. And that same development platform is not always best for the task. There is no way to use specific technology for specific feature. Feature upgrade is also a problem need to upgrade the whole app. With microservices the decentralized governance attribute solves it.

Inflexible Deployment

With monolith, new deployment is always for the whole app. There is no way to deploy only part of app. Even on updating only one component, the whole codebase is deployed. Forces rigorous testing for every deployment.

With Microservices the componentization via services attribute solves it. Also decentralized data management.

Inefficient Compute Resources

With monolith, compute resources (CPU & RAM) are divided across all components. If a specific component needs more resources, there is no way to do that. It becomes very inefficient.

With microservices, the componentization via service can solve this problem, we can divide the compute resources as per the requirement.

Large and Complex

With every little change can affect other components. Testing not always detect all bugs. That’s why very difficult to maintain, it might make the system obsolete.

Complicated and Expensive ESB

With SOA, the ESB is one of the main components, which can quickly become bloated and expensive. It tries to do everything that’s why difficult to maintain.

With microservices, the smart endpoints and dumb pipes attribute solves this problem.

Lack of Tooling

For SOA to be effective, short development cycles were needed. Allow for quick testing and deployment. No tooling existed to support this. No time saving was achieved. With infrastructure automation attribute solves it. Automate testing and deployment. Provide short development cycles. Make the architecture efficient and effective.

Designing Microservices Architecture

1. It should be methodical
2. Donot rush into development
3. Plan more code less.
4. Critical to the success of the system

The architecture process

1. Understands system requirements.
2. Understand the non functional requirements.
3. Map the components. Split to communication pattern
4. Select the technology stack
5. Design the architecture
6. Write architecture document
7. Support the team.

Mapping the components

The single most important step in the whole process. Determines how the system will look like in long run. Once set not easy to change.

What is it? Defining the various components of the system. Remember components = Service. Mapping should be based on.

1. Business requirements. Collection of requirement around specific capability. For example. Order management. Add, remove, update calculate amount etc.
2. Functional autonomy. The maximum functionality that doesnt involve other business requirements. Example get all the orders made by user aged between 35 and 45.
3. Data Entities: Service is designed around well specified data entities. Example order, items and etc.
4. Data Autonomy: Underlaying data is an atomic unit. Service doesn’t depend on data from other services to function properly. For example: employee service that relies on Addresses service to return employees data.