Three Paradoxes of High Availability

Even when funding is not an issue, any organization attempting to build high-availability (HA) applications must deal with three paradoxes and find an appropriate balance within each.

Agility vs. reliability. Although Microsoft’s current marketing campaign emphasizes both agility and reliability, the two goals actually work against each other. Agility means the ability to change rapidly in response to shifting business or technical requirements. However, rapid change introduces a high risk of failure to a hitherto stable system. As most IT managers know all too well, simply fixing something that is broken or insecure introduces opportunities to make things worse (sometimes much worse). The most reliable systems are designed to perform well-defined tasks, are tested thoroughly before going into service, and are then changed minimally or not at all from that point onward. Rapid, frequent changes, even when done carefully by skilled personnel, are deadly to reliability. Even organizations that have the people and time to implement changes like patches, service packs, or software upgrades are often reluctant to do so because the risks of service disruption associated with applying these changes often outweigh the risks of keeping a faulty system running. Furthermore, to ensure reliability, organizations must implement strict change control and documentation standards. These processes, which must occur before changes are made, dramatically slow down the rate at which changes can be implemented. Microsoft’s most stringent HA product, Windows 2000 Datacenter Server, has such rigorous testing and recertification requirements that it could take a month or more before a fix or patch is even approved by the Datacenter vendor that supplies the hardware.