Cloud ontology: to boldly go where ITIL, Grid and SOA have gone before

I wasn’t at the recent Cloud interop meeting in Mountain View, but based on blog reports from those who were (Stu, James and Bob) a key takeaway is that we need a “Cloud taxonomy”.

As John points out, there are plenty of existing proposals. The SPI taxonomy (SaaS/PaaS/IaaS), the SADIST-PIMP taxonomy (Storage, App, DB, Info, Security, Test, Platform, Integration, Management, Process – which I took the liberty to re-order) and the UCSB/IBM “Toward a Unified Ontology of Cloud Computing” paper.

Is it a matter of picking one of these? And if we do, how are we better of?

Let’s look at some related domains that are a bit more mature to see how they handled this and what benefits they got out of it. The three most relevant comparison I can come up with are ITSM, Grid Computing and SOA.

ITSM has ITIL, a key part of which is its glossary which provides value in and of itself, even if you don’t explicitly use the rest of the framework. Is this what the Cloud taxonomy should aim for? I contend that the Cloud field is not nearly mature enough to aim for this.

Grid Computing has OGSA, which started as a white paper containing a service model (section 6.1). It was later expanded (within GGF, a standards organization specific to Grid Computing) into this document and was used as a basis for many standard technical specification. Is the goal of the Cloud Ontology to follow a similar path? OGSA was more than a glossary though, it included a vision, goals and architectural recommendations. Sure you can start with the glossary, but I am willing to bet that a stand-alone glossary would change significantly if/when a Cloud Computing architecture is defined based on it. And there isn’t today, for Cloud Computing, the singularity of vision that the Globus gang brought to Grid Computing and that is necessary for an architecture.

SOA was never as structured. There was an early attempt, called the Web Services Architecture at W3C. Like OGSA, this is a high level architecture, not just a taxonomy. In any case, the WSA work didn’t really end up having much of an influence in SOA (or even Web services) practice. Then came the SOA Reference Model, an OASIS standard. Of the three (ITIL, OGSA, SOA-RM) this is what I think is closest to what a Cloud taxonomy should aim for at this point. An ITIL-like glossary would be too brittle (if it has any depth) and it’s too early for an OGSA-like architecture.

Again, I was not at the meeting and only know what was blogged about. This is not a criticism of the proposal, just some thoughts about how it might compare to similar efforts.

Side note #1: I prevented myself from going off about the difference between a controlled vocabulary, a glossary, a taxonomy and an ontology. These differences are not germane to the present discussion. And I am not wearing my pedantic hat today (for once). If some want to call a wedding cake an ontology, who am I to stop them?

Side note #2: Speaking of trying to be less pedantic in 2009, this entry represents my capitulation: I finally created a “Cloud Computing” category in this blog, rather than my prefered designation, “Utility Computing”, which I have been using so far. A small step for me, a microscopic step for humanity.

[UPDATED 2009/1/28: We’re getting there (fast!). Via John, this updated taxonomy graph from Chris Hoff is going in the right direction, I think. Next step: more text describing the relationships between the boxes to have more of a model.]

[UPDATED 2009/1/30: If you think that any single-vendor taxonomy will be suspicious, that a multi-vendor taxonomy won’t happen and that customers are too busy to do it, then you may be asking “aren’t analysts supposed to do this?”. Help may be on the way.]

8 Comments

Filed under Cloud Computing, Everything, Grid, ITIL, Modeling, Standards, Utility computing

8 Responses to Cloud ontology: to boldly go where ITIL, Grid and SOA have gone before

  1. Pingback: People Over Process » Links for January 29th

  2. Stu

    Yeah, the biggest concern with the latest “ontology” talk is that these things are (politely) very high level. Less politely, they’re not even really ontologies, they’re …. marketectures ?

    I’m not sure half the twitterati in the Cloud space would give any of the DMTF or OGSA specs the time of day, let alone the ITIL work to date (or even Charles Betz’ valiant attempts at codifying a data model out of ITIL). (A side note – OGF president Craig Lee was in attendance at the interop event too , along with DMTF’s Dave & Winston.)

    A repeated point made at the cloud interop session, one that I echo, is that we weren’t starting with goals or use cases, we were starting with “shared interests”. Which is true at 10,000 feet, but I think splinters pretty quickly as we drill into it. Some people want a high-level API to build a cloud ecosystem (and no lock-in) among vendors, some want to solve problems that WS-Man and CIM try to solve across public/private clouds, some want to integrate PaaS/SaaS data and want more standards on RESTful integration, etc. Classic case of technologists rushing to solving a problem that hasn’t been defined.

    I continue to think cloud standards work is very premature – at best we can publish a variety of ideas that represent the various goals, and then try to figure out where innovation is needed vs. where commonality exists, and thus can be standardized. A collaboration on Cloud taxonomy or ontology probably is a useful paper exercise of highlighting these things without too much effort, so long as people don’t get religious about it (wait, wut? of course they will be ;)

  3. Fully agree Stu. And yes, they’ll get religious about it. Worst, companies will start pumping out marketing slides that show how they “do” everything in the taxonomy and how their competitors don’t “do” concepts X, Y or Z. It will become a RFP checklist which would be too bad.

    What would be very useful, if that Wiki that you guys talked about comes up, is to have it contain all the public interfaces (whether network interfaces, SDK-type APIs or config formats) of the different Cloud tools and services. Not trying to harmonize them (not yet at least), just provide a consolidated listing of them all.

  4. William,

    Nice blog as always.

    I agree too. Defining a taxonomy will be difficult in these types of organizations because they are comprised of vendors who stand to make or lose money based-on how they their products might be classified. But I have faith in the market. The market tends to cut to the chase…ignore things that aren’t relevant and latch onto things that have value. Thus, this taxonomy, if it does go forward, had better be right and done quickly otherwise the market will move on. Otherwise it stands a chance of being ignored (like some of the standards created by these organizations). Also, this taxonomy had better use existing terms…Pandora’s box has been opened and people are assigning names and definitions already. A taxonomy isn’t going to magically rename something just because a vendor wants to be classified in a certain way.

    Cloud computing in some ways reminds me of how the term “Green Computing” started. At first, it seemed pretty clear that “Green Computing” was about energy efficiency. But over time, the water became pretty murky because everyone wanted a piece of the action. Vendor products that were never “green” before were suddenly labled as “green”. Product recycling became “green”. Anything that saved time or effort became “green”. While Green Grid, ASHRAE and others are helping to clear up what “Green Computing” means, the term has certainly suffered from a lack of clarity because of a lack of classification and definition.

    There are some areas of the cloud that, IMHO, would benefit customers if standardized. Cloud computing, if it is truly “utility, service-based computing” has to arrive at the point where it can be self-service, trustworthy, reliable, inexpensive, easy-to-use, enable workload mobility, etc. That level of utility requires that we all have a common understanding and reasonable expectation that the cloud works the same (or very similar) everywhere. Just like electricity (the ultimate utility), we expect that the 3-prong outlets in the US are 110v, we will want cloud infrastructure providers to have a common idea of what a CPU cycle is or virtual machine is. If the outlet in my home is 110v and the outlet in my neighbor’s home is 175v (or something odd), we would all need to adjust everyday appliances to every house’s quirky little grid. Alas, I don’t think this will happen in the long term.

    Don’t get me wrong, I’m not in favor of tons of standards. There are plenty of standards that have gone no where (again, market defining the relevance). Heck, I’ve helped write some of them. But there are some things that we just plain need (think DNS for the Internet). I mean, how do we solve network connection fixup when workloads move? What about storage connectivity and latency? How about a common way to initiate service or an XML-based definition for SLAs?

    The problem is, as Stu pointed out, is the work is very immature right now. IMHO, we need to first identify what we need….the wiki (anthology) and taxonomy is as good place to start.

  5. Pingback: William Vambenepe’s blog » Blog Archive » UCI: setting RDF for failure?

  6. Pingback: Cloudology* › Cloud Burst

  7. Pingback: William Vambenepe’s blog » Blog Archive » Separating model from protocol in Cloud APIs

  8. Pingback: William Vambenepe — Taxonomy of Cloud Computing Benefits