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
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.
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
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
-~----------~----~----~----~------~----~------~--~---
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
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.
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
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
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
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
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/>
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 ?
Or as Bezos put it, someone else “handling the muck” so that companies can focus on their core business.
Cheers
<k/>
Sent via BlackBerry by AT&T
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.
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...
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
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?
Shishir Garg
________________________________________________________
Confidential
Document – If you receive this mail in error,
please discard and destroy immediately. Thanks.
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
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.
Love the ODBC analogy! I'm going to make sure to include that in some of my upcoming preso's.
{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-----
Mascot thing sounds nice. I know a logo designer.
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.
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.