Microservices vs. Distributed Objects: Architectural Trade-offs and Pitfalls
This article by Martin Fowler clarifies the distinction between "distributed objects" and microservices, arguing that microservices, with their coarse-grained interactions, do not violate the "First Law of Distributed Object Design." It explores the inherent complexities introduced by distributed systems, such as network latency and failure, and discusses the ongoing debate and empirical evidence regarding monoliths versus microservices as preferred architectural styles.
Read original on Hacker NewsThe "First Law of Distributed Objects"
Martin Fowler's "First Law of Distributed Object Design" states: "don't distribute your objects." This law emerged from the era of technologies like DCOM and CORBA, which aimed to make remote method calls transparently behave like in-process calls. However, this transparency is a fallacy, as fundamental differences exist between local and remote communication.
The Fallacy of Distributed Transparency
Remote calls are orders of magnitude slower and inherently unreliable due to network latency, partitioning, and remote process failures. Attempting to treat them identically to in-process calls leads to fragile and inefficient systems. This is a core principle to understand when designing any distributed system.
Microservices vs. Distributed Objects
Microservices, unlike distributed objects, do not aim for in-process/remote transparency. Advocates of microservices understand the implications of distribution and design for coarse-grained interactions, often using HTTP or lightweight messaging with documents, rather than fine-grained object method invocations. This approach acknowledges the distributed nature of the system from the outset, thus avoiding the pitfalls of the distributed objects paradigm.
Complexity Booster: The Trade-offs of Distribution
Despite satisfying the "letter" of the first law, microservices still introduce significant complexity due to distribution. Key challenges include:
- Coarser-grained APIs: Requires more thought in designing interfaces that minimize chatty communication.
- Failure handling: Mechanisms for dealing with remote call failures, timeouts, and retries are essential.
- Consistency and availability: Distributed transactions and maintaining data consistency across services are complex problems.
- Performance considerations: Network hops and serialization overhead impact overall system performance.
- Operational complexity: Deploying, monitoring, and debugging many small, interconnected services is more challenging than a monolith.
- Refactoring difficulties: Changes spanning multiple services require coordinated deployments and careful versioning.
Monolith vs. Microservices: An Ongoing Debate
Fowler acknowledges that while distribution is a "complexity booster," many teams have found success with microservices (e.g., Netflix, Amazon, Spotify). Conversely, others like Etsy and Facebook have scaled successfully with monolithic architectures. The article highlights that empirical evidence is crucial, but a definitive, universally applicable answer remains elusive due to the difficulty of comparing real-world scenarios with counter-factuals. Architectural decisions often depend on specific team structures, organizational context, and problem domains.