Why do we suddenly expect service providers to 'fix' the risks we've had for years?

One of the cool things about publishing a book for the Kindle is you get to see a list of "popular highlights" in the book.

One of the cool things about publishing a book for the Kindle is you get to see a list of "popular highlights" in the book. (This is where Amazon shares a list of the passages in the book that have been most-often highlighted by readers.) I was looking through the list of popular highlights of our DaaS book and thought the following one was interesting:

. . . there are unknowns everywhere, and one of the challenges of DaaS is that we get stuck in a trap of listing out all these far-fetched “unknown” risks with our DaaS providers that have actually been risks for years—it’s just that now we’re somehow expecting our DaaS providers to meet all these crazy standards that we ourselves have never met.

In the case of DaaS, we might be ask our provider questions like, "How secure is their facility? Do they have 24 hour security? Do they have biometric authentication to get in the building? Is their facility in the flight path of the airport?" We seriously weight the answers to these questions while not realizing that our own datacenter would fail every one of these questions.

It's funny to see companies so concerned about their cloud provider's security while they don't even consider that their own on-premises facility has never had the security they suddenly "require" from a DaaS provider.

We see the same thing with employee theft and background checks. Some customers want to somehow ensure their DaaS provider won't hire criminals and so they want to find out what types of background checks and verifications the provider users. Meanwhile that company's own servers are in their office which is regularly visited by random cleaning staff, delivery drivers, and building management people.

We also see this with SLAs. Using email as an example, some have argued against outsourcing mail to Gmail because Google Apps only has a 99.9% SLA. While that initially seems shocking in our world where everyone talks about  "five nines," 99.9% availability still only means about 45 minutes of downtime per month. So it's ironic that companies might not choose Google because they don't like that Gmail could be down for 45 minutes a month, when these companies have not managed to run their own email servers with that same level of availability.

In the DaaS world, Amazon Web Services WorkSpaces DaaS offering has a maintenance window from midnight to 4am every Sunday. (Again, this does not mean it is always unavailable during those hours, rather, it means the service might be unavailable during those hours, and if it is, it does not count against the SLA.) Some folks kind of freaked out when they first heard that, exclaiming, "What? So WorkSpaces might not be available 4 hours a week? That's 2.3% downtime!" (Or "only" 97.7% uptime.)

Okay, yes, that math is correct. But how many existing VDI environments are guaranteed to be available for more than that?

A lot of this boils down to the irrationality of human nature and how we tend to over-estimate our own abilities. ("Illusionary Superiority" is one of my new favorite terms, especially as it applies to people wanting to build their own VDI versus outsourcing it to a DaaS provider.)

For example, from 2008-2010 there were 0.003 deaths per 100 million passenger miles in airplanes, versus 0.54 per 100 million passenger miles in cars. Yet everyone whom I've ever met who fears airplane travel has no problem riding in cars. A lot of that stems from the fact that any commercial airline crash that involves fatalities is in the news, yet almost 100 people in the US die in car accidents every day, so it has become common we don't even think about it.

The same can be said with cloud service providers (whether it's Gmail or DaaS). When they go down they are in the news, and everyone shouts, "See! The cloud is not reliable!" But if you compare that to all the little unreported outages that happen every day via companies' on-premises IT systems, I have no doubt that they are down more often. (In other words I have no doubt that the average Gmail user's mail is available more often than the average user whose mail is provided by their internal IT department. Anecdotally working as an employee of a company who owns and operates their own on-premises Exchange servers, I can confirm there's about a 100x reliability difference between my work email and my personal Gmail.)

So as you're evaluating DaaS providers, I'm not saying that you shouldn't consider their security, SLAs, and hiring practices. But keep it in perspective, and certainly don't "rule out DaaS" because you think your own environment is somehow more insulated from these issues than third-party providers.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Its kind of like the hidden SLA bump that desktops get from simply becoming VDI desktops. But with DaaS you get an extra bump on top of that.


Oh man! I completely forgot about that, but yeah, good point. I just found that article. It's four years old. Man....

How the hidden "SLA bump" can kill your VDI project: You'd better know your desktop SLAs going in!



One difference between expecting something from an MSP vs. what you expect from yourself is the lack of control that comes with going to an MSP.  When an on premise system goes down the local IT can diagnose, find out what it happened, etc....but if the same thing happens through services supplied off premise the lack of control makes it much more perplexing and fraught with hand wringing/stressful moments wondering what is happening.

Secondly, what is most likely the biggest sales pitch of an MSP is that they have the expertise and infrastructure to do it better than can be done locally...ok, if that is true and companies on premise solution has a 95% up time record, they will expect a better record with an MSP...otherwise why go with them?  Sure there are lots of other costs involved and not just SLA percentages but if an MSP's SLA, security and hiring practices are not better than mine then one of the larger reasons to switch to off premise is marginalized.  


Off topic, but deaths per billion miles is a bogus stat.  Deaths per billion passenger journeys is what is important because you are either on a journey that has an accident or you are not.

Deaths per billion journeys

Bus: 4.3

Rail: 20

Van: 20

Car: 40

Foot: 40

Water: 90

Air: 117

Bicycle: 170

Motorcycle: 1640

however your point is sound so long as you replace it with bicycles instead of cars ;-)


Haha..Yeah I actually thought about that, especially since the average car trip is just a few miles and the average plane trip is probably a few hundred miles. So yeah, do you count per mile traveled, or per minute on the trip, or per mile of the trip, or... ???? Depends on what you're most afraid of I guess.

Good info from the book "How to Lie with Statistics." From 1954!! :)


(BTW this was a big source for our "How to Lie with Cost Models" chapter of the VDI delusion.)