architect-handbook

Software Architect Handbook

View on GitHub

Splitting the Monolith

Summary

For incremental rollout to work we have to ensure that we can continue to work with, and make use of, the existing monolithic software.

To Change the Monolith, or Not?

Consider whether or not you plan (or be able) to change the existing monolith.

Cut, Copy, or Reimplement?

We want to copy the code from from the existing code, and at this stage, at least, we don’t want to remove the functionality from the monolith itself. Why? Because leaving the functionality in the monolith for a period of time gives you more options. It can give us a rollback point, or perhaps the opportunity to run both implementations in parallel.

Once you’re happy that the migration has been successful, you can remove the functionality from the monolith.

Refactoring the Monolith

Often the biggest barrier to making use of existing code in the monolith in your new microservices is that existing codebases are traditionally not organized around business domain concepts. Technical categorizations are more prominent (e.g., MVC).

When you’re trying to move business domain functionality, this can be difficult: the existing codebase doesn’t match that categorization, so even finding the code you’re trying to move can be problematic.

Seam

Michael Feathers defines the concept of seam in Working Effectively with Legacy Code.

A seam is a place where you can change the behavior of a program without having to edit the existing behavior. Essentially, you define a seam around the piece of code you want to change, work on a new implementation of the seam, and swap it in after the change has been made.

A modular monolith

It is worth considering to take your newly identified seams and start to extract them as separate modules, making your monolith a modular monolith.

Having modules that can be veloped independently can deliver many benefits while side-stepping many of the challenges of a microservice architecture.

Incremental rewrites

We are in danger of repeating the problems associated with big bang rewrites if we start reimplementing our functionality. The key is to ensure you’re rewriting only small pieces of functionality at a time, and shipping this reworked functionality to your customers regularly.