Tightly coupled software presents the biggest difficulty when teams are looking to extend or change systems. As systems get larger, coupling limits the scope of change and self perpetuates. The easiest way to extend tightly coupled code is often to weave in even more interdependence.
One can think of coupling as the measure of effort to separate a logical module from its reliance on another. Languages and frameworks provide a means of abstraction that help to manage the cost of this effort. Object-oriented languages generally provide some methodology to organise and segregate functionality – viz. classes, interfaces, modules, etc. The protection they offer developers against logical coupling is weak, and the barrier to entry for introducing coupled code is very low.
Traditional monolithic design tends to amplify and enable coupling. While it’s possible - with good software design, testing, and great rigour - to avoid increasing coupling over time, it is rarely seen in practice.
In contrast, microservices enforce decoupled solutions. Maintaining a level of coupling that enables change in large systems is a virtually impossible task. As a system grows, its code coupling inevitably increases. These monoliths by definition have sprawling functionality.
As the functionality continues to increase, large systems experience code entropy: module specificity decreases, and coupling increases. The design encourages this. Very often the immediate incentive for a developer to finish a feature on time runs counter to reducing coupling across an application, even if this long term success of the software might depend on it.
While it’s not wholly impossible to create a tangled spaghetti mess of tightly coupled code within a microservice, their very nature discourages it. Microservices increase the cost of changes that introduce coupling. They do this by making these negative changes harder by design in several ways:
First, microservices force a distinction between the interface for external consumers to interact with them and their implementation.
Second, they limit the scope of coupling within their own code. When an application is only a couple hundred - or thousand - lines of code, the magnitude of coupling is limited. In comparison, many monolithic systems have deeply nested coupling that spans hundreds or thousands of classes!
Third, microservices break the biggest source of shared state, in most applications: the database as a global variable. This forces consumers to decouple their domain representation of state from that of others in the distributed system.
Of course, this isn’t the only approach to encouraging good design. Another (and more common) approach is to modularise domain concerns into libraries. These libraries can then be managed and versioned through some dependency management tool, for e.g. Maven, NPM, and RubyGems.
Indeed, shared libraries are not incompatible with a service-based approach, and complement much of the common boilerplate of cross-cutting concerns. For example, an HTTP client library, circuit breaker, or metrics gathering component all provide shared benefits to microservices in a distributed system.
Shared libraries, however, do not offer many of the other benefits that microservices bring. When they are the only form of modularisation, they make using a different language and/or platform impossible, limiting solutions that might be more appropriate for specific domains. They don’t enable many of the advantages of process isolation, and they cannot be made to scale independently as load requires. Shared libraries also mean shared or planned releases, coupling your release process across teams.
In principle, it is possible to create independent modules within a single monolithic application. In practice, this is seldom implemented. Code within the monolith most often, and quickly, becomes tightly coupled. Microservices, in contrast, encourage architects and developers the opportunity to develop less coupled systems that can be changed faster and scaled more effectively.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.