Feb 21, 2011

Of Clouds and Contracts


I've been ruminating on the topic of contracts for cloud based services for some time.  I had started reading AWS and Google terms of service to see what they had to offer when Alistair Croll, Principal at Bitcurrent, pointed me in the direction of some research that was done in the UK (see below). This is a first pass on what's been banging around in my head for a little while and there is more than likely going to be a second pass at some point in the near future to expand on/update/correct what I write here today.


It is true that consumers and vendors of cloud based services need to clearly distinguish between "reasonable expectations" by, as Darrell Plummer of Gartner says, using a common language, the contract. However, it is clear that service level agreements which are universal in basic IT service contracts and that are taken for granted generally do not apply to cloud based offerings; they take on new meanings given the new environments in which computing power is consumed and data is stored on demand.

Point in case: the phrase, "service level agreement," does not appear in the AWS contract. The closest it gets to an SLA is to lay out the "availability" of the service as follows:

7.1. Downtime and Service Suspensions. In addition to our rights to terminate or suspend Services to you as described in Section 3 above, you acknowledge that: (i) your access to and use of the Services may be suspended for the duration of any unanticipated or unscheduled downtime or unavailability of any portion or all of the Services for any reason, including as a result of power outages, system failures or other interruptions; and (ii) we shall also be entitled, without any liability to you, to suspend access to any portion or all of the Services at any time, on a Service-wide basis: (a) for scheduled downtime to permit us to conduct maintenance or make modifications to any Service; (b) in the event of a denial of service attack or other attack on the Service or other event that we determine, in our sole discretion, may create a risk to the applicable Service, to you or to any of our other customers if the Service were not suspended; or (c) in the event that we determine that any Service is prohibited by law or we otherwise determine that it is necessary or prudent to do so for legal or regulatory reasons (collectively, "Service Suspensions"). Without limitation to Section 11.5, we shall have no liability whatsoever for any damage, liabilities, losses (including any loss of data or profits) or any other consequences that you may incur as a result of any Service Suspension. To the extent we are able, we will endeavor to provide you email notice of any Service Suspension in accordance with the notice provisions set forth in Section 15 below and to post updates on the AWS Websites regarding resumption of Services following any such suspension, but shall have no liability for the manner in which we may do so or if we fail to do so. 
7.2. Security. We strive to keep Your Content secure, but cannot guarantee that we will be successful at doing so, given the nature of the Internet. Accordingly, without limitation to Section 4.3 above and Section 11.5 below, you acknowledge that you bear sole responsibility for adequate security, protection and backup of Your Content and Applications. We strongly encourage you, where available and appropriate, to (a) use encryption technology to protect Your Content from unauthorized access, (b) routinely archive Your Content, and (c) keep your Applications or any software that you use or run with our Services current with the latest security patches or updates. We will have no liability to you for any unauthorized access or use, corruption, deletion, destruction or loss of any of Your Content or Applications.
(Source: AWS Customer Agreement accessed upon sign-up to AWS EC2 services Feb. 13, 2011.)


By contrast, Google Apps Premier terms include a service level agreement by reference (both accessed February 21, 2011) that guarantees uptime of 99.9% (which amounts to about 43 minutes of downtime, measured at the server) though it's unclear if it's consecutive or aggregate downtime. Of course, the customer is left to try to claim the service credits offered as a remedy based on user experience which is not taken into account in Google's determination of availability.

The Cloud Legal project (accessed Feb. 15, 2011), conducted by Simon Bradshaw et al. at the Centre for Commercial Law Studies at the Queen's University of London, determined that contracts vary greatly among cloud based service providers though there some overarching templates and language that are common to various discrete groups of unrelated providers. This is, as far as I know, the most extensive survey of contracts for cloud based services available.

This is a first pass on contracts and I fully expect to write more in the near future. In the meantime, if you're looking for some light bed time reading, there's always the City of LA contracts with CSC/Google (posted by InfoLawGroup, accessed January 12, 2011)...
Effectively, Amazon is washing its hands of any responsibility/liability for its or anyone else's actions that might have an adverse effect on their customers. From a governance perspective, customers are left to fend for themselves and accept, rather than mitigate or avoid, risks.

Feb 20, 2011

Gartner defends its MQ for IaaS and hosting

At the risk of seeming like I'm jumping on the bandwagon, and amid much flak from the community over its apparently misguided Magic Quadrant for Cloud IaaS and Web Hosting Providers (link to GoGrid's website), I can't say that I fully agreed with Gartner's assessment of where they positioned Amazon.

That said, Lydia Leong, Research VP at Gartner, did post a rebuttal of sorts to whatever criticism Gartner received. In her post, Leong makes the case that the MQ was for IaaS AND web hosting providers which is why Amazon was placed in the visionaries quadrant. This logic, by itself, was enough to satisfy me that the MQ was basically correct.

But, then I started thinking that Gartner missed the mark on the subject of the MQ: IaaS can be considered as a form of web hosting, but it's a stretch. IaaS and web hosting as fundamentally different in that the former is a service that is rapidly available on demand (among other characteristics published in the NIST definition) while the latter is an engagement that requires managed services and is billed on a monthly basis.

Enter Leong again who wrote that Gartner was preparing to publish a mid-year version of the MQ only, this time, it was going to be cloud only. This seems to indicate that Gartner made the same logical leaps I did and is now committed to providing a more accurate layout of the competitive landscape for IaaS. The one lingering doubt I have is how Leong framed it:

"The mid-year version will be cloud-only, specifically the self-provisioned “virtual data center” segment of the market."



I'm not quite sure about how Gartner is defining "self-provisioned 'virtual data center'" and how they will rank the contributing organizations.

Despite this,  I am am very curious to know how it turns out and look forward to reading it through. If anyone from Gartner reads this and would like to send me a copy, I'd be more than happy to read it through and post my thoughts. ;)