Where do you start when confronted with the daunting task of bringing a legacy system up to date? How do you figure out what the pieces of that system are, let alone what they do? In any legacy system, there are pieces that have been forgotten. Yet you are under pressure to reduce risk and bring this system “up to snuff”.
Make it Small
Monoliths are risky. They are designed so that everything needs to happen at once. Because they are not separated by process boundaries, each piece moves along with the whole. This large change makes the project risky. One way to reduce that risk is to find a way to make the changes smaller.
Break the monolith up into smaller modules. Give each module the ability to be released independently. Then, you can upgrade each of the smaller modules one at a time. This of course will take more time than the big-bang approach, but will reduce the risk considerably.
There is also some risk introduced with the act of breaking apart the system into smaller modules. This also is no easy task, or it would have already been done. However this path sets you up for much better and faster work in the future.
Start at the Edges
Where do you start breaking apart the monolith? What do you choose to start with? It is tempting to pick the pieces that change the most, as these will seem to give you a large development boost. Once you split those pieces out, iterations on them can start going faster than the rest of the system. Profit.
However, those high volume places are likely also the most important to the system. They will be the pieces most entangled in other parts of the system. They will be the hardest ones to pull out. In short, they will be the pieces you will most likely fail to extract. It is also tempting to start with new features; all new features must be added to some new system. This has similar pitfalls. Plus you get artificial and crappy boundaries with an approach like that.
It is best to start at the edges of a system. These are the pieces of the system that are already fairly disconnected. They may be pieces that are not under active development. You can easily find the boundaries of the module. If module seams do not already exist, it is fairly obvious where they should be introduced.
Mikado Method
This is basically the Mikado method. It is a game of pick-up sticks. You have to pick up the sticks at the edges before you can uncover the ones in the middle.
It is also important to remember to change as little at a time as possible. It is tempting to upgrade a module at the same time you extract it. Especially when moving the system towards a microservice architecture. Upgrading the language or framework at the same time you pull it out seems natural, since that was the goal to start with. However, that tends to go horribly wrong. And you are left trying to figure out if you messed something up, or if the upgrade is to blame. Extract the piece, make sure that works as expected, then upgrade.
As you extract the existing edges, new edges will become visible. They will now be the parts to work on. Eventually, those core pieces will be exposed.
Conclusion
Of course this is no quick task. It can take a very long time to “modularize” an existing monolith. You will need to make choices on what is useful to extract, and what to leave alone. Sometimes you should just take the riskier “big-bang” approach. Sometimes it will make sense to extract one or two pieces, and then “big-bang” the rest.