Below are some of the key principles that need to be evaluated when one starts to break out services from a monolithic platform.
1. Target Core Services or Fringe Services First?
Target Functionality that doesn’t require
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.
2. Split Schema or Code First?
If the core services are clear then always 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, two services accessing the same
database results in tight coupling between these services.
3. 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, 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.
4. Building Micro or Macro or Mini services?
When creating a service, first identify the core services and define clear bounded contexts. Until then, the first step is to create a macro service until the core services are clearly demarcated. Once the demarcations are clear it is easy to further split into microservices.
5. 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 clear defined boundaries for each
service. If approached properly, this will reduce possible data integrity
issues.
6. 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 to the monolithic platform. Ensure that the new services do not call
the monolithic application directly and always access it via anti-corruption
layer.
7. 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.
8. 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).
9. 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 less dependent on external systems.
10. 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 to the monolithic platform. Ensure that the new services do not call
the monolithic application directly and always access it via anti-corruption
layer.