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
Drue Reeves
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
-- mark
Matthew Zito
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
OK only kidding.
What's wrong with making this part of W3C?
paul....@gmail.com
Paul
From: Drue Reeves <dre...@burtongroup.com>
Date: Thu, 12 Feb 2009 13:39:58
To: cloud...@googlegroups.com<cloud...@googlegroups.com>
Drue Reeves
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
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
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
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
> Interoperability Forum, it's quickly becoming apparent that the problems of
> interoperability go far beyond just cloud computing.
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
I think you're asking to define the use cases and requirements. I that
correct ?
-gary
Mike DiPetrillo
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
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
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
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.
/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
ruv
M. David Peterson
Love the ODBC analogy! I'm going to make sure to include that in some of my upcoming preso's.
Michael Richardson
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
-Franklin
M. David Peterson
Mascot thing sounds nice. I know a logo designer.
M. David Peterson
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.