Cloud Computing Nukes the Fridge...
Chris Marino
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
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
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
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
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
Lori Mac Vittie
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
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)
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
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
-----------------------------------------------
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
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
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
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)
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
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: 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/>
>
>
>
> <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...
>
> 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
> 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
JP Morgenthal
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)
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
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)
Or as Bezos put it, someone else “handling the muck” so that companies can focus on their core business.
Cheers
<k/>
Jayson Vantuyl
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
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
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
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
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
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
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)
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
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
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
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
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