Chapter 1: Introduction to Mitosis in Software Development

We've all encountered the challenge of maintaining a tightly coupled monolithic application, yearning to break it down into smaller, more manageable microservices, each with a clear responsibility. So, how do we tackle this task? Numerous articles outline various strategies, but in this piece, I will share our journey in disassembling our monolith.

When we initiated our planning, we aimed to begin with the smallest possible component and transition it into an independent service, all while maintaining a meticulous approach. We were also keen on monitoring our progress to enhance visibility and assess the remaining workload.

Years ago, my studies in biology reminded me of the process of mitosis, which became a fitting metaphor for our endeavor. I shared this concept with my colleagues, and together, we decided to visualize and plan our transformation accordingly.

Our architecture is straightforward and familiar: a user interface (UI) communicating with a backend via a RESTful API, featuring multiple diverse endpoints and a multi-layered structure. The data resides in a relational database.

One distinct area is the back office, which enables administrators to set up and manage essential data for users. This segment is sufficiently isolated, making it an ideal candidate for conversion into its own service. Additionally, it is compact and lacks extensive business logic, leading us to believe that the transition would be relatively straightforward.

However, we quickly learned that splitting a monolith is seldom easy. It's a reality we must accept or seek a different field entirely—there are no shortcuts here.

Nonetheless, the back office data consists of several components, and for the sake of discretion, let's say they all pertain to billiard equipment: tables, cues, chalks, gloves, etc. To minimize the changes, we chose one of these components and applied the mitosis process to it. This allowed us to assess our strategy and determine if we were on the right track before proceeding with the next component.

In the following sections, I’ll outline the various stages of our process.

Section 1.1: Prophase

This initial stage represents a singular backend encompassing all endpoints, business logic, and CRUD operations.

Section 1.2: Prometaphase

During this phase, we relocate everything pertinent to the selected component into a distinct module of the monolith, including endpoints, business logic, and database queries. This will facilitate the eventual transition to an independent service.

Section 1.3: Metaphase

At this juncture, we establish a new service (or utilize an existing one) and transfer the code from the module into it. We then create endpoints in both services to enable data retrieval and storage, mirroring the previous method calls between the modules.

It's important to note that both services are still sharing the same database temporarily. Furthermore, the UI continues to send requests to the monolith, unaware of the ongoing transition.

Section 1.4: Anaphase

In this stage, we set up a new database specifically for the back office service, containing only the necessary tables. If we find that the monolith still requires access to any of these tables, it suggests we haven't fully isolated the component and may need to either move more parts into the new service or create additional endpoints for the monolith's needs.

Section 1.5: Telophase

Now, it's time to transfer the relevant endpoints from the monolith to the new service and redirect the UI calls accordingly. Before eliminating the endpoints from the monolith, it's wise to verify that everything functions correctly by making the same calls to both services and comparing the responses.

If everything checks out, we can celebrate our success and prepare to mitosis the next component.

Chapter 2: Benefits of the Mitosis Approach

So, what are the advantages of this methodology?

1. Clear Roadmap: It provides a structured path, outlining precisely what needs to be accomplished at each step.
2. Incremental Steps: Each action is as minimal and contained as possible, minimizing the impact of any errors and easing the recovery process.
3. Predictability: After several iterations, you can develop an estimate that closely aligns with reality.
4. Scalability: With effective isolation, multiple teams can potentially work in parallel.
5. Common Vocabulary: This approach allows teams to articulate their progress, such as stating one team is in the metaphase stage with cues while another is in anaphase with chalks, enabling effective visualizations.