The fundamental principles for using microservices for modernization

In Part 1 of the microservices series, we spoke about how to manage the move to microservices in a mature way. In this second part, we will look at some of the key principles to follow when using either of the three approaches we discussed: Brownfield or Greenfield or Bluefield

Some of the key principles that need to be evaluated when one starts to decompose the monolithic platform into microservices.

1. Modularization

Modularization in microservices journey is a necessary prerequisite. Modularization is essentially an abstraction of business capabilities by understanding and defining the exact core services or modules of an application landscape. Not defining modules at the onset result in anti-patterns of complex data interoperability across distributed systems, tightly coupling of services by maximizing dependencies, minimal composability, and abstraction. Using Domain-driven design (DDD) helps in choosing domain boundaries or business contexts.

2. Maintaining singular state

Each microservices built needs to have a data model that is completely decoupled and focused on the rest of the system landscape. The only way other systems or services can access the dedicated state is via API that the service provides and avoid conceptualized interfaces.

3. Target Core Services or Fringe Services First?

Core services by definition are services that mainly focus on persistence and are pure data-centric. Each isolated core service will be the future Master of Information and the discrete source of truth. Also, over-creating of these core services will lead to several unnecessary layers. It just adds complications to the application landscape where every service depends on the other without any realm of responsibility.  Once the core services get created, detailing out the Peripheral and Composite services becomes easy.

Target Functionality that doesn’t require drastic changes to the end customer application and possibly also doesn’t need any core database migration or changes. It becomes easier for subsequent services by building CICD pipelines, required alert and monitoring systems, testing strategies, and version control.

4. Split Schema or Code First?

If the core services are clear, then it’s easier to first split out the schema and keep the services together before splitting the application code out into microservices. If the services are too coarse-grained, they will be split into smaller services creating another data migration. Also, anytime two services accessing the same database results in tight coupling between these services, i.e., more complexity.

5. Moving out Services Vertically or Horizontally?

Moving out of Services can happen either vertically or horizontally. Try to move out a single core service at a time by first moving the database, business functionality, and then the front end. This technique avoids costly and repeated data migrations and makes it easier to adjust the service granularity when needed.

6. Building Micro or Macro or Mini services?

When creating a service, first identify the core services and define clear bounded contexts. It is much easier to create a macro/mini service until the core services are clearly demarcated. Once the demarcations are clear it is easy to further split into microservices.

7. Outside In or Inside Out Creation of Services?

The easiest way to create services is from outside-in, understanding how the various integrations need to talk to various applications. However, this leads to data inconsistencies and data integrity issues. Designing service inside-out is more time consuming but cleaner with defined boundaries for each service. If approached properly, this will reduce possible data integrity issues.

8. Rewriting Code or Capability?

When building new functionality try to rewrite capability and not the code. This may be time-consuming to build, but the monolithic platform already has a lot of redundant code. By rewriting capability, it gives an opportunity to improve the granularity of the service, revisit business functionality, and maintain a clean codebase.

9. Incremental or Radical updates?

Target to decouple modules or services that result in reducing traffic towards the monolithic application, this will improve the performance of the application as well as help in decommissioning of infrastructure and helping cost (licenses) if any.

10. Versioning Services Incrementally or Concurrently?

Having multiple versions of the same code leads to issue concerning maintainability and cost, but until the microservices and surrounding integrations are matured, maintaining multiple versions of the service endpoint at any given time helps in reducing failure risks and is less dependent on external systems.

11. Where to build New functionalities?

Target any new functionality getting created as new micro-services, target services that are business-centric. Do not add a dependency back to the monolithic platform. Ensure that the new services do not call the monolithic application directly and always access it via the anti-corruption layer.

Having spent a number of years learning and understanding the platform revamp of moving away from a bulky monolithic commerce platform to service-based architecture, I have learned myriad ways on how IT organizations bungle up a journey and at times come a whole full circle. There is no direct method to this madness but for sure there are best practices and learnings from earlier blunders and possibilities to circumvent hidden traps and pitfalls.

If you’d like to find out more and discuss how you can navigate the microservices journey smoothly, please feel free to get in touch with me.

Published by: Shailendra Bhatt
Managing Delivery Architect at Capgemini Sweden (Digital and Cloud Solutions)

Shailendra is a skilled Cloud Solutions Architect with over 18 years of experience in building modern digital platforms for several major clients across USA and Europe. He has led and been part of several large end to end digital solutions for different clients and demonstrated expertise in architecting, implementing and supporting enterprise grade technical solutions. His primary focus is on Cloud Transformation and Modernization, Automation, Software Architecture, Digital Commerce and Omni Channel Solutions.