amazon

Amazon would like to remind you where the hype started

Amazon would like to remind you to thank them for the heightened expectations.

So a Web app running on a telecom service goes belly up and cloud is moribund yet again. That seems to be the latest version of the slightly overheated cloud marketing machine this week.

It may be that the end user cannot tell Amazon Web Services apart from Gmail, which isn’t his job, really, or that the Sidekick/Danger/Microsoft data loss may be one of the most spectacular IT bungles ever made, but this is certainly not going to register in the real cloud computing markets.

No-one stores their email contacts on AWS. Salesforce.com isn’t ever going to let this happen (call me if they do, just sayin’) and Azure, well, isn’t exactly a thing yet, and had zero contact with the destroyed data. I would venture that not a single consumer of any of these services even blinked when they heard about the Sidekick apocalypse.

Seriously, who unplugs a light fixture, let alone a SAN running a live database, in a data center without checking that they made a backup? And when did rolling live backups go out of style in the enterprise world? Hell, I’ve put in rolling live backups for companies with 15 employees.

Anyway, Peter DeSantis, VP of EC2 talked to me at length about last week’s cloud-killer du jour DDOS on bitbucket.org. Here’s a few of his other thoughts on the DDOS, the hype and the possibly incontrovertible fact that without Amazon to raise the bar, we wouldn’t be talking about it at all.

For instance, DeSantis said it would be trivial to wash out standard DDOS attacks by using clustered server instances in different availability zones.

“One of the best defenses against any sort of unanticipated spike is simply having available bandwidth. We have a tremendous amount on inbound transit to each of our regions. We have multiple regions which are geographically distributed and connected to the internet in different ways. As a result of that it doesn’t really take too many instances (in terms of hits) to have a tremendous amount of availability – 2,3,4 instances can really start getting you up to where you can handle 2,3,4,5 Gigabytes per second. Twenty instances is a phenomenal amount of bandwidth transit for a customer.” he said.

The largest DDOS attacks now exceed 40Gbps. DeSantis wouldn’t say what AWS’s bandwidth ceiling was but indicated that a shrewd guesser could look at current bandwidth and hosting costs and what AWS made available, and make a good guess.

“ I don’t want to challenge anyone out there, but we are very, very large environment and I think there’s a lot of data out there that will help you make that case.” he said.

DeSantis said that the reason that stories like the DDOS on Bitbucket.org (and the non-cloud Sidekick story) is because people have come to expect always-on, easily consumable services.

“People’s expectations have been raised in terms of what they can do with something like EC2. I think people rightfully look at the potential of an environment like this and see the tools, the multi- availability zone, the large inbound transit, the ability to scale out and up and fundamentally assume things should be better. “ he said.

In the meantime, DeSantis urges the skeptical to look at the big picture. Things have changed so fast, he said, that people have lost sight of what it used to take to get what Amazon offers:

“A customer can come into EC2 today and if they have a Web site that’s designed in a way that’s horizontally scalable, they can run that thing on a single instance; they can use [CloudWatch] to monitor the various resource constraints and the performance of their site overall; they can use that data with our autoscaling service to automatically scale the number of hosts up or down based on demand so they don’t have to run those things 24/7; they can use our Elastic Load Balancer service to scale the traffic coming into their service and only deliver valid requests.”

“All of which can be done self-service, without talking to anybody, without provisioning large amounts of capacity, without committing to large bandwidth contracts, without reserving large amounts of space in a co-lo facility and to me, that’s a tremendously compelling story over what could be done a couple years ago.”

Measuring the Growth of Cloud Computing

As cloud computing has grown in recognition, and the marketplace has started to attract serious cash, some people are beginning to put some serious effort in to tracking and measuring actual cloud usage. Here’s a small collection of links that show, with some veracity, the state of cloud computing today.

Guy Rosen has the rough cut of usage for public clouds, which finds that among IaaS providers, Amazon EC2 leads the pack, followed by Rackspace, Joyent and GoGrid.

But there are caveats to Rosen’s data. Rosen is only counting websites running in the cloud. The raw data comes from Quantcast, which Rosen has analyzed according to IP location to generate comparisons.

It’s worth questioning how useful Rosen’s analysis is. Classically, Web servers are a primary use case for cloud computing, but increasingly, data processing stacks, test and dev and similar applications are pitched as potential uses for the public cloud. With Amazon continually making hay over its use by the enterprise, this analysis may be accurate, but it is certainly limited.

Another stab at quantifying the cloud comes from those beloved propeller-headed comp sci types, which they dub “Cloud Cartography.” In the course of analyzing multi-tenancy security vulnerabilities, researchers at the University of California, San Diego and MIT came up with a bone-simple way to coarsely measure actual servers on Amazon’s EC2 cloud. (Hint: it involved a credit card, nmap, wget and Amazon’s DNS servers.) According to their cursory research, the number of responding server instances on EC2 currently stands at 14,054.

Cloud Cartography promises to be a very entertaining arms race between cloud providers and the curious, and will doubtless be emulated by others for different sites. I’ll try to keep this space updated as new metrics come around. In the meantime, vendor-neutral suggestions about ways to gauge the state of cloud computing are welcome. Let’s make this a haven for learning what’s really going on.

Amazon VPC: moving the goal posts or playing catch-up?

Amazon has announced, in its inimitable bloggy style, a new service to allow users to create virtual private clouds within its data centers.

The new Amazon VPC offering is “virtual” because the networking and the machine images are opaque to the physical infrastructure. It’s “private,” because unlike standard EC2 instances, they don’t have a public IP address. And it’s “cloud,” naturally, because you pay $0.05/hour for the service and you can quit whenever you want.

The cloud computing blogosphere was abuzz with the announcement (e.g., here, here, and here). But is Amazon VPC, as these blogs say, really revolutionary, a re-definition of private cloud, and a validation in thinking about public, private and hybrid clouds?

None of the above, I believe. While it’s fun to poke holes on an announcement such as this, especially when it’s by acknowledged cloud market leader Amazon, there has to be a street-level view of this that looks at the reality of what’s in the offering and why.

Frankly, Amazon VPC is a terrible virtual private cloud. Network control and management are rudimentary, the VPN is stone-age, users can’t expose clients to the internet and can’t assign them IP addresses. Clearly it is not ready for prime-time, and clearly it is not aimed at Amazon’s existing user base, because they’d all have to uproot their current infrastructures to use it. It is for experimenters who start with requirements that preclude public cloud.

Granted, it’s early days, and changes are in the works, but the kind of technology in Amazon VPC was hashed out with hosting, complex hosting and managed hosting years ago. Compared to what is standard for secure VPN infrastructures in these areas, the Amazon VPC and VPN are decidedly small beer.

Next, arguments that this announcement validates definitions for different types of cloud computing or somehow affect the current market as it applies to private cloud are risible. Suppliers don’t define a marketplace — they react to it.

Cloud computing is essentially a consumption model: as much as, for as long as, and whenever you like. Cloud underpinnings like virtualization, security and costing models are just a means to an end. It was only natural that when large enterprises saw this new model of self-service and low-overhead management, they would want to try it out in their own data centers.

It’s also natural that those interested in private clouds wouldn’t want to use public clouds — public cloud is antithetical to controlling your IT environment. Hosting providers quickly realized that enterprises wanted fenced off reserves to noodle around with cloud stuff, not open pasture.

Indeed, VMware has been leaping to fill that need since last year, with vSphere and vCloud and hosting partnerships with Rackspace and Terremark, among others.

So Amazon isn’t defining the conversation by any means- they’re playing catch-up. As it stands, the Amazon public cloud isn’t designed to be private — just the opposite. Amazon VPC is a radical change of pace for them, not for the cloud market. The cloud market is rapidly filling up with providers who understand the enterprise cloud market and want to service it, which has never been Amazon’s goal.

In the near future (*cough* VMworld *cough*), we’ll see products and services that make the Amazon VPC look like chopped liver, and it will be abundantly clear that Amazon is just starting to react to a segment of cloud that is already well under way and they never set out to capture, but is taking off faster than many thought possible.

Big Week In The Clouds

Most weeks are pretty cloudy for me these days. However, this one was chock-filled with exciting stuff. In case you missed any, here goes…

Rackspace Cloud API

Rackspace has three cloud offerings, ( Cloud Files, Cloud Sites, and Cloud Servers). Cloud Sites is their PaaS offering that use to be called Mosso. Cloud Files is, of course, their cloud storage offering. The big question for Rackspaces’s IaaS has been no-API (i.e, Cloud Servers). Some people believe that you really can’t be called an IaaS unless you have an API to manage the infrastructure. This week Rackspace answered this question.

Link…

Azure Pricing

This week Microsoft announced the long awaited pricing for their new PaaS offering called Azure. Microsoft announced that their bare bones windows services, running on Azure, will be $0.12 per hour. The big debate this week has been focused on comparing the Azure pricing with Amazon’s EC2 Windows pricing at $0.125 per hour. The answer is, you really can’t compare. First off, Azure is a PaaS that doesn’t offer OS level access and Amazon is an IaaS that gives you Administrator (root) level access.  Secondly, Azure applications can only run as .Net or Win32 based applications.  Azure runs similar to the way Google’s PaaS works. You can install your application code into their Paas; however, you can’t install an already packaged application. For example, you can’t install something like Drupal on Azure, at least not easily.  One last point is that, Amazon EC2 Windows instances run as Windows 2003 Servers only.  In the end the primary choice will most likely not be price, and more likely will be based on the target application.

Link…

GSA To Build A Store Front To The Clouds

The General Services Administration is plaining to launch an online application, (i.e., storefront), to enable agencies to purchase cloud computing applications like Amazon Web Services. The Federal CIO, Vivek Kundra, announced this on Wednesday.

Link…

BMC Offers A Deployment Solution For Amazon Web Services

BMC Software announced this week that they are leveraging Amazon Web Services to manage hybrid cloud environments by managing deployments to Amazon’s EC2.  BMC has had a solid story for behind-the-firewall-management ever since their acquisitions of BladeLogic and Remedy.  By combing service management solutions with strong provisioning in a cloud environment could make this move exciting.

Link…

AWS growth info exposed

We recently came upon some photos displaying, in fancy picture form, the growth of Amazon Web Services in terms of bandwidth usage and objects stored in Amazon S3. The results are impressive, as you’ll see below:

With S3 storage almost tripling in a year, not to mention AWS usage equally skyrocketing, the future of cloud computing at Amazon seems, as assumed, to be very bright indeed.

If anyone out there wants to challenge, confirm or comment on these numbers, we’d love to hear from you.

Cloud draws crowds as Interop winds down

It’s great fun watching a big trade show wind down. Day one is all vigor and pizazz and manic tweets. By the third day, attendees are sprawled in the halls, their listless fingers struggling to update mere blogs. At any rate, Wednesday (day three) brought a telling scene. An event photographer crept out of a room and said, “Finally! A full room.”

What topic, after three days of talks and speeches by the brightest stars in the IT firmament, drew the masses? Cloud computing, naturally.

Anyway, Lew Moorman recently gave me an excellent interview, which made it into a story about Rackspace’s position in the infrastructure cloud market.

But Moorman might have had more ready numbers on hand. Rackspace is spending “millions” of new dollars of data center investment, he told me, and is positioning his $500 million company as a scrappy, little-guy going up against the $20 billion dollar behemoth Amazon.

Looking at Amazon’s and Rackspace’s latest quarterly reports gives the real numbers. From 2008 to Q1 2009, Rackspace spent $11 million out of $37 million in total capital expenditure investments on “data center build outs.” Amazon, which only lists “Purchases of fixed assets, including internal-use software and website development,” spent $55 million total capex for IT in Q109. Assuming similar ratios, Amazon might have only spent $16 million on new data center development.

Rackspace. What an underdog, hunh?

The long and short of it is that Rackspace is a hosting company, and Amazon is an e-commerce company. Both are, in terms of capacity and potential compute power, massive. Rackspace does lack the “perfect cloud” offerings of Amazon, but it is no mean competitor, and the money and the market is there. Before cloud, Rackspace wasn’t hurting for customers; they probably still aren’t.

Day 2 dawns at Enterprise Cloud Summit

We’re exploring new frontiers at the Enterprise Cloud Summit, as cloud deckhands try to haul up the sails and ship owners look for value. Overall the mood is good; people are receptive, especially since the order of the day for cloud evangelists is “saving money” and they have examples to prove it.

Probably the biggest news of the day was from Amazon, which announced a new set of AWS  services that address performance and monitoring. It’s worth noting that that’s something many cloud management services (e.g., RightScale) are also offering.

Amazon CTO Werner Vogels also point-blank ducked a question on how Amazon makes decisions on how to bring new AWS products to market. This is obviously of interest to cottage industries springing up around AWS.

Other highlights have included a snappy “Dark Side” talk by Forrester Analyst James Staten, providing welcome relief after other sugar-coated morning sessions.

Then, a panel featuring an honest-to-goodness risk analyst and an insurance wonk outlined the meaning of their pet neologism, “intellectual malpractice,” that is, losing/misusing the citizenry’s personal identity materials. Their opinion is that adding cloud providers into the insurance mix may add hitherto unknown risks, since victims may be able to sue anybody involved in the chain.

Technology has outpaced the law, and it’s a breakout world for litigators, argued Bob Parisi, from the risk advisory firm The Marsh Group. That may prove to be a roadbloack for enterprise adopters, he said. Drew Bartkiewicz from The Hartford was unequivocal, however. “Cloud insurance exists,” he said. It’s just going to cost you an unspecified amount of money.

EUCALYPTUS sprouts business shoots

In what is surely a contender for the most-complicated backronym of the ages, the Elastic Utility Computing Architecture for Linking Your Programs to Useful Systems, first developed at Middleware and Applications Yielding Heterogenous Environments for Metacomputing, UC- Santa Barbara (MAYHEM in case you weren’t seeing the silly nomenclature trend) has jumped the public lagoon for the open waters of commerce:

Eucalyptus Systems, formed out of the team that developed EUCALYPTUS has gone commercial to sell help with their open-source software to cloud-minded types.

EUCALYPTUS (fingers…getting…so… tired) is a set of open-source software tools that allow users to interact with and deploy AWS-type clouds. You can use the software to administer your EC2 images or create your own private data cloud along the same model. Pretty neat, and free, but what happens when AWS decides to re-tool their APIs? Questions soon to be answered.

read the press release here.

watch this page for updates.

Amazon’s New Elastic Map Reduce

Amazon has offered a new web service that provides Hadoop services called Elastic Map Reduce.  Hadoop is a Java based framework that implements Map Reduce.  Map Reduce is a method of programming that gives a program the capability of breaking a job up into hundreds or even thousands of separate parallel processes.  The idea is that you can take a simple process (like counting the words in a book) and  break it up into multiple running parts (i.e., The Map), then collect them all back into summary counts (i.e., The Reduce).  This allows a programmer to process extremely large data sets in a timely manner.  Hadoop is used by companies like Google, Yahoo,  AOL,  IBM,  Facebook, and Last.fm to name a few.

The new Amazon Elastic Map Reduce service is another pay-as-you-go service that starts at .015 cents per hour and can go as high as .12 cents per hour.  This is an additional charge on top of your standard EC2 and S3 services.  For example, if you use the Hadoop to read data from S3 and start up 4 EC2 instances, you will be charged the original costs for the EC2 and S3 usage plus an additional charge for the Elastic Map Reduce service.  Amazon is charging you for the setup and administration of Hadoop - as a service.  The Elastic Map Reduce service is extremely simple to set up and run.  Basically, you upload your application and any data you wish to process to an S3 bucket.  You then create a job that includes the location on S3 of your input and output data sets and your map reduce program.  The current implementation supports writing Hadoop Map Reduce  programs in Java, Ruby, Perl, Python, PHP, R, and C++.  You then also configure the number of EC2 instances you want to run for the Map Reduce job.  You can also add some advanced arguments and use more complex processing methods, if you choose.  The AWS Management console has been updated to support a new tab for the Elastic Map Reduce service.  This new service hides all of the system administration complexities in setting up a Hadoop environment which can be quite complex.  A hadoop setup of multiple systems is not a simple task.  Hadoop runs as a cluster of machines with a specific file system called the HDFS (Hadoop File System).  It also has a number of servers called Datanodes (these are the job processing clients) and a master server called the Namenode server.  Here is a diagram of an HDFS environment:

This morning I had an opportunity to test out the new Elastic Map Reduce service using the Amazon Management Console.  I setup one of their sample jobs to do a word count Map Reduce.  There is an excellent video from Amazon on how to get started here.  Here are some screen shots of my testing this morning:

I also had an opportunity to speak to Don Brown, a local Atlanta entrepreneur and founder of twitpay.me, about the significance of the new Amazon Elastic Map Reduce service.  Don  pointed out two significant aspects to the new Amazon Elastic Map Reduce announcement.  First, by Amazon creating this new service,  they have put a higher level of significance on the usage of Map Reduce and Hadoop.  Organizations looking to explore new techniques for large data set processing and/or new ways to do data warehousing, might start hearing about Map Reduce and Hadoop.  With Amazon’s new service these organizations will start getting Google search result lists that show Amazon as a leading player with Hadoop and Map Reduce.  This will add instant credibility to this technology.  In Don’s words, “Amazon is sort of like the new IBM when it comes to cloud computing . . . you can’t go wrong with Amazon!”.  All of this should speed up the adoption of Map Reduce being used as sort of a new data warehouse technology which Don and I both agree is a good thing.  Secondly, Don suggests that the administration it takes an organization to setup Hadoop is a bargain at .015 to .12 cents per hour.  He has done a number of Hadoop consulting engagements and says the cost of a consultant to do a Hadoop setup is not cheap.

We both agree, however, despite all the hoopala regarding this new announcement, that it is still hard to implement a Hadoop solution and there are not that many experts.  Therefore, as exciting as the new Amazon announcement is, it still only gets you half way there.  Learning how to develop code using Map Reduce and Hadoop is a completely different way of thinking than traditional programming paradigms.  Most traditional programming shops will have to re-tool to take advantage of this new paradigm.  On an upside, all freshman CS students at the University of California Berkley are required to learn Hadoop in their freshmen semesters.  All and all this new announcement, in my opinion, puts Amazon in a  class of their own when it comes to “Cloud Computing.”

The Tale of Three Cloud SLA’s

Wikpedia says…

The SLA records a common understanding about services, priorities, responsibilities, guarantees and warranties. Each area of service scope should have the ‘level of service’ defined. The SLA may specify the levels of availability, serviceability, performance, operation, or other attributes of the service such as billing. The ‘level of service’ can also be specified as ‘target’ and ‘minimum’, which allows customers to informed what to expect (the minimum), whilst providing a measurable (average) target value that shows the level of organization performance. In some contracts penalties may be agreed in the case of non compliance of the SLA (but see ‘internal’ customers below).It is important to note that the ‘agreement’ relates to the services the customer receives, and not how the service provider delivers that service.

There has been a lot of hype around the discussion of Service Level Agreements (SLA) in the cloud as of late. SLA hype has been around as long as I can remember and definitely predates the cloud. In the enterprise you will typically hear numbers like 99.999 or terms like “Five Nines”. Five nines is sort of the gold standard in the enterprise, equating to about 5 minutes of outage per year. However, whenever I think of the five nine metric it reminds me what one of my old Six Sigma mentors used to say about five nines – “Five Nines equates to about one commercial plane crash per day for a year.”

The age old problem of negotiating an SLA has always been a difficult task for any client. One of the main contention points in negotiating an SLA is around the outage credits and how they are applied. Does the customer get a reimbursement for the lost services or is the SLA applied to a future credit? In the classic hosting example, a future credit might include hours added after your service contract terminates. The credit for future services is always a suspect model for an SLA. However, with some of the newer pay as you go models in the cloud, it is easier to apply these types of credits (e.g., next month’s bill). However, in any case the test of a great SLA is one that gives a customer a direct reimbursement for lost services. Another area of difficulty when negotiating an SLA is defining the SLA outages. A few times I have been on the provider side of defining an SLA, and it is always in the best interest of the provider to supply extremely clear SLA definitions. Detailed reports are always a good best practice for the provider and the customer. Without clear definitions and documented reports, in most cases, an SLA will be useless. Here are three main areas I typically focus on when discussing an SLA:

1. Defining the outage.
2. How does a customer prove an outage to get credit?
3. How does the credit get applied?

I thought I might take a look at some of the top Cloud providers who provide server instances and see what their SLAs are in relation to the aforementioned three areas.

Amazon Web Services EC2

The Amazon Web Services EC2 SLA can be found at: http://aws.amazon.com/ec2-sla/ and describes the details of the AWS EC2cSLA. In the AWS SLA EC2 agreement, Amazon claims a 99.95% SLA. Let’s break down their SLA based on the three areas described above.

Defining the outage

Basically a defined outage in AWS is very confusing at best. It basically means that you can not launch a replacement instance within a 5 minute period while at least two availability zones within the same region are down. I take this to mean that if if two out of three data centers are available and you still can’t launch and/or run any application on your EC2 server, it will not be defined as an outage. To further complicate the matter, AWS calculates their 99.95 based on the previous 365 days. If the customer doesn’t have 365 prior days of service with AWS the prior days are calculated as 100% available. This means if you are a new customer (say 2 months), and a catastrophic event happens to hit two of the three US based data centers and you can’t start an instance for three days, you would get a 10% credit for only one day’s prorated costs for EC2 services. The first two days would not be below the 12 month period 99.95 outage percentage. Also complicating the AWS EC2 SLA is the new reserve instances’ up front fees are not eligible for credits concerning outages. Whoops, they have an exclusion for that scenario described above - “caused by factors outside of our reasonable control, including any force majeure event.”

How does a customer prove an outage to get credit?

In order to receive a credit for a defined AWS EC2 outage a customer has to capture, document, and send a request to Amazon to be processed. In other words, the onus is on the customer to prove the outage. AWS does not provide any interface or report documentation to help the customer define their outages. Furthermore, Amazon requires the customer to document the region, all instance ids, and provide service logs. The customer also is required to cleanse confidential information from the logs and all of this must be done within a 30 day period of the outage.

How does the credit get applied?

First off, the AWS credit gets applied against future credits and is not a reimbursement of lost services. As previously stated it is the customer’s responsibility to provide all of the proof and do it with a 30 day period. If the customer supplies all of the documentation and Amazon approves the outage that qualifies for the below 99.95%, they will then apply a 10 percent discount on the next month’s bill.

SLA Grade “C”

AWS puts a heavy burden on the client to prove the outage. The terms of the SLA are difficult at best to understand.

RackSpace/Mosso Cloud Sites

Cloud Sites was formally called Mosso. Cloud Sites is a service that provides a platform based cloud where users share scalable back end load balancing, web services, and databases clusters. The Cloud Sites SLA can be found here: http://www.mosso.com/sla.jsp. Let’s break down their SLA based on the three areas described above.

Defining the outage

Based on the agreement, the definition of an outage from Cloud Sites is extremely simple and is described in less than 150 words. The AWS EC2 SLA is over 1000 words. Simply put, if you open an support incident report with Cloud Sites, they will credit you with a 1 day prorated credit for every hour of downtime. Supposedly all you have to do is tell the rep that you have an outage. They should then start the incident and calculate the outage.

How does a customer prove an outage to get credit?

Here is the rub, they don’t tell you about recording the outage when you call. You have to tell them to record the incident as an outage, and then you will have to continuously monitor the situation and call back support to confirm the ending time. Cloud Sites does not do this automatically for you. The reason I know this is because one of my blog sites is hosted on Mosso/Cloud Sites. I have never been given an automatic credit even though I have had at least 5 or 6 outages over the last year. I have also called in at least 5 or six times and an incident report was never discussed. In fact, on most calls they say that a specific cluster is down and that it should be up soon with no mention of a start time or stop time for recording the outage. You have to point this out to them. One of the things that has always annoyed me about Mosso/Cloud Sites is that they never notify you when the outage is fixed, even if you call in and ask about the outage. You have to find that out for yourself. This makes it extremely difficult to document an outage. Another problem with Cloud Sites is that you don’t have access to the servers the way you do with AWS EC2, so it is difficult to gather the appropriate logs to document the outage.

How does the credit get applied?

Cloud Sites outages get applied against future credits and are not a reimbursement of lost services. The Mosso Cloud Sites SLA is a great example of where less is actually less. The brevity of their SLA seems attractive at first, however, they do not have a defined process for requesting a credit. At least AWS has a documented email where you can send your detailed information. There is nothing in the Cloud Sites’ short 58 word SLA that tells you how to go about getting a refund. The client would have to assume they could call Cloud Sites support and request a refund, assuming they actually documented the start and end time of the outage. All and all, it seems like a very confusing process that is supposed to be “as described” very simple. If you can get through all of the above, then Cloud Sites will credit you a one day prorated credit for every 60 minutes of documented downtime.

SLA Grade “B minus- ”

Cloud Sites offers a simple plan; however, they need to be more clear on their SLA. In the SLA, they state that if you open up an incident report they will start the clock. However, they don’t even have a ticketing system for customers to input incidents. You have to call or start a live chat. Also, they do not notify you when the outage is cleared and this makes it difficult for a customer to keep track of their outages.

3Tera

3Tera recently announced a new 99.999 SLA for their Virtual Private Datacenter (VPDC) customers. The SLA announcement can be found at the following location: http://www.3tera.com/News/Press-Releases/Recent/3Tera-Introduces-the-First-Five-Nines-Cloud-Computing.php. Let’s break down their SLA based on the three areas described above.

Defining the outage

According to the 3Tera announcement, the customer does not have to define the outage. 3Tera will automatically detect and calculate outages. The AppLogic Cloud Computing Platform constantly monitors and reports the availability of the system and instantly alerts 3Tera’s operations team of critical issues. Some might think that the 3Tera five nines announcement is the significant part of their SLA compared to AWS 99.95; however, it’s the automatic recording of the outage that is an unprecedented feature of their SLA. While other cloud vendors require the customer to prove the outage times, 3Tera automates this process.

How does a customer prove an outage to get credit?

Short and sweet..automatically with no human intervention.

How does the credit get applied?

3Tera’s credit gets applied to the current month’s bill. VPDC customers automatically receive SLA service credits for any calendar month where availability falls below the targeted 99.999 percent. If availability is anywhere between 99.999 percent and 99.9 percent, a 10 percent credit applies to the whole VPDC service for the entire month. If availability is lower than 99.9 percent, a 25 percent credit applies.

SLA Grade “A minus- ”

I would have otherwise given 3Tera a solid “A”; however, the service has just been announced and is not available yet. When they actually post the SLA page and the actual customer contract, then I will adjust this rating accordingly