Are you breaking up monoliths, or creating rubble piles?

This week I learnt (via the wonderful Skeptics' Guide to the Universe) that asteroids in the solar system come in two varieties: monoliths and rubble piles. These are exactly what they sound like: monoliths are big, singular rocks, while rubble piles are, well, piles of rubble, held together by gravity.

Rubble piles have a couple of interesting properties. First, the oldest asteroids are rubble piles. This makes sense: if a monolith experiences a collision and gets broken up, it may become a rubble pile. But there’s no way for a rock pile to go back to being a monolith. Second, rubble piles are harder to move. If we detect a big monolith heading towards Earth, we may be able to change its trajectory with a single impact. But if we send something up to impact a rubble pile, it might just jiggle around and do nothing to stop it coming towards us.

Naturally, to anyone working in enterprise technology, hearing the word ‘monolith’ makes us think of monolithic systems. This is the term we’ve used for years to describe, by analogy, big systems which exist as unitary entities. While they may be stable and solid, they are usually hard to change, because we have to deal with them as a great big lump. If we change one bit of a monolithic core banking system (for example, the way that interest is calculated on an account), we have to make sure that we haven’t broken anything else (the way payments are processed, or balances are shown, or tax is reported - or any of the hundreds of functions that typically make up monoliths).

We don’t like monoliths in enterprise technology. If you hear someone describe a system as a monolith, then it probably means that they think it is bad in at least some way.

As a result, we try to change our monoliths, by refactoring or rearchitecting them. (Or sometimes by decanting everything from one monolith to another - but that’s a different story.) We tell ourselves that we are decomposing the monolith into smaller, more agile components, which we can manage and release independently.

But do we always achieve this outcome? Or are we actually in the process of creating rubble piles?

Some projects I have worked on to decompose monoliths have ended up with something that looks remarkably like a rubble pile: components which are theoretically independent, but still seem to be tightly coupled and connected with each other. You can detect these rubble piles because, when you suggest making just one change, the people who have to make the change look gloomy and tell you about all the dependencies you need to take account of. In fact, you may even find that the rubble pile is harder to change than the monolith. At least with the monolith, you can make big decisions and changes of direction. If you try to make big changes to the rubble pile, you may just jiggle the pieces around. Just like the rubble piles in space, there’s a force of gravity keeping all these components together.?

How do we overcome this gravitational attraction?

Fortunately, because we are dealing with software rather than real rocks, we can break the laws of physics and invoke some architectural anti-gravity. Like all good technology architects, let’s invent a few principles:

We’re not friends any more: components that were all broken off the same monolith are sometimes given privileged access to components with the same heritage. It’s fine, you can invoke that secret method: we used to share code. Of course you can still read my database, you used to have access. If we are to overcome gravity, then when we break off components from the monolith, we need to expel them from its orbit once and for all: to treat them as no more familiar or privileged than components that have never met before.

Don’t shut up about what you’re doing: the team that maintains the refactored components is often the same team that maintained the monolith. As a result, they know the inner workings of those components, they know how the interfaces work. They have a shared heritage and a private language. Why would they need documentation? One of the big challenges with monoliths is their implicit inner language: when we break them down, we must make the implicit explicit and document their APIs thoroughly.

You can’t rely on anybody: when components are part of the same monolith, they can rely on each other. After all, if you’re not working, I’m not working, so why would I check your availability? When we break up the monolith and expel the fragments into space, they can’t rely on each other any more than they can rely on other components. Sometimes, when they make that API call, they’re going to get a timeout, and they need to be prepared for that event.

These principles might not be good for human beings, but they seem to be good for software, and help us to remember that, while it’s good to break up monoliths, we have to make sure that we don’t create rubble piles.

(Views in this article are my own.)