The data centre need not fear the cloud

From what you read and hear of the buzz surrounding cloud computing, it sounds like a model that will just steamroller over the whole data centre industry and make everything we've built over the past two decades obsolete. It will allow IT to scale without effort, at minimal cost! It is an on-demand data centre with zero capital outlay! It slices, dices and juliennes! But even in the best-case scenario it seems like it can only really solve a small subset of the industry's needs. In the worst case it will be a punch line for lame jokes a few years from now, much like other over-hyped buzzwords from the past.

To be honest, I had not really thought much about cloud computing until I was asked directly about it. So I sat down, looked at everything that was running inside the facilities I manage, pulled out Occam's razor and started slicing. The first cut was on myself, or at least on my perspective. As a user, what would I want to put "out in a cloud"? What subset of my data could safely run on top of a completely unknown and amorphous infrastructure? As a provider, how could I make the cloud model work? How could I build the hard assets required to run a cloud and survive in the marketplace?

At one level, I totally get the concept. It is sexy as hell. Total software abstraction from the hardware layer -- applications running everywhere and anywhere. In reality, much like a centrefold model in the flesh, without benefit of an army of stylists before the shoot and a heavy dose of Photoshop afterwards, the sexiness wears off fast. Cloud computing has a lot of unrealistic hopes and desires obscuring plenty of flaws, blemishes, and unresolved issues.

As a user, I could not immediately think about any process running that I would want to throw out onto a cloud, so I started with the stuff I knew I could never let leave the building.

First on the list is something that is fresh on my mind: Payment Card-involved and/or e-commerce systems. We just helped a client survive a rather intense Payment Card Industry Data Security Standard (PCI-DSS) audit. The auditors have a very clear idea of exactly what they want to see in terms of server infrastructure, software configuration and network deployment. Deviations from the script are hard to get away with. Paramount to everything is the ability to audit. To see where, when and how payment card data is used. When they ask "where is X?" you have to point to a specific spot (be it a server, a file system or a database table) and say, "X is right there." You also have to prove that X has not been altered without record of it, nor has ever left the building in an insecure or unencrypted state.

So can any of this be trusted to a cloud? I doubt it. A cloud is amorphous and indistinct. It is layer seven, abstracted from all the lower layers. You can't audit a cloud. It is virtual. Sure, we all know that it translates to a physical manifestation at some point, but can you touch it? Can you audit, with absolute certainty, its file systems, logs and physical access? Can you be absolutely certain that it is physically secure? Can you be absolutely certain that its virtualised file systems are not mingled on a physical disk with somebody else's data? Absolute certainty is required for compliance. You can't find absolute certainty out there in a cloud, by definition.

What goes for PCI also goes for all those other "fully acronym-compliant" compliance regulations out there -- HIPAA, SOX, SAS70, GLBA, etc. No matter what industry you operate in, there are regulations somewhere that you either have to be compliant with now, or will have to be in the near future. Further, it is difficult to fully detach those systems that require compliance with other corporate systems that interact with them.

Additionally, as so many IT managers have learned through hard lessons, data retention for legal purposes is also vital these days. Law enforcement as well as state or federal courts routinely deal with data retention requests. In corporate environments, issues of civil and contractual liability also play into data retention. This has traditionally been in the realm of email, but can be theoretically extend to any and all corporate communications, documentation, applications and data. Frequently this transforms into third parties wanting physical access to the data, and just as importantly, audit trails of who has access to the data and systems. Here again, cloud computing isn't going to fly because it lacks the absolute certainty that auditors and legal systems require.

So if you have to have audit-safe data, cloud computing is out. If you have to live by any retention rules, which cover more and more data types each year, the cloud is ruled out. So is cloud computing just a solution in search of a problem? If it can not really contain core corporate data, what is it good for? Well… edge cases.

If you Google the term "cloud computing success stories," you get lots of press releases from cloud computing providers and startups, but very few actual success stories. Those that exist are all edge cases -- situations in which prototype applications endure fast scaling, such as a Facebook plug-in or video content. Cloud deployment allows a startup with limited capital to ride somebody else's infrastructure to scale quickly, but what happens when they need to, in that term that biz dev types love so much, "monetise" it? Once you start down that path you become entangled in regulatory and compliance realms. That startup is going to have to deploy some of its own infrastructure to support that, and revert to some hybrid-mode usage of cloud computing. The cloud cannot contain anything critical, only things that overwhelm your ability to scale them. Even then, that deployment may only be temporary until you can build up your own infrastructure. A startup could use the cloud as a crutch until it could stand on its own, so to speak.

So in the end, the cloud is a place to put things of little importance -- items of a temporary nature. Much of the Internet can be described as items of little importance, so perhaps there is something to the cloud concept. The hard part then becomes making it pay. From the cloud provider's perspective, how can you build a successful business on temporary items and users? Every successful Internet business has been built on the concept of reoccurring revenue. Being hit-and-run by a series of resource-hogging customers doesn't sound like sound business strategy to me.

What's in it for cloud computing providers?
The old adage is true: There is no free lunch.

Those of us who have built and maintained data centres know that doing so on a scale required to truly handle anything thrown at them know that doing so is not cheap. The bill has to be paid at some point. Wildly popular Web apps with no revenue won't pay the cost of the servers, much less the electricity bill. I can't see how cloud providers can spend the cash to build out the infrastructure and then have enough margin in the usage charges to enjoy healthy profits. They will have to keep their usage percentages high to stay ahead of the capital expenditure curve. Just like all the previous iterations of shared computing resources in the past, as actual usage goes up, performance goes down. So if they are successful in keeping usage high, they'll have to keep spending more capital to expand and upgrade their infrastructure. This sounds like Sisyphus on roller skates.

I always like to boil down complex concepts to overly simple descriptions. They help clarify so much fuzzy thought. For example, I have always said that the definition of a data centre is "a place where electricity gets transformed into bits, on a very large scale." Think about it -- power goes in, bits come out. The byproduct of that large-scale process is heat, which plays into the definition a tad, but otherwise that is a data centre in a nutshell. So let's boil cloud computing down to its most basic definition: Cloud computing is data centre on-demand.

Data centres, as we know, are capital-intensive places. They are expensive to build and expensive to run. It is very hard to deliver something so large and unwieldy in an instant to meet sudden demand, even using modular techniques. Demand fluctuates, and unless you are going to charge usurious rates when demand comes in, you will burn cash at terrifying rates when demand is down. The fire will continue to burn even when demand is moderate. When demand suddenly scales upward, it is unlikely you can meet it, unless you have phenomenal amounts of unused capacity lying around burning capital. You cannot have a truly scalable, redundant, reliable data centre infrastructure at low cost. The capital and return on that capital have to come from somewhere. The lifetime of a data centre facility averages between five and 15 years. The lifetime of a server is even shorter -- 18 to 36 months. No cloud provider wants to be a break-even prospect, much less a money-losing one. So how will any of them survive unless they charge their users far more than it costs to build and run their facilities? See the bowl-swirling process trap here awaiting the potential cloud computing provider?

Another thing to consider: When the provider goes "tango uniform," what happens to all your data out there in the clouds? It evaporates. Good thing it wasn't anything critical, eh?

The only real successful "cloud provider" today is Amazon, with its AWS services, and its current stance actually backs up my viewpoint. If you read its user agreement "carefully" -- as they request that you do prior to signing up -- it lays out a service that really should not be used for anything critical or sensitive. It is clear that Amazon's model is selling unused capacity on its own systems, and while it'll be as nice as possible while you are a (paying) guest there, the company's needs come first. With anything from 60 down to five days notice, it can terminate the bargain, with cause or without. Amazon also states that neither security nor uptime is guaranteed and that it can suspend the service pretty much at any time it wishes, and have no liability to its customers whatsoever in that event. This works fine for low-usage stuff, non-critical software infrastructure and meaningless items of temporary interest … but it will not fly for mission-critical corporate IT functions.

Finally, one thing I think happens often in the business is "buzzword overlap." People throw the buzzword du jour at whatever concept they are trying to sell. The overlap I see a lot in the cloud space right now is "Software as a Service," aka SaaS. SaaS can use a cloud as its underlying infrastructure, but SaaS is not a cloud. So before you start firing up a flaming rebuttal to my thoughts, get out your own mental knife and cut away the SaaS components from your cloud ones. I feel that SaaS and other online applications have a strong future. I look at the stuff running in the facilities I manage and good portions of it are SaaS delivery of some sort. The whole mobile market and most Web applications are SaaS of some sort or another. The SaaS market is in its toddlerhood, having evolved from the previous buzzword, "application service provider" -- same idea, different name. Google, for example, is not a cloud provider per se, it is an application (search, video, mail, chat, etc.) provider that happens to use cloud technologies to support its applications. You don't buy compute or data center capacity directly from Google, you buy application time online. SaaS has a future.

So what does the future hold for cloud computing? I think that as an underlying technology it makes a lot of sense. Anyone developing software should do it with the assumption that it will run across many machines and many locations. But as a business model? If I were a venture capitalist I'd be chasing people out of my office as soon as they used the phrase. I foresee a lot of cloud computing startups evaporating like their namesake.

About the author: Chuck Goolsbee is an executive at colocation provider digital.forest. He has achieved notoriety blogging about the obsolescence of raised floor in the data center and for threatening to gas server designers from Dell with FM200.