Cloud Computing Nukes the Fridge...

15 views
Skip to first unread message

Chris Marino

unread,
Feb 11, 2009, 10:05:12 AM2/11/09
to cloud...@googlegroups.com
Gang, I've gone dark on this group for a while but have been trying to keep up as best I can.

One reason is that I've been busy with other things, but another is that it seems that a lot of the topics here are replays of ones that come up over and over again.

'What is Cloud Computing', for example.

That by itself doesn't bother me, but when I read Reuven's 'Hybrid Cloud Multiverse' post I just couldn't take it any longer.

Within days of the dust settling on the 'Cloud Ontology' discussion, he throws the whole thing open again with a cloud 'multiverse'.

"The cloud is a kind of  "multiverse" where the rules of nature can continually be rewritten using quarantined virtual worlds within other virtual worlds"

Huh?? What the heck are you talking about?

Reuven, you're super smart, and are (obviously) passionate about cloud computing, but let me tell you something.  You are WAY AHEAD of users on this.  Not just the laggards, or the majority, or even the early adopters.  You're ahead of everyone. 

I might be going out a limb here, but I'm going to predict that Cloud Computing isn't going to rewrite the rules of nature.

Gang, like it or not, to the overwhelming majority: Cloud Computing = Google.

To the slightly more knowledgeable: Cloud Computing = Salesforce.com (SaaS)

The sophisticated: Cloud Computing = AWS (and their ilk).

Multiverse aside, even the IPv6 issue is front running even the most sophisticated practitioner of cloud computing.  I don't want to seem like the crotchety old man, but let me tell you kids something:

20 yrs ago (I'm not kidding), I was in discussions with people about about the imminent collapse of the ARPANET because of address space exhaustion. This was right around the time we were building the MIPS R4000 with 64 bit addressing because clear limitations of 2GB virtual addressing.

OK, so here we are, more than 10 yrs. after IPv6 and nearly 20 years after the R4000 and neither of these issues make the to the top of the list of any mainstream user.

Cloud Computing is going to be successful because of the familiar things it does better. Not because it does can do things that people haven't thought of.  That will come along for the ride.


Matthew Zito

unread,
Feb 11, 2009, 10:19:02 AM2/11/09
to cloud...@googlegroups.com

I have to agree with at least part of this statement – there’s really no need for IP portability in any infrastructure today.  DNS has long since accomplished handling name portability across different facilities, and MPLS is not a new innovation, it’s been used for years as a way for service providers to provide clear SLAs and assist in making traffic decisions without having to do deep packet inspection, which has a lot of overhead.  It was designed as a physical-protocol independent way to provide the functionality that ATM was designed to provide without any of ATM’s horrific crappiness.

 

I think there is a bit of a tendency to look for solutions for problems that don’t exist yet.  Let’s actually figure out how someone would move an object from one cloud provider to another, and why they would want to do that (I still don’t quite understand why they would in most situations), and how we’re going to talk about this, before we start talking about how IPv6 is going to be critical to the cloud.

 

Thanks,

Matt

 


Drue Reeves

unread,
Feb 11, 2009, 10:31:37 AM2/11/09
to cloud...@googlegroups.com

Even higher, before we talk about moving objects between clouds, let’s settle on a cloud definition and diagram (because moving an object may not apply to all levels of the cloud).  Then we can divide into groups based on the taxonomy and solve individual problems in that area to our hearts desire.

Pat Wendorf

unread,
Feb 11, 2009, 11:05:08 AM2/11/09
to cloud...@googlegroups.com
Normally a lurker here as well, but I'm getting the big picture here:

I don't think Ruv is talking specifically about the laws of nature and physics being re-written by a technological system, I think he's talking in the more abstract sense about where the cloud idea will eventually evolve into.

Right now, from the trenches of working in a cloud infrastructure company (full disclosure, I work for Ruv) the idea in most customers minds about cloud computing is service based systems that can be spun up/down as needed.  Our current take on this problem is a flexible clustered virtulization system.  Think one step above that:  Fully flexible, virtualized business infrastructure.  A system that allows the entire set of services a business needs to operate spun up/down as needed and priced as a utility.  This seems reasonable considering where cloud computing is going at the moment, and isn't a huge leap from where we are now.   Think one more step above that:  The entire set of internet resources (servers, hosts) acting as a "multiverse" of flexible resources where any service imaginable can connect and interact with any other service at some level of compatiblity.  All of these services being geogrpahically redunant, completely isolated (storage/processing/networking).  Now you have something a little more sci-fi and a little less here-and-now.  Every machine acts as a host and a participant for these isolated units of service and we finally fully utilize all the hardware/networking advances we've seen over the last 20 years from companies like Intel and Cisco.  Add onto that a fully ontologically relational way of representing this massive service cloud, and I think we're talking about something 1-2 steps behind what Ruv is talking about now ;)

- Pat

Matthew Zito

unread,
Feb 11, 2009, 11:08:27 AM2/11/09
to cloud...@googlegroups.com

See, my problem with this kind of talk is you can go s/cloud/grid/ and you’re talking about the cycle of what was described back in 2002-2003 when Grid was at the peak of its hype cycle.  There were a pile of companies that were looking to make money off of both internal and external compute grids, and many of these companies have now just repositioned their businesses as Cloud offerings.  

 

What is different about the cloud, as compared to “the grid”, such that the concept will live up to the hype this time?

 

Thanks,

Matt

 


From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Pat Wendorf


Sent: Wednesday, February 11, 2009 11:05 AM
To: cloud...@googlegroups.com

Pat Wendorf

unread,
Feb 11, 2009, 11:17:31 AM2/11/09
to cloud...@googlegroups.com
I think the business focus is the difference.  Grid computing, as I understood it, focused entirely on the performance you could get by tying machines together.  It brought about things like Linux based research clusters and huge number crunching financial systems.  Cloud, from my perspective, focuses on using virtualization to isolate already well known system architectures (n-teir, client/server) into something very flexible for the sysadmin to work with.  The focus is not performance or straight-out number crunching.  This is from a "cloud as an infrastructure" point of view of course.  The SaS platform cloud providers probably see things more as "apps are free to scale automatically" which really is an innovation on plain ol' web services.  I think the confusing part is that we call both "cloud" right now and techies can spot the differences and call foul.

Lori Mac Vittie

unread,
Feb 11, 2009, 11:19:58 AM2/11/09
to cloud...@googlegroups.com

If I were trying to explain the difference between cloud and grid I would put it this way:

 

Grid was about executing up long, complex processes across a distributed set of compute resources; running them in parallel.  

Cloud is at a higher level, at the application. It’s about executing applications across a distributed set of compute resources; running in serial.

 

Multi-threaded versus multi-process, if you will. Grid would be more like the way Apache splits off threads to specifically handle logging in a non-blocking way as opposed to cloud where Apache is spawning multiple processes to handle the entire request-response process.

 

Lori

 

From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Matthew Zito


Sent: Wednesday, February 11, 2009 8:08 AM
To: cloud...@googlegroups.com


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

 

Schliesser, Benson

unread,
Feb 11, 2009, 11:59:18 AM2/11/09
to cloud...@googlegroups.com


I agree with Matthew's comment that we need to start with the abstract definition of what the objects are and why they would move. But I would point out that even at an abstract layer we need to describe affinities and/or dependencies of these objects. Architecture doesn't just describe what the items are, but also how they relate to each other (connect, etc).

IP addresses, subnet membership, broadcast segment (aka VLAN) membership, layer-3 network association, DNS namespace, etc, etc, are all examples of things that we might eventually need to capture as attributes of an object. Some of these imply an affinity between objects such that they need to "move" together, as a group. Some of these attributes simply describe relationships that translate to requirements on the environment hosting the object. But all are relevant to this discussion, because we need an abstract way of describing each class of relationship.

On a more detailed level, I also think Matthew makes a good point about existing architecture and standards. We, and more importantly our eventual customers, must accept that best-practices exist and we should acknowledge that we're not necessarily experts in all of the domains needed to describe ideal IT infrastructure. For instance, I am a network architect by experience and profession and I can attest that much (but not all) of the conversation here regarding network architecture has been amateur and sometimes just wrong. (I'm glad to see some of Matthew's comments, I.e. on DNS.)

My suggestion is that the organization identify the technology domains where expertise and detailed knowledge is required, and then recruit individuals to contribute in each domain. The goal of each domain-specific group is to accurately describe the elements and classes of an abstract architecture that reflects best-practises for that technology area. I.e. Not to inject detailed attributes into the architecture, but to capture the meta-attributes and pass them along to the overall CCIF.

Without a governance model and core (structured) architecture team, I'm not sure how we manage this. Part of me hates to make the suggestion, but is it perhaps time for a formal org structure in the CCIF?

Cheers,
-Benson




From: cloud...@googlegroups.com
To: cloud...@googlegroups.com
Sent: Wed Feb 11 09:19:02 2009


Subject: RE: Cloud Computing Nukes the Fridge...

I have to agree with at least part of this statement – there’s really no need for IP portability in any infrastructure today.  DNS has long since accomplished handling name portability across different facilities, and MPLS is not a new innovation, it’s been used for years as a way for service providers to provide clear SLAs and assist in making traffic decisions without having to do deep packet inspection, which has a lot of overhead.  It was designed as a physical-protocol independent way to provide the functionality that ATM was designed to provide without any of ATM’s horrific crappiness.

 

I think there is a bit of a tendency to look for solutions for problems that don’t exist yet.  Let’s actually figure out how someone would move an object from one cloud provider to another, and why they would want to do that (I still don’t quite understand why they would in most situations), and how we’re going to talk about this, before we start talking about how IPv6 is going to be critical to the cloud.

 

Thanks,

Matt

 


From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Chris Marino
Sent: Wednesday, February 11, 2009 10:05 AM
To: cloud...@googlegroups.com
Subject: Cloud Computing Nukes the Fridge...

 

Gang, I've gone dark on this group for a while but have been trying to keep up as best I can.

One reason is that I've been busy with other things, but another is that it seems that a lot of the topics here are replays of ones that come up over and over again.

'What is Cloud Computing', for example.

That by itself doesn't bother me, but when I read Reuven's 'Hybrid Cloud Multiverse' post I just couldn't take it any longer.

Within days of the dust settling on the 'Cloud Ontology' discussion, he throws the whole thing open again with a cloud 'multiverse'.

"The cloud is a kind of  "multiverse" where the rules of nature can continually be rewritten using quarantined virtual worlds within other virtual worlds"

Huh?? What the heck are you talking about?

Reuven, you're super smart, and are (obviously) passionate about cloud computing, but let me tell you something.  You are WAY AHEAD of users on this.  Not just the laggards, or the majority, or even the early adopters.  You're ahead of everyone. 

I might be going out a limb here, but I'm going to predict that Cloud Computing isn't going to rewrite the rules of nature.

Gang, like it or not, to the overwhelming majority: Cloud Computing = Google.

To the slightly more knowledgeable: Cloud Computing = Salesforce.com (SaaS)

The sophisticated: Cloud Computing = AWS (and their ilk).

Multiverse aside, even the IPv6 issue is front running even the most sophisticated practitioner of cloud computing.  I don't want to seem like the crotchety old man, but let me tell you kids something:

20 yrs ago (I'm not kidding), I was in discussions with people about about the imminent collapse of the ARPANET because of address space exhaustion. This was right around the time we were building the MIPS R4000 with 64 bit addressing because clear limitations of 2GB virtual addressing.

OK, so here we are, more than 10 yrs. after IPv6 and nearly 20 years after the R4000 and neither of these issues make the to the top of the list of any mainstream user.

Cloud Computing is going to be successful because of the familiar things it does better. Not because it does can do things that people haven't thought of.  That will come along for the ride.





This message contains information which may be confidential and/or privileged. Unless you are the intended recipient (or authorized to receive for the intended recipient), you may not read, use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachment(s) thereto without retaining any copies.

Krishna Sankar (ksankar)

unread,
Feb 11, 2009, 12:12:14 PM2/11/09
to cloud...@googlegroups.com

Matt,

 

                I have two blogs on this topic (and couple of pointers to papers) - http://doubleclix.wordpress.com/2008/08/03/cloud-computing-and-grids/ and http://doubleclix.wordpress.com/2008/09/23/cloud-computing-grids-and-paczkis-part-deux/

 

                The short answer is elasticity and multi-tenancy as well as the ability to run your own application stack. I am also of the opinion that grids focused on scheduling and resource allocation while clouds focus on scalability. Another difference, IMHO, is that grids focused on computing tasks while clouds focus on normal IT applications.

 

Having said that there is a finite possibility that Cloud domain could go the way of grids or SOA – especially if we start generating 100s of standards ;o(. I am not saying grids are not useful but most probably didn’t catch mainstream adoption.

 

Cheers

<k/>

 

From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Matthew Zito


Sent: Wednesday, February 11, 2009 8:08 AM
To: cloud...@googlegroups.com

JP Morgenthal

unread,
Feb 11, 2009, 12:17:39 PM2/11/09
to cloud...@googlegroups.com
Lori,

I can see why you would identify each in this way, but I see it a bit differently.

Grid = redundancy and fault tolerance
Cloud = elasticity and dynamism

I don't think these things are mutually exclusive and I believe that grid should be identified as a component of IaaS.
JP
-----------------------------------------------
JP Morgenthal
cell : 703-554-5301
email: jpmorg...@gmail.com
email: m...@jpmorgenthal.com
twitter: www.twitter.com/jpmorgenthal
blog: www.jpmorgenthal.com/morgenthal

JP Morgenthal

unread,
Feb 11, 2009, 12:19:22 PM2/11/09
to cloud...@googlegroups.com
funny, i just got to read Krishna's posts and he sees cloud inside grid, whereas I stated I see grid inside cloud.  Hmmmm.  You say pot-a-to I say pot-ah-to! Sounds like SOA all over again! :-)

-----------------------------------------------
JP Morgenthal
cell : 703-554-5301
email: jpmorg...@gmail.com
email: m...@jpmorgenthal.com
twitter: www.twitter.com/jpmorgenthal
blog: www.jpmorgenthal.com/morgenthal


Matthew Zito

unread,
Feb 11, 2009, 12:56:51 PM2/11/09
to cloud...@googlegroups.com

I agree that if you put those restrictions around grid, there are differences, but there’s no practical reason why those differentiations had to exist.  For example, companies like Ejasent, Appistry, Trigence, all enabled customers to build dynamic application grids, based on normal IT applications.  Oracle has and had a whole Grid pitch around running IT applications on a distributed subset of servers.  Grid solutions like LSF, DataSynapse allowed you to run your own application stack.

 

Multi-tenancy is an interesting answer, but Sun used to sell compute time by the hour in a multi-tenant format in their Grid offering, so that can’t be a difference.  

 

So far, it seems like the biggest differentiator that I’ve heard is “virtualization” – but does everyone agree that virtualization is a requirement for cloud computing?   I would imagine no.

 

Thanks,

Matt

 


Matthew Zito

unread,
Feb 11, 2009, 1:15:22 PM2/11/09
to cloud...@googlegroups.com

I think I see them as basically the same thing with different marketing, using some slightly different abstraction technologies, with the same hype cycle.  So now we cover the spectrum.  Clearly it’s time for us to create several thousands of pages of standards that no one will ever use, like SOA and Grid.

 

Matt

 


Lori Mac Vittie

unread,
Feb 11, 2009, 1:18:33 PM2/11/09
to cloud...@googlegroups.com

Heh. Time to go back to the beginning, Vizini?

 

I think the important thing is that we agree on the components necessary to move forward, regardless of how we spell/pronounce/define it.

 

 


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

Krishna Sankar (ksankar)

unread,
Feb 11, 2009, 1:34:14 PM2/11/09
to cloud...@googlegroups.com

JP,

 

                Interesting …

 

                Why is redundancy and fault tolerance a grid artifact ? That is a cluster and I am not sure we can equate grids and clusters. Job scheduling & distribution as grid artifact yep.

 

                Another question which I had asked before – Is mapReduce a grid or cloud application ? What about a paxos based system ? What about a web server farm with loadbalancing, backend database cluster and so forth ? What about a highly scalable RubyOnRails infrastructure ?

 

Cheers

<k/>  

Gary Mazzaferro

unread,
Feb 11, 2009, 1:52:58 PM2/11/09
to cloud...@googlegroups.com
Hi All,

I see grid inside cloud, and cluster inside grid. Unless of course, you
are building a grid or a cluster made of clouds.

IMHO, I see clouds as a true abstractions of computing objects with all
the interfaces. However, it not a solid object, it's semi-porous, hollow
and filled with a lightweight medium, so "agents" can enter it, execute
and live there, talk to other "agents" in there until its moved. Once
moved to a new cell, the agent must talk to his old agent friends though
the cloud interfaces. I guess more like a cell membrane than a universe.
But then again, the universe is just membranes... On a macro scale,
clouds can be organized into structures, the structures are defined 2
ways, external binding and intrinsic bindings embedded in the "agents".
All which is constrained by management policies (security, QOS,
authorization).

Maybe eventually, the cloud networks will be come self-organizing, like
slime molds.

Or it can become self aware; try to wipe out mankind; send a robot back
in time to terminate the mother of the resistance leader... Sounds like
there could be a movie script in there someplace.. lol

gm



JP Morgenthal wrote:
> funny, i just got to read Krishna's posts and he sees cloud inside
> grid, whereas I stated I see grid inside cloud. Hmmmm. You say
> pot-a-to I say pot-ah-to! Sounds like SOA all over again! :-)
> -----------------------------------------------
> JP Morgenthal
> cell : 703-554-5301
> email: jpmorg...@gmail.com <mailto:jpmorg...@gmail.com>
> email: m...@jpmorgenthal.com <mailto:m...@jpmorgenthal.com>
> twitter: www.twitter.com/jpmorgenthal
> <http://www.twitter.com/jpmorgenthal>
> blog: www.jpmorgenthal.com/morgenthal
> <http://www.jpmorgenthal.com/morgenthal>
>
>
> On Wed, Feb 11, 2009 at 12:12 PM, Krishna Sankar (ksankar)
> <ksa...@cisco.com <mailto:ksa...@cisco.com>> wrote:
>
> Matt,
>
>
>
> I have two blogs on this topic (and couple of
> pointers to papers) -
> http://doubleclix.wordpress.com/2008/08/03/cloud-computing-and-grids/
> and
> http://doubleclix.wordpress.com/2008/09/23/cloud-computing-grids-and-paczkis-part-deux/
>
>
>
> The short answer is elasticity and multi-tenancy
> as well as the ability to run your own application stack. I am
> also of the opinion that grids focused on scheduling and resource
> allocation while clouds focus on scalability. Another difference,
> IMHO, is that grids focused on computing tasks while clouds focus
> on normal IT applications.
>
>
>
> Having said that there is a finite possibility that Cloud domain
> could go the way of grids or SOA – especially if we start
> generating 100s of standards ;o(. I am not saying grids are not
> useful but most probably didn't catch mainstream adoption.
>
>
>
> Cheers
>
> <k/>
>
>
>
> *From:* cloud...@googlegroups.com
> <mailto:cloud...@googlegroups.com>
> [mailto:cloud...@googlegroups.com
> <mailto:cloud...@googlegroups.com>] *On Behalf Of *Matthew Zito
> *Sent:* Wednesday, February 11, 2009 8:08 AM
> *To:* cloud...@googlegroups.com <mailto:cloud...@googlegroups.com>
> *Subject:* RE: Cloud Computing Nukes the Fridge...
>
>
>
> See, my problem with this kind of talk is you can go s/cloud/grid/
> and you're talking about the cycle of what was described back in
> 2002-2003 when Grid was at the peak of its hype cycle. There were
> a pile of companies that were looking to make money off of both
> internal and external compute grids, and many of these companies
> have now just repositioned their businesses as Cloud offerings.
>
>
>
> What is different about the cloud, as compared to "the grid", such
> that the concept will live up to the hype this time?
>
>
>
> Thanks,
>
> Matt
>
>
>
> ------------------------------------------------------------------------
>
> *From:* cloud...@googlegroups.com
> <mailto:cloud...@googlegroups.com>
> [mailto:cloud...@googlegroups.com
> <mailto:cloud...@googlegroups.com>] *On Behalf Of *Pat Wendorf
> *Sent:* Wednesday, February 11, 2009 11:05 AM
> *To:* cloud...@googlegroups.com <mailto:cloud...@googlegroups.com>
> *Subject:* Re: Cloud Computing Nukes the Fridge...
> <mailto:christophe...@gmail.com>> wrote:
>
> Gang, I've gone dark on this group for a while but have been
> trying to keep up as best I can.
>
> One reason is that I've been busy with other things, but another
> is that it seems that a lot of the topics here are replays of ones
> that come up over and over again.
>
> 'What is Cloud Computing', for example.
>
> That by itself doesn't bother me, but when I read Reuven's 'Hybrid
> Cloud Multiverse' post I just couldn't take it any longer.
>
> Within days of the dust settling on the 'Cloud Ontology'
> discussion, he throws the whole thing open again with a cloud
> 'multiverse'.
>
> "The cloud is a kind of "multiverse
> <http://en.wikipedia.org/wiki/Multiverse>" where the rules of
> nature can continually be rewritten using quarantined virtual
> worlds within other virtual worlds"
>
> Huh?? What the heck are you talking about?
>
> Reuven, you're super smart, and are (obviously) passionate about
> cloud computing, but let me tell you something. You are WAY AHEAD
> of users on this. Not just the laggards, or the majority, or even
> the early adopters. You're ahead of everyone.
>
> I might be going out a limb here, but I'm going to predict that
> Cloud Computing isn't going to rewrite the rules of nature.
>
> Gang, like it or not, to the overwhelming majority: Cloud
> Computing = Google.
>
> To the slightly more knowledgeable: Cloud Computing =
> Salesforce.com (SaaS)
>
> The sophisticated: Cloud Computing = AWS (and their ilk).
>
> Multiverse aside, even the IPv6 issue is front running even the
> most sophisticated practitioner of cloud computing. I don't want
> to seem like the crotchety old man, but let me tell you kids
> something:
>
> 20 yrs ago (I'm not kidding), I was in discussions with people
> about about the imminent collapse of the ARPANET because of
> address space exhaustion
> <http://en.wikipedia.org/wiki/IPv4_address_exhaustion>. This was
> right around the time we were building the MIPS R4000
> <http://en.wikipedia.org/wiki/MIPS_architecture> with 64 bit

JP Morgenthal

unread,
Feb 11, 2009, 2:16:35 PM2/11/09
to cloud...@googlegroups.com
For me, grid = redundancy and fault tolerance because of it's ancestry.  The idea of the grid comes from traffic and energy grids, where there is no single point of failure.  If one part of the grid goes down the grid continues to operate.  You can design a cloud to offer this level of service, or you can design a cloud to scale linearly, but not be redundant.

I don't know where you're getting job scheduling and distribution as grid artifacts, but it sounds like you've been smoking too much of your own company's marketing literature. ;-)


JP
-----------------------------------------------
JP Morgenthal
cell : 703-554-5301
email: jpmorg...@gmail.com
email: m...@jpmorgenthal.com
twitter: www.twitter.com/jpmorgenthal
blog: www.jpmorgenthal.com/morgenthal


Krishna Sankar (ksankar)

unread,
Feb 11, 2009, 5:40:19 PM2/11/09
to cloud...@googlegroups.com

JP,

Come on JP, you can do better than that (may be not ;o)). Let us leave the company I work and marketing out of it. And what makes you think that I need marketing to make an opinion, Yikes … ;o)

 

Anyway, agreed on the analogy with electric grids. I think cloud has more synergy with telecom systems and am a big fan of Erlang as a cloud substrate.

 

But going back to the original question Matt asked, is redundancy the killer app for clouds ?

Andrew Badera

unread,
Feb 11, 2009, 5:43:59 PM2/11/09
to cloud...@googlegroups.com
I think scalability and affordability are the cloud's killer apps, with data redundancy close behind. Operational redundancy, not so much.

Thanks-
- Andy Badera
- and...@badera.us
- (518) 641-1280
- Tech Valley Code Camp 2009.1: http://www.techvalleycodecamp.com/
- Google me: http://www.google.com/search?q=andrew+badera

Krishna Sankar (ksankar)

unread,
Feb 11, 2009, 6:01:03 PM2/11/09
to cloud...@googlegroups.com

Or as Bezos put it, someone else “handling the muck” so that companies can focus on their core business.

 

Cheers

<k/>

Jayson Vantuyl

unread,
Feb 11, 2009, 6:41:52 PM2/11/09
to Cloud Computing Interoperability Forum (CCIF)
Cloud Computing is rewriting the rules of application development.
It's a mistake to see it as anything that's new. It's basically the
confluence of:

1. Distributed Applications
2. The Ubiquitous Internet
3. Elastic Infrastructure

The "grid" was 1 + 2. The elasticity distinction is interesting
because infrastructure has always been elastic. When you need a
machine, just have Bob install one. Poof, elastic. The problem was
that it always took really long to do so. It turns out, that this
still isn't really any more elastic. You just pay an "elastic
provider" to have wasted infrastructure that you can "elastically"
expand into, and trust them to amortize the risk of exhaustion over
all of their customers and grow appropriately.

In the end, this doesn't change anything concrete, just how people use
things. We've been pushing #1 for years. #2 made it more useful. #3
stands to drive it home. However, in the end, what we're really
witnessing is the promise of Distributed Applications finally being
delivered.

The rest of the talk is usually just heat and light, not the real
work.

On a side note, IP portability is needed to allow the Internet to be
delivered as intended. Otherwise, fast-moving hosts can't maintain
persistent connections. DNS doesn't really resolve this, so much as
provide a crude way to try to keep up. That said, it probably isn't
going to be a driving force in Cloud Computing for any particular
reason that I can identify.

Also, I challenge the statement that AWS == Cloud for "the
sophisticated". AWS == "shared-nothing delivered", which is one
definition of scalable, but isn't necessarily the only (or best) way
to deliver all applications in the Cloud.

fzap...@gmail.com

unread,
Feb 11, 2009, 7:10:38 PM2/11/09
to cloud...@googlegroups.com
Chris,

Thanks for saying this.

Are you doing anything in and for the Cloud?

I am finding the cloud elastic, as you might see from my linked in profile.

Regards,
Fred


Sent via BlackBerry by AT&T


From: Chris Marino
Date: Wed, 11 Feb 2009 07:05:12 -0800
To: <cloud...@googlegroups.com>
Subject: Cloud Computing Nukes the Fridge...

Drue Reeves

unread,
Feb 12, 2009, 2:28:38 AM2/12/09
to cloud...@googlegroups.com

I have to agree with Chris here. Just when it seemed we were about to have a serious discussion on cloud definition, we’re thrown into questions about “multiverse” and “grid”.

 

So far it seems people are intent on stating that the cloud isn’t anything new, it’s simply a new spin on “grid” or “hosting” or “utility computing”. Perhaps this is all true, but does it REALLY matter?!? I don’t care if the cloud is a relabeling of 14 different ideas – the point is – the “cloud” is what they are calling it now. Trying to stop the industry from using the term “cloud” is like trying to hold back the tide. Folks, Pandora’s box has been opened. If you want to shout at the wind and say that the cloud is nothing more than a grid, then be my guest, but it won’t help this forum reach interoperability.

 

So, rather than trying to re-label “cloud” or define what the cloud is not, let’s start defining what it is.

 

If we can’t do that, I don’t think this forum will last much longer. Rest assured, time is of the essence.

 

Drue

 

From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Chris Marino
Sent: Wednesday, February 11, 2009 9:05 AM
To: cloud...@googlegroups.com
Subject: Cloud Computing Nukes the Fridge...

 

Gang, I've gone dark on this group for a while but have been trying to keep up as best I can.

Srinivas Vedula

unread,
Feb 12, 2009, 3:04:06 AM2/12/09
to cloud...@googlegroups.com
Chris put my frustration with this group in words. The group started out fine but never had a single thread of worthy discussion. I alluded to defining the objective of the group in my last email but it never happened.

The point is the group's aim is to create interoperability specifications. It does not matter what cloud is. We just have to come up with the cases which need to be interoperable.

Reuven is great to start discussions but he always talks from a 10000 foot view or at a very low level about XMPP and IPv6. Nothing in between. I agree with Drue, time is of the essence.

- Srinivas

Schliesser, Benson

unread,
Feb 12, 2009, 4:22:23 AM2/12/09
to cloud...@googlegroups.com
Forgive me for being repetitive, but we need to organize some leadership structure if we hope to accomplish anything meaningful as the CCIF.
 
It appears to me that we have rough consensus over the need to create an ontology. And it appears to me that we all want the ontology to translate into a universal interface of some sort. If I'm not mistaken, many of the most ardent arguments have revolved around semantics and technical preferences, not the fundamental goals.
 
So what is the next step toward organizing those goals into charters, milestones, and working teams? Ruv may be the founder and most vocal CCIF member, but he can't do this entirely on his own. We need to organize democratically now to build a self-sustaining organization.
 
I'm no organizational expert, so I hope other folks chime in here. But my suggestion is that we elect an architecture team with the 2-part charter of a) identifying sub-architectural working groups that need to be formed, and b) acting as editors of an evolving high-level ontology.
 
At some point we need to agree on methods and procedures, but too much focus on procedure too early in the work cycle is just red-tape in my opinion and would drown us all. Process will evolve on its own if the work's quality is deserving.
 
The only bit of procedure that we need right now is a way of gathering and validating votes for the initial architecture team. My suggestion here is that a small group of volunteers, none of whom will be eligible for leadership positions at this time, run the election. Perhaps a sign-up "page" for election volunteers is called for?
 
Please comment. I'm offering these thoughts to spur conversation, so flame away.
 
Cheers,
-Benson
 
 


From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Srinivas Vedula
Sent: Thursday, February 12, 2009 2:04 AM
To: cloud...@googlegroups.com
Subject: Re: Cloud Computing Nukes the Fridge...

Reuven Cohen

unread,
Feb 12, 2009, 9:46:31 AM2/12/09
to cloud...@googlegroups.com
On Thu, Feb 12, 2009 at 4:22 AM, Schliesser, Benson <ben...@savvis.net> wrote:
Forgive me for being repetitive, but we need to organize some leadership structure if we hope to accomplish anything meaningful as the CCIF.
 
It appears to me that we have rough consensus over the need to create an ontology. And it appears to me that we all want the ontology to translate into a universal interface of some sort. If I'm not mistaken, many of the most ardent arguments have revolved around semantics and technical preferences, not the fundamental goals.
 
So what is the next step toward organizing those goals into charters, milestones, and working teams? Ruv may be the founder and most vocal CCIF member, but he can't do this entirely on his own. We need to organize democratically now to build a self-sustaining organization.
 
I'm no organizational expert, so I hope other folks chime in here. But my suggestion is that we elect an architecture team with the 2-part charter of a) identifying sub-architectural working groups that need to be formed, and b) acting as editors of an evolving high-level ontology.
 
At some point we need to agree on methods and procedures, but too much focus on procedure too early in the work cycle is just red-tape in my opinion and would drown us all. Process will evolve on its own if the work's quality is deserving.
 
The only bit of procedure that we need right now is a way of gathering and validating votes for the initial architecture team. My suggestion here is that a small group of volunteers, none of whom will be eligible for leadership positions at this time, run the election. Perhaps a sign-up "page" for election volunteers is called for?
 
Please comment. I'm offering these thoughts to spur conversation, so flame away.
 
Cheers,
-Benson
 
 

Sorry for my delayed response, I've been at conference.

To be clear, my mission for the CCIF is to drive the discussion for the potential of cloud interoperability. I will admit my ideas may sometime be "out there" and possibly overly verbose. But in fairness, as Benson said, I can't do this alone, nor do I want to. If your first post to this group is to do nothing more then complain, then you're adding even less then I am.

My suggestion is rather then writing a long winded post about how my ideas are totally wrong, why not instead contribute something new, original and worthwhile. Sure great stuff happened 20 years ago, I'm more concerned with what will happen 2 years from now.

As for the formal organizational structure, David Bernstein, Jesse Silver, Dave Nielsen, Steve Diamond and a few others have been working with me with the goal of creating a self-sustaining organization for the CCIF and CloudCamp. There will be some big announcements coming soon., I promise.

ruv

Gary Mazzaferro

unread,
Feb 12, 2009, 12:39:06 PM2/12/09
to cloud...@googlegroups.com
Hi All,

I'm still living VC hell... So, my company is still stealth..

In some discussions, there seems to be much confusion about what this
group is doing, the scope of the effort and process for defining the
specification.

Ruv has done a great job forming a body in a completely open forum. As
far as I know, that is the first time its happened this way. Cudos to
Ruv for this effort.
Because the body is starting up in a an open forum and new comers are
joining regularly, there is going to be some additional confusion in the
first weeks.

I'd like to clarify four items/issues already addressed and shows this
"soon to be formalized body" is making progress:

Mission Statement:
Ruv has done a great job at defining the mission for this group, you can
read it here: http://www.cloudforum.org/about
If anything is missing or the scope is too broad or something in the
statement needs clarification, that is another discussion.

Formalizing the Organization:
Ruv mentioned the organization would be incorporated by the end of the
month in CA. I had offered to incorporate in CO this week. If anyone is
interested, I'll can have the articles of incorporation and bylaws out
by Monday. We need an "official name" for the corporation and will need
to file for 501.3C status with the IRS. I may still have the IRS forms I
submitted for another standards body, or my lawyer does. I'll check. We
need an Intellectual Property Release for members, so contributors will
require to be members. This will help alleviate any patent infringement
complications for implementors. I haven't provided those docs before, so
I don't have a copy to leverage. Anyone that does, I'm sure it would be
welcomed as a starting point for review by an attorney.

Working structure:
We are still defining working groups, there is a sign up form for
working groups located at:
http://groups.google.com/group/cloudforum/web/uci-working-group-signup

The Specification:
Ruv has also taken a first swipe at the spec, or at least the front
matter. Nice work Ruv !!! You can read it here:
http://code.google.com/p/unifiedcloud/wiki/UCI_Requirements
Everyone has a different view of what cloud computing is and how it
should be structured. IMHO, every is right and no one is wrong. That's
a tough statement for some to accept and its easy to see why, it makes
this effort seem ambiguous. We should end up with definition and model
that is very conventional and easy to understand. We won't know the
outcome until there is a formal discussion. Last week, I had promised
to start working on the "basic abstraction model" at the end of this
week. I've just started shifting gears today, so its making progress.

cheers,

Gary

David Bernstein (daberns)

unread,
Feb 12, 2009, 12:55:54 PM2/12/09
to cloud...@googlegroups.com
Hi Gary and Others

Just a note on legal stature of CCIF and so on. I'd suggest, companies
such as mine (Cisco) are really picky about all these details,
covenants, governance, IP intermingling provisions, umbrella cross
licensing of embedded intellectual property, etc etc, are land mines. We
are no different from Intel, IBM, SUN, or any other big company. There
are professional organizations like Open Group and IEEE who have turnkey
way to make this happen which address all the "big company" concerns.
Please don't try to reinvent the wheel here. If CCIF is to become a
success, we must not be amateur in the formation. A number of us larger
companies have been discussing this already, as you might have
suspected, I'd suggest, just hang on, let that process percolate so we
can make sure this accidentally isn't a "startups only" venue.

Thank You

-----Original Message-----
From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com]
On Behalf Of Gary Mazzaferro
Sent: Thursday, February 12, 2009 9:39 AM
To: cloud...@googlegroups.com
Subject: Re: Cloud Computing Nukes the Fridge...


Matthew Zito

unread,
Feb 12, 2009, 1:35:56 PM2/12/09
to cloud...@googlegroups.com
I agree - there's already a pile of groups that know how to deal with
these kinds of things. In addition to David's, there's the IETF and the
Open Grid Forum, which even says in its mission statement:

" OGF is an open community committed to driving the rapid evolution and
adoption of applied distributed computing. Applied Distributed Computing
is critical to developing new, innovative and scalable applications and
infrastructures that are essential to productivity in the enterprise and
within the science community."

Sounds like it's right up our alley. Why reinvent the wheel?

Matt

Reuven Cohen

unread,
Feb 12, 2009, 1:56:12 PM2/12/09
to cloud...@googlegroups.com, cr...@mhbackup.aero.org

I've been chatting with Craig Lee from the Open Grid Forum as well as a few other related standards groups about potential strategic opportunities in order to leverage our industry momentum.

I'm open to any other suggestions.

r/c

Gary Mazzaferro

unread,
Feb 12, 2009, 2:59:36 PM2/12/09
to cloud...@googlegroups.com
Hi,

I didn't want to seem pushy and recommend we immediately join one of the
larger organizations. I'm glad someone else mentioned it.

Sometimes it takes time to get accepted by these groups, more time than
what we have. Its already been mentioned to me privately, we need to
have an organization in place quickly. In the next week, other
established organizations will be asked the question about their actions
on cloud interoperability. We need to legitimize, press release and join
an existing standards organization. Then, we can continue to develop
relationships with the larger companies.

My previous comments about the "openness" of this body's startup process
was inferring to these issues. I guess I should be more direct, but I
don't want to appear I'm hijacking this process.

IMHO, we need to select a group closely aligned with the mission of this
body AND has broad industry traction.

The OGF has good alignment to our mission. I would prefer to see this
effort in the OMG, but IETF, ECMA, OASIS or anyone else that will take
us QUICKLY is OK by me.

-gary

Drue Reeves

unread,
Feb 12, 2009, 3:36:14 PM2/12/09
to cloud...@googlegroups.com
Agreed. Using another group to get up to speed is ideal. The gentleman from Cisco is absolutely correct, companies of that size will not participate in this type of forum without legal protection of their IP. At both HP and Dell, we had the same issue.

Couple of concerns to keep in mind:

1. Cost. Some of these groups require a hefty price tag for member companies to participate. There should, at least, be an individual membership fee that is very, very inexpensive so we don't shut out people who are trying to join.

2. Customer input. Some of these forums don't lend themselves well to taking customer input. Not including customers is usually where these standards make a mistake.

3. Alignment with the CCIF goal (Cloud interoperability). While the OGF may seem like a good place, it implies a cloud implementation. Does a cloud provider HAVE to use a grid to be deemed a cloud? Seems like that's what our alignment with OGF would imply. I don't think that's the case. Doesn't matter if the service provider is using carrier pigeons as their underlying infrastructure...as long as they are able to meet the delivery model and service requirements for cloud computing (which we define), then we shouldn't care. Shouldn't we align with someone who is interested in interoperability rather than implementation? Like W3C or DMTF? (although I will stipulate that W3C or DMTF have their own implications...like use XML or CIM). Is there a forum out there that would serve well without too many implications? OASIS?

You may find this is a moot point as I'll bet at least one of these organizations already has cloud computing interoperability on their radar.

Drue

-----Original Message-----
From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Gary Mazzaferro
Sent: Thursday, February 12, 2009 2:00 PM
To: cloud...@googlegroups.com

Drue Reeves

unread,
Feb 12, 2009, 3:39:58 PM2/12/09
to cloud...@googlegroups.com
Agreed on not reinventing the wheel, but it's the "grid" part of OGF that causes some hangup.

While the OGF's charter is written as very open...it's application is more towards grids, which implies an implementation. If this is OGF's true mission, why not call themselves ODCF (open distributed computing forum)?

Alignment is a *very* key issue. Choose wisely.

-----Original Message-----
From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Matthew Zito
Sent: Thursday, February 12, 2009 12:36 PM
To: cloud...@googlegroups.com

Mark A. Carlson

unread,
Feb 12, 2009, 3:43:52 PM2/12/09
to cloud...@googlegroups.com
Because Grid was the prior hot buzzword before Cloud came along?

-- mark
--
Mark A. Carlson
Sr. Architect

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

Matthew Zito

unread,
Feb 12, 2009, 3:45:30 PM2/12/09
to cloud...@googlegroups.com
Well, I think that the term "Grid" was chosen much like the term "Cloud"
was chosen - it's a buzzword that people have jumped on as representing
a set of yet-undefined technologies and opportunities.

"Grid" is no more an implementation term than "Cloud" is - it's simply a
set of technologies and concepts. I recently asked the question, "how
is cloud different than grid", and the responses were extremely varied
and inconsistent, even in terms of what people considered "grid". Some
people considered grid a subset of cloud, others that cloud is a type of
grid, I happen to think they're mostly equivalent other than semantic
differentiation.

If we're gonna give the "grid" folks grief about picking a
flavor-of-the-month buzzword, maybe we should rename this forum to the
"amorphous computing forum".

Alexis Richardson

unread,
Feb 12, 2009, 3:46:48 PM2/12/09
to cloud...@googlegroups.com
How about Open Buzzword Forum?

OK only kidding.

What's wrong with making this part of W3C?

paul....@gmail.com

unread,
Feb 12, 2009, 3:53:28 PM2/12/09
to cloud...@googlegroups.com
As a former chair of the OGF I'd just like to say that the organization is a reflection of it's members and participants. If this community chooses to collaborate within the context of the OGF then it would be very welcome and would, I expect, influence the character of the organization. And it may be a useful umbrella. But it is true that the majority of the organization has focussed on a particular application class. However they are concerned with many of the same issues - interoperability, collaboration, mapping distributed services onto distributed infrastructure. The name is an artifact in some sense and is not always easy to change based on the hype du jour. They did this once. Anyway I'd be very happy to engage in a short discussion to see if ogf and CCIF are a good fit. Without prejudice :o). This is about moving ccif forward and maximizing the chances of success.

Paul
Sent via BlackBerry by AT&T

-----Original Message-----
From: Drue Reeves <dre...@burtongroup.com>

Date: Thu, 12 Feb 2009 13:39:58
To: cloud...@googlegroups.com<cloud...@googlegroups.com>

Drue Reeves

unread,
Feb 12, 2009, 3:59:25 PM2/12/09
to cloud...@googlegroups.com

Heh.

 

Hardly the point…and you know it.

 

Expertise and the group’s real direction are important. When you join a group, you have to been keenly aware of what their ideology, backgrounds, and current standards are. Do you think that W3C would easily accept a change to meta-schema change to XSD? Or worse, would they support a completely new presentation protocol if cloud computing required it? Probably not.  Mark, perceptions matter. Put CCIF into OGF, would people start looking at the product of this group as a standard for grids…not clouds. Same thing for W3C, DMTF, or any other.

 

All I’m saying is choose wisely, because you’ll have to maneuver in that environment.

 

Drue

 

 

From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Mark A. Carlson
Sent: Thursday, February 12, 2009 2:44 PM
To: cloud...@googlegroups.com
Subject: Re: Legal Structure for CCIF

 

Because Grid was the prior hot buzzword before Cloud came along?

Drue Reeves

unread,
Feb 12, 2009, 4:14:45 PM2/12/09
to cloud...@googlegroups.com
Matt,

I think the term "grid" has more implementation implications than you're giving it credit for. We do have grids out in the market that conjure up an implementation, even if, people can't describe it very well. I think your term for "grid" is very broad if cloud and grid are equivalent. For example, how is Salesforce.com a grid? Grid may be a "best practice" to building a cloud service, but if a service provider creates a service without using a grid implementation (or something that clearly is not a grid) then, does that mean they aren't a cloud?

Color me naive, but I don't think this cloud term is going away any time soon. So putting the cloud under OGF could create more confusion without OGF changing its name or charter. People will ask, what's the difference between a cloud and a grid? I would answer by asking this question: Can you build a cloud service without a grid? Yes. So, why does a grid matter? Matters only a potential "best practice" to build a cloud.

The important part to cloud is the service characteristics. Define those....then you can create interoperability.

Drue

-----Original Message-----
From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Alexis Richardson
Sent: Thursday, February 12, 2009 2:47 PM
To: cloud...@googlegroups.com
Subject: Re: Legal Structure for CCIF


l...@aero.org

unread,
Feb 12, 2009, 5:43:06 PM2/12/09
to cloud...@googlegroups.com, Craig Lee


All,

I've been trying not to say anything -- but I've just gotta respond.

The original goal of "grids" was effective distributed computing,
albeit from the perspective of big science and HPC. As the field
evolved, however, we tried to generalize the notion of "grids".
(That's why the "g-word" does not appear in the OGF mission stmt
and we focus on "applied distributed computing".)

Wrt clouds, the grid "branding" will be the hardest thing to deal with.
We've discussed changing the name of OGF, and I actually have a
briefing slide I've publicly used where I go through some options:

Grid Forum <= historical start
Global Grid Forum
Open Grid Forum <= in current use
Open Cloud Forum?
Open Scaleable IT Forum?
Open Buzzword de Jour Forum?
Open "Chasing Bright, Shiny Objects" Forum?

Clearly I played this for a joke, but you get the idea. Rather than
throwing away the grid brand completely, we decided to informally
refer to OGF as an uninterpreted trigram, and broaden our scope.

That said, any "inter-cloud" environment is going to run into all the
same issues of discovery, security, reliability, portability,
interoperability, monitoring, accounting, data mgmt and job mgmt that
the grid community has. These could be issues even for a client
dealing with a single cloud provider. While people can argue
endlessly about the differences between "grid" and "cloud", there are
similar requirements in a lot of these areas.

The primary issues I see are branding and perception.

At a minimum, what I think will happen is that current grid operators
engaged in OGF will work to determine how dynamically provisioned
resources (i.e., clouds) and frameworks (e.g., map-reduce) can be
integrated into their existing systems. (Example: Steven Newhouse,
Technical Director of EGEE, has publicly said they will be integrating
some cloudbursting capability.)

Beyond that, I don't think there is any inherent limit on what could
be done at OGF. OGF has all the IPR ironed out (the lawyers for all
the corporate members did another review last year), and we have a
document process and series in place.

Pragmatically speaking, though, no one organization is going to do
everything, and these things grow up organically based on where people
feel most comfortable working. There is so much wide-spread activity
across so many organizations, however, that Bob Marcus and I are
putting together a "Cloud Coordination Summit" (with the tortured
acronym of SATCCI) in an effort to bring some sanity to the process.
The target date is March 23 at the OMG meeting in DC.

I look forward to working with everyone...

--Craig

P.S. OGF-25 is in Catania, Sicily, March 2-6, and is having a cloud camp
and a "grid to cloud" track. ;->
--
====================================================
Dr. Craig A. Lee, l...@aero.org
President, Open Grid Forum, www.ogf.org
Senior Scientist, High Performance Computing
The Aerospace Corporation, M1-102
2350 East El Segundo Blvd.
El Segundo, CA 90245 USA
voice: 310-336-1381
fax: 310-336-0613
http://www.aero.org

The Aerospace Corporation operates a non-profit,
federally funded research and development corporation.

Reuven Cohen

unread,
Feb 12, 2009, 6:06:43 PM2/12/09
to cloud...@googlegroups.com

I'm a big fan of the work Paul and Craig and others are doing at the Open Grid Forum, they have a keen grasp on both the problems and opportunities that "distributed computing" faces. I agree one of the biggest problems with the open grid forum is in one word, "Grid".  Cloud is hot, grid is not. But it's also interesting that over the last few years the OGF in a lot of ways have attempted to solve a lot of the same problems we have in cloud computing.

As a side note I could have just as easily called CCIF the Open Interoperability Forum, it's quickly becoming apparent that the problems of interoperability go far beyond just cloud computing.

r/c 

Mike DiPetrillo

unread,
Feb 12, 2009, 6:32:23 PM2/12/09
to Cloud Computing Interoperability Forum (CCIF)
> As a side note I could have just as easily called CCIF the Open
> Interoperability Forum, it's quickly becoming apparent that the problems of
> interoperability go far beyond just cloud computing.

You know, we still haven't defined what's trying to interoperate with
what. You say there are all of these huge interoperability issues but
what exactly are they? Fo me in my world something that needs to be
worked out is how does the infrastructure layer talk to the storage or
networking or firewalls or power units or other pieces of
infrastructure. That's what comes to my mind on interoperability.
Above the infrastructure you need to worry about things like how does
the management stack see or know about what's going on below in the
infrastructure stack.

Once you define some of these problems then you can start to think
about who should be working on them - not before.

So, let's try a new exercise. Let's all list out what our view is on
interoperability problems. After all, that's the whole goal of the
group, right? No more talk about what is and isn't cloud since cloud
is just about everything. No more detailed talk on the best solution
for the problems we haven't yet described. No more ontology or
taxonomy talk. Let's first get a handle on some problems. After that
we can group and model them. After that we can break into groups to
figure out the best way to solve them. Along the way we might just
find a good model and definition for cloud appear.

Sound fair? I'll brainstorm and create a new post with my thoughts on
problems. This will come from my view of the world (the datacenter).
We have a lot of great people here with other views so put down your
ideas and throw them out to the group. Someone take notes and start to
group together the problems and we be off and running on some real
work.

Sorry to be so frank but if we continue down our existing path of
finding our place in the universe then nothing will get done and an
already established standards body will create a cloud
interoperability group that has backing and organization and gone will
be the days of the CCIF.

Mike
----------------------------
Mike DiPetrillo
VMware
Email: mike...@mac.com or mi...@vmware.com
Twitter: mikedipetrillo
Blog: http://www.mikedipetrillo.com

Gary Mazzaferro

unread,
Feb 12, 2009, 6:38:12 PM2/12/09
to cloud...@googlegroups.com
Hi Mike,

I think you're asking to define the use cases and requirements. I that
correct ?

-gary

Mike DiPetrillo

unread,
Feb 12, 2009, 7:08:05 PM2/12/09
to Cloud Computing Interoperability Forum (CCIF)
Exactly. I think that would help us get to the next step. Define what
we're trying to solve and then go and solve it. A little brainstorming
around this will help us get started on our work. I think how we
define the cloud and the model will naturally evolve out of this.
Given that it's Darwin's birthday this is the same approach he took.
Came up with a hypothesis, studied to find out what the problem is and
if the hypothesis was right, and then published the model to glue it
all together. Not to go back to the scientific method but it helps.

We've come up with the hypothesis - there are interoperability
problems in computing (any type of computing). Now we go and do some
studying to prove that hypothesis by listing out those problems.
Finally we put it all together with a nice model.

scott radeztsky

unread,
Feb 12, 2009, 8:05:09 PM2/12/09
to cloud...@googlegroups.com
May I propose we consider two parallel and eventually converging
approaches?...one from framework->down, another interop problems->up?
My hope is that it lets folks think of or write about this space
(multiverse) from different perspectives (that match their experiences
or "how they think"), to inform and eventually meet in the middle.

one side of this was the source of my "what's the space (framework) of
the multiverse" post from yesterday...a proposal for a simplified view
of what are the things that help us define the boundaries of what we are
trying to interconnect:

cloud interaction types:
private interop w/private
private interop w/public (aka hybrid)
public interop w/public
etc

and then IssS / PaaS / SaaS layers add 3 more perturbations:

IaaS private interop w/ Iaas private
IaaS private interop w/ PaaS private
...
...
Saas public interop w/ SaaS public

the third side could consist of some patterns of domain architectures
and clouds to help us with some of these interfacces/interactions,
others are really first ascents.

if we don't have a way to commonly speak the parts we're trying to
connect, we'll never describe what part A needs to connect to which
piece B, much less the double click into the use case driving it...

not married to this framework, just advocating something as a draft to
shoot at.

Scott.
--
Scott Radeztsky, Ph.D.
Sun Principal Engineer
Chief Technologist, Americas Systems Engineering
Sun Microsystems, Inc.

(312) 952-6761 cell

* Customer First * Integrity * Respect for the Individual *
* Teamwork * Financial Success * Openness * Fun *

shishi...@orange-ftgroup.com

unread,
Feb 13, 2009, 4:42:34 PM2/13/09
to cloud...@googlegroups.com
I tend to agree with the differentiation that Krishna has defined.
 
One of the key issues I feel grid computing faced is the need to rewrite your applications to be ported to the grid, or essentially to be grid-enabled. You wouldn't typically take a web-app or other commonly used piece of software and try to grid enable it. This is also why grids are typically considered in the context of HPC, because you also don't want to partition that CPU but want to throw jobs at it that maximize the utilization of the processor. So multi-tenacy in grids, wasn't a desirable feature but it is a key feature in cloud, obviously enabled primarily with virtualization.
 
With Cloud computing, the ability to package the application stack, with all underlying dependencies including the OS, and create "appliances" gives a key notion of portability of applications that hasn't been that obvious in the grid world. This is a very basic capability that then allows for both elasticity and reliability. 
 
However, as grid frameworks evolve there is probably an interesting middle ground to be had. Grid schedulers and middleware are quite sophisticated and are able to adapt as cloud management tools. As this is happening, that divide is going to merge and I don't know which will end up inside the other. For example, things like discovery and accouting/metering type issues are quite relevant in both cases.
 
Now the case of hadoop is a particularly interesting one, as it has the elasticity features that we associate with cloud, but not multi-tenant. By saying hadoop is not multi-tenant, I mean each physical server typically contains one node inside the cluster. But if you consider hadoop clusters running on AWS, they are multi-tenant but that'a s function of the AWS cloud. But hadoop also posesses grid like characteristics as you need to create custom map-reduce software to use hadoop.
 
Thanks,

Shishir Garg
________________________________________________________
Confidential Document If you receive this mail in error, please discard and destroy immediately. Thanks.

 


From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Krishna Sankar (ksankar)
Sent: Wednesday, February 11, 2009 9:12 AM
To: cloud...@googlegroups.com
Subject: RE: Cloud Computing Nukes the Fridge...

Matt,

 

                I have two blogs on this topic (and couple of pointers to papers) - http://doubleclix.wordpress.com/2008/08/03/cloud-computing-and-grids/ and http://doubleclix.wordpress.com/2008/09/23/cloud-computing-grids-and-paczkis-part-deux/

 

                The short answer is elasticity and multi-tenancy as well as the ability to run your own application stack. I am also of the opinion that grids focused on scheduling and resource allocation while clouds focus on scalability. Another difference, IMHO, is that grids focused on computing tasks while clouds focus on normal IT applications.

 

Having said that there is a finite possibility that Cloud domain could go the way of grids or SOA – especially if we start generating 100s of standards ;o(. I am not saying grids are not useful but most probably didn’t catch mainstream adoption.

 

Cheers

<k/>

 

From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Matthew Zito
Sent: Wednesday, February 11, 2009 8:08 AM
To: cloud...@googlegroups.com
Subject: RE: Cloud Computing Nukes the Fridge...

 

See, my problem with this kind of talk is you can go s/cloud/grid/ and you’re talking about the cycle of what was described back in 2002-2003 when Grid was at the peak of its hype cycle.  There were a pile of companies that were looking to make money off of both internal and external compute grids, and many of these companies have now just repositioned their businesses as Cloud offerings.  

 

What is different about the cloud, as compared to “the grid”, such that the concept will live up to the hype this time?

 

Thanks,

Matt

 


From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf Of Pat Wendorf
Sent: Wednesday, February 11, 2009 11:05 AM
To: cloud...@googlegroups.com
Subject: Re: Cloud Computing Nukes the Fridge...

 

Normally a lurker here as well, but I'm getting the big picture here:

I don't think Ruv is talking specifically about the laws of nature and physics being re-written by a technological system, I think he's talking in the more abstract sense about where the cloud idea will eventually evolve into.

Right now, from the trenches of working in a cloud infrastructure company (full disclosure, I work for Ruv) the idea in most customers minds about cloud computing is service based systems that can be spun up/down as needed.  Our current take on this problem is a flexible clustered virtulization system.  Think one step above that:  Fully flexible, virtualized business infrastructure.  A system that allows the entire set of services a business needs to operate spun up/down as needed and priced as a utility.  This seems reasonable considering where cloud computing is going at the moment, and isn't a huge leap from where we are now.   Think one more step above that:  The entire set of internet resources (servers, hosts) acting as a "multiverse" of flexible resources where any service imaginable can connect and interact with any other service at some level of compatiblity.  All of these services being geogrpahically redunant, completely isolated (storage/processing/networking).  Now you have something a little more sci-fi and a little less here-and-now.  Every machine acts as a host and a participant for these isolated units of service and we finally fully utilize all the hardware/networking advances we've seen over the last 20 years from companies like Intel and Cisco.  Add onto that a fully ontologically relational way of representing this massive service cloud, and I think we're talking about something 1-2 steps behind what Ruv is talking about now ;)

- Pat

M. David Peterson

unread,
Feb 13, 2009, 7:19:36 PM2/13/09
to cloud...@googlegroups.com
Long time list lurker, first time poster, but as Reuven can attest, I'm certainly no stranger to the whole world of utility computing. While my time is at present time severely limited, this does seems like an interesting point to get involved with the conversation.  So, here we go :-)

On Thu, Feb 12, 2009 at 7:46 AM, Reuven Cohen <r...@enomaly.com> wrote:

To be clear, my mission for the CCIF is to drive the discussion for the potential of cloud interoperability.

And this is a /very/ real problem from both a web service-style interop and application portability perspective.  e.g.:

Web Service-style Interop
* Can I communicate with other web applications, regardless of the underlying ecosystem in which they live, using existing code and web service standards, and can they communicate with me just the same?

Application Portability
* Can I take an existing application that runs within my data center and/or within another grid, cloud, and/or application service provider and, with minimal effort, run that same application on a competing stack?

The above categories are two very distinct, very real problems, the first of which has a mature foundation of software standards, related libraries, and code bases that extend from those libraries.  While there's still some lingering arguments out there related to REST vs. SOAP/WS-*, for the most part we've reached the point where we've solved the cross-platform distributed application mash-up problem, a solution which embraces the diversity of our computing hardware and software universe by requiring only that we speak the web's minimal lingua franca power pack -- TCP/HTTP(S)/XML -- to be able to interop with one another.  

The second problem -- that of application portability -- is at a completely different point in its evolution, however.  While virtualization technologies facilitate the ability to take physical hardware and blur its physical constraints such that you can slice, dice, blend, and mix compute and storage units to deal with the expanding and contracting needs of any given use case, not every service provider looks at the general idea of utility computing -- that of using and paying for only the compute and storage units you need when you need them, and not using and paying for them when you don't -- with the same pair of rose-tinted glasses.  While with minimal effort it's possible to take most any pre-existing code base that runs on a pre-existing hardware/software stack and deploy it on top of the AWS stack, the same isn't true of both Google's AppEngine and MSFT's Windows Azure utility computing platforms. Yes, you only pay for what you need when you need it.  But you're required to completely re-architect, and in many cases, re-code your applications to take advantage of each platforms services and feature sets.  

There's advantages to doing so in both cases, just as there's advantages to moving away from the more traditional LAMP/WISP stacks to take advantage of what SimpleDB and SQS have to offer.  The disadvantage, of course, is that you lose application portability. And this is where the importance of efforts such as that in which Reuven et. al are proposing come into play:

Just as ODBC has played a crucial role in providing a well defined interop layer between disparate DB systems, and just as TCP/HTTP/XML has done the same for the world of web services, similar efforts are required to ensure that we -- as engineers, system integrators, software developers, IT managers, etc. -- have not only the ability to communicate with disparate systems using common protocols, but to move from one service provider to another and back again with minimal amounts of effort on our part.  If for no other reason (and there are several other reasons) spending the time to define the equivalent of ODBC and/or TCP/HTTP/XML for utility computing interop will help ensure that we maintain a vibrant and competitive utility computing marketplace where vendors can lure us in with pricing and features rather than tie us down via vendor lock-in.

I will admit my ideas may sometime be "out there"

You're a big thinker, Reuven. By its very definition, they /should/ be "out there." (and that's a /good/ thing.)

and possibly overly verbose.

My favorite language is XSLT. Verbosity is like candy to me! ;-)
 
But in fairness, as Benson said, I can't do this alone, nor do I want to.

You're not going to do all the work? That sucks! ;-) 

Well, if that's the attitude you're going to take, Reuven, I guess I'd best bite the bullet and throw my hat into the ring. How can I help? :-)

If your first post to this group is to do nothing more then complain, then you're adding even less then I am.

I /TOTALLY/ *ROCK* the "No Complaints Here" Casbah, huh?!  w00t! :-D

My suggestion is rather then writing a long winded post about how my ideas are totally wrong, why not instead contribute something new, original and worthwhile.

I'd like to propose we create a CCIF mascot: A white cloud with a silver lining named "Fluffy."

All in favor?  :-)

Sure great stuff happened 20 years ago,

Yep! For example, I got my drivers license almost 20 years ago to the day. Top that, Reuven Cohen! ;-)
 
I'm more concerned with what will happen 2 years from now.

Or 2 minutes from now, for that matter. 

As for the formal organizational structure, David Bernstein, Jesse Silver, Dave Nielsen, Steve Diamond and a few others have been working with me with the goal of creating a self-sustaining organization for the CCIF and CloudCamp.

What about "Fluffy"? You're just gonna leave him out in the cold and bitter skies to fend for himself? 

That sucks, Reuven Cohen! ;-)

There will be some big announcements coming soon., I promise.

Will any of those announcements include the re-inclusion of our beloved mascot into the CCIF fold? 'Cuz yeah, they oughta! 

Peace. :-)

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.d...@3rdandUrban.com | m.d...@amp.fm
Mobile: (206) 999-0588
http://3rdandUrban.com | http://amp.fm | http://broadcast.oreilly.com/m-david-peterson/

Reuven Cohen

unread,
Feb 13, 2009, 9:11:58 PM2/13/09
to cloud...@googlegroups.com
 Love the ODBC analogy! I'm going to make sure to include that in some of my upcoming preso's.

ruv

M. David Peterson

unread,
Feb 13, 2009, 10:21:54 PM2/13/09
to cloud...@googlegroups.com
On Fri, Feb 13, 2009 at 7:11 PM, Reuven Cohen <r...@enomaly.com> wrote:

 Love the ODBC analogy! I'm going to make sure to include that in some of my upcoming preso's.

Nice! :-) 

Michael Richardson

unread,
Feb 13, 2009, 11:34:24 PM2/13/09
to cloud...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


{I joined the list yesterday, but my career experience is a decade doing
with the Interop side of things for APIs/protocols}

>>>>> "M" == M David Peterson <xmlh...@gmail.com> writes:
M> take most any pre-existing code base that runs on a pre-existing
M> hardware/software stack and deploy it on top of the AWS stack,
M> the same isn't true of both Google's AppEngine and MSFT's Windows
M> Azure utility computing platforms. Yes, you only pay for what you

...

M> There's advantages to doing so in both cases, just as there's
M> advantages to moving away from the more traditional LAMP/WISP
M> stacks to take advantage of what SimpleDB and SQS have to offer.

With MSFT/.Net, MS says you can have a machine (will they release a
VM/virtual-appliance?) that will run identically.... be neat if google,
did the same thing.

Maybe we'll see SimpleDB or SQS in a VM... that might help with the
second kind of portability that you speak about.

I think that we can get revision 1 of portability of VMs at some base
level --- OVF is nice, but doesn't go anywhere near far enough yet.

M> part. If for no other reason (and there are several other
M> reasons) spending the time to define the equivalent of ODBC
M> and/or TCP/HTTP/XML for utility computing interop will help
M> ensure that we maintain a vibrant and competitive utility
M> computing marketplace where vendors can lure us in with pricing
M> and features rather than tie us down via vendor lock-in.

Hey, even if you feel that you'll only ever be with one vendor, a
specification will make it easier for that vendor to update their
environment in an intelligent way.

- --
] Y'avait une poule de jammé dans l'muffler!!!!!!!!! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSZZJy4CLcPvd0N1lAQIC0Qf/S2MVYOBnxC+VMkl/+LINmHJPZn2AIjzq
R8sdMpjpG4358hB+b6ci+atShQYtF7NoIdIisNTHvxeO3NYJsnbwCq914dKAu5dD
rq/Xc2db/5keIwP3uO9IS/YH8/NbP1h42ZQhfn9HFMG/Wpuo/ZwWJplnOOCKk477
xli3CKieaDDeV7gieva1CNSYrpa9/BuGI1NSyE6dbqhI3f3C3TzAveoIC6U0aTa5
BFC94JMHWewyXZCZw2tdHU46YPMYhvhXLYmAFPqF25n8ulQ1x+ftzfa+ZLL7631o
nLLGnVpr2vya55otgG69J5zhMCqgRnxoTjh2z9xFL8TC9otIC4RojA==
=xd3l
-----END PGP SIGNATURE-----

Franklin Naval

unread,
Feb 14, 2009, 4:47:59 PM2/14/09
to cloud...@googlegroups.com
Mascot thing sounds nice.  I know a logo designer.

-Franklin