A couple of weeks ago at the DevNexus conference Simon Brown gave a keynote (slides) titled the “Modular Monolith”.  It was an interesting presentation and he made a number of good points. His final slide asked this excellent question:

If you can’t build a well-structured monolith, what makes you think microservices is the answer?

He had made a similar point on Twitter:

I’ll keep saying this … if people can’t build monoliths properly, microservices won’t help. #qconlondon #DesignThinking #Modularity

— Simon Brown (@simonbrown) March 4, 2015

As had other tweets:

I see you have a poorly structured monolith. Would you like me to convert it into a poorly structured set of microservices?

— Architect Clippy (@architectclippy) February 24, 2015

Alright folks, this is serious stuff: how many of you would buy this? RT if you would #microservices pic.twitter.com/CXKcORbdek

— Álvaro Sánchez (@alvaro_sanchez) October 8, 2015

I don’t disagree with the sentiment of Simon’s question. But I think it misses a critical point.

Most teams know how to build a modular system. They want to build a modular system. Most teams usually do. The challenge is maintaining the modularity. A large and/or complex application will often degenerate into a big ball of mud.

The challenge is maintaining modularity

There are several factors that make it difficult to maintain modularity:

• Current programming languages lack genuinely useful modularity mechanisms. Java visibility rules are insufficient. Perhaps Java 9 modules will finally solve this problem.
• Monoliths often become too complex for a developer understand. This increases the chance that changes will violate implicit modular boundaries causing the design to degrade.
• Time pressure. There are no depths to which a developer will not sink (especially under pressure from management) in order to meet a deadline. Who cares about modularity when you need to ship software?!

Microservices can help with modularity

Microservices are certainly not a silver bullet. But one benefit they offer is that your application is functionality decomposed into smaller (not necessarily tiny) services. Each service is much easier to understand. In theory, it is easier to preserve its architecture and modularity.

More importantly, the service API is an impermeable barrier that encapsulates the service implementation. It takes real effort and determination to breach that barrier.  A developer is less likely to make a quick hack to solve a problem the night before a deadline. As a result, it is likely that it will be easier to maintain the modularity of the system.