Beware of the tangled web that we weave - Microservice Maintenance
From Monoliths to Microservices to Mayhem?
Introduction
This is a short post to help us think about the possible road ahead as the term microservices seems to be heard everywhere and even being touted as a Silver Bullet, an antidote to the pains of working on and owning a monolithic application.
We will carefully side-step the issue of the term 'Monolith' being misused, often incorrectly used to describe large codebases that are deployed as a single application. Whilst describing the main characteristic, a monolith actually describes more about the lack of internal layers and the absence of external integrations.
And we will also, carefully and deliberately place our leading foot over here.....again side-stepping another issue, the other issue of the term 'Microservices' also being used to describe a wide range of ideas from simple distributed systems to the very prescriptive architecture of protocols and data ownership. Some times pedantry and an attention to this detail is helpful, but not right now.
Modularity & Complexity
Modularity has long been the primary tool for managing highly complex situations and systems, not limited to the software world. The concept of modularity in Software architecture is that of separating out parts of the system into separately named, addressable modules often called components.
In doing so, it makes the source code more 'intellectually manageable'. It is therefore easy to conclude that, if we subdivide software indefinitely, the effort required to develop it will become negligibly small. Unfortunately, other factors come into play, resulting in this conclusion to be invalid. In the graph above, the effort (cost) to develop an individual software module does decrease as the total number of modules increases. Given the same set of requirements, more modules means smaller individual size. However, as the number of modules grows, the effort (cost) associated with integrating the modules also grows. This is true regardless of the specifics in which modules exist and the method of their integration. As such, we can assume that as the number of distributed systems, modules, microservices increases beyond a certain number, so too does the risk of a decreasing ability to effectively maintain the overall system and its codebase.
Conclusion
Without even considering whether the distributed nature of microservices and the new set of considerations that they bring, be it data ownership, or latency, managing cross-cutting aspects such as authentication and what may still need to be centralised, we can see that whilst we enjoy the benefits that they bring today, we must keep one eye on the future. That is not to say that the answer is to revert back to, or to stick with your existing monolithic architecture, it is simply to state that modularity is a vast continuum and not simply a debate between Monolith or Microservice. Beware of the tangled web that we may be weaving.
