The Microservices development team needs to have a clear list of trade-offs they have made during the Microservices identification, design, development, and deployment phases. Following is the tradeoffs checklist one can use and document in detail each aspect of tradeoff before services development.
Before you ponder into the below list, I think, it is important to know what a “trade-off” means?. In my view, it means “advantages & disadvantages”.
Below thoughts are developed based on the research done on the trade-off topics.
| 1 | Improved Modulatory, Coupling, Cohesiveness | 1. Understand the core structural abstractions of current application architecture before jumping into Microservices and achieving modularity of your application through the Microservices approach 2. For an Enterprise domain, like say Healthcare, while building Microservices in a modular way, first, we need to identify the sub-domains in the enterprise domain in the context, establish the responsibilities and boundaries of each sub-domain, design domain models and data models for each of the modules using DDD approach with each boundary (bounded context) becoming a Microservice 3. Then decide whether you need to distribute the above-identified Microservices into “a distributed services” or “a single monolith with all identified Microservices together in a disciplined coding/development practices and code analysis tools” 4. It is due importannt to understand the reasons to adopt the microservices architecture style needs to be well understood. Some of the questions that need to be asked while modularizing or adapting different Microservices are: 1. Do they (different modules) really work with different business domains? 2. Can these services be developed and deployed independently on each other – if not then it is better to put then into a single microservice 3. Does your microservices is providing good functionality for the domain or sub-domain in the context |
| 2 | Low Operational Overhead | 1. Developer Productivity – a specific service responsibilities and internal processes ‘vs’ communication with other services through inter-process communication mechanisms 1. A developer doing Inter-process communication require a great deal of understanding the service contract definition (say through Swagger definition) and transforming the current service Aggregate object or Entity object or Value Object into the service contract definition JSON or YAML format 2. Ability and time for a developer to find another services in the service registry 3. Detailed description to developers on how dependent services are glued together or what other services dependent service invokes to understand the service invocations journey of a core entity model primary key 2. No of integration points (internal other business systems and 3rd party systems) 3. No of runtime environments 4. No. of business logic transformations 5. New feature development – still keeping current system alive 6. Pull ‘vs’ Push Events management |
| 3 |
Environmental Isolation |
1. Auto-scaling of individual services 2. Monitoring of each service performance at CPU, Memory, Network bandwidth 3. Faster exception handling if any runtime exception occurred in any of the services |
| 4 |
Mono-repo ‘vs’ Micro-repo All Microservices codebase in a single source code repository |
1. Time taken to test each service and sub-modules within it 2. Shared libraries testing 3. Impact of each individual service(s) testing when shared libraries version gets updated 4. In Mono-repo approach, failure of test cases in any of the services can impact the release of other successful testcases passed services 5. Testing dozes of services in Mono-repo might take more time compared to testing each Microservice independently and packaging them when ready Mono-repo provides an advantage of consistent shared libraries code versions and also 3rd party libraries versioning |
| 5 | Out of the box visibility | 1. List of services running 2. Command line and 3rd party app tools that provide querying of services and their logs for operational or debugging purposes 3. Detailed graphical view of services that provide nitty-gritty details on the services running like CPU, RAM, No of times invoked, throughput, performance, access pattern, security aspects, input-output data formats, its auto-scaling information, 4. Categories of Visibility: 1. Service Discovery – Visibility of New or Updated Services 2. Services Dependencies Visibility – including interaction of services, their connectivity 3. Policy driven interactions visibility that details both whitelisted and blacklisted hosts or ports; un-authorized access to the services 4. Visibility on performance and health checks – performance of inbound and outbound requests; Visibility of CI/CD practices – build or release versioning of each service in case of blue-green deployment; visibility on configuration parameters and their values used in each service |
| 6 | Message Queue Depth | 1. Messages queue depth or volume and how many services or how much a single service needs to consume and process them Head-of-the-line handling – since message queues are FIFO (first-in first-out), how much of each message is taking their message processing time (i.e. head-of the line in the queue) so that messages behind the line are not waiting for them to be consumed and processed further |
| 7 | Changes to shared libraries – impacting all the services | 1. What level of code duplicity is required if we can separate a business domain/sub-domain into different microservices 2. Though certain types of coupling is a big NO-NO, sometimes it is ok to have a coupling with shared libraries a. But ensure that the above common library is not trying to fit requirements of multiple microservices with multiple if-else conditions within the library that supports every microservice that is using this library b. Maybe create shared libraries for utility functions or common DAO (data access) repositories that can improve the developers productivity Also ensure that such dependent libraries does not slow down the desired microservice release because the desire for microservice is to release often |
| 8 | Auto-scaling approaches, challenges & issues resolution | 1. Understanding of auto-scaling concepts is due importance. Some of them are: 1. Naming Server (location transparency) if you have multiple instance of your microservices. 2. When to use auto-scale – attributes that needs to be considered to auto-scale should be defined clearly. One way to do this is through monitoring of your application services / microservices |