As we have discussed over the years, there are many reasons why developers should choose microservices and good reasons why they should avoid them. Recently Gene Hughson wrote an article about how improved modularity is probably not one of the reasons to select microservices, a view shared by author Simon Brown.
As Hughson mentions:
I believe that if you’re having problems building a monolith properly, trying to use a distributed architecture to force modularity may actually cause harm.
In fact, as we discussed back in 2014, Brown and Hughson discussed microservices and the Big Ball of Mud analogy, and Brown said at that time:
If you're building a monolithic system and it's turning into a big ball of mud, perhaps you should consider whether you're taking enough care of your software architecture. Do you really understand what the core structural abstractions are in your software? Are their interfaces and responsibilities clear too? If not, why do you think moving to a microservices architecture will help? Sure, the physical separation of services will force you to not take some shortcuts, but you can achieve the same separation between components in a monolith.
Hughson likens building using microservices to icebergs, with much more going on under the surface than appears at first sight:
If a development team cannot or will not comply with design guidelines (e.g. modularity requirements), injecting additional complexity is probably not the solution you need. Distributing an application makes it harder to accidentally entangle different concerns, but it doesn’t make it impossible.
And Hughson illustrates this last point with a link to another tweet from Brown.
Referring back to his comment about development teams who cannot or will not comply to design guidelines, Hughson goes on:
I’d argue that making it harder to accidentally break modularity addresses neither of the groups I mentioned earlier: those that cannot or will not comply. It’s ironic, but those who fail to understand the need for modularity can be very creative in their “solutions”, regardless of the obstacles. Likewise, those who refuse to comply.
Hughson argues that as a distribution (microservices are inherently distributed) as a means to modularity is not fit for purpose. He also believes that the concerns are not limited to application architecture but apply equally well to the application data.
A disciplined, monolithic team can maintain modularity in a monolithic data architecture. Multiple separate teams trying to share a monolithic data architecture will either experience a crippling level of governance overhead or a complete breakdown in modularity.
Christian Posta mentioned last year how managing the data aspect of applications can be the hardest part when moving to microsrvices and we reported at the time.
Building microservices for a reasonably complex enterprise domain, we need to find the boundaries between different responsibilities within that domain. In each of these boundaries we create a domain model, designed for and representing that responsibility. The data model for each boundary is then driven by the domain model in the same boundary. Using DDD we can find theses boundaries and create a bounded context for each, with each context becoming a microservice.
In response to a comment on his article suggesting some form of governance may be required, Hughson agrees:
Passive measures, whether structural (“let’s distribute the components so people can’t break modularity”) or procedural (e.g. “be disciplined”), will not be sufficient. Governance at the application level (which is, IMO, the application architect role) and above is absolutely necessary to help reconcile competing interests and monitor that the design is not wandering down some dark alley. It’s critical to bear in mind that this can happen by misunderstanding, lack of experience, non-compliance, or even incoherence in the design. Someone needs to be monitoring what’s happening and equally important, why.
In conclusion, it's important to understand that Hughson believes microservices do have their role to play in building applications that need independently managed, scaled and deployed components. However, the reasons for choosing to go down the microservice route need to be well understood.
