A note on the examples: many of my clients are in the middle of valuations or are actively doing business. To protect their brands and their investors, I replace names and industries with generic labels like Company A and Company B.
You paid a team to break your software into smaller pieces. The work is done and the invoices are paid. But releases are still stressful, one change still seems to touch several pieces, and nothing is faster than before.
There’s a name for what may have happened: a “distributed monolith.” This post explains what that means in plain words, how to check whether you have one without being technical, and what your options are.
The words, in plain English
A monolith is software built as one big program. Everything lives together, like a single large building.
Microservices is the name for the opposite approach: a set of small programs, each doing one job. Think of a strip mall instead of one big store. Each shop can close for repairs, change its menu or reopen without the others noticing.
A distributed monolith is what you get when a team builds the strip mall but wires it like the single building. From the street it looks like separate shops. Behind the walls, they share one front door, one storeroom and one set of keys, so closing one shop closes them all. You have more buildings to look after, and the same problems as before.
What the split was supposed to give you
In a well-known 2014 article, two software designers, James Lewis and Martin Fowler, describe the idea this way. Each small program can be updated on its own, so a change to one usually means updating only that one. And each one keeps its own information, which they call its own database.[1] The database is simply the place where the software stores your information, like customers and orders.
Compare that with a single large program, where any change means rebuilding and updating the whole thing.
That freedom is the point of the split. If the pieces can’t be updated separately, the split hasn’t delivered what you paid for.
Three questions you can ask your team
You don’t need to read code to test this. Ask these in plain words and listen to the answers.
1. “Can you update one piece without touching the others? Show me.” Ask for a small change to one piece while the rest stay as they are. If the answer is “we have to update them all together,” the pieces aren’t independent.
2. “Does each piece keep its own information, or do several pieces share the same storage?” If several pieces read and write the same records, changing those records affects all of them. That’s the shared storeroom.
3. “If one piece breaks, can customers still use the rest?” Ask what a customer sees when one piece is down. If everything stops, the pieces depend on each other more than the diagrams suggest.
These questions come straight from the definition above. They’re not a full inspection, but if the answers to all three are bad, you have your answer.
What the published advice says about order
In 2015, Martin Fowler wrote an article called “Monolith First.” He reports that almost all the successful stories of splitting software into small pieces started with one big program that worked and had grown too large, and was then broken up. Teams that began with the small pieces from day one usually ran into trouble.[2]
He calls his advice tentative, because the evidence is limited, and he notes that some of his colleagues favor starting with small pieces, especially teams that have done it before.
That doesn’t tell you who is at fault. It tells you that order matters. A team that splits software it doesn’t yet understand is working without a foundation.
Why the design underneath comes first
Company B had a different problem, but it’s a useful comparison. Its first version cost about $15K and was too buggy to deliver key features, so a team of American contractors rewrote it. The second version cost about $37K a month for three years, about $1.3M in total, and was still unstable. Both versions lacked what developers call application architecture: the plan for how the software is organized inside, the way a building has a floor plan.
Repairing the second version would have cost more than rebuilding it. I rebuilt it over 14 months and kept about a quarter of the existing code. Monthly maintenance dropped below $8K, then to under $2K.
Company B wasn’t a project about splitting software into pieces. The lesson is about where the problem sat: in the plan underneath, not in how many buildings there were. If each small piece has the same weak plan inside, splitting makes you more pieces with the same weakness.
Your options
Join back the pieces that always change together. If two pieces always have to be changed at the same time, they behave as one. Running them as one removes a moving part.
Finish the split. Give each piece its own storage and its own schedule, one piece at a time, until all three questions above get a good answer.
Leave it alone. If releases are calm and the monthly bill is acceptable, there may be nothing to fix.
Which one fits depends on what the three questions show and on what the software costs you each month. It’s a question of numbers, not style.
Who can fix this
You may be asking which companies can help. I can only answer for myself, so here is how to judge anyone, including me.
Get a second opinion from someone who is paid the same whichever option you choose. If the team that built the split is the one telling you what’s wrong with it, they have a reason to say the answer is more work from them.
Ask who will be working in your software, and ask to talk to that person.
Ask to see a past project with a before and after in numbers, such as cost per month or months to finish.
I follow established design patterns from Martin Fowler’s Patterns of Enterprise Application Architecture and Gregor Hohpe’s Enterprise Integration Patterns, and I’ve built on .NET since 2009.
What the first call covers
I work fully remotely with U.S. companies of 1 to 10 people. On a free 15-minute call, bring the answers to the three questions. You’ll hear what looks wrong and what it would take to fix.
If your team split your software and things didn’t get better, book a free 15-minute call.
Sources
The Company B example comes from my own work.
- James Lewis and Martin Fowler, “Microservices,” 25 March 2014. https://martinfowler.com/articles/microservices.html
- Martin Fowler, “Monolith First,” 3 June 2015. https://martinfowler.com/bliki/MonolithFirst.html