“Microservices” is one of the most popular buzz-words in the field of software architecture. While our first article talks about the fundamentals and benefits of microservices, in this article we will explain how enterprises can implement microservices in real-world use cases by leveraging key architectural principles.

How to Start with Designing Microservices-Based Cloud Solution Architecture

Microservices-based solution architecture is not always the best fit for all use-cases, and using a one size fits all approach has several drawbacks. Before designing a microservices-based solution architecture, enterprise solution architects must address the following questions.

1. Is microservices architecture a good fit for the solution?
2. How should one define the microservices architecture?

While building microservices architecture for the first version of an application, we suggest going for a “monolithic” approach. This means you build your application in a simple way to validate your idea first. Then, you apply the principles included in this blog to scale and evolve your initial monolith into a microservices-based solution architecture.

There is no value in creating architecturally pure microservices that do not offer value back to the business. Monolithic Architecture patterns will help you to understand several issues and limitations about large and complex systems (that can possibly occur with Microservices architecture).

Once you have implemented your application using monolithic architecture, you need to consider the following development and operations patterns that you can apply in undertaking a microservices transformation.

1. Decomposition of The Application Into Services

Microservices architecture is a set of loosely coupled services and decomposition of the application into services plays a key role in microservices architecture implementation, deployment, and CI/CD.

Solution architects can define the decomposition methods based on need & solution, there are no “best” methods for decomposition but there are common methods, which can help you to decompose your solution in several services as mentioned below.

To apply decomposition, you need to understand the need & role of each component, weight/links between several components, and more factors for each component of the entire solution.

Decomposition Strategies

1. Decompose by module/business capability: This method suggests defining each component for each module or feature i.e. messaging, logging, device communication, user management. This helps you to assign an entire feature/module to separate teams, where respective teams will be responsible for a module/feature.
2. **Decompose by domain: **This method suggests defining the region where your solution is going to be deployed, and further defining the services to that region. Define services corresponding to Domain-Driven Design (DDD) subdomains. DDD refers to the application’s problem space - the business - as the domain. A domain consists of multiple subdomains. Each subdomain corresponds to a different part of the business. E.g. User Management, Device Management, Device Communication.

Things to consider while decomposition:

• Find boundaries for each service and align them with business capabilities
• Stay focused on defining the scope of the microservice, and not just shrinking the service. The (right) size of the service should be the required size to facilitate a given business capability
• The Service should have very few operations/functionalities and a simple message format.
• Make sure the microservices design ensures the agile/independent development and deployment of the service.
• Each service must be testable and deployable individually.
• Services must be cohesive. A service should implement a small set of strongly related functions.
• Each service should be small enough so that it can be developed by a small team of 6-members
• The application must be easy to understand and modify
• The Service must be scalable in load balancer infrastructure like ELB

#microservices #monolithic architecture #legacy applications #microservices implementation #decomposition