Cloud Nines: Understanding Accessibility Versus Availability in Cloud Computing for Lawyers

Cloud computing, by definition, relies on networks as well as servers, software, and related items. The lawyer, thus, should understand the important distinction between cloud provider promises of service availability (uptime) and network accessibility when considering the use of cloud computing.

Distinguishing Availability from Accessibility

In a nutshell, availability describes issues that the cloud provider generally has direct control over such as system maintenance, software updates, computer server updates, and computer equipment. The cloud provider generally has control over these issues because the cloud provider “owns” the equipment and software involved and maintains the technical teams that oversee the operations.

Similarly in a nutshell, accessibility describes the vast internet network interposed between your computer/mobile device and the cloud provider. The cloud provider, as well as the lawyer, only have limited control over the network. Think of accessibility somewhat like driveways (the lawyer’s and the cloud provider’s) connected to the road systems (internet). The lawyer or cloud provider has general control over the driveway but less control over the road system. Granted, the cloud provider might spend the funds necessary to directly connect to a highway interchange or might simply settle for a typical driveway feeding into a local road (the choice potentially distinguishes the cloud service).

Example: Cloud Provider Promise of 99.9% Availability

For example, a cloud provider may promise that its Software-as-a-Service (SaaS) application is 99.9% available (8 hours 45 minutes 58 seconds downtime per year), which may be true. But, think of the above analogy. The truck might be sitting in the cloud provider’s driveway idling; but if the road is closed, the truck cannot go anywhere. Similarly if the network (internet) is down anywhere “between”, the subscriber/lawyer and the cloud provider, the uptime guarantee is effectively irrelevant from a practical work-load perspective. The point here is to realize that vendor “guarantees” of availability are not the whole picture. The cloud application must be both accessible and available.

Network Availability Issues with the Cloud

The cloud fundamentally relies on internet infrastructure. While the internet was designed to be self-healing, that does not mean that the internet is 100% fault tolerant. The internet spans dozens if not hundreds of nodes between the subscriber and the provider. [FN1] Furthermore, the route changes according to conditions, network congestion, and routing tables (not to mention potential attackers). DNS pollution, denial-of-service attacks, network cable failures (someone forgot to call-before-they-dug), equipment failures, misconfigured equipment, weather events, botched updates, and deliberate outages (think recent revolutionary events where internet networks were taken offline) all may effect the network availability. The point is: while the internet was originally designed to withstand a nuclear attack, the modern internet is (1) susceptible to far more points of failure and, (2) due to the reliance on internet capabilities, the failures have widespread effects.[FN2] Internet service providers certainly endeavor to maintain high quality and persistent connectivity, but problems can, do, and will occur.

Redundant Network Connections: A Partial Solution

A lawyer might seek redundant internet connections to assure alternative means of connecting to the cloud service especially for a law firm’s mission-critical SaaS applications. While redundant connections will not solve all network outages and probably do not cure issues on the cloud provider’s end, the redundancy may provide access in the event of localized outages such as locally severed cables, severe storms, bad WIFI/cell connections, or network provider outages.

Clearing the Air on Availability (Uptime) “Guarantees”

The following chart illustrates the planned downtime according to the cloud provider’s guarantee.

Cloud Nines Chart

Promised Uptime Expected Downtime Per Year
99% 3 days
15 hours
39 minutes
56 seconds
99.9% 0 days
8 hours
45 minutes
58 seconds
99.99% 0 days
0 hours
52 minutes
32 seconds
99.999% 0 days
0 hours
5 minutes
16 seconds

[FN3]

Review Contract Remedies Carefully

The contract with the cloud provider may limit the lawyer’s remedies in the event the cloud provider breaches the promised uptime guarantee. With consumer-grade offerings, the contract could limit remedies to refund of subscription fees paid or a credit for future services. Notably, the contract may expressly limit consequential, incidental, and direct damages and might even waive alternate remedies under the UCC or other statutory provisions. The lawyer should carefully review the contract to determine the viability of the contractual remedies to make whole— especially if the contract also waives any claims for data loss or other losses in the event of cloud provider breach. For example, customers affected by the recent Amazon EC2 outage, which appears to have involved data loss as well as service loss, received credits. [FN4] (My point is not to comment on specific remedies offered by a cloud provider but to illustrate that a lawyer needs to make sure the contractually permitted remedies are adequate considering the magnitude of the event.)

Conclusion

This brief article identifies the important distinction between cloud provider promises of availability versus accessibility. Knowing the difference is important to properly evaluate cloud services. The Cloud Nines Chart converts the sometimes confusing percentages (99%, 99.9%, 99.99%, or 99.999%) into easily understandable language. The article suggests two options for a lawyer to help mitigate downtime risk: (1) redundant internet connections (understanding that this only affects the lawyer’s driveway as analogized) and (2) carefully reviewing the cloud provider contract for subjectively unacceptable limitations on remedies.

Original Publication

13 June 2011

Footnotes

FN1—On Windows, open a command prompt and type tracert {www.yourwebsite.com} (replace www.yourwebsite.com with the name of your firm website). (On Linux or Unix, use traceroute instead.) The tracert tool traces the route that a packet takes between your computer and your website. Each hop reported is a node. Surprised at the number of nodes listed?

FN2—The recent Amazon EC2 outage demonstrates that failures can occur (and to ANY provider, not just Amazon EC2, is subject to these issues).

FN3—While some online resources merely quote percentages or decimal days, I created a spreadsheet using date-math to calculate the actual days, hours, minutes, and seconds for easier reference. If you want to see the spreadsheet, please contact me (the calculations are more complex than they seem). See also Wikipedia, High Availability, http://en.wikipedia.org/wiki/High_availability

FN4— See Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region, Amazon WebServices, http://aws.amazon.com/message/65648/ (official response from Amazon WebServices indicating 10 day credit).