The Challenges of Modular Monoliths

While modular monoliths are structured into logical components for easier management, they can quickly grow complex and become hard to scale. As your application expands, so does its complexity, making it difficult to maintain and introduce new features without impacting the entire system. Microservices architecture provides a viable solution by allowing you to decompose your monolith into smaller, independent services. This approach enables you to scale, update, and deploy parts of your application without causing widespread disruptions. However, the prospect of migrating an entire monolith to microservices can be intimidating, which is where tactical forking comes into play.

What is Tactical Forking?

Tactical forking refers to a systematic approach for migration that entails creating a new version of your application, or a "fork," while preserving the current modular monolith. This fork acts as a foundation for gradually constructing microservices without necessitating a complete rewrite. It's important to note that tactical forking is applicable only to modular monoliths.

How Tactical Forking Functions

Having established the rationale, let's examine the practical steps involved in tactical forking:

1. Identify and Decouple Modules

   The initial step in tactical forking is to identify and decouple the modules within your monolith. This requires understanding the dependencies among modules and minimizing them as much as possible. Utilize code analysis tools to pinpoint module boundaries, refactor the code to reduce inter-module dependencies, and set up clear APIs for communication between modules. Each module will eventually operate as a separate microservice, possibly with its own database. Therefore, a robust data modeling strategy is essential to separate the existing monolith database schema into distinct databases while maintaining normalization.

   

2. Create a Fork

   After isolating the modules, create a fork of your monolith. This fork will serve as the foundation for your transition to microservices. Establish a separate code repository for the fork, ensuring that it can run independently while implementing version control to manage the forked codebase.

3. Gradual Microservices Implementation

   The exciting phase involves integrating microservices into your forked application. Identify a module that is suitable for migration to microservices, extract it into a standalone service, and set up necessary infrastructure such as containerization and orchestration. Implement API gateways for service communication. At this point, utilize "glue code" to abstract the calls to the extracted service API within your monolith, effectively hiding the transition from module-to-module calls to API calls. Employ the new data modeling strategy to divide the existing database into separate databases for each microservice according to requirements, which can be one of the more challenging tasks.

   

4. Testing and Monitoring

   Comprehensive testing and monitoring are vital for ensuring the reliability and performance of your microservices. Incorporate automated testing for microservices, set up logging and monitoring solutions (like the ELK stack or Prometheus), and keep an eye on performance while collecting feedback.

5. Iterate

   Continue the process of modularizing and migrating modules one at a time until you reach your desired microservices architecture. Iterate through the last two steps for each module, consistently evaluate the overall system’s performance and reliability, and refine your microservices strategy based on feedback and lessons learned.

   

Benefits and Limitations of Tactical Forking

Advantages:

• Risk Mitigation: You can progressively migrate functionality, reducing the risk of impacting your existing system.
• Continuous Delivery: You can deploy microservices as soon as they’re ready, enhancing your development and release cycles.
• Testing Ground: The forked version allows for experimentation with microservices without affecting production.

Limitations:

• Redundancy: Initial stages may involve duplicated code, as migrating some parts of a module entirely may not be feasible.
• Data Strategy Overhaul: You may need to completely remodel your data strategy to ensure data integrity during the forking and splitting process.
• Knowledge Transfer: Teams must have a comprehensive understanding of the entire monolithic system before starting tactical forking to operate on their fork independently.
• Performance Overhead: The overhead from containerization and service orchestration can affect system performance.
• Potential Over-engineering: There’s a risk of over-complicating the microservices architecture, leading to unnecessary complexities.