A Gmail Failure Is Not Cloud Failure

We need to clear the air about cloud services and hosted services (SaaS). A lot of people conflate Software As A Service (SaaS) with cloud service, and that is a wildly inaccurate view of the world. The moment that SaaS was included in any cloud definition, the definition of a cloud become entirely unusable. Anything can be a SaaS, therefore anything can be a cloud. When Gmail or some other hosted service has an interruption, it does not indicate a cloud failure. It's a service failure. The dist

Mike Fratto

September 24, 2009

5 Min Read
Network Computing logo

We need to clear the air about cloud services and hosted services (SaaS). A lot of people conflate Software As A Service (SaaS) with cloud service, and that is a wildly inaccurate view of the world. The moment that SaaS was included in any cloud definition, the definition of a cloud become entirely unusable. Anything can be a SaaS, therefore anything can be a cloud. When Gmail or some other hosted service has an interruption, it does not indicate a cloud failure. It's a service failure. The distinction is important.

We have applications services, aka SaaS, like Gmail and Salesforce CRM, that lets customers rent or lease applications. You don't necessarily get a whole lot of say about features and functions. While you can add users, documents and other objects, you don't really have any direct control over scaling. You use the application and if performance drops ito the dumper, you call support. We also have clouds like Google App Engine, Amazon Web Services, Rackspace Cloud that are hosting environments for applications you write or install in the cloud providers environment. You can also host entire virtual machines on a cloud.  

In Cloud Computing Isn't The Emperor's New Clothes, I summed up, saying "taken together, cloud computing becomes a computing resource that lets application developers and managers focus on the things they need to do, like developing and managing applications, rather than worrying about the implementation details of which server and network to use."

If only product sets were that clear cut. Salesforce has a cloud service called Force.com, which is a Platform As A Service (PaaS). Salesforce also sells Sales Cloud and Service Cloud, which looks to me like their CRM apps renamed with "cloud" (My assessment could be wrong). Google has a bunch of applications like Gmail and their AppEngine. Amazon has AWS along with their storefront. I think it's confusing to conflate a company's SaaS offering with the cloud offering and call it all cloud. Thus a failure on one side of one type of service is proclaimed as a failure of "the cloud." That is inaccurate.

When Gmail suffers a service failure, it means exactly this: Google's hosted email had a disruption. This does not, as Ian Paul says, cast a dark cloud on cloud computing. InformationWeek's Michael Hickins points out, correctly, that "Gmail's Outage Says More About Google Than Clouds." Google is not the cloud. Neither is Amazon. These two companies are, arguably the poster children, or whipping posts, depending on the day, of cloud computing. But they are not the end-all and be-all of cloud computing. There are many other cloud providers like ElasticHosts, Force.com, GoGrid, GridLayer,  Rackspace Cloud. More popping up like mushrooms.But let me go one step further. An outage with Amazon's AWS or Google AppEngine is not a cloud failure. It is a service failure. Specifically, a service failure in that particular cloud service. Cloud is a special kind of hosted service, but still fundamentally a service.

And guess what? There isn't anything particularly special about a cloud service having a failure. The damage of a particular cloud service having an outage is not particularly or uniquely more damaging than any other service outage of similar kind and magnitude, other than the inevitable chorus of "the cloud is failing, the cloud is failing!"

Oh, I know, one of the benefits of cloud computing is supposed to be rapid restoration, and that is certainly not as automated or as rapid as we'd like today. But for some types of failures, like a server failure, rapid restoration can occur in the time it takes to move and spin up a new instance. Other failures, for instance, in a cloud providers core network services, will take out a larger portion of the particular cloud service, impacting more customers. This may take longer to recover, but that is the nature of a service.

Look, cloud services aren't some magical thing that will guarantee 100% uptime. A disruption in Amazons AWS does not mean a disruption in another cloud service (unless your application relies on the other cloud service, but that is a whole 'nother situation). All this Henny-Penny panic simply clouds (sorry) the real state of cloud stability. Lenny Rachitsky has a list of SaaS and cloud computing health dashboards. Take a look through them and decide for yourself how well the services fare. In many cases the uptime is probably as good or better then you are used to. Cloud computing is still a nascent field, and there is some uncertainty that comes with any new technology, or in this case, a mash-up of many technologies, but the cloud services market won't fail because of a few unrelated, intermittent outages.

I think there are two types of cloud failures: the first is when organizations or individuals decided they didn't want to pay for cloud services and instead went back to a hosted application model. That would result in a lot of cloud services shuttering. That would be a cloud failure. The second would be if the cloud providers didn't live up to the hype that simultaneously they are inflicting on the public, and this is being inflicted upon the cloud providers, resulting in organizations losing interest and taking their business elsewhere. That would be a cloud failure. I don't think either will happen.InformationWeek has published an in-depth report on the public cloud, digging into the gritty details of cloud computing services from a dozen vendors. Download the report here (registration required).

About the Author(s)

Mike Fratto

Former Network Computing Editor

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
More Insights