True monoliths are difficult to change. But, difficult change is bigger than overcoming spaghetti code. Ask yourself, if you were modifying a couple of lines of code, how long would that change take to make it to production? For many organizations with monoliths, that answer would be at least a month. A month is too long and does not inhibit agility.

It’s important to use the microservice principles as a guiding light so that there’s a payoff. The risk of microservices for the sake of microservices is a distributed monolith. Distributed monoliths and nanoservices have the worst of both worlds: extremely complex, brittle, and difficult to change.

Here’s a great litmus test.

Don’t have a monolith? Then there’s no need to create microservices. Don’t get caught in the trap - if you are not creating microservices, it doesn’t mean you’re building a monolith. It takes time to create a monolith. It also takes momentum to create a piece of software that is that difficult to change. But if you do have one, then microservices can help.