I have already posted about things like the definition of "on" vs. "off" and how those are not even necessarily universally agreed upon. So it is a bit mystifying why there has been such a push for a demonstrable, inarguable definition.
I am not pushing the following as "the definition", rather my definition which enables me to keep moving ahead with my work.
First, the Wikipedia definition is looking pretty good. I don't agree with it, but I don't hate it. So at a certain level I am willing to declare industry victory and lets move on. But...what if I don't have time to explain several screens full of information to someone?
In earlier posts I described two types of clouds: x86 container clouds (EC2, ElasticHosts) and language module clouds (AppEngine, Azure). That was only for simplicity sake, because I certainly hope for IBM Cell Processor container clouds, Symbolics LISP Machine container clouds and others someday.
So I have generalized a bit more to not draw such hard distinction between AppEngine and EC2 in casual, short conversation. Instead I lump them together as being able to consume a customer defined and created workload.
As a result Pat's Cloud Definition is:
- Customer defined workload
- Dynamically delivered to a 3rd party provider
- Workload causes use of dynamic resources (cpu, network, storage, vendor value adds)
- API
- Credit Card (simple, low impedance access model from a financial perspective)
- Short windows of usage (and subsequent billing) are available
The key thing I believe missing from the Wikipedia definition is the API. If one of the brave souls patrolling the boundaries of the Wikipedia definition would please consider adding that to the "Key Characteristics" section I would be quite happy.
This was the definition I used on a Canonical-led webinar last week with RightScale and FlexiScale, and upon reflection I am quite happy with it.
Now, whilst talking about language let us begin the battle anew.
COMMODITY
This is the new battleground in the "what is it" aftermath. There are a lot of these type sentences in the newsgroups: "How or why would any enterprise use a commodity to build its business on?", " Do you really expect competitive companies to use the same commodity cloud as everyone else for their primary offerings?".
A couple points and then please talk among your selves.
- Commodity does not necessarily mean cheap (platinum, gold, oil are all commodities).
- IT allows business differentiation to express itself, and in many cases can be one of the business differentiators. However, that differentiation is in the embodiment of an innovation, not the building blocks of the embodiment.
Enterprises today buy the same electricity, same air conditioners, same types of buildings, same servers, same switches, same cables, same infrastructure software. (As well as hire the same species, mostly humans, from the same schools, and have them work in the same cities.) It is the innovative expression of all these somewhat fungible elements towards a profitable or charitable endeavor that make organizations winners and leaders.
- Commodity DOES mean "close enough to quantitatively fungible to have market norms", but actually doesn't fully cover the qualitative aspects.
The quantitative fungibility is where users of the commodity will win, meaning more businesses will be able to express their unique innovation, not fewer. And the qualitative differences are where the commodity providers can win, by creating innovative embodiments that cloud customers want to consume.
Cheers - pk
