Microservices, Monoliths, and Conflicts to Resolve

Two tweets, opposites in position, and both have merit. Welcome to the wonderful world of architecture, where the only rule is that there is no rule that survives contact with reality.

Enhancing resilience via redundancy is a technique with a long pedigree. While microservices are a relatively recent and extreme example of this, they’re hardly groundbreaking in that respect. Caching, mirroring, load-balancing, etc. has been with us a long, long time. Redundancy is a path to high availability.

Centralization (as exemplified by monolithic systems) can be a useful technique for simplification, increasing data and behavioral integrity, and promoting cohesion. Like redundancy, it’s a system design technique older than automation. There was a reason that “all roads lead to Rome”. Centralization provides authoritativeness and, frequently, economies of scale.

The problem with both techniques is that neither comes without costs. Redundancy introduces complexity in order to support distributing changes between multiple points and reconciling conflicts. Centralization constrains access and can introduce a single point of failure. Getting the benefits without the incurring the costs remains a known issue.

The essence of architectural design is decision-making. Given that those decisions will involve costs as well as benefits, both must be taken into account to ensure that, on balance, the decision achieves its aims. Additionally, decisions must be evaluated in the greater context rather than in isolation. As Tom Graves is fond of saying “things work better when they work together, on purpose”.

This need for designs to not only be internally optimal, but also optimized for their ecosystem means that these, as well as other principles, transcend the boundaries between application architecture, enterprise IT architecture, and even enterprise architecture. The effectiveness of this fractal architecture of systems of systems (both automated and human) is a direct result of the appropriateness of the decisions made across the full range of the organization to the contexts in play.

Since there is no one context, no rule can suffice. The answer we’re looking for is neither “microservice” nor “monolith” (or any other one tactic or technique), but fit to purpose for our context.

Advertisements

3 thoughts on “Microservices, Monoliths, and Conflicts to Resolve

  1. RE “Caching, mirroring, load-balancing, etc. has been with us a long, long time. Redundancy is a path to high availability.” and versioning, please.

    RE “Centralization provides authoritativeness and, frequently, economies of scale.” I believe that centralisation and “economies of scale” don’t correlate strongly enough.

    So, it is necessary to understand HOW to synergize uniformity (i.e. standartisation, centralisation) and diversity (i.e. decentralisation). A couple of hints:
    – slide 11 and 12 in http://improving-bpm-systems.blogspot.ch/2014/10/e-government-reference-model-gegf2014.html
    – “Enterprise patterns: Anisotropically Decentralized Organisation (ADO)” http://improving-bpm-systems.blogspot.ch/2013/09/enterprise-patterns-anisotropically.html

    Thanks,
    AS

    Like

    • Alexandre,

      Thanks for the links. Indeed, knowing the capabilities and the constraints of the centralized vs. federated (and hybrid) solutions is key to choosing the solution that best matches the context and goals.

      Like

  2. Pingback: Full Stack Enterprises (Who Needs Architects?) | Form Follows Function

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s