By Andrew Lewthwaite and Leahan Shimon, Avolution
Many organizations have started to break up a portion of their monolith applications and systems, transitioning to sets of smaller, interconnected microservices.
A recent survey by TechRepublic, found that organizations who used microservices were reaping clear benefits: 69% were experiencing faster deployment of services, 61% had greater flexibility to respond to changing conditions, and 56% benefited more from rapidly scaling up new features into large applications. 
But when are microservice architectures the best option? When can they offer the most value to an enterprise? And how do they fit in the enterprise architect’s toolbox?
The Benefits of Microservices
Consider a car production assembly line, where task specialization has been introduced to manufacture each part. Individual tasks become more efficient due to dedicated resources, operations, and labor. These newly generated efficiencies drive greater productivity and output, benefiting the overall process.
Similarly, in microservices, or microservice architectures, separate modules are responsible for building and maintaining different components of the end-product. Individual units can be modified and scaled without disrupting the other parts. In contrast, implementing changes to a single, large “monolith” module, can be difficult to manage and can quickly become complicated.
Microservice vs. Monolith Architectures
The O’Reilly Microservices Adoption in 2020 report found that “77% of respondents have adopted microservices, with 92% experiencing success with microservices.” 
While the advantages of microservice architectures are plentiful, there are also tradeoffs to consider when comparing to monoliths.
In short, microservices still need to be “architected”:
- Communication between separate services is more complex. As large applications can contain dozens of services, managing the interactions between modules securely can add extra challenges.
- While microservices allow for different programming languages to be used, the deployment and service discovery process is more complicated. A broader knowledge is needed to understand an application’s full scope.
- More services equal more resources. For the car manufacturing example above, each task station requires individual tools, workers, and processes. Likewise, a single service may call for a dedicated database, server, and APIs.
How and when to Migrate a Monolith to a Microservices Architecture
When deciding if a microservice architecture is the right option, enterprise architects need to consider their organization’s goals and concerns.
As it’s uncommon for new architectures to be built from the ground up, a migration from one state to another is the most likely scenario. This transition begs the questions: What does the current architecture allow? What does it limit? What are we trying to achieve?
Sam Newman, author of Building Microservices: Designing Fine-Grained Systems, suggests starting with Domain-driven design or DDD. This modeling exercise enables an organization to “figure out what is happening inside the monolith and to determine the units of work from a business-domain point of view”.
Considerations when Building a Microservice Architecture
Once an enterprise architecture practice has settled on migrating from one architecture to another, the team can ensure the process is heading in the right direction by:
- Determining the level of modelling detail;
- Deciding on the applied properties, and;
- Setting appropriate KPIs.
Microservices (Integration layer) dashboard in ABACUS
As different microservice platforms have different approaches to service classification, classifying an organization’s microservices should be a key priority.
One commonly used approach is to categorize services across the 3-layers of: Experiences, Processes and Systems. The diagram below illustrates this approach, using 3 layers of integration components for business services/events.
Microservices Modeling in ABACUS using an Extended metamodel for Integration Services in 3 layers: Experience, Process, and Systems
The Process of Mapping Microservices
It’s straightforward to model microservice architecture. The following 7 steps can help to inform your modeling process:
- Adapt the metamodel to support microservices. ABACUS provides a number of architectural patterns which can be used to update your current framework for this purpose.
- Populate the microservices portfolio to enhance the production architecture of the microservices layer. Use the data you have already uploaded or integrated with ABACUS.
- Add properties and values to further develop the architecture
- Create views such as Microservices Portfolio, Microservices Solution View, Microservices Dependency Views, etc.
Layered Microservices Modelling using Application Services and Application Interface in ABACUS
Microservices Modelling using “Publisher – Broker – Subscriber” Pattern in ABACUS
- Establish the relationship between microservices based on data flow and services orchestration.
- Design and implement analytics such as microservices cost, complexity, and availability.
- Develop a reporting dashboard and assess integration scenarios (see above example Microservices (Integration layer) dashboard).
Andrew Lewthwaite and Leahan Shimon, Avolution
Avolution produces ABACUS, used by 3000+ organizations worldwide to deliver quick, powerful enterprise architecture and digital business strategy. Integrate and collaborate on data with editable cloud-based lists, build models and roadmaps, run analytics & algorithms and report with rich visuals and dashboards.