The delusions that companies have about the cloud

shutterstock_23758640

In the years that I led the Google Apps team, I heard every imaginable objection to cloud computing. Back in 2007, perhaps, those arguments may have had more merit, given the immaturity of most services and limited track record of the providers.

But over time, it became clear to me that those who rejected cloud computing (typically in favor of that unicorn of technology: the private cloud) were experiencing a form of insanity that, if left untreated, would put the very existence of their companies at risk.

When I left Google last year (to found Upstart), I jumped over the table and became a consumer of the cloud. As CEO of a tech company that does not even own a computer, tablet or phone, I now get to fully experience the cloud from a customer’s perspective. So before I get into any specifics about the myths of the cloud averse, allow me to recount a couple of anecdotes to give a little context.

I’m entirely obsessed with Google Analytics’ real-time dashboard, so it was with much dismay that on the morning of Jan. 16 of this year  I saw our traffic at Upstart drop to zero.

Zilch. Nada. Zippo.

Checking quickly with our engineers, I learned that Heroku had gone down and since we’re hosted on Heroku, we got taken down with it. Hard. Because Heroku is an application platform that runs on Amazon Web Services, I didn’t know whom to blame. To me, it didn’t matter – we were down for 40 minutes or so, and that sucked. I checked Heroku’s status page, and figured out what had happened, and what they were doing to fix it.

But all I could really say to our users was “we’re waiting as fast as we can!”

That is one of the chief conundrums of cloud computing: you are powerless to fix a problem, and entirely dependent on somebody you can’t see, hear or yell at, to fix it. People hate that.

I was on the other side of this sort of panic many times during my years at Google. Despite the BS about the “end of email,” it’s still the most broadly and voraciously consumed business application in the world. So I occupied an elite circle in Hell when our services failed to deliver. In short, when Gmail went down, pandemonium ensued – particularly in Silicon Valley. In fact, the outcry from a sizable Gmail crash was enough to bring down Twitter, too.

I recall a particularly terrible outage that happened three or four years ago. I was in a hotel in Philadelphia when my own email stopped working, and my Twitter feed lit up like a roman candle. Gmail was down, and I’m not talking about one of those outages that affects less than 1 percent of users (you know, like a few million people). I’m talking about a big one.

I called a couple of engineers who I knew were close to the situation and were working to resolve it. But I got off the phone quickly, because I knew talking to me wasn’t helping anything. (To the contrary, I was wasting their time.) So I went out for a run, just praying that Gmail would be back up by the time I returned (which it was).  So even as President of Google Enterprise, I was powerless to do more than ensure that the best people were working on resolving the outage.

And this, in fact, is the essence of the cloud. As a consumer or corporate buyer of cloud computing, your task is ridiculously simple: Make sure the best people are working on it. And in fact, those engineers working on Gmail are so good that sizable outages are extremely rare these days. Yet whether it’s service reliability, data protection, or regulatory issues, there remains to this day an insane resistance to cloud computing that is quickly becoming the “Darwinian litmus test” for companies in every industry.

This insanity has three pervasive dimensions to it:

Insanity #1: These big outages mean we should keep things in house

I have news for you: a big public outage is actually a sign of success for a cloud vendor – after all, it means tons of customers are relying on its service, no?  (When was the last time you read about IBM experiencing a hosted Lotus Notes outage?) But underlying the essence of Insanity #1 is the presumption that a cloud outages implies your in-house IT organization could do it better.

In reality, outages merely provide your IT department with excuses to protect their kingdom. The facts are that Gmail uptime is in the range of 99.99 percent – meaning the average user experiences about four minutes of downtime per month – and Amazon targets 99.95 percent for AWS. So, can your team beat that?

Further, this confused IT leader thinks his team can manage a service more reliably than a company whose entire existence depends on its ability to do so. To put it bluntly, Google has assembled the greatest collection of computer science talent in the world. Similarly Amazon has a multi-year lead in delivering compute power by the drop, with which it’s happy to provide to you with the single-digit gross margins of a successful retailer. Your IT organization simply doesn’t rate at this level.

Insanity #2: I need somebody to talk to when a service interruption occurs

I’ve never understood why IT departments seem to care deeply about how important they are to their vendors. It’s a dysfunctional need that can only result in you paying far more to your vendors than is necessary, so that they can afford to show you the love.

Needing to talk to a cloud vendor when there’s an outage is a striking example of this: Would you rather have your cloud provider spending millions on account managers to call you when something goes wrong, or instead to spend their money on world-class engineers working to fix the problem?

You can’t have both (unless you want to pay a lot more for your service). By this time, any credible cloud vendor has mastered the art of providing online status updates (just as Heroku did for us here). It’s no small challenge to do this right (we worked on it for years at Google), but it’s critical to servicing customers well in the cloud. So why are so many large companies turned off by the idea of getting updates via a website or RSS? Because it doesn’t make them feel special.

As a consumer of cloud computing, your goal is to be as unimportant to your cloud vendor as possible – to ride the curve of innovation and cost reductions that result from their efforts to serve an enormous and diverse customer base.

Insanity #3; Cloud is OK for non-critical applications with non-sensitive data

If you believe that cloud vendors are just plain better, faster and cheaper at delivering IT services, then it’s another level of insanity (and illogic) to limit the use of these services to inconsequential applications that aren’t critical to your organization. This is the status quo’s last stand – “this data is too sensitive to enable Company X to manage it for us!” (A similar concern is for those who find perverse comfort in actually knowing where their data physically resides.)

This thinking is backwards. If you care about the reliability, security, and the protection of your data, then you should entrust it to those who are most capable of managing it. If you believe you can match the capabilities and rigor of Google’s Security Operations team, I wish you well.

Of course, the objection to the cloud heard more often than any other is “it’s not me, it’s them.” In this case, “them” means the boss, the lawyers, the executive team, or the board of directors. And just as frequently, “them” is a varied assortment of regulators whose statutes invariably fail to give clear guidance on whether cloud computing is, in fact, legal. Strangely, even when you speak with these regulators, you will hear the same thing: It’s not me, it’s them.

Ultimately, the spoils of cloud computing will accrue to those organizations that break through the insanity, that resolutely fight through these distractions and ambiguities to drive this radically better approach to computing throughout their organizations.

Dave Girouard is founder and CEO of UpStart. Previously he was President of Enterprise at Google. Follow him on Twitter @davegirouard.

Photo courtesy of John Wollwerth/Shutterstock.com.

loading

Comments have been disabled for this post