Governance, Trade‑offs, and Complexity in Microservices Architecture

One of the things I love most about blogs (and never get enough of) is feedback. My previous article “Carving It – Microservices, Monoliths, and Conway’s Law” generated comments and discussion that together warranted a follow‑up post.

One discussion involved a Twitter exchange with Ruth Malan and Jeff Sussna about governance. Jeff called the concept of decentralized governance “controversial,” while also noting that centralized governance can be “problematic” and “rigid.” Ruth observed that it is at least a trade‑off axis in organizational design, and even “federation” has many interpretations. I defend the need for some centralized governance, but with restraint, warning that over‑management can cause issues such as BDUF (Big Design Up Front) where the problem is B, not UF.

When an application spans multiple teams that each deploy independently, some level of centralized governance is required. The key is to define road‑rules that let teams work autonomously without interfering with each other or being micromanaged. This orchestration need is not limited to technical concerns; as Tom Cagley noted in a comment on my previous post, process improvements across team and organizational boundaries can also benefit from such governance. Process models that cause inter‑team conflict can make distributed solutions overly complex.

Another comment on “Carving It – Microservices, Monoliths, and Conway’s Law” came from Robert Tanenbaum, who discussed reuse and questioned whether libraries might be a better choice in some cases. Robert also observed that agile principles tell us to implement the minimal architecture that satisfies the need, resorting to more complex architectures only when requirements exceed the minimal implementation. I view microservices and SOA more as partitioning mechanisms than reuse tools, because reuse often adds cost and burden. I agree that distributed architecture may be more suitable for later evolutionary steps rather than as a starting point.

Another challenge of using a microservices architecture is deciding at which stage of the application lifecycle to adopt it. In the first version of an application you typically do not encounter the problems this architecture solves. Moreover, a carefully designed distributed architecture can slow development speed.

Michael Brunton‑Spall’s “What are Microservices and Why Do They Matter?” provides further background on the trade‑offs involved in this architectural style.

Microservices break down a monolith into complex single blocks for simple services in a complex interaction system. A massive whole can be so complex that reasoning about certain behaviors becomes difficult, even if technically possible. Interacting simple services will exhibit emergent behavior that cannot be fully reasoned about. For complex systems, cascading failures are a problem; a failure in a simple system can cause failures in others. Fortunately, patterns such as back‑pressure, circuit breakers, etc., can help mitigate this, but you need to consider them. Finally, even when problems change, microservices can become a solution. Thus, once built, if your needs evolve, the correct solution might be to retire two current services and create three to replace them, though often it is easier to modify one or two. This means microservices can be changed easily in small cases but require more supervision for large‑scale changes.

The distinction between “complicated” and “complex” is especially important. The emergent behavior mentioned implies that the behavior of complex systems can only be fully explained retrospectively. This means distributed applications cannot be viewed as a whole with spatially separated parts, but must be designed according to their nature—a major theme in Jeppe Cramon’s ongoing work on microservices at TigerTeam.

In a LinkedIn discussion, Jeppe noted that small services focused on business capabilities are preferable to monolithic services, but this differs from merely linking several giant networks and web services. The main focus is the nature of the data a service “owns.” I briefly mentioned the need for authoritative concepts (central governance) in my previous post. Jeppe agreed and pointed out that the overall structure can lead to a multi‑master data architecture , where multiple systems contain redundant and possibly conflicting data for the same entity.

Bottom line: In my view this architectural style has huge potential to enhance enterprise operations, provided it is not over‑hyped (“SOA cures baldness, IBS, promotes world peace…free!!!”). Services are not a magic bullet that effortlessly transforms legacy systems into 21st‑century technology. There are warnings, trade‑offs, and costs. A pragmatic approach that weighs these factors against potential benefits is more likely to succeed than a naïve “build it and they will come” philosophy.