Cloud as Larry Ellison put it so dearly, is FASHION. Still, if you wouldnt be caught dead in last years pink, you cant do better than to rely on the best Brit tailors to cut a suit to your fit.

Thumbs up again James.

> 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.

-Eric Novikoff
ENKI

So after a few months, does this ring true now?

I’d say it’s close and should be closer…

Best.
alain
mor.ph