Unified Ontology of Cloud Computing

[Reuven Cohen]

John M. Willis has pointed me to a new research paper by Lamia Youseff
(University of California, Santa Barbara) Maria Butrico, Dilma Da
Silva (IBM T.J. Watson Research Center), have created titled "Toward a
Unified Ontology of Cloud Computing."
(http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf)

The paper lays out a proposed Cloud Computing Ontology: depicted as
five layers (Cloud Application Layer, Cloud Software Environment
Layer, Cloud Software Infrastructure Layer, Software Kernel, Hardware
and Firmware), with three constituents to the cloud infrastructure
layer (Computational Resources, Data Storage, Communication). The
layered approach represents the inter-dependency and composability
between the different layers in the cloud.

The paper proposes "an ontology of this area which demonstrates a
dissection of the cloud into five main layers, and illustrates their
interrelations as well as their inter-dependency on preceding
technologies. Better comprehension of the technology would enable the
community to design more efficient portals and gateways for the cloud,
and facilitate the adoption of this novel computing approach to
computing."

The paper goes on to describe "The current state of the art in cloud
computing research lacks the understanding of the classification of
the cloud systems, their correlation and inter-dependency. In turn,
this obscurity is hindering the advancement of this research field. As
a result, the introduction of an organization of the cloud computing
knowledge domain, its components and their relations – i.e. an
ontology – is necessary to help the research community achieve a
better understanding of this novel technology.

Interesting read.
http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf
--
--

Reuven Cohen
Founder & Chief Technologist, Enomaly Inc.
blog > www.elasticvapor.com
-
Open Source Cloud Computing > www.enomaly.com

[Reuven Cohen]

Just a quick follow up on my earlier post. Christofer Hoff has posted
his own version of a cloud ontology.
I particularly liked his approach including his use of a facilities
layer which includes things like power & space. I'd say the only thing
he's missing is a geographic/location element and human element
(meatcloud).

Check it out at
At http://rationalsecurity.typepad.com/blog/2009/01/cloud-computing-taxonomy-ontology-please-review.html

r/c

[Ralph Biesemeyer]

I think Christofer's ontology makes sense:
I suggested that
Resource is Implementation
Network is I/O (Transport is Network)
Governance/Security/Compliance parallels the entire stack
Provisioning/Autonomics parallels the bottom 4 layers (could fit on right side of diagram)
SLA-Management/Billing parallel the top 5 layers (from the API layer to Presentation Layer)

to your points:  Facility could include geo-location, meatcloud is in SLA Management/Billing

Ralph

[xfer_rdy]

Well, I'm not sure about "starting" with Christofer's model.
Christofer is using an ontology to define an architecture for the
cloud, which looks more like VMware's view of a PC.

Ontologies are simply a "description of concepts". In the information
world, its how we represent knowledge (almost). Christofer, who's work
is very good, is developing an ontology that represents his model of
the cloud, My model is definitely different from Christofer's. I'm not
saying his is wrong, but not everyone has the same model at those
levels. If we start with architectures from IBM's Z series mainframe,
or HP's DOMs or SUN's LDOM models, we will inevitably end up with a
different ontology. Of course they will be similarities, from the
general systems perspective, but there will also be details
incompatible between implementations. The ontology will favor one
company's proprietary solution over another. I think we must be
watchful to prevent that from occurring.

We could use Ralf's model based on facilities, which is my personal
favorite. Its a general use case model treating the cloud as a black
box and organizes capabilities based on what we currently know about
operating with multiple enterprises in a global environment.

I think if we start from a "model" to describe, we should consider
DMTF's CIM meta model. I believe in certain areas its a more
appropriate model to work from as a starting point. CIM is a very
flexible network (not networking) object scheme. It has a UML model
equivalent. It can easily describe traditional architectures, as
Christofer's, as well as alternate architectural models not yet
invented. Leveraging CIM also allows us to include the existing SNIA
storage models.

Granted CIM does focus on resources and components, very much like
SNMP. However, it is not limited to those simple models. SNIA uses CIM
to model complex sub-systems including large disk arrays, and tape
libraries. As an example, SNIA agents not only allow for the
collection of metrics, but the configuration of the systems, including
provisioning (ex. creating raid volumes), mapping hosts to arrays,
managing file systems and ensuring SLAs are met via metric
collection.

The CIM scheme is sufficiently flexible to easily integrate services
and facilitates as well as new verbs. The UML scheme for CIM is
available in XML format. Additionally, the CIM models have already
been mapped to 2 web based interfaces, WBEM and WS-management. The WS-
management is part of the WSDL set of specifications. I believe there
are tools still out there to generate a RDF ontology for WSDL
documents.

I'm not saying we should disregard Christofer's model or Ralf's
suggestions, in fact the opposite. We should find a way to incorporate
all in to a meta model. Then we can leverage strategic advantages of
Christofer's model and Ralf's comments; and quickly bring real world
management applications to clouds implementations.


-gary

> >http://rationalsecurity.typepad.com/blog/2009/01/cloud-computing-taxo...
>
> > r/c

[Hoff]

Gary:

My goal wasn't really to personalize the model as "mine" and given the
feedback I've received and incorporated back into it, it's certainly
becoming
a community concept...

Regardless, I think it's far from being the "one true model," and my
focus was
to make sense of what I know to sort out my thoughts and incorporate
the work
of others in so doing.

It's very much a case of trying to rationalize the "traditional" use
cases of the
outliers, but not to the point of exclusion. I'd really like to
understand more about
how that mainframe model (of the cloud) would change the ontology I'm
working
on or whether or not it would make sense at all.

I'm a simple man...many of the meta models and mapping of layers via
XML/UML
are simply at a point beyond where I personally need to be right now
in envisaging
relationships between layers, so I want stick figures. I think there
are a lot of folks
in my boat ;)

Thanks to everyone who is contributing, especially in light of
TypePad's (my
blog's hosting service) problem with their "next generation" comment
system :(

Thanks,

/Hoff

[gary mazzaferro]

Sorry Ralf, didn't mean to infer you were the creator of the concept, but we need a way to reference approaches, since I was on the end of a 40hr day, it seemed only reasonable to assign the approach to you, personally,  as a discussion point. Its a good practical approach.
 
I'm in a agreement with you, there is not going to be a "one true model" typifying the morphological nature of the cloud's internal  system. Interoperability between clouds doesn't effect the internal organization of the cloud, or at least it shouldn't. Can we completely ignore the internal working of a cloud, sure, but moving forward, it will be more difficult to implement ignoring the successes of the past and currently embedded technologies.  But if we focus on common capabilties, in terms of general system facilities, we can insulate ourselves from the risk of obsolecence.

Let me explain my comment about the models. My issue with adopting the other model as an approach is they are defining layers with capabilities like SaaS and DaaS before there is consensus of whether there is a SaaS or DaaS. They are also defining rigid relationships between entities.  This is a real problem for building specification that will not be obsoleted with the next "popular" architectural innovation or new capability.

I like your approach, looking at the cloud as a set of common facilties, especially for billing. I'm sort of a techology darwinist. I believe that if something has been used for a while and is making companies lots of money, they must be doing something right. 

Mainframes have been around since the 1950's. I believe 50 years of success is nothing to be ignored. Many of their approaches for both sales and training are from the user's persective. They treat the mainframe as a black box and focus on capabilities and facilities.

From a cloud persective, the mainframe industry has already addressed many issues faced today with cloud computing; from  reliability, management and operations perspectives. Natural selection has helped organize their facilities that make sense for business, grown symbiotic or otherwise. In the late seventies and early 80s when Open Systems standards were formed, many of the lessons learned from the mainframe world were somehow ignored. Now 30 years later in the Open Systems world, we almost have standards and  a direction for reliability that equal the capabilities mainframes were shipping 30 years prior.

The operations and functions of mainframe management do effect the ontology. If the operations, relationships and interfaces aren't recognized, they can't be in the ontology.

I feel your pain about the layers and layers of meta-meta-meta whatever...  I started my career as a microwave stripline antenna engineer, I feel your pain. I've been beaten down for so long, I've just accepted the meta-meta-meta. But there is real value to it.

And your right if we can't show how this all works with stick figures, it will take a looooong time to adopt, if at all.

When we get a bit more input, I'll take a stab at the dwgs if anyone doesn't mind.


-gary

[xfer_rdy]

Sorry Christofer, Ralf,

I though your email was Ralf... Its been a very tough week... I
haven't been to sleep yet.

Again, I wasn't deliberately assigning personal ownership of that
model to you, outside of a reference for a discussion point.

I think its a great idea to move forward with it the way you did. I
have started an interoperability standards body in the past in the
data storage industry. Hopefully some of my opinions would help this
group avoid some of the pitfalls I've experienced in the past.

Signing off... I'll be catching zzzs for the rest of the day...

-gary

[Ralph Biesemeyer]

The model that Christofer is maintaining provides the opportunity to encapsulate technical tools, like DMTF CIM and CDM, but also provisions Cloud Service Customers to compare service offerings, contract for the services they need and manage the required infrastructure to the extent they want.  

Most cloud services follow the general partitioning outlined by the dotted SaaS, PaaS, IaaS, etc boxes, which don't really need to be labelled.  They only prove that the model fits reality.

I am fairly new at this, but I think with some minor tweaks, the model could support the majority of use cases, actors, tools and standards that could be applied to the business ecosystem.  From cloud construction, contracting, management, to billing disputes and regulatory compliance.

Ralph

[Reuven Cohen]

On Thu, Jan 29, 2009 at 2:15 PM, Ralph Biesemeyer <rebi...@gmail.com> wrote:
> The model that Christofer is maintaining provides the opportunity to
> encapsulate technical tools, like DMTF CIM and CDM, but also provisions
> Cloud Service Customers to compare service offerings, contract for the
> services they need and manage the required infrastructure to the extent they
> want.
>
> Most cloud services follow the general partitioning outlined by the dotted
> SaaS, PaaS, IaaS, etc boxes, which don't really need to be labelled. They
> only prove that the model fits reality.
>
> I am fairly new at this, but I think with some minor tweaks, the model could
> support the majority of use cases, actors, tools and standards that could be
> applied to the business ecosystem. From cloud construction, contracting,
> management, to billing disputes and regulatory compliance.
>
> Ralph
>
>

Slap an Ontology Language ontop such as (OWL RDF) or something
similar. This could be an ideal method to describe our semantic cloud
data model (taxonomy & ontology). The interesting thing about RDF /
OWL is it acts as general method for the conceptual description or
modeling of information that is implemented by the various cloud
resources. These cloud resources could just as easily be
"infrastructure resources" or even other API's.

Random thought.

reuven

[Lamia Youseff]

Dear Reuven and all,

Thank you for sharing with everybody the UCSB/IBM Ontology. The discussions going on the cloudosphere here and in response to James Urquhart's, John M. Willis's and Reuven Cohen's are very enlightening.

With the end goal of defining a common ontology/taxonomy for the cloud, I would like to add few points to the discussion. First, linguistically, there is difference between an ontology and a taxonomy.  An ontology is the study of the basic categories of things, but also focus more on their inter-relations. Taxonomy usually focus more into classification of things, and sometimes relating them into hierarchical structure (parent-child relation). At least, this is what the Merriam-Webster and Wikipedia say :) For that reason, we thought that 'taxonomy' does not closely apply to the field of cloud computing here. so, we used 'ontology'.

Enough about linguistics, now to the actual cloud computing. In the UCSB/IBM model, our goal was to capture the relation between components of cloud computing. After going from a pyramid diagram to concentric circles to the current stack model; we found that a layered stack model -- much like the models we usually teach in our operating system classes -- is most appropriate. In our paper, we described how one layer (higher in the stack) of the cloud can be composed/build upon services of the other layers if they share a common line in the UCSB/IBM ontology diagram. Therefore, we would argue that this ontology also captures the interoperability issues and opportunities that are facing the cloud community. To explain, one can deduce from the figure, for example that we can build an appengine on top of EC2 to provide interoperability for google apps between google and EC2 cloud offerings. However, the opposite is not feasible (i.e. building an EC2 inside appengine), since the latter is higher in the stack! Other characteristics, higher-availability for example comes to mind, can also come as a result of enabling such interoperability. More details on that are discussed in the paper (especially section 3 and 4). I still argue that UCSB/IBM model makes it easier to see and realize such opportunities. 

Another point that was raised in the discussion is that cloud-management softwares, those providing services like load-balancing, fault tolerance ...etc, are not represented in the model. Actually, they are. Although they don't look like traditional SaaS, I would argue that they are part of the cloud software layer.   They do provide their services to other SaaS, and they also interact with the other cloud layers (whether PaaS or IaaS) through APIs.  In this sense, business models like Rightscale's, in my opinion would be classified as a cloud application that is providing its services to other cloud applications-- rather than to direct cloud end-users.

WRT Hoff's model, it is very comprehensive and detailed model. It also does capture the interoperability and composability concepts as the UCSB/IBM model does. Therefore, it is an excellent step towards the unified model.  However, I am afraid that the many details in the figure would hinder its fast  uptake. I would agree that UCSB/IBM model is very simple, but it serves the needs for a model to teach to students and/or new-comers to cloud computing which is faster to adapt and understand. I have also to say that, I am looking from the view point of a scientist/ academician, but not the business side. I am really willing to work with Hoff's and/or anybody in the community who is interested in defining a cloud ontology for the hope to define a common ontology for use in both the business and the academic circles. .... 

Finally, many thanks for the fruitful discussions and the excellent feedback from the community ..  
-- Lamia Youseff
www.cs.ucsb.edu/~lyouseff
Link to paper preprint is: http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf [for the records, the paper was first sent for publication in August 2008].

[Hoff]

Lamia:

Thanks very much for the work you and your collaborators did on the
ontology you produced.

I do hope to reinforce the point that I didn't create the model to in
any way suggest that yours
was lacking, but rather, just as you qualified your perspective as
being "scientist/academician"
whereas mine approaches things from that of a "networking/security/
developer" perspective.
I needed more detail that someone from my line of work resonates with;
so far that crowd has
given me very good feedback on the approach.

I think the two models complement one another, but it would be nice to
be able to cross-reference
the broader "chunks" and I bet we could do it.

Thanks you again for your paper and hard work.

/Hoff

On Jan 29, 6:16 pm, Lamia Youseff <lyous...@gmail.com> wrote:
> Dear Reuven and all,
>
> Thank you for sharing with everybody the UCSB/IBM Ontology. The discussions
> going on the cloudosphere here and in response to James

> Urquhart<http://news.cnet.com/8301-19413_3-10152106-240.html?tag=mncol;txt>'s,
> John M. Willis's<http://www.johnmwillis.com/cloud-computing/unified-ontology-of-cloud-...>and
> Reuven
> Cohen's<http://www.elasticvapor.com/2009/01/unified-ontology-for-cloud-comput...>

> > On Thu, Jan 29, 2009 at 2:15 PM, Ralph Biesemeyer <rebie...@gmail.com>

[Hoff]

Lamia:

Thanks very much for the work you and your collaborators did on the
ontology you produced.

I do hope to reinforce the point that I didn't create the model to in
any way suggest that yours
was lacking, but rather, just as you qualified your perspective as
being "scientist/academician"
whereas mine approaches things from that of a "networking/security/
developer" perspective.
I needed more detail that someone from my line of work resonates with;
so far that crowd has
given me very good feedback on the approach.

I think the two models complement one another, but it would be nice to
be able to cross-reference
the broader "chunks" and I bet we could do it.

Thanks you again for your paper and hard work.

/Hoff

On Jan 29, 6:16 pm, Lamia Youseff <lyous...@gmail.com> wrote:

> Dear Reuven and all,
>
> Thank you for sharing with everybody the UCSB/IBM Ontology. The discussions
> going on the cloudosphere here and in response to James

> Urquhart<http://news.cnet.com/8301-19413_3-10152106-240.html?tag=mncol;txt>'s,
> John M. Willis's<http://www.johnmwillis.com/cloud-computing/unified-ontology-of-cloud-...>and
> Reuven
> Cohen's<http://www.elasticvapor.com/2009/01/unified-ontology-for-cloud-comput...>

> > On Thu, Jan 29, 2009 at 2:15 PM, Ralph Biesemeyer <rebie...@gmail.com>

[Ralph Biesemeyer]

                                                      
Correct me if I misinterpreted...Lamia's paper acknowledges on page 3 & 4 the model is in process:  "...security and availability...two of the major issues in this model, and they are currently avoided by the use of lenient service level agreements.... "

We should address the sticky issues cropping up in these cloud forums:  QoS, security, compliance and the new attack surfaces that abstracted IT exposes.  The ontology must allow customers, providers and regulators to define and enforce responsibilities or the evolution of cloud infrastructure will be constrained by lenient service level agreements.

This is why "Christofer's model" makes sense to me:  Over the last 18 months, I have been driving a cloud resource management system to support a consumer facing service.  It has proceeded like a tunneling project, with separate teams working on opposite sides of the mountain, tunneling towards the juncture of middleware and API, as illustrated in "Christofer's model".  Both teams realize that they must each maintain their own section of the tunnel; they are interdependent once the traffic starts passing. 

And getting back to the stack model: We need an ontology that helps define the API that allows the "bottom" of the stack to be switched out with a minimum amount of "top" service disruption, to enable "cloud interoperability". 
                                                      
Isn't that what we are trying to do?

Ralph

[xfer_rdy]

Lamia bring up an excellent point, there will be instantiation/
constructs of clouds which are specifically purposed. The construct
for educational purposes may not be directly applicable for business
or a super-computing center and conversely others may not be
appropriate for educations purposes. Interoperability is probably not
the easiest of specification tracks to take on. It usually requires a
few different core constructs to be established. I also think taking
on interoperability first will ease and expedite the development of
construct specifications in the cloud arena.

We are also in a very unique position in the world today, we all want
to produce a cloud interoperability specification. What makes this so
unique, we don't have to start from requirements from a hard pre-
existing market or be concerned with alienating well established
product lines. However, it still does not preclude us from developing
a set of goal, objectives and requirements we would like to meet with
the specification, better said; our mission.

There is a concern, voiced on several blogs as well as here, that this
effort would take to long to be meaningful or be useful or be
accepted. Fear tends to drive me to agree with that statement.
However, let me temper that with experience of failed specifications
that placed business expedience over technical readiness. This
undertaking is not a trivial task. If it was, it would probably be
already completed.

I'm going to go out on a limb here and voice what I would like to see
the spec accomplish. If no one wants to adopt moving forward with
this, that ok. If anyone has been working on a list and like some of
the ideas, feel free to use them.

1) See the specification adopt two categories for interoperability;
physical (hardware) and logical (everything else)
2) At a minimum specify cloud "edge object" discovery, object
description, prerequisites, connection methods/models.
3) Include a set of constructs/facilities/features/operations from the
following industries:
a) academia teaching,
b) academia research,
c) academia/Enegry Research/supercomupting,
d) academia/Climate Research/supercomupting NOAA, NCAR in boulder
e academia/Astro Physics
f) Business/Telecommunications
g) Business/Retail
h) Business/Health Care
i) Business/Automotive
j) Govt/Privacy
k) Govt/Business compliance
h) Govt/eGovt.

4) Incorporate the capabilities of the existing standards and mappings
to
a) DMTF CIM
b) SNIA (DMTF CIM)
c) OMG's CORBA CCM, DDS, KDM, XMI, CWM, Services, Facilities,
Broker & IIOP
d) ITU's Telecommunication Network Management specification (TNM)
e) TINA-C's Telecommunication Intelligent Network Architecture
specification (it looks just like a cloud based on CORBA)
f ) UCSB/IBM model
g) The CTO model (Hoff's), is there a "real" name for this ?
h) The Open Grid Specification
i) Globus
j) Liberty Alliance (SAML and others)
k) We need an working authorization spec.
l) We need a working SLA spec. TNM has something..

I would like to see both the UCSB/IBM and CTO construct edges to be
subsets of the interop spec.

Just as an FYI, the telecom industry has battled these same problems
for years. They eventually settled on using CORBA as a communication
backbone for management, and connectivity. The have a relatively
robust networking and resource management scheme based on TMN.
For any interested in this area, the links are:
Wikipedia brief: http://en.wikipedia.org/wiki/Telecommunications_Management_Network
The specs, are on page http://www.itu.int/rec/T-REC-M/e the TNM specs
start at M.3100

If I'm not making sense here, I have the flu while trying to
participate.

-gary


On Jan 29, 4:16 pm, Lamia Youseff <lyous...@gmail.com> wrote:

- Hide quoted text -
- Show quoted text -

...

read more »

On Jan 29, 9:13 pm, Ralph Biesemeyer <rebie...@gmail.com> wrote:
> Correct me if I misinterpreted...Lamia's paper acknowledges on page 3 & 4
> the model is in process:  "...security and availability...two of the major
> issues in this model, and they are currently avoided by the use of lenient
> service level agreements.... "
>
> We should address the sticky issues cropping up in these cloud forums:  QoS,
> security, compliance and the new attack surfaces that abstracted IT
> exposes.  The ontology must allow customers, providers and regulators to
> define and enforce responsibilities or the evolution of cloud infrastructure
> will be constrained by lenient service level agreements.
>
> This is why "Christofer's model" makes sense to me:  Over the last 18
> months, I have been driving a cloud resource management system to support a
> consumer facing service.  It has proceeded like a tunneling project, with
> separate teams working on opposite sides of the mountain, tunneling towards
> the juncture of middleware and API, as illustrated in "Christofer's model".
> Both teams realize that they must each maintain their own section of the
> tunnel; they are interdependent once the traffic starts passing.
>
> And getting back to the stack model: We need an ontology that helps define
> the API that allows the "bottom" of the stack to be switched out with a
> minimum amount of "top" service disruption, to enable "cloud
> interoperability".
>
> Isn't that what we are trying to do?
>
> Ralph
>

> > > -- Lamia Youseffwww.cs.ucsb.edu/~lyouseff<http://Youseffwww.cs.ucsb.edu/%7Elyouseff>

> > > Link to paper preprint is:

> >http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf[for<http://www.cs.ucsb.edu/%7Elyouseff/CCOntology/CloudOntology.pdf%5Bfor>the

[xfer_rdy]

Well, it looks like I'm apologizing to this group again...

I've been trying to convince an old colleague who has an long
engineering backgound in this area to join the group. He turned me
down for personal reasons. We share similar views, but he has some
very strong opinions on issues, much, much stronger than mine and he
voices them robustly, so to say. He didn't understand the entire
thread, he only read it briefly, I was clarifying in a response.

Unfortunately, parts of his comments leaked into one of my comments on
this topic and may have been emailed to the group. IE losing it mind.
Those were private comments to me, not the group.

again apologies no offense was intended

-gary

>  The specs, are on pagehttp://www.itu.int/rec/T-REC-M/ethe TNM specs

> read more »

[GREGG WONDERLY]

On Jan 29, 2009, at 10:13 PM, Ralph Biesemeyer wrote:
> And getting back to the stack model: We need an ontology that helps
> define the API that allows the "bottom" of the stack to be switched
> out with a minimum amount of "top" service disruption, to enable
> "cloud interoperability".

Some of you might be familiar with Jini (now the River project at
Apache), I don't recognize any names here from that community, so I am
not sure. One of the things present in Jini is the Java Extensible
Remote Invocation stack. In this stack, there are several features
that allow Java developers to just write Java code, and for deployment
to cover all aspects of interworking, authentication and authorization.

It would be interesting, I think to look at the model there and see
how the things there can help provide a clean separation between the
software and the cloud of things it talks to.

For those unfamiliar, here are some details, which I think should be
familiar as there are of course other places that you find this kind
of plug-ability.

Closest to the network is the endpoint implementation. This is simply
the transport media interface, including
notions of transport data security such as SSL, Kerberos etc.

Next up is the invocation layer. This is the mechanism that allows
the software on one end to exchange messages with software on the
other end. Jini provides Java to Java invocation layer
implementations, but others can be inserted at deployment time.

Wrapping these two concepts is the exporter, which provides attachment
of "Constraints" to the complete interface into a service. These
constraints can include things like "server must authenticate via
Kerberos as ..." or "client must authenticate to server as ...", as
well as other constraints which an application can design and deploy
as part of its implementation to cover things related to its
implementation.

The exporter is what a deployment would provide to the software via a
configuration file where it is initialized and defined with all the
appropriate bits and pieces.

This is low level stuff if you just consider it as the architecture of
the JERI stack. But, I find it provides a very clean separation of
the details which are useful for anything that has a "cloud"
architecture.

Gregg Wonderly

[Reuven Cohen]

Gregg, thanks for pointing this project out. I will take a closer look, from what you describe it sounds very interesting.

r/c

[Ralph Biesemeyer]

I think this is going in the right direction.
I found Gregg has also written on REST and Jini here:
http://www.mail-archive.com/service-orienta...@yahoogroups.com/msg06897.html
As Gregg points out: In order to make a decision on the interface type, it helps to define what the interface needs to do.
Certainly authentication, authorization, app discovery and invocation are critical functions.
I think near realtime messaging and event notifications would be important too.
It may be interesting to compare these interface requirements with XMPP capabilities.
Anyone done that?

Ralph

[Andy Edmonds]

Hey Gary - you mention SLAs: SLA@SOI are also working on the aspects of SLA specifications and that project are more than happy to help out on that aspect.

Andy

[Lori Mac Vittie]

Before I make any comments I am just verifying that “Hoff’s CTO model” refers to the taxonomy he recently blogged/diagrammed, correct?

 

Lori

 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Cloud Computing Interoperability Forum (CCIF)" group.
To post to this group, send email to cloud...@googlegroups.com
To unsubscribe from this group, send email to
cloudforum+...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/cloudforum?hl=en

-----
Join our Twitter Group at www.twitter.com/cloudforum
Or Our Linkedin Group at http://www.linkedin.com/e/gis/927567
-~----------~----~----~----~------~----~------~--~---

[Andy Edmonds]

Hi Ralph,
As mentioned before in the other XMPP related thread, we are looking into the suitability of XMPP for our infrastructure - I promised that I'd send out our experiences to date on XMPP and perhaps that might answer some of your queries. Looking at the list you've mentioned... from my experience of access and authorisation it seems to be somewhat a server implementation issue (i.e. what back end AA systems can be used). Application discovery is supported by the protocol via IQ packets. Invocations - XMPP supports XML-RPC and SOAP (as XEPs) however XMPP does not map cleanly when it comes to REST, though it's somewhat close. I'm sure, if I'm incorrect in some of these statements, that Peter Saint Andre will correct ;-)

Andy

[Greg Pfister]

I think there's something strange here. Nothing leaps out at me
taxonomically / ontologically / structurally, in either of the two
organizations, that causes them to specifically describe a *cloud*.

They look like a generic ontology / taxonomy / structure / whatever
attempting to cover all the conceivable contents of any IT shop, cloud
or not.

Does "cloud" just mean you do such a generic description, and then add
"aaS" to every useful point of entry?

Maybe... that actually is what "cloud" means. *aaS.

I don't recall anybody trying to restrict what their cloud notions
cover, in general -- everyone wants to be able to do it all. Which
means that the natural thing to do is try to define "it all." And then
aaS it.

Greg Pfister
http://perilsofparallel.blogspot.com/

> Athttp://rationalsecurity.typepad.com/blog/2009/01/cloud-computing-taxo...
>
> r/c

[Reuven Cohen]

On Tue, Feb 3, 2009 at 5:59 PM, Greg Pfister <greg.p...@gmail.com> wrote:
>
> I think there's something strange here. Nothing leaps out at me
> taxonomically / ontologically / structurally, in either of the two
> organizations, that causes them to specifically describe a *cloud*.
>
> They look like a generic ontology / taxonomy / structure / whatever
> attempting to cover all the conceivable contents of any IT shop, cloud
> or not.
>
> Does "cloud" just mean you do such a generic description, and then add
> "aaS" to every useful point of entry?
>
> Maybe... that actually is what "cloud" means. *aaS.
>
> I don't recall anybody trying to restrict what their cloud notions
> cover, in general -- everyone wants to be able to do it all. Which
> means that the natural thing to do is try to define "it all." And then
> aaS it.
>
> Greg Pfister
> http://perilsofparallel.blogspot.com/
>

I think what's missing is the subparts of each of those *aas
components, it's everything underneath -- whats actually important. I
think Hoff's layer cake does a great job of painting the 10,000 foot
picture but does nothing to actually address what is needed at every
other layer below.

Actually one of the best diagrams I've seen is on the CIM website >
http://www.dmtf.org/standards/cim/cim_schema_v220

The CIM_Application and CIM_System PDF's are particularly good.

r/c

[Greg Pfister]

I think you're correct to point to what's probably the most detailed
and complete standard definition of "a computer system." I don't know
enough about it to say whether they cover the higher levels included
in the ontologies / etc. discussed here.

Does that mean you agree, these are just generic taxonomies with "aaS"
attached at appropriate points? And you just want more detail as to
exactly where "aaS" gets attached?

(I'm going to make my original comment a blog post soon, with a bit of
expansion.)

Greg Pfister
http://perilsofparallel.blogspot.com/

On Feb 3, 5:26 pm, Reuven Cohen <r...@enomaly.com> wrote:

[Reuven Cohen]

Yes, I think we need more details as to where exactly "aaS" gets attached. And yes, we need a complete standard definition of "a cloud computing system".

r/c

[Drue Reeves]

Please, let’s not use the CIM model to describe a cloud computer system. If you haven’t written part of the CIM spec, I encourage you to try before recommending this definition (run away, run away). The CIM specification is full of opaqueness and doesn’t really enable interoperability (at least not yet).

 

But I think we’re getting ahead of ourselves. What is the compelling reason to define a cloud computer system at this point? Seems like we should consider more of the SML approach to defining a “service” before we define a Cloud Computer System.

 

IOW – Yes, I agree with the statement that cloud is, in many ways, *aaS. At Burton Group, we define “the cloud” as the set of technologies and delivery models necessary to offer IT services. (this is the definition we’ve discussed thus far). It may be a bit overly succinct, but it’s better than a long-winded definition with multiple exceptions or inclusion phrases to encompass every possibility. We then define “characteristics of the cloud” to clarify. This seems to work.

 

We also describe the cloud in terms of “tiers”. SaaS on top, PaaS below that, Software Infrastructure asS below that, and System Infrastructure aaS at the bottom. The resulting graphic looks like a stair-step to convey the fact that each *aaS can build on the other, but also, an IT organization can engage the cloud at each level. (If I had 3 dimensions, I’d also show that each *aaS can build the underlying layers themselves if they so choose).

 

But, I don’t see the rush to define a computer system object. Where is it? Let’s define the services first, creating service objects and a way to describe the service in web-services protocols. Then, if the service needs common objects for every vendor in that space, we can go there. This is much like SNMP. Let’s give them a common protocol and structure to define the service and let the data model be vendor defined until we see a need to standardize it.

 

From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Reuven Cohen
Sent: Tuesday, February 03, 2009 10:26 PM
To: cloud...@googlegroups.com
Subject: Re: Unified Ontology of Cloud Computing

 

 

On Tue, Feb 3, 2009 at 11:22 PM, Greg Pfister <greg.p...@gmail.com> wrote:

[Krishna Sankar (ksankar)]

Drue,

Agreed. Time to run fast indeed !  If we follow this path, before long we would have a huge CIM-like hierarchy of all the elements between earth and heavens ;o(

 

IMHO, we are aiming at capturing the relationships between VMs, attributes and related artifacts. Wouldn’t a light weight RDF and OWL work here ? Rather than any elaborate CIM hierarchies.

 

There are at least three vectors – the representation, exchange semantics and a processing model. If we keep them lightweight, even OWL-Lite should work; I do not think we need the decidability and completeness.

 

Cheers

<k/>

[Gary Mazzaferro]

Drue, Krishna,

I definitely disagree with the comments about CIM. I have a few comments...

No one here is expecting the WBEM interface or other CIM interfaces be
adopted as "the standard". It is one of several models that "need" to be
examined and included from a conceptual standpoint, so we know what the
ontology will represent.

On a side note: Granted, the CIM/WBEM interface in not the easiest to
use, but that's a CIMOM implementation issue, which is an
educational/exploration/development tool. Some how its being used as a
production system, it just goes to show you, anyone will use anything as
long as its free. Writing CIM/WBEM agents is not any more difficult than
GDMO/CMIS/CMIP or the SOA. I written all of the above...

Second, CIM brings significant value in terms of modeling, similar to
the OMG, TNM, TINA-C, GDMO models. None trivial to speak of, and in
broad application are equally complex as CIM. There is no free ride in
terms of modeling; flexibility usually brings robustness which begets
complexity.

The advantage and drawback to CIM is the ability to transverse the
management objects. Like with SNMP, if you know the object you are
looking for, you can access it quickly. This requires detailed knowledge
of the system you are monitoring or configuring. CIM intended to
alleviate the management application from knowing about each system, the
details of how the systems are constructed and configured could be
discovered. This also allows for more intelligent application planning
and system provisioning. For mission critical applications, very
intelligent management applications or personal could inspect in detail,
develop and execute recovery actions including degraded operations. If
you are considering CIM for a data center of 50 cpus, Drue is correct,
go use SNMP, Nagios and Webmin. If your data center is 50,000 cpus with
a diversity of systems, well, you may want to consider a more robust
provisioning and management solution.

Third, VMs are not cloud computing.... its a clever technology. In a few
more years, we all may be laughing, saying I can't believe we used that
stuff...

Fourth, SML and RDF/OWL are representation technologies, like any other
language. You need something to represent before you start figuring out
how you are going to do it. RDF/OWL is very very good for certain
applications, but it is not widely adopted, yet (I'm an advocate). Like
CIM it is very flexible, which brings an amount of complexity,
unnecessary by some opinions. ASN.1 and WSDL are other representation
languages should we exclude those and the associated industries
(finance,banking,retail, govt procurement) ?

Side Note: you can't use anything like SML, it not RDF compliant..

Consider this scenario: XMPP, CIM and CORBA have discovery schemas. Very
similar in nature, but radically different technologies. Cloud1 may
include a service that supports both XMPP and COBRA. How do we (as
cloud1) tell another (cloud2) about our capabilities ? How (as cloud2)
do we ask cloud1 about our capabilities. How is cloud1's service defined
for XMPP and CORBA definitions ?

That scenario is only one level in cloud compute, there are also
multiple networking levels. Clouds may need to translate from one of
several logical levels to a physical level. If the application is from
the telecom industry, what about languages, billing, auditing, quality
of service, cell addresses of sessions and data on sonet networks,
separation of data and signaling, provisioning the number of trunks need
for the application ? How does cloud1 and cloud2 communicate this
information ? How is this information defined ? How do the services
connect ? How are the logical services mapped to the physical so when
things go wrong, the engineers can find them ?

Luckily, most of this work has been completed for decades, we just need
to find a way to incorporate the definition.

If we want to write our own protocols and define our own behaviors, have
at it. But then, that is just another compute or architecture model,
except this one has no adopters. XaaS is just also just another model.
Unfortunately today, most products are just rebranded, no new
capabilities. There will be a market backlash as seen with Web 2.0.

Compute models come and go depending on the capabilities of the hardware
and the demands on the application(s). When hardware capabilities exceed
application demand, we consolidate, conversely we distribute workloads.
When user expectations exceed connect quality, we locally cache data.
Then complain its out of sync.

This interoperability specification should be agnostic to the current
state of technology. Drue has a good point about starting with services,
but services are artifacts arising from either technological or business
issues. Besides the application operations, hardware and system
maintenance are a significant business issues and impacted by underlying
technologies. I vaguely remember some cloud platform going down for 3
days, the provider couldn't find where the problem was....

Today, the CIM model and others address one type of business issue,
service and maintenance. Again in agreement with Drue, using GDMO, OMG
and DMTF's work for maintenance is like using a moon rocket to go around
the block for a container of milk. This is a good example of what not to
do with a model, reputations get ruined. But, I guess you have to find
work where you can get it. Although, the ITU decided to deploy CORBA as
a management technology for protocol commonality.

Now that ubiquitous computing is becoming a reality, lets not waste the
good works that came before this effort; built in anticipation of this
opportunity. Should we shy away just because it appears too hard. Or,
should we consider approaches employed by other bodies to accelerate
standards adoption and approval. The fastest track to adoption is the
encapsulation of widely deployed technologies, not by recognition from
university students; by real IT infrastructures supporting global
industries.

Success of this effort will be reflected by the number of industries and
companies that adopt it. Exclusionary practices for interoperability
standards only serve to alienate existing products and industries. It
may be prudent for this body to be cognoscente of more mature (adopted)
works and conservatively reinforce them in terms of classification,
categorization and additional definition.

Courting industries with promised potentials: I'm concerned a "cut the
cord" approach to existing infrastructures may not sufficiently persuade
IT stakeholders to adequately consider adoption with an immediacy or
sense of urgency needed to sustain the current cloud population.

This was only discussing the modeling component of interoperability.
Then there are the bridge/gateway/translation/transcode components.

gm

Krishna Sankar (ksankar) wrote:
>
> Drue,
>
> Agreed. Time to run fast indeed ! If we follow this path, before long
> we would have a huge CIM-like hierarchy of all the elements between
> earth and heavens ;o(
>
> IMHO, we are aiming at capturing the relationships between VMs,
> attributes and related artifacts. Wouldn’t a light weight RDF and OWL
> work here ? Rather than any elaborate CIM hierarchies.
>
> There are at least three vectors – the representation, exchange
> semantics and a processing model. If we keep them lightweight, even
> OWL-Lite should work; I do not think we need the decidability and
> completeness.
>
> Cheers
>
> <k/>
>

> *From:* cloud...@googlegroups.com
> [mailto:cloud...@googlegroups.com] *On Behalf Of *Drue Reeves
> *Sent:* Tuesday, February 03, 2009 8:45 PM
> *To:* cloud...@googlegroups.com
> *Subject:* RE: Unified Ontology of Cloud Computing

> *From:* cloud...@googlegroups.com
> [mailto:cloud...@googlegroups.com] *On Behalf Of *Reuven Cohen
> *Sent:* Tuesday, February 03, 2009 10:26 PM
> *To:* cloud...@googlegroups.com
> *Subject:* Re: Unified Ontology of Cloud Computing

>
> On Tue, Feb 3, 2009 at 11:22 PM, Greg Pfister <greg.p...@gmail.com
> <mailto:greg.p...@gmail.com>> wrote:
>
>
> I think you're correct to point to what's probably the most detailed
> and complete standard definition of "a computer system." I don't know
> enough about it to say whether they cover the higher levels included
> in the ontologies / etc. discussed here.
>
> Does that mean you agree, these are just generic taxonomies with "aaS"
> attached at appropriate points? And you just want more detail as to
> exactly where "aaS" gets attached?
>
> (I'm going to make my original comment a blog post soon, with a bit of
> expansion.)
>
>
> Greg Pfister
> http://perilsofparallel.blogspot.com/
>
> On Feb 3, 5:26 pm, Reuven Cohen <r...@enomaly.com

[Paul Strong]

Well, I was finally contemplating a response when Gary's email saved me a lot of effort :o)

Some additional thoughts based on my work here at eBay and elsewhere...

IMHO it is far more important to decide the set of things to be modeled than on the representation, although as per below, representations offer both opportunities and contraints, depending on what you want to achieve via the representation.  If one thinks of managing infrastructure (internal/external cloud, traditional data center) and the services that run on it then one needs to capture -

• The set of things to be managed
• The relationships between these - which one could argue are *the* most important things, as it is how one connects things together in a networked world that delivers functionality and defines value, and it is the number of relationships and the desire to change them that drive complexity
• The life-cycle of those things and relationships
• The processes that are used to manage those life-cycles

No one model captures all of these things.  The EGA/OGF Reference Model (http://forge.gridforum.org/sf/go/doc14766?nav=1 - full disclosure - I had a hand in this doc) tries to reconcile some of these in some sense, at a high level, and to reference other useful models, like CIM (for things) and ITIL (for processes and life-cycle).  It is currently incomplete but work on it is still ongoing and contributions would be welcome.  The diagram in 2.2.11 page 24 may be interesting/useful.

At eBay we have used the basic concepts of this model as the basis for what we call a Semantic Query Service.  This is a tool that federates multiple configuration and monitoring tools and allows consumers of the service to answer interesting questions such as -

• If this URL/Command breaks, what are the infrastructure (logical, physical) and services that support it?
• If load balancer X breaks what business processes are impacted?
• If we have two symptoms of failures, are there any things (relationships) they have in common?

This tool is essentially semantic web based (RDF/OWL), collects data from other tools, adds semantics and then stores the relationships in memory, allowing other services to query it using SPARQL.  It also includes many of the verbs that can be applied to managed components and management relationships within the ontology, thus allowing new patterns to be managed without recoding tools that sit on top.  Now this tool is at a relatively early stage in its life, but with a minimal vocabulary (perhaps 20 types of things and 10 types of relationships) has enabled us to do lots of interesting things.  Sidenote - A server infrastructure with 4000 servers (about 20% of our production infrastructure for eBay.com) results in about 10 million triples. Processing large numbers of relationships is "entertaining". ;o)

Anyway we have been able to extract this value by

• Having a very clearly bounded problem, in terms of what use cases we wanted to support for which things/services/relationships etc.
• Only modeling (including Ontology work) what we absolutely had to, to solve the problem
• Choosing a set of tools that allowed the (meta-)model to be very extensible
• Keeping everything as simple as possible
• Reinventing as little as possible
  

I think this brings me back to the need for a very clear problem statement and use case(s) that we want to support.  IMHO if this community effort is to be successful then we need this clarity and we need to decide what specifically needs to be solved for Clouds, whether or not some other collective is already working on it, and whether/how we can add value or otherwise solve the problem.

My 2c for what it's worth.

Paul

--
Paul Strong
email - Paul....@gmail.com
AIM - FractalPaul
Skype - FractalPaul

[Greg Pfister]

OK, I think Drue, Krishna, Gary, and Paul (probably others by the time
this post appears) have successfully exorcised the demon CIM. I'm
relieved, because it means I still don't have to learn UML. :-)

So let's back up. What's the purpose of all this? Classifying kinds of
clouds, I think. That's useful, but is only part of the job. What I'd
like to do is make sense of all the cloud-related products, not just
the cloud types themselves.

That would need to cover products that provide infrastructure for the
cloud itself, enabling you to build one. These aren't necessarily
provided aaS themselves, but enable that for other offerings.

There are lots of those out there, too many to ignore: VMware's
Virtual Datacenter OS, VMLogix managers, Enomaly's ECP, Globus'
Nimbus, Eucalyptus, etc.

Greg Pfister
http://perilsofparallel.blogspot.com/

On Feb 3, 10:26 pm, Reuven Cohen <r...@enomaly.com> wrote:
> On Tue, Feb 3, 2009 at 11:22 PM, Greg Pfister <greg.pfis...@gmail.com>wrote:
>
[arguably irrelevant stuff deleted]

[Subramaniyam Pooni]

One of the problems I found when working with CIM/WBEM was there are way too many associations IN CIM and association traversal is always a big headache. Also CIM does not support something like a getbulk request (like in SNMP) where you can get the entire profile in one shot if we don't want to traverse the associations. This is one of the reasons why the resync logic implemented in many devices is very slow. So definitely for a personal standpoint I don't believe modeling based on CIM is the best approach.

Sam


--- On Thu, 2/5/09, Greg Pfister <greg.p...@gmail.com> wrote:

[Mark A. Carlson]

You can certainly code badly in any model or language, but the CIM-XML protocol
does allow you batch several commands. The protocol itself doesn't know about profiles,
so that is up the the client to code. There is also the concept of view classes that get you
all the properties you need in a single fetch. I have seen bad code that ignores these concepts
and is slow, but I have also seen very efficient, fast code that uses CIM/WBEM.

Associations are a powerful concept for expressing relationships - an important part of
any semantic model.

What I don't get is all the NIH and readiness to reinvent wheels that have take years to
refine and get broad agreement and adoption on already.

-- mark

--

Mark A. Carlson Sr. Architect Systems Group Phone x69559 / 303-223-6139 Email Mark.C...@Sun.COM

[Krishna Sankar (ksankar)]

Greg,

Not so fast ! We might still use a few UML diagrams to express our model - CIM or not ;o) If we have state diagrams or sequence diagrams, UML would be very useful. But we will keep it simple and promise to give you a quick-painless tutorial ;o) (or you can take the red pill).

And I hope you are not as allergic to RDF/OWL !

Cheers
<k/>

|-----Original Message-----
|From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com]

|On Behalf Of Greg Pfister
|Sent: Thursday, February 05, 2009 9:09 AM
|To: Cloud Computing Interoperability Forum (CCIF)
|Subject: Re: Unified Ontology of Cloud Computing
|
|

[Gary Mazzaferro]

K,

I think you missing the point on this subject. We are not saying exclude
RDF. We are talking about models and what to represent; what we should
leverage and how to include much of the adopted technologies and
standards. We don't need another model for this part of the effort (I'm
not stopping you from doing one), we really need a meta model: a
composite that has the ability to be extensible.

"You take the blue pill and the story ends. You wake in your bed and
believe whatever you want to believe. You take the red pill and you stay
in Wonderland and I show you how deep the rabbit-hole goes. Remember --
all I am offering is the truth, nothing more." o);

I think we are going to have to get something on paper, or else these
types of discussions will go on forever.

Ruv has taken a good first cut at the front matter.

I'll start looking at organization of a "top down" capabilities matrix
for existing standards to publish. This will give us a starting
point/inventory of the existing capabilities/facilities. This is only a
working tool and may not be current as underlying standards change.

I there are no objections, I'm offering to take stab at this. I'll look
at model components first , so we can get a composite capabilities
model and start that discussion process.
I'm very familiar with CORBA, TNM, TINA-C, DMTF CIM, SNIA, OBS, WSDL,
SML, GDMO, SNMP, ASN.1, OWL/RDF, COPS, SAML, Liberty, oAuth, XMPP, T10
storage, a bunch of JSRs, sonet/ATM, SS7, most ethernet/IP rfcs, and a
bunch of others. I have very limited time until Wed.

I'm open for suggestions on where to publish. We need read access for
Releases and for the WIP, write access for contributing WIP and some
version system ?

I'll use Open Office, if there are no objections. M$ Office 2007 is my
alternative. I use windows and Solaris Sparc and x64 at home. Sorry, no Mac.

gm



Krishna Sankar (ksankar) wrote:

[Ralph Biesemeyer]

Can we attach files? I haven't seen anybody do that.
At the risk of upleveling this quite a bit, I took a cut at Christofer Hoff's ontology diagram and inserted some of the business processes & interrelationships implied by his diagram.  I put it in PNG format for portability and Visio for anybody who wants to modify the diagram.
I inserted an interface called "terms and conditions" that could help serve as the "interoperability" interface.
This interface would provide loose coupling of the service with the underlying technology.
Of course we would need standard interface types to Governance/Compliance/Security operators.

Ralph

[Gary Mazzaferro]

Hi Ralph,

It came though on email... It looks good ! A few more domain use cases
will help.

we need a place to put all this stuff, like a "work in progress" wiki or
file share. Does some on this list have a collaboration product we can
use ? If know, we may be able put it source forge or another repository.

What do you mean by governance ?

gm

> <mailto:r...@enomaly.com>> wrote:
> |> On Tue, Feb 3, 2009 at 11:22 PM, Greg Pfister

> |<greg.pfis...@gmail.com <mailto:greg.pfis...@gmail.com>>wrote:
> |>
> |[arguably irrelevant stuff deleted]
> |
>
>
>
>
> >
>
> ------------------------------------------------------------------------
>

[Gary Mazzaferro]

Since we don't have an official working entity, how are we going to
handle licensing/copyrights. Collective Commons ?

gm

Hi Ralph,

It came though on email... It looks good ! A few more domain use cases
will help.

we need a place to put all this stuff, like a "work in progress" wiki or
file share. Does some on this list have a collaboration product we can
use ? If know, we may be able put it source forge or another repository.

What do you mean by governance ?

gm


Ralph Biesemeyer wrote:

> <mailto:r...@enomaly.com>> wrote:
> |> On Tue, Feb 3, 2009 at 11:22 PM, Greg Pfister

> |<greg.pfis...@gmail.com <mailto:greg.pfis...@gmail.com>>wrote:
> |>
> |[arguably irrelevant stuff deleted]
> |
>
>
>
>
> >
>
> ------------------------------------------------------------------------
>

[Ralph Biesemeyer]

To me,

Governance means management - product, service and facilities management
Compliance would be Business e.g SLA. & Legal e.g. HIPPA, EU Privacy, etc. regulations reporting
Security would be data-domain partitioning, AAA & firewalling.

It's simple, but that's what I think.

Ralph

[Drue Reeves]

Sorry I didn't reply earlier y'all...day job you know. Lots of things to address here, I'll try to write to people individually, but also to the group.

To all -- Greg is absolutely right to ask the question of 'what problem are we trying to solve?' The whole CIM_ComputerSystem discussion makes me concerned that we're diving too deep before we've decided what problems we have and how to divide the work up properly. IMHO -- A taxonomy diagram and general cloud definition is a good place to start because it will give us direction and allow us to break up into separate working groups, each where our interests lie, rather than a UML diagram just yet (it may be necessary later). If one thinks about a real architect (e.g. one that designs a house or building), they don't start with the blueprint, they start with a conceptual diagram. Why? Because it gives everyone an idea of what we're talking about without having to understand building codes, scale, etc. IOW -- it sets vision, gives perspective and allows us to know how to attack the problem. For example, if our cloud taxonomy diagram looks something like a tiered architecture of services (and I recommend we keep it simple), then we can break up into groups like SaaS, PaaS, IaaS (or HaaS) and Interoperability working groups. The Interoperability WG would be the place where we define the things that all cloud services need: protocols and data models metamodels for defining a cloud service (in general), necessary protocols, define how customers initiate a relationship with a vendor, SLAs, etc. Then each *aaS group would then discover the specific requirements for their area and can either address the concern themselves or ask the Interoperability group to consider the *aas group's issue as part of any deliverables the Interoperability group designs.

Ralph and Gary, I strongly urge you to have an agreement in place before you exchange ideas, diagrams, documents, etc. Been down this path before with several other standards bodies. If legal agreements aren't in place, chaos can ensue. Proceed at your own risk.

Gary -- I'll respond to your comments in a separate email, since they are long-winded. Full disclosure, I'm a SMI-S and CIM spec author, worked on SML too (left Dell's CTO office before the spec went 1.0) so I'm intimately familiar with the issues.

BTW -- Nice meeting y'all. You're a new group for me.

Drue

[Gary Mazzaferro]

Hi Drue,

Before you spend a bunch of time on a response, wait until I get
something structured and written down. I think you'll be pleasantly
surprised. My goal is to simplify without alienating.

Drue is correct, about defining the problem space, the challenge with
cloud computing transverses so many industries, compute models and
technologies; its hard to establish a baseline. IMHO, I don't see
anything wrong with leveraging capabilities from existing, deployed
standards from different industries to achieve a baseline.

I hear Drue's concerns loud and clear. In my opinion, I believe that is
one of the difficulties of CORBA and CIM. They didn't consider "ease of
use" as one of the goals. (this is when I usually quit po'd, or I quit
when the body gets hijacked and bullied by a big company) Hopefully,
we'll be able to take advantage others' experiences, like Drue's, and
prevent us from repeating errors of the past.

BTW, I'll be publishing my works as creative commons, unless someone
objects.

gm

[Ralph Biesemeyer]

Drue,

Welcome to the group.
I neglected to include the product divisions of *aaS that Christofer had in the original diagram, and make sense to me.
Check it out at
http://rationalsecurity.typepad.com/blog/2009/01/cloud-computing-taxonomy-ontology-please-review.html
Thanks for your advice.  Christofer acknowledges that his diagram is an amalgamation of many inputs.  Mine is just one of many.
I don't have a blog, so I attached for the group's convenience.

Ralph

[Drue Reeves]

Hi Mark, good to hear from you again!

 

Come on now…we both know that “broad adoption” is a very arguable statement. If CIM is so widely adopted then let’s compare the number of CIM clients to the non-CIM clients out there. Where’s the customer demand? Don’t have any customers saying “give me some more of that CIM”. If CIM is so widely adopted, why is management interoperability still a problem in almost every data center? As for “broad agreement”, it’s easy to claim that when the specification is opaque or optional in many places. You know as well as I do that when we can’t agree in the WGs, we define things more broadly and opaquely…at the sacrifice of interoperability.

 

What I don’t understand is why we have to boil the ocean just to describe a service. Do we have to define the entire set of objects and attributes that every PaaS vendor might need to describe his service before we can attain interoperability? Or, can we create a single object definition that any application can understand and enables providers to plug in the own data model? The latter has a better track record to interoperability amongst management protocols.

 

Drue

[KentLangley]

I'm not 100% up to speed on this very long thread yet(just joined
today). So, I need to catch up. I did post an updated Cloud
Computing Stack (related to this) though yesterday that I made last
December.

http://www.productionscale.com/home/2009/2/5/cloud-computing-stack-update.html

Kent Langley
www.nscaled.com

> Interesting read.http://www.cs.ucsb.edu/~lyouseff/CCOntology/CloudOntology.pdf

[Drue Reeves]

Interesting, nice diagram...very similar to the diagram we've been presenting to customers:
http://dcsblog.burtongroup.com/data_center_strategies/2008/10/cloud-definitio.html (this is a blog post, very informal. We have much more formal presentations).

The reason we don't define the cloud underneath System-Infrastructure-as-a-Service is because it implies an implementation that not every vendor may have/want. Why should a cloud definition include things like virtualization if the vendor decides to offer System-Infrastructure-as-a-Service without virtualization?

While I like the architecture, everything at the "Operating System Userland" and below (grey colored area) is vendor specific. I'm not sure users care how they implement it as long as it meets the service-level or functionality requirements. As such, not sure we should attempt to define that portion of the stack either. This is where the UCSB Cloud Ontology falls down too.

The layers above "Operating System Userland" should be easy to classify. We have examples in the market that fit. Below that, we're probably either have a hard time classifying vendors that implement their environment this way OR we'll have to generalize the picture more to make them fit.

My two cents: Let's start with the color parts of this picture (i.e. "the services"...after all, isn't that what this is about)?

Drue

-----Original Message-----
From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of KentLangley
Sent: Friday, February 06, 2009 1:24 PM
To: Cloud Computing Interoperability Forum (CCIF)
Subject: Re: Unified Ontology of Cloud Computing

> knowledge domain, its components and their relations - i.e. an
> ontology - is necessary to help the research community achieve a