15 Ways I Am Wrong About Enterprise Cloud Computing

My post 15 Ways to Tell Its Not Cloud Computing has had a lot of play – 24 trackbacks and counting…

A lot of the commentary so far has generally approved of the angle I took, though clearly there are strong dissenting voices. Before I proceed to one of them I just want to point out that 15 Ways was always intended to take a strong position, though hopefully with some humour. That is, the post was somewhat rhetorical. Of course not all enterprises are going to suddenly drop enterprise IT and do everything over at Amazon Web Services. That would be a. absurd and b. impossible.

But on the flipside I see a lot of over-complication from major players – around something that originally simply spoke to provisioning architecture for developers without the headaches. Cloud started as a description of a web phenomenon, not an enterprise, phenomenon. Can enterprises learn from Web simplicity? Of course they can, and should. Can web companies learn from enterprise middleware scalability patterns? Yup.

However- whatever else the cloud is, it should not just be an excuse to try and rewarm technology that has already failed in the marketplace. It should not be an excuse to sell a new complexity.

And so to pushback. I am really happy that I got such a considered and thoughtful response from Eric Novikoff of ENKI Consulting, who does some work with 3Tera. You might want to read my original piece first, but I will leave everything inline, my original 15 points in bold.

I thoroughly disagree with this “backwards” definition of cloud computing. James Staten of Forrester defines Cloud Computing as “A pool of highly scalable, abstracted infrastructure, capable of hosting end-customer applications, that is billed by consumption.” This is a definition that is amenable and extensible to the enterprise. This list of “nots” is not.

> If you peel back the label and its says “Grid” or “OGSA” underneath… its not a cloud.

Cloud computing as defined by Staten can be delivered from a variety of architectures, including Grids or SalesForce’s Big Iron. That’s the point of the cloud: abstracted infrastructure.

> If you need to send a 40 page requirements document to the vendor then… it is not cloud.

More and more cloud vendors are offering solutions rather than cpu cycles. CPU cycles are great for programmers, but businesses want to solve business problems. Without a definition of what the customer’s problem is, and an honest and transparent reply from the cloud vendor, you are running on hopes and dreams instead of a known value delivery system. The result is that the companies most successful with Amazon have dedicated staff and management to ensure a successful cloud deployment and to make sure Amazon doesn’t change something underneath that breaks their app. Where is the savings in that?

> If you can’t buy it on your personal credit card… it is not a cloud

Businesses don’t like to pay for expenses on personal (or business) credit cards. In fact, they prefer a budgetable monthly spend which of course contradicts with consumption billing. Our customers *don’t want* to pay by credit card, by and large. Only the web2.0-in-a-garage startups are interested in credit card payment: possibly because they’re financing their business that way.

> If they are trying to sell you hardware… its not a cloud.

This seems like it should be true. However, corporate customers are reticent to send internal data out into a public cloud. Why wouldn’t they buy hardware from a cloud vendor to get similar advantages, delivered internally?

> If there is no API… its not a cloud.

You won’t get much disagreement from me on that, but most of our customers aren’t interested in an API, so they probably would disagree. They just want to deploy and go, not write their own cloud operating system.

> If you need to rearchitect your systems for it… Its not a cloud.

That would be nice, but I haven’t seen one cloud that doesn’t require some rearchitecting. Wholesale rearchitecting is often required to get around Amazon’s peccadilloes, and even the AppLogic system we deploy on, despite it’s virtual datacenter analogy, still has some characteristics that require minor architecture changes for some applications. Whether or not you have to rearchitect depends more on how much you encoded your expectations of the hardware environment into your code than it does the particular cloud you deploy to.

> If it takes more than ten minutes to provision… its not a cloud. If you can’t deprovision in less than ten minutes… its not a cloud.

Where are you measuring the time period from? We can bring up a virtual private data center in the cloud in 2 minutes. But our customers often take days, weeks, or months to figure out how they want to provision from the moment they decide to. For businesses, the time from decision to deployment is a better measure than time to provision.

> If you know where the machines are… its not a cloud.

This simply points up disagreements about the definition. Most customers who demand high performance (say, running Oracle) and certification (say, HIPAA) both want and need to know where the machines are. They are unlikely to deploy to clouds where the architecture is so opaque that they can’t meet their requirements.

> If there is a consultant in the room… its not a cloud.
This is false on two counts. First, those companies who have successfully deployed their entire operations to the Amazon cloud have dedicated staff to manage Amazon deployment. Call them “internal consultants” if you will – people whose job is to manage/consult on the cloud. Second, a large number of reseller/consultants have sprung up to facilitate the use of Amazon. Amazon is becoming something like a physical server: you need someone to run it for you. These consulting/reselling companies do that. They may not be “in the room” however, which is one of the benefits of Cloud Computing: it creates an internet-enabled ecosystem of knowledge workers you can use with your application without providing a cube for them.

> If you need to specify the number of machines you want upfront… its not a cloud.

This is an assumption that Amazon has catered to. If you do the math, you’ll see that Amazon bought it’s cloud business by selling under its costs. Especially in the early days, keeping huge reserve capacity up and running was a cost that was not passed on to the users. Many of today’s cloud providers manage their inventory of physical hardware to reduce their costs, by offering discounts on usage to customers based on contracts. This will (and does) lower the prices for customers over the “big daddy in the sky with infinite computing power” cloud model. You’re going to see more of it. If cloud computing is a commodity with perfect competition, like air travel, you’re going to see vendors deploying intense strategies to manage their unused capacity.

> If you need to install software to use it… its not a cloud.

Cloud computing and open source seem to go hand in hand. My experience is that each of my customers wants a different version of their operating system, database, etc. Cloud vendors typically provide a library of code images, but they cannot custom-configure to meet an individuals’ needs. The trick is not avoiding installation, but making it easy.

> If you own all the hardware… its not a cloud.

There definitely are cloud providers out there who have their customers lease the underlying hardware, which defeats the concept of usage-based billing. However, your statement would get puzzled looks from many large enterprises who run their own clouds.

Its funny I get such strong reactions from consultants like Jeff and Eric. I just can’t work out why that is 😉

So what about these “puzzled looks” from folks that Eric says have built their own behind the firewall cloud. An enterprise guy is welcome to call the infrastructure they’ve been building out a cloud. Everything is a cloud these days, right (one of the reasons I wrote 15 ways of course)? An end to end VMWare shop is going to be in pretty good shape for rapid provisioning, for example – which is why VMware is certainly in the running as a CloudOS player.

When I say that IBM lacks a cloud strategy what I mean is that its cloud strategy is currently too diffuse, too complex, and not closely enough managed. Where are the simple on ramps? We currently have such a bad case of definition sprawl that some segmentation is required.

I like Tim O’Reilly’s recent three leg definition – Utility computing, Platform as a Service and Cloud-based end-user applications. But we need more segmentation on the Utility side, to take account of “enterprisey” concerns and mores. To get a little bit goldilocks about all of this the 451 has done an awesome job of cloud segmentation with a report I… can’t find on the internet, mind the firewall guys -but its actually too granular as a I remember it.

Its not my intention to put forward my own segmentation at this point but I do want to point to a recurring theme from Eric, about my missing the point – we could call this the Hidden Costs of Amazon Web Services argument. Or AWS TCO Smackdown or something. I will refer at this point to another post by Novikoff, where he talks about his experiences as an SDForum Cloud Event.

Each of the companies using EC2 had developed intense internal expertise on Amazon’s service. That’s right, you read correctly: on Amazon’s service. Not on Cloud Computing in general (though there are those who argue that EC2 and Cloud Computing are the same thing) but rather on the intricate technical and organizational details of dealing with Amazon and its service as well as optimizing their use of it.

It wasn’t a surprise to me that these companies, dependent on Amazon for their success, would get to know the service well. What did surprise me was the lengths to which they went to mitigate the risks. Generally, if you have doubts or fears about something, you want to learn all you can about it. These companies showed incredible technical depth at understanding EC2’s characteristics and peccadillos. They asserted that it was critical to their success. But this seems to me to be in direct conflict with the ideal of Cloud Computing, which is the democratization of information technology; in other words, lowering the barriers of entry. I think this is an admission that Cloud Computing technology in any form is still not polished enough for completely casual use. At ENKI, we realized this early on and decided to strive to be the “onramp to the Cloud” by providing all the services necessary to use our cloud without having to know anything about Cloud Computing.

At Redmonk we tend to think low barriers to entry don’t require consultants to navigate – but that’s just us. As is clearly the case right now the turbulence surrounding the cloud conversation is a barrier to entry, which is where people like Eric and RedMonk come in.

The truth is I am probably half right, and half wrong. I leave the reader to decide to turn the dial to parse Eric’s comments and my own. What do you think?