« Asynchronous Architectures [3] | Home | Asynchronous Architectures [1] »

Asynchronous Architectures [2]

The Fallacies of Distributed Computing

Performance Wisdom: 12

  1. The network is reliable
  2. Latency is zero
  3. Bandwidth is infinite
  4. The network is secure
  5. Topology doesn't change
  6. There is one administrator
  7. Transport cost is zero
  8. The network is homogeneous

-- Peter Deutsch, James Gosling, Bill Joy, Tom Lyon

This post is the second in a series presenting arguments for asynchronous architectures as the optimal way to build high-performance, scalable systems for a distributed environment. The first post reviewed the general case for asynchronous communication among interdependent components or services, and highlighted Bell's Law of Waiting.

In this post I discuss how the design of distributed systems should draw on that of manual business systems. Of course, distributed computing can shorten the timescales of some business operations enormously. But drawing analogies with the way manual systems work is an observation that will help us to design efficient and scalable distributed systems.

In Five Scalability Principles, I reviewed an article published by MySQL about the five performance principles that apply to all application scaling efforts. When discussing the first principle -- Don't think synchronously -- I stated that:

Decoupled processes and multi-transaction workflows are the optimal starting point for the design of high-performance (distributed) systems.

Starting from the wrong place

Designing a computer system based on multi-transaction workflows is not a particularly revolutionary proposal. Indeed, if we had somehow been able to skip the first 40 years of the computer age and start automating our business systems using today’s technology, we would probably not have thought it the least bit unusual, because all manual systems work this way.

But like our computers, our reasoning can be so logical that it lacks real thought. Occasionally, we need to balance our linear thinking with a small dose of simple wit like that ascribed to the Irish farmer, who, when asked by strangers for directions to a distant town, began his answer by saying “Well, I wouldn’t start from here”!

Most of our troubles stem from the fact that, when trying to reach the destination of distributed systems, we keep starting from the wrong place, namely the application designs and systems software of centralized computing:

  • Design discussions dwell on how best to partition applications for the distributed environment. Manual systems, however, are already partitioned naturally -- the supposedly monolithic application that is being “partitioned” would not exist in the first place if it had not been conceived as “the right solution” by a designer with a centralized computing mindset.
  • The reason computer science devoted so much attention to distributed databases and distributed transaction management is because these concepts are extensions of the core mechanisms of centralized information processing -- shared databases and transaction monitors.

But The Fallacies of Distributed Computing -- assembled during the 1990's by architects at Sun and the subject of today's Performance Wisdom (above) -- highlight crucial differences between centralized and distributed computing. Adding network components to an application introduces many potential problems that a centralized solution does not have to consider. So rather than trying to force the centralized mechanisms to work in a distributed environment, we should adopt mechanisms that are more appropriate.

Starting from the right place

In fact, we should start from the design of manual business systems. All large scale human systems are inherently distributed and asynchronous in nature. Even the participants in close knit team efforts operate asynchronously. We find chorus lines, cheerleaders, marching bands, and synchronized swimmers so interesting because they are such an aberration. So, before the advent of the centralized mainframe, the idea of recording an entire business transaction with a single synchronized set of human actions did not arise because it is so absurdly impossible.

Traditionally, the business process is divided into its natural components (or phases), according to the roles of the various human processors (or workers). Work flows through the phases, and information is recorded as necessary along the way. If anything goes wrong along the way, the appropriate set of compensating actions must be taken to undo whatever partial progress has been made. And the whole operation is designed to ensure that no irrevocable actions are taken too early in the process--usually meaning before the money is in the bank. Companies that mail out the diamonds before cashing the checks soon learn how to design a more effective multi-phase business process.

Asynchronous architectures may reflect manual systems

Manual systems always permit asynchronous operation of their separate components, because no other mode of operation is possible. Only computers make synchronous changes even possible. To a degree, centralized computing could deliver synchronous changes to related databases because the same computer managed all the system resources. Peaks in the workload could cause contention and delays, but provided the machine kept running, a congested machine acted as it’s own governor.

But processor technology does not allow the centralized computing model to scale up without limits. When the workload surpasses the capabilities of the largest centralized processor, the only way to keep growing is to divide and conquer -- to create a network of computers. Networked computers demand a different approach to application design. Pursuing the vision of enterprise wide synchronization of information through networked computers can cause delays and inefficiencies when any part of the whole system operates below par. This is the Achilles heel of interdependent systems--the whole is no stronger than it’s weakest part.

Therefore, the rigid concept of synchronous transactions must be replaced by a wider range of possible application designs:

  • The older, synchronous methods are still appropriate for changes that are within the scope of a single processor, or even for occasional communication between controlled components separated by a very carefully controlled, high speed network;
  • These must be combined with asynchronous designs in which the user must accept that unconfirmed changes will be reflected in the enterprise database(s) at a later time.

Business process design

When we do a good job of distributed systems design, it becomes an integral part of business process design. Rather than bending the business process to meet the needs of a centralized computer, we must blend the power of distributed computers into the business process.

Ironically, these changes bring us almost full circle back to the days of manual systems. In a manual system, it is normal for changes to be recorded quickly in one location, but for those changes to take a few days to percolate through the system, with the total processing time being somewhat uncertain. Distributed computing shortens the timescales, but applying many design principles that made manual systems work efficiently can help us to create effective and scalable distributed systems, even when we do not control the performance characteristics of all the components of those systems.

In my next post I will review some recent thinking about the intersection of asynchronous architectures and the world of Web services and SOA.

This post contains material first published in High-Performance Client/Server, Chapter 16: Architecture for High Performance, pp509-510 and 526-527. My 1998 book is out of print now, and contains some outdated examples and references. But most of the discussions of performance principles are timeless, and you can pick up a used copy for about $3.00 at Amazon.

Tags: , , , , , , , , , , , , , , , , ,

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>