There have been some awesome discussions on this group and many
others, and every time I read or talk with someone I feel like things
are congealing into something more solid.
One thing that seems to be confusing a lot of different people are
some of the definitions regarding cloud computing, specifically
regarding the difference between, cloud, grid, rapid provisioning, and
cloud storage.
I would define Cloud Computing as the overarching concept of all of
the outsourced,rapid provisioning,pay-per-use services that exist
today - Ideally with a low barrier to entry and the ability to
automate your environment.
Grid Computing seems to be services that are extremely granular or
'lightweight clouds'. Pay per usage on a per request model, rather
than an hourly model. Eg: AppEngine
Rapid Provisioning would be services that are more 'heavyweight'. Pay
per usage on a time model, with the real benefit being getting your
service online quickly, and being able to turn it off when possible.
Eg: EC2.
Many providers fall in between these or combine each of their
elements. Do we attempt to define this scale, or simply keep
everything abstracted as a 'cloud'?
> There have been some awesome discussions on this group and many > others, and every time I read or talk with someone I feel like things > are congealing into something more solid.
I'm a new addition to this list, so I may have missed some of the discussion, but I don't feel that things are as clear as I would like them. I'm eager for them to get clearer and for some of the definitions to become standards, de facto or not.
> One thing that seems to be confusing a lot of different people are > some of the definitions regarding cloud computing, specifically > regarding the difference between, cloud, grid, rapid provisioning, and > cloud storage.
In looking at a number of the responses, I'm less inclined to 'stick to my guns' on some of my stance in that posting. I think I could be swayed, but I have a couple of major concerns.
The first is that using SaaS as the model for cloud services doesn't really make sense. The end-user is a non-technical user and the 'Software' in SaaS is generally a vertical app. Just about any product offering on the Internet is a 'service' by definition. I don't know that throwing 'aaS' on the end clarifies or confuses. aaS in relation to software makes sense because historically software is sold as a shrink wrapped package. So, juxtaposing Software with Service makes a lot of sense. But some other places I think it just confuses.
Second, the 'computing' part of 'cloud computing' bugs me as it implies computation/cpu cycles. I've seen folks try to carve out servers on-demand as 'cloud processing', but that's not any clearer. 'Cloud computing is being hijacked, a lot like the term 'hacker' was back in the day. It may be that 'cloud computing' is already too embedded into the mainstream, but I still feel that 'cloud services' makes more sense as the general umbrella with 'cloud computing' being servers on-demand.
> I would define Cloud Computing as the overarching concept of all of > the outsourced,rapid provisioning,pay-per-use services that exist > today - Ideally with a low barrier to entry and the ability to > automate your environment.
I like Cloud Services better, but I can live with Cloud Computing if this is the generally accepted terminology. I think an important notion is that they are 'self-service'.
> Grid Computing seems to be services that are extremely granular or > 'lightweight clouds'. Pay per usage on a per request model, rather > than an hourly model. Eg: AppEngine
I think Grid Computing is already pretty much defined, isn't it? Grids are HPC clusters for homogeneous massively parallel problems, right? I see grid technology as something that powers clouds and cloud services, not as a 'lightweight cloud'.
> Rapid Provisioning would be services that are more 'heavyweight'. Pay > per usage on a time model, with the real benefit being getting your > service online quickly, and being able to turn it off when possible. > Eg: EC2.
This is the first time I have heard this term.
> Many providers fall in between these or combine each of their > elements. Do we attempt to define this scale, or simply keep > everything abstracted as a 'cloud'?
I'm still stuck on drawing a line in the sand saying that 'cloud' services are small point services designed for developers to consume. Witness Google I/O, AWS marketing efforts, CloudCamp, Force.com, etc. It's all targeted at developers. The attempts to re-define SaaS as cloud or otherwise jump on the cloud bandwagon are just confusing to most folks.
Thanks,
--Randy
Randy Bias, chief tactician, neoTactics, Inc. (877) NEO-TKTX, ran...@neotactics.com
Tervor, the problem is that everyone seems to have their own prism through which to view the cloud. I'm not going to offer anything new here, but can point you to one definition that I liked and one that I hated.
>-----Original Message----- >From: cloud-computing@googlegroups.com >[mailto:cloud-computing@googlegroups.com] On Behalf Of trevoro >Sent: Tuesday, June 17, 2008 3:34 PM >To: Cloud Computing >Subject: Cloud Definitions
>There have been some awesome discussions on this group and >many others, and every time I read or talk with someone I feel >like things are congealing into something more solid.
>One thing that seems to be confusing a lot of different people >are some of the definitions regarding cloud computing, >specifically regarding the difference between, cloud, grid, >rapid provisioning, and cloud storage.
>I would define Cloud Computing as the overarching concept of >all of the outsourced,rapid provisioning,pay-per-use services >that exist today - Ideally with a low barrier to entry and the >ability to automate your environment.
>Grid Computing seems to be services that are extremely >granular or 'lightweight clouds'. Pay per usage on a per >request model, rather than an hourly model. Eg: AppEngine
>Rapid Provisioning would be services that are more >'heavyweight'. Pay per usage on a time model, with the real >benefit being getting your service online quickly, and being >able to turn it off when possible. >Eg: EC2.
>Many providers fall in between these or combine each of their >elements. Do we attempt to define this scale, or simply keep >everything abstracted as a 'cloud'?
Pretty good to re-visit the definition of Cloud Computing.
In addition to that of the previous mail, I think it may also be helpful to consider the following definition of Cloud. (quoted from IBM white paper on Cloud Computing -
*What is a cloud?* Cloud computing is a term used to describe *both a platform and type of application*.
A *cloud computing platform* dynamically provisions, configures, reconfigures, and deprovisions servers as needed. Servers in the cloud can be physical machines or virtual machines. Advanced clouds typically include other computing resources such as storage area networks (SANs), network equipment, firewall and other security devices. Cloud computing also describes *applications* that are extended to be accessible through the Internet. These cloud applications use large data centers and powerful servers that host Web applications and Web services. Anyone with a suitable Internet connection and a standard browser can access a cloud application.
*Definition*
A cloud is *a pool of virtualized computer resources*. A cloud can: • Host a variety of different workloads, including batch-style back-end jobs and interactive, user-facing applications • Allow workloads to be deployed and scaled-out quickly through the rapid provisioning of virtual machines or physical machines • Support redundant, self-recovering, highly scalable programming models that allow workloads to recover from many unavoidable hardware/software failures • Monitor resource use in real time to enable rebalancing of allocations when needed
Cloud computing environments support grid computing by quickly providing physical and virtual servers on which the grid applications can run. Cloud computing should not be confused with grid computing. *Grid computing involves dividing a large task into many smaller tasks that run* *in parallel on separate servers*. Grids require many computers, typically in the thousands, and commonly use servers, desktops, and laptops. *Clouds also support nongrid environments*, such as a three-tier Web architecture running standard or Web 2.0 applications. A cloud is more than a collection of computer resources because a cloud provides a mechanism to manage those resources. Management includes provisioning, change requests, reimaging, workload rebalancing, deprovisioning, and monitoring.
-----END QUOTE-----
Is this enough to make it clear? Or could/should we add more?
On Wed, Jun 18, 2008 at 7:34 AM, trevoro <trevo...@gmail.com> wrote:
> There have been some awesome discussions on this group and many > others, and every time I read or talk with someone I feel like things > are congealing into something more solid.
> One thing that seems to be confusing a lot of different people are > some of the definitions regarding cloud computing, specifically > regarding the difference between, cloud, grid, rapid provisioning, and > cloud storage.
> I would define Cloud Computing as the overarching concept of all of > the outsourced,rapid provisioning,pay-per-use services that exist > today - Ideally with a low barrier to entry and the ability to > automate your environment.
> Grid Computing seems to be services that are extremely granular or > 'lightweight clouds'. Pay per usage on a per request model, rather > than an hourly model. Eg: AppEngine
> Rapid Provisioning would be services that are more 'heavyweight'. Pay > per usage on a time model, with the real benefit being getting your > service online quickly, and being able to turn it off when possible. > Eg: EC2.
> Many providers fall in between these or combine each of their > elements. Do we attempt to define this scale, or simply keep > everything abstracted as a 'cloud'?
IMHO, you're clouding up the terms ;-). IMO, grid generally refers to
a flavor of technologies which usually has some kind of work
dispatcher that schedules work do be performed on various nodes.
Globus, platform lsf, datasynapse to name a few all share this common
pattern.
Over the years there was a new term spoken about called "enterprise
grid" which tried to stretch the term from the classic grid tools to
encompass broader dynamic infrastructures including rapid provisioning
etc. This never really seemed to stick, as a term - and the
technologies have been challenging.
When server virtualization made it to x86, many of these rapid
provisioning environments started to leverage the technology to
simplify and improve overall system reliability, predictability, and
manageability. In fact, I recall this being used by IBM for its
partners called the virtual loaner program back in 2003. The system
allowed partners to "borrow" a slice of a system-p server to test
their software. This was based on a hypervisor called p-hype.
Many adopters of this kind of rapid provisioning built self service
interfaces to allow end users to allocate and release resources on
demand. When Amazon offered this kind of service publicly, they
called it cloud computing.
The term cloud has been used to refer to web based systems and
services for some time. So cloud computing seems appropriate to
encompass some kind of virtual computing platform in the sky. To me
this means that the service running in the cloud must offer a means
for programmability - ok this gets vague. Virtual x86 machines are
certainly user programmable as is AppEx, Bungee, AppEngine, etc. What
about DabbleDB, QuickBase or Zoho? I think so. In fact, I think ning
or even g.ho.st are "programmable" computing platforms delivered as a
service running in the _cloud_.
In the end, this is just a word ;-). I think the more interesting
thing is to examine the services that are exposed/delivered from the
_cloud_. Infrastructure as a Service (IaaS) should include things
like storage, network and compute resources. Platform as a Service
(PaaS) would include slightly higher level services like bigtable,
simpledb, appex, or even SQS.
Sure the lines get blurred when we label them - but the key is the
service offering. IMHO, compute services that are highly reusable
should be standardized - e.g. VMs, Storage, SQS, bigtable, layer 2
partitioning (Vlans), router and firewall services, load balancing
services, caching services, storage volume services, SAN connectivity
services etc. In a sense, everything you find in a datacenter should
be virtualized and exposed programmatically. All this stuff is
already virtual and programmable - but all proprietary. Back in the
day, the OGSA might have created standardized interfaces for all these
data center resources. In fact there are products that expose this
kind of infrastructure as wsdm resources. Unfortunately WS_dum_ ;-)
got hosed and eclipsed by ws-man - oh well ;-).
So let's try again with restful http based, json, etc.
I'd like to see standardization work its way up the infrastructure and
application stack.
thoughts?
On Jun 17, 6:34 pm, trevoro <trevo...@gmail.com> wrote:
> There have been some awesome discussions on this group and many
> others, and every time I read or talk with someone I feel like things
> are congealing into something more solid.
> One thing that seems to be confusing a lot of different people are
> some of the definitions regarding cloud computing, specifically
> regarding the difference between, cloud, grid, rapid provisioning, and
> cloud storage.
> I would define Cloud Computing as the overarching concept of all of
> the outsourced,rapid provisioning,pay-per-use services that exist
> today - Ideally with a low barrier to entry and the ability to
> automate your environment.
> Grid Computing seems to be services that are extremely granular or
> 'lightweight clouds'. Pay per usage on a per request model, rather
> than an hourly model. Eg: AppEngine
> Rapid Provisioning would be services that are more 'heavyweight'. Pay
> per usage on a time model, with the real benefit being getting your
> service online quickly, and being able to turn it off when possible.
> Eg: EC2.
> Many providers fall in between these or combine each of their
> elements. Do we attempt to define this scale, or simply keep
> everything abstracted as a 'cloud'?
*What is Cloud Computing?* An emerging computing paradigm where data and services reside in massively scalable data centers and can be ubiquitously accessed from any connected devices over the internet.
*Characteristics of Cloud Computing:* + Virtual: Physical location and underlying infrastructure details are transparent to users + Scalable: Able to break complex workloads into pieces to be served across an incrementally expandable infrastructure + Efficient: Services Oriented Architecture for dynamic provisioning of shared compute resources + Flexible: Can serve a variety of workload types - both consumer and commercial
On Wed, Jun 18, 2008 at 9:44 AM, Brian MyungJune JUNG <
> Pretty good to re-visit the definition of Cloud Computing.
> In addition to that of the previous mail, > I think it may also be helpful to consider the following definition of > Cloud. > (quoted from IBM white paper on Cloud Computing -
> *What is a cloud?* > Cloud computing is a term used to describe *both a platform and type of > application*.
> A *cloud computing platform* dynamically provisions, configures, > reconfigures, and deprovisions servers as > needed. Servers in the cloud can be physical machines or virtual machines. > Advanced clouds > typically include other computing resources such as storage area networks > (SANs), network > equipment, firewall and other security devices. > Cloud computing also describes *applications* that are extended to be > accessible through the > Internet. These cloud applications use large data centers and powerful > servers that host Web > applications and Web services. Anyone with a suitable Internet connection > and a standard > browser can access a cloud application.
> *Definition*
> A cloud is *a pool of virtualized computer resources*. A cloud can: > • Host a variety of different workloads, including batch-style back-end > jobs and interactive, > user-facing applications > • Allow workloads to be deployed and scaled-out quickly through the rapid > provisioning of > virtual machines or physical machines > • Support redundant, self-recovering, highly scalable programming models > that allow > workloads to recover from many unavoidable hardware/software failures > • Monitor resource use in real time to enable rebalancing of allocations > when needed
> Cloud computing environments support grid computing by quickly providing > physical and virtual > servers on which the grid applications can run. Cloud computing should not > be confused with > grid computing. *Grid computing involves dividing a large task into many > smaller tasks that run* > *in parallel on separate servers*. Grids require many computers, typically > in the thousands, and > commonly use servers, desktops, and laptops. > *Clouds also support nongrid environments*, such as a three-tier Web > architecture running standard > or Web 2.0 applications. A cloud is more than a collection of computer > resources because a > cloud provides a mechanism to manage those resources. Management includes > provisioning, > change requests, reimaging, workload rebalancing, deprovisioning, and > monitoring.
> -----END QUOTE-----
> Is this enough to make it clear? > Or could/should we add more?
> Best regards, > Brian.
> On Wed, Jun 18, 2008 at 7:34 AM, trevoro <trevo...@gmail.com> wrote:
>> There have been some awesome discussions on this group and many >> others, and every time I read or talk with someone I feel like things >> are congealing into something more solid.
>> One thing that seems to be confusing a lot of different people are >> some of the definitions regarding cloud computing, specifically >> regarding the difference between, cloud, grid, rapid provisioning, and >> cloud storage.
>> I would define Cloud Computing as the overarching concept of all of >> the outsourced,rapid provisioning,pay-per-use services that exist >> today - Ideally with a low barrier to entry and the ability to >> automate your environment.
>> Grid Computing seems to be services that are extremely granular or >> 'lightweight clouds'. Pay per usage on a per request model, rather >> than an hourly model. Eg: AppEngine
>> Rapid Provisioning would be services that are more 'heavyweight'. Pay >> per usage on a time model, with the real benefit being getting your >> service online quickly, and being able to turn it off when possible. >> Eg: EC2.
>> Many providers fall in between these or combine each of their >> elements. Do we attempt to define this scale, or simply keep >> everything abstracted as a 'cloud'?
> Sure the lines get blurred when we label them - but the key > is the service offering. IMHO, compute services that are > highly reusable should be standardized - e.g. VMs, Storage, > SQS, bigtable, layer 2 partitioning (Vlans), router and > firewall services, load balancing services, caching > services, storage volume services, SAN connectivity services > etc. In a sense, everything you find in a datacenter should > be virtualized and exposed programmatically. All this stuff > is already virtual and programmable - but all proprietary. > Back in the day, the OGSA might have created standardized > interfaces for all these data center resources. In fact > there are products that expose this kind of infrastructure > as wsdm resources. Unfortunately WS_dum_ ;-)got hosed and > eclipsed by ws-man - oh well ;-).
> So let's try again with restful http based, json, etc.
> I'd like to see standardization work its way up the > infrastructure and application stack.
I think one of the problems here is that some cloud-based web services, particularly very scalable ones, such as databases are essentially defined by their limitations in material ways. Any standard that could be consistently and properly supported across most services may necessarily be so constrained that you lose most of your functionality or so broad that no one can reasonably implement the spec for fundamental architectural reasons. Finding a balance that people are happy with will be difficult, and at this stage in the game I think many types of services (like cloud database services) are so limited that it might be premature to define standards derived from the current weak implementations if the market is moving quickly -- you may lock out better ways.
Of course, standardization of interfaces does not imply practical portability, though it helps. There are plenty of examples where architectures behind the standard interface vary sufficiently that you end up writing for a specific architecture through the standard interface. (See: portability of SQL-based apps across databases that use different concurrency control models.) On the other hand, a lot of services should be effectively standardizable and it should be encouraged, but I think for some core services this will be harder than it sounds. Transparency of switching between cloud providers may be hard to come by even if the interfaces are the same.
Andrew,
When I wrote this I hedged a bit whether or not to include bigtable or
even SQS. I eventually decided to include them because they seem to
be widely reusable services. However, I would certainly prioritize
the lower level virtual data center resources like server, storage and
network services over these higher order services which could be
implemented on top of an organization of virtual data center
resources. Standardization of these lower level resources will make
it easier to build and deploy higher order systems. With time and
reuse, higher order services will emerge as dominant patterns
requiring standardization. By standardizing and providing open
implementations of these lower level services, it will help to promote
the use/reuse leading to the emergence of these higher order services.
Your point about locking out better ways is almost always true for
standardization. However, there's also theory that shows where
implementations are "good enough" standardization and componentization
will flourish. The corollary is also true that where the components
aren't good enough, they will not survive as standard components.
It's interesting that, for instance, that perhaps one reason for
vendors opting for higher level PaaS offerings like AppEngine simply
gets around the problem that server virtualization is not quite good
enough. For example, it's not uncommon for one VM to hog I/O
resources otherwise starving other VMs on the same host, for example.
Unfortunately, you're absolutely right that standardization does not
imply portability. All too often the standardization process becomes
a giant group compromise that allows parties to agree to disagree.
IMHO, that's a failure of the standardization process - it's no easy
task. IMHO, that's also why open source is an interesting way to
create de facto standards using a different "open process".
On Jun 18, 1:38 pm, Andrew Rogers <jr89...@yahoo.com> wrote:
> --- On Tue, 6/17/08, Tross <hook...@gmail.com> wrote:
> > Sure the lines get blurred when we label them - but the key
> > is the service offering. IMHO, compute services that are
> > highly reusable should be standardized - e.g. VMs, Storage,
> > SQS, bigtable, layer 2 partitioning (Vlans), router and
> > firewall services, load balancing services, caching
> > services, storage volume services, SAN connectivity services
> > etc. In a sense, everything you find in a datacenter should
> > be virtualized and exposed programmatically. All this stuff
> > is already virtual and programmable - but all proprietary.
> > Back in the day, the OGSA might have created standardized
> > interfaces for all these data center resources. In fact
> > there are products that expose this kind of infrastructure
> > as wsdm resources. Unfortunately WS_dum_ ;-)got hosed and
> > eclipsed by ws-man - oh well ;-).
> > So let's try again with restful http based, json, etc.
> > I'd like to see standardization work its way up the
> > infrastructure and application stack.
> I think one of the problems here is that some cloud-based web services, particularly very scalable ones, such as databases are essentially defined by their limitations in material ways. Any standard that could be consistently and properly supported across most services may necessarily be so constrained that you lose most of your functionality or so broad that no one can reasonably implement the spec for fundamental architectural reasons. Finding a balance that people are happy with will be difficult, and at this stage in the game I think many types of services (like cloud database services) are so limited that it might be premature to define standards derived from the current weak implementations if the market is moving quickly -- you may lock out better ways.
> Of course, standardization of interfaces does not imply practical portability, though it helps. There are plenty of examples where architectures behind the standard interface vary sufficiently that you end up writing for a specific architecture through the standard interface. (See: portability of SQL-based apps across databases that use different concurrency control models.) On the other hand, a lot of services should be effectively standardizable and it should be encouraged, but I think for some core services this will be harder than it sounds. Transparency of switching between cloud providers may be hard to come by even if the interfaces are the same.
From my experience in discussions with people from the grid community
it does not lead anywhere to discuss about the definition of the cloud
(as they will always tell you that it is only a relabeling of Ian
Fosters original definition of grid computing). A more interesting
approach to discuss the differences between grid and cloud was chosen
by the EGEE grid computing research group at CERN. They compared their
own EGEE grid implementation with the Amazon cloud implementation
EC2+S3 (which from their point of view is the core of the cloud).
You can read the paper here: https://edms.cern.ch/document/925013/
The major idea is that the cloud started off b/c it provides
interfaces that developers can easily use with their applications,
such as REST and BitTorrent. Imho this is an important point, since it
allows third party developers to build their own frameworks on top of
the cloud (such as Scalr), as some of my previous speakers already
pointed out. There are some more pros and cons listed in the paper but
I think that usability / API is the most important one (the cloud is a
developer-facing business).
The question about standardization is: what would be the incentive for
Amazon, Google et al. to allow people move away from their cloud. As I
understand it, they want to create a vendor lock-in situation. But
perhaps we will see initiatives like in the social network world with
OpenSocial and Facebook Open Platform.
> From my experience in discussions with people from the grid community > it does not lead anywhere to discuss about the definition of the cloud > (as they will always tell you that it is only a relabeling of Ian > Fosters original definition of grid computing). A more interesting > approach to discuss the differences between grid and cloud was chosen > by the EGEE grid computing research group at CERN. They compared their > own EGEE grid implementation with the Amazon cloud implementation > EC2+S3 (which from their point of view is the core of the cloud). > You can read the paper here: https://edms.cern.ch/document/925013/
> The major idea is that the cloud started off b/c it provides > interfaces that developers can easily use with their applications, > such as REST and BitTorrent. Imho this is an important point, since it > allows third party developers to build their own frameworks on top of > the cloud (such as Scalr), as some of my previous speakers already > pointed out. There are some more pros and cons listed in the paper but > I think that usability / API is the most important one (the cloud is a > developer-facing business).
> The question about standardization is: what would be the incentive for > Amazon, Google et al. to allow people move away from their cloud. As I > understand it, they want to create a vendor lock-in situation. But > perhaps we will see initiatives like in the social network world with > OpenSocial and Facebook Open Platform.
It is almost always true that vendors want to lock in their customers, but there is an equal or greater pressure from users not wanting that to happen. So long as there is lock-in via proprietary interfaces the market will remain small (take for instance the XAM standard for CAM devices). So economics come into a play: 100% of a small market isn't always better than some fraction of a larger market.
I don't think clouds came about because of REST or BitTorrent. I think clouds are just a logical extension of computing, in general. From stand alone, single application systems (aka DOS/360) to time sharing (Whirlwind, etc) to cluster, grids and now the amorphic idea of generic "clouds". Remember with Sun it was the network was the computer? Isn't that a cloud?
Markus Klems wrote: >>From my experience in discussions with people from the grid community > it does not lead anywhere to discuss about the definition of the cloud > (as they will always tell you that it is only a relabeling of Ian > Fosters original definition of grid computing). A more interesting > approach to discuss the differences between grid and cloud was chosen > by the EGEE grid computing research group at CERN. They compared their > own EGEE grid implementation with the Amazon cloud implementation > EC2+S3 (which from their point of view is the core of the cloud). > You can read the paper here: https://edms.cern.ch/document/925013/
> The major idea is that the cloud started off b/c it provides > interfaces that developers can easily use with their applications, > such as REST and BitTorrent. Imho this is an important point, since it > allows third party developers to build their own frameworks on top of > the cloud (such as Scalr), as some of my previous speakers already > pointed out. There are some more pros and cons listed in the paper but > I think that usability / API is the most important one (the cloud is a > developer-facing business).
> The question about standardization is: what would be the incentive for > Amazon, Google et al. to allow people move away from their cloud. As I > understand it, they want to create a vendor lock-in situation. But > perhaps we will see initiatives like in the social network world with > OpenSocial and Facebook Open Platform.
> I don't think clouds came about because of REST or BitTorrent. I think
> clouds are just a logical extension of computing, in general. From stand
> alone, single application systems (aka DOS/360) to time sharing
> (Whirlwind, etc) to cluster, grids and now the amorphic idea of generic
> "clouds". Remember with Sun it was the network was the computer? Isn't
> that a cloud?
Of course you are right that this isn't the only reason for cloud
success, although I still think that usability and simplicity is the
main factor that drives cloud computing.
Another interesting aspect pointed out in the paper is that clouds are
commercial - in contrast to typically public funded grids. The main
feature of Amazon EC2 is elasticity (to a certain degree), which is
made possible by mapping resource scalability to the scalability of
your credit card. This is something a grid cannot deliver because
normally resources must be added by a human operator.
"The question about standardization is: what would be the incentive for Amazon, Google et al. to allow people move away from their cloud. As I understand it, they want to create a vendor lock-in situation. "
IT sales experience shows that people join your party more easily if they feel that they can get away again. Once they are in inertia and good customer service work in favor of the vendor. Being standards based supports growth, you can always add convenience features later-on to increase the cost of switching.
> From my experience in discussions with people from the grid community > it does not lead anywhere to discuss about the definition of the cloud > (as they will always tell you that it is only a relabeling of Ian > Fosters original definition of grid computing). A more interesting > approach to discuss the differences between grid and cloud was chosen > by the EGEE grid computing research group at CERN. They compared their > own EGEE grid implementation with the Amazon cloud implementation > EC2+S3 (which from their point of view is the core of the cloud). > You can read the paper here: https://edms.cern.ch/document/925013/
> The major idea is that the cloud started off b/c it provides > interfaces that developers can easily use with their applications, > such as REST and BitTorrent. Imho this is an important point, since it > allows third party developers to build their own frameworks on top of > the cloud (such as Scalr), as some of my previous speakers already > pointed out. There are some more pros and cons listed in the paper but > I think that usability / API is the most important one (the cloud is a > developer-facing business).
> The question about standardization is: what would be the incentive for > Amazon, Google et al. to allow people move away from their cloud. As I > understand it, they want to create a vendor lock-in situation. But > perhaps we will see initiatives like in the social network world with > OpenSocial and Facebook Open Platform.
He was my guest in Feb. and this topic came up during his discussion with one of my students and he gave us some of his insights.
Generally, my understanding so far is that grid is "free" and encourages the use of "open standards", but cloud is for commercial purposes and approaches are mostly proprietary. They share several common challenges and problems.
I can be totally wrong and would be happy to learn more. Let me know if you think differently.
I am still catching up with all the discussion during the past few days that I have join this group.
Best, Masoud
------------------------------------------------------------------ Masoud Sadjadi, PhD Assistant Professor School of Computing and Information Sciences Florida International University University Park, ECS 212C 11200 SW 8th St., Miami, FL 33199
-----Original Message----- From: cloud-computing@googlegroups.com [mailto:cloud-computing@googlegroups.com] On Behalf Of Chris Marino Sent: Tuesday, June 17, 2008 8:20 PM To: cloud-computing@googlegroups.com Subject: RE: Cloud Definitions
Tervor, the problem is that everyone seems to have their own prism through which to view the cloud. I'm not going to offer anything new here, but can point you to one definition that I liked and one that I hated.
>-----Original Message----- >From: cloud-computing@googlegroups.com >[mailto:cloud-computing@googlegroups.com] On Behalf Of trevoro >Sent: Tuesday, June 17, 2008 3:34 PM >To: Cloud Computing >Subject: Cloud Definitions
>There have been some awesome discussions on this group and >many others, and every time I read or talk with someone I feel >like things are congealing into something more solid.
>One thing that seems to be confusing a lot of different people >are some of the definitions regarding cloud computing, >specifically regarding the difference between, cloud, grid, >rapid provisioning, and cloud storage.
>I would define Cloud Computing as the overarching concept of >all of the outsourced,rapid provisioning,pay-per-use services >that exist today - Ideally with a low barrier to entry and the >ability to automate your environment.
>Grid Computing seems to be services that are extremely >granular or 'lightweight clouds'. Pay per usage on a per >request model, rather than an hourly model. Eg: AppEngine
>Rapid Provisioning would be services that are more >'heavyweight'. Pay per usage on a time model, with the real >benefit being getting your service online quickly, and being >able to turn it off when possible. >Eg: EC2.
>Many providers fall in between these or combine each of their >elements. Do we attempt to define this scale, or simply keep >everything abstracted as a 'cloud'?
I think this threat has hit on most of the salient points:
- Grid is computing that scales out to many machines
- Virtualization is sandboxing of logical elements
- Cloud is the combination of grid and virtualization to create
computing resources that can be deployed self-service style
But the confusion comes because there's not only an "operations" cloud
-- which most of the discussions here reflect -- focused on scaling
operational elements (capacity, availability, etc.) but also a
"development" cloud, which is focused on re-usable components that
speed up development. Ultimately, these mean you can build on someone
else's platform faster and more easily than rolling your own.
This second one is where the contention comes from, IMHO: Many times,
a simple SaaS offering is labeled "cloud" because it's self-
provisioned; but unless it's also a platform that allows customization
(like Force.com) it's not really worth it.
I don't think free enters into it. There are open source platforms for
many clouds; and there are commercial grids (think render farms.)
But I do think the key element that distinguishes clouds from grids is
what distinguishes the Internet from a private network: When I throw
packets into the Internet, they come out the other side. I don't get
to care whether the net uses cans and string or mice with backpacks to
get the data there: Whatever's below my layer of abstraction is none
of my business. A new app can self-provision on the Internet (Skype
doesn't need permission [for now ;-)] to start using the net.) A
similar model exists for clouds, and it allows a greater level of
experimentation that its predecessors.
I'm gonna point to this one: http://refresh.gigaom.com/2008/06/18/do-you-know-what-kind-of-cloud-y... and throw myself on the mercy of the court; on the upside, I have the
unique privilege of talking to a bunch of cloud folks (Geva Perry at
GigaSpaces, Jason Hoffman at Joyent,
Tony Lucas at XCalibre, Lew Moorman at Rackspace, Christophe Bisciglia
at Google, and Joe Weinman at AT&T) at the Structure08 conference
( http://events.gigaom.com/structure/08/) next week, so I'm kinda
planning on asking them for their versions. Any other questions I
should throw at them? ;-)
> He was my guest in Feb. and this topic came up during his discussion with one of my students and he gave us some of his insights.
> Generally, my understanding so far is that grid is "free" and encourages the use of "open standards", but cloud is for commercial purposes and approaches are mostly proprietary. They share several common challenges and problems.
> I can be totally wrong and would be happy to learn more. Let me know if you think differently.
> I am still catching up with all the discussion during the past few days that I have join this group.
> Best,
> Masoud
> ------------------------------------------------------------------
> Masoud Sadjadi, PhD
> Assistant Professor
> School of Computing and Information Sciences
> Florida International University
> University Park, ECS 212C
> 11200 SW 8th St., Miami, FL 33199
>
> Email: sadj...@cs.fiu.edu
> Web: www.cs.fiu.edu/~sadjadi > Tel: 305-348-1835
> Fax: 305-348-2336
> ------------------------------------------------------------------
> -----Original Message-----
> From: cloud-computing@googlegroups.com [mailto:cloud-computing@googlegroups.com] On Behalf Of Chris Marino
> Sent: Tuesday, June 17, 2008 8:20 PM
> To: cloud-computing@googlegroups.com
> Subject: RE: Cloud Definitions
> Tervor, the problem is that everyone seems to have their own prism
> through which to view the cloud. I'm not going to offer anything new
> here, but can point you to one definition that I liked and one that I
> hated.
> >-----Original Message-----
> >From: cloud-computing@googlegroups.com
> >[mailto:cloud-computing@googlegroups.com] On Behalf Of trevoro
> >Sent: Tuesday, June 17, 2008 3:34 PM
> >To: Cloud Computing
> >Subject: Cloud Definitions
> >There have been some awesome discussions on this group and
> >many others, and every time I read or talk with someone I feel
> >like things are congealing into something more solid.
> >One thing that seems to be confusing a lot of different people
> >are some of the definitions regarding cloud computing,
> >specifically regarding the difference between, cloud, grid,
> >rapid provisioning, and cloud storage.
> >I would define Cloud Computing as the overarching concept of
> >all of the outsourced,rapid provisioning,pay-per-use services
> >that exist today - Ideally with a low barrier to entry and the
> >ability to automate your environment.
> >Grid Computing seems to be services that are extremely
> >granular or 'lightweight clouds'. Pay per usage on a per
> >request model, rather than an hourly model. Eg: AppEngine
> >Rapid Provisioning would be services that are more
> >'heavyweight'. Pay per usage on a time model, with the real
> >benefit being getting your service online quickly, and being
> >able to turn it off when possible.
> >Eg: EC2.
> >Many providers fall in between these or combine each of their
> >elements. Do we attempt to define this scale, or simply keep
> >everything abstracted as a 'cloud'?
This is almost a religious question these days. One of my recent
definitions was that, "cloud computing is a commercial extension of
utility computing that enables scalable, elastic, highly available
deployment of software applications while minimizing the level of
detailed interaction with the underlying technology stack itself."
I went into that in grand detail, defining all those various terms, in
the article "Get your head in the Clouds."
Kent
On Jun 17, 3:34 pm, trevoro <trevo...@gmail.com> wrote:
> There have been some awesome discussions on this group and many
> others, and every time I read or talk with someone I feel like things
> are congealing into something more solid.
> One thing that seems to be confusing a lot of different people are
> some of the definitions regarding cloud computing, specifically
> regarding the difference between, cloud, grid, rapid provisioning, and
> cloud storage.
> I would define Cloud Computing as the overarching concept of all of
> the outsourced,rapid provisioning,pay-per-use services that exist
> today - Ideally with a low barrier to entry and the ability to
> automate your environment.
> Grid Computing seems to be services that are extremely granular or
> 'lightweight clouds'. Pay per usage on a per request model, rather
> than an hourly model. Eg: AppEngine
> Rapid Provisioning would be services that are more 'heavyweight'. Pay
> per usage on a time model, with the real benefit being getting your
> service online quickly, and being able to turn it off when possible.
> Eg: EC2.
> Many providers fall in between these or combine each of their
> elements. Do we attempt to define this scale, or simply keep
> everything abstracted as a 'cloud'?
Cloud computing is one of those catch all buzz words that tries to encompass a variety of aspects ranging from deployment, load balancing, provisioning, business model and architecture (like web2.0). It's the next logical step in software (software 10.0). For me the simplest explanation for cloud computing is describing it as, "internet centric software". This new cloud computing software model is a shift from the traditional single tenant approach to software development to that of a scalable, multi-tenant, multi-platform, multi-network, and global one. This could be as simple as your web based email service or as complex as a globally distributed load balanced content delivery environment. I think drawing a distinction on whether its, PaaS, SaaS, HaaS is completely secondary, ultimately all these approaches are attempting to solve the same problems (Scale).
As software transitions from a traditional desktop deployment model to that of the a network & data centric one, "the cloud" will be the key way in which you develop, deploy and manage applications in this new computing paradigm.
On Tue, Jun 17, 2008 at 6:34 PM, trevoro <trevo...@gmail.com> wrote:
> There have been some awesome discussions on this group and many > others, and every time I read or talk with someone I feel like things > are congealing into something more solid.
> One thing that seems to be confusing a lot of different people are > some of the definitions regarding cloud computing, specifically > regarding the difference between, cloud, grid, rapid provisioning, and > cloud storage.
> I would define Cloud Computing as the overarching concept of all of > the outsourced,rapid provisioning,pay-per-use services that exist > today - Ideally with a low barrier to entry and the ability to > automate your environment.
> Grid Computing seems to be services that are extremely granular or > 'lightweight clouds'. Pay per usage on a per request model, rather > than an hourly model. Eg: AppEngine
> Rapid Provisioning would be services that are more 'heavyweight'. Pay > per usage on a time model, with the real benefit being getting your > service online quickly, and being able to turn it off when possible. > Eg: EC2.
> Many providers fall in between these or combine each of their > elements. Do we attempt to define this scale, or simply keep > everything abstracted as a 'cloud'?
> Cloud computing is one of those catch all buzz words that tries to > encompass a variety of aspects ranging from deployment, load > balancing, provisioning, business model and architecture (like > web2.0). It's the next logical step in software (software 10.0). For > me the simplest explanation for cloud computing is describing it as, > "internet centric software".
Thanks Reuven. I like this tack. It's interesting to think about cloud services as 'internet centric software'. I don't really think I agree that it's software, but maybe it's an 'internet centric software *process*'?
> As software transitions from a traditional desktop deployment model to > that of the a network & data centric one, "the cloud" will be the key > way in which you develop, deploy and manage applications in this new > computing paradigm.
Absolutely, although I feel like there is too much emphasis on 'scale' in the general community. I'm just as guilty as everyone else on this historically, I just see a lot more use cases with my current clients than 'scalability' and I think the 'scale' discussion masks a lot of other very interesting uses.
I think there is a particular focus on scale simply because if your application is static with little or no growth then cloud computing is not going to be very useful. Your probably better off just putting your app on a VPS or dedicated server. There are other cloud benefits, such as cost, speed, flexibility etc, but most of which all relate back to the scale.
On Sun, Jun 22, 2008 at 4:53 AM, Randy Bias <ran...@neotactics.com> wrote:
> On Jun 21, 2008, at 10:51 AM, Reuven Cohen wrote: >> Cloud computing is one of those catch all buzz words that tries to >> encompass a variety of aspects ranging from deployment, load >> balancing, provisioning, business model and architecture (like >> web2.0). It's the next logical step in software (software 10.0). For >> me the simplest explanation for cloud computing is describing it as, >> "internet centric software".
> Thanks Reuven. I like this tack. It's interesting to think about > cloud services as 'internet centric software'. I don't really think I > agree that it's software, but maybe it's an 'internet centric software > *process*'?
>> As software transitions from a traditional desktop deployment model to >> that of the a network & data centric one, "the cloud" will be the key >> way in which you develop, deploy and manage applications in this new >> computing paradigm.
> Absolutely, although I feel like there is too much emphasis on 'scale' > in the general community. I'm just as guilty as everyone else on this > historically, I just see a lot more use cases with my current clients > than 'scalability' and I think the 'scale' discussion masks a lot of > other very interesting uses.
--- On Sun, 6/22/08, Randy Bias <ran...@neotactics.com> wrote:
> Absolutely, although I feel like there is too much emphasis on > 'scale' in the general community. I'm just as guilty as everyone > else on this historically, I just see a lot more use cases with > my current clients than 'scalability' and I think the 'scale' > discussion masks a lot of other very interesting uses.
I think the emphasis on 'scale' is largely because we've already invested a lot in that aspect of the cloud and are starting to become good at it, in part because that was one of the major problems cloud-like technologies were invented to solve. But I very much agree that over the long term much of the value of the cloud will come from elsewhere as other aspects are more fully developed.
For me, I see the seamless and secure integration of data, service, apps, components, and analytics through market mechanisms inside and across the clouds as long term value of the cloud ecosystem, which has relatively little to do with 'scale' when you get down to it. Clouds will fundamentally change the basic architecture of the Internet, given time and development, and what we see at these nascent stages reflect their history and genesis rather than their direction.
--- On Thu, 6/19/08, Jim Peters <jazzman...@gmail.com> wrote:
> Isn't a compute cloud simply a set of documented interfaces, > with no idea how those interfaces are implemented?
In theory yes, and even in practice for many types of cloud services. However, for some types of performance/efficiency sensitive applications the result may vary by integer factors depending on whether or not the application is designed for that specific implementation even if using the standard interfaces. Even with standard interfaces, internal architectural design decisions will be reflected in the compute cloud behavior while running applications.
Conventional databases are a common example of this. The interface may be standard SQL, but how you write your queries and design your system will adversely impact performance depending on the internals of the database engine selected. The fast design on one database may be an order of magnitude slower on another, not due to intrinsic differences in performance capability but simply implementation tradeoffs, and app designers will internalize the tradeoffs implicit in the implementation even though they access it using standard interfaces.
In short, sometimes implementation matters regardless of interface standardization, other times it does not.
> I think there is a particular focus on scale simply because if your > application is static with little or no growth then cloud computing is > not going to be very useful. Your probably better off just putting > your app on a VPS or dedicated server. There are other cloud benefits, > such as cost, speed, flexibility etc, but most of which all relate > back to the scale.
Reuven, I don't agree. Cloud computing is useful for much more than scale. For example, I have a client who is leveraging EC2 for QA & testing. They need 100 servers for 24 hours a few times a month. This is a purely elastic use case. They don't grow the servers to a demand curve. Instead, they periodically bring up the 100 servers they need, run the task to completion, gather the results, and shut them down.
I am aware of many use cases like this. The Internet Archive has a similar situation, using 300+ servers every few months to crunch a large data set then turning them off. This is an extremely compelling set of use cases that is largely a greenfield. It's also impractical or impossible using VPS or dedicated hosting.
My interpretation is that you are using scale in the broadest sense possible, but I think that waters the meaning down too much. The very first sentence on Scalability in Wikipedia is exactly my meaning (http://en.wikipedia.org/wiki/Scalability ):
"In telecommunications and software engineering, scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged."
There are more use cases for clouds than just the ability to grow to meet a given workload. My example of a static no growth application that is simply turned on for 24 hours for the purposes of testing shows this. The customer in question has estimated they will save hundreds of thousands of dollars over a few years in OpEx and CapEx.
As I mentioned in the blog posting, there are a number of use cases that are not directly related to scalability. They are also not necessarily specific to cloud technology. For example, the cost savings are related to the utility charge model, not clouds themselves. It just so happens that most current clouds use the utility charge model; however, there is no guarantee it will stay this way in the future.
In the case of speed, it's a question of getting a server provisioned and running *now* so you can complete a project in the short term rather than waiting for corporate IT to complete a request. Signing a contract for a VPS or dedicated server is largely undesirable in these cases and likely to result in a delay.
Reach, the final use case, has yet to be seen as clouds are largely a U.S. phenomena, but I am aware of quite a few folks outside the U.S. using EC2 as a platform for delivering services to U.S.-based customers. The most obvious example being Morph (http://www.mor.ph/), who provide a management layer on top of EC2, but are based in the Philippines. As more clouds appear globally, the mobility of infrastructure will not only become important, but critical to competing effectively.
IMO, the most important feature of clouds are the on-demand and rental nature, not enabling a particular application to scale.
----- Original Message ---- From: Randy Bias <ran...@neotactics.com> To: cloud-computing@googlegroups.com Sent: Sunday, June 22, 2008 8:43:36 PM Subject: Re: Cloud Definitions
On Jun 22, 2008, at 8:09 AM, Reuven Cohen wrote: > I think there is a particular focus on scale simply because if your > application is static with little or no growth then cloud computing is > not going to be very useful. Your probably better off just putting > your app on a VPS or dedicated server. There are other cloud benefits, > such as cost, speed, flexibility etc, but most of which all relate > back to the scale.
Reuven, I don't agree. Cloud computing is useful for much more than scale. For example, I have a client who is leveraging EC2 for QA & testing. They need 100 servers for 24 hours a few times a month. This is a purely elastic use case. They don't grow the servers to a demand curve. Instead, they periodically bring up the 100 servers they need, run the task to completion, gather the results, and shut them down.
I am aware of many use cases like this. The Internet Archive has a similar situation, using 300+ servers every few months to crunch a large data set then turning them off. This is an extremely compelling set of use cases that is largely a greenfield. It's also impractical or impossible using VPS or dedicated hosting.
My interpretation is that you are using scale in the broadest sense possible, but I think that waters the meaning down too much. The very first sentence on Scalability in Wikipedia is exactly my meaning (http://en.wikipedia.org/wiki/Scalability ):
"In telecommunications and software engineering, scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged."
There are more use cases for clouds than just the ability to grow to meet a given workload. My example of a static no growth application that is simply turned on for 24 hours for the purposes of testing shows this. The customer in question has estimated they will save hundreds of thousands of dollars over a few years in OpEx and CapEx.
As I mentioned in the blog posting, there are a number of use cases that are not directly related to scalability. They are also not necessarily specific to cloud technology. For example, the cost savings are related to the utility charge model, not clouds themselves. It just so happens that most current clouds use the utility charge model; however, there is no guarantee it will stay this way in the future.
In the case of speed, it's a question of getting a server provisioned and running *now* so you can complete a project in the short term rather than waiting for corporate IT to complete a request. Signing a contract for a VPS or dedicated server is largely undesirable in these cases and likely to result in a delay.
Reach, the final use case, has yet to be seen as clouds are largely a U.S. phenomena, but I am aware of quite a few folks outside the U.S. using EC2 as a platform for delivering services to U.S.-based customers. The most obvious example being Morph (http://www.mor.ph/), who provide a management layer on top of EC2, but are based in the Philippines. As more clouds appear globally, the mobility of infrastructure will not only become important, but critical to competing effectively.
IMO, the most important feature of clouds are the on-demand and rental nature, not enabling a particular application to scale.
Yeah, I don't mean just scalability, I mean economies of scale as well. If I need 100 servers for an hour a month, it is cheaper to use EC2 then to go out and buy 100 servers. If I need 100 servers for a year, it's cheaper to buy those servers.
On Mon, Jun 23, 2008 at 12:08 AM, Ray Nugent <rnug...@yahoo.com> wrote: > I think he means to use "scale" in both directions, thus elasticity.
> Ray
> ----- Original Message ---- > From: Randy Bias <ran...@neotactics.com> > To: cloud-computing@googlegroups.com > Sent: Sunday, June 22, 2008 8:43:36 PM > Subject: Re: Cloud Definitions
> On Jun 22, 2008, at 8:09 AM, Reuven Cohen wrote: >> I think there is a particular focus on scale simply because if your >> application is static with little or no growth then cloud computing is >> not going to be very useful. Your probably better off just putting >> your app on a VPS or dedicated server. There are other cloud benefits, >> such as cost, speed, flexibility etc, but most of which all relate >> back to the scale.
> Reuven, I don't agree. Cloud computing is useful for much more than > scale. For example, I have a client who is leveraging EC2 for QA & > testing. They need 100 servers for 24 hours a few times a month. > This is a purely elastic use case. They don't grow the servers to a > demand curve. Instead, they periodically bring up the 100 servers > they need, run the task to completion, gather the results, and shut > them down.
> I am aware of many use cases like this. The Internet Archive has a > similar situation, using 300+ servers every few months to crunch a > large data set then turning them off. This is an extremely compelling > set of use cases that is largely a greenfield. It's also impractical > or impossible using VPS or dedicated hosting.
> My interpretation is that you are using scale in the broadest sense > possible, but I think that waters the meaning down too much. The very > first sentence on Scalability in Wikipedia is exactly my meaning > (http://en.wikipedia.org/wiki/Scalability > ):
> "In telecommunications and software engineering, scalability > is a desirable property of a system, a network, or a process, > which indicates its ability to either handle growing amounts > of work in a graceful manner, or to be readily enlarged."
> There are more use cases for clouds than just the ability to grow to > meet a given workload. My example of a static no growth application > that is simply turned on for 24 hours for the purposes of testing > shows this. The customer in question has estimated they will save > hundreds of thousands of dollars over a few years in OpEx and CapEx.
> As I mentioned in the blog posting, there are a number of use cases > that are not directly related to scalability. They are also not > necessarily specific to cloud technology. For example, the cost > savings are related to the utility charge model, not clouds > themselves. It just so happens that most current clouds use the > utility charge model; however, there is no guarantee it will stay this > way in the future.
> In the case of speed, it's a question of getting a server provisioned > and running *now* so you can complete a project in the short term > rather than waiting for corporate IT to complete a request. Signing a > contract for a VPS or dedicated server is largely undesirable in these > cases and likely to result in a delay.
> Reach, the final use case, has yet to be seen as clouds are largely a > U.S. phenomena, but I am aware of quite a few folks outside the U.S. > using EC2 as a platform for delivering services to U.S.-based > customers. The most obvious example being Morph (http://www.mor.ph/), > who provide a management layer on top of EC2, but are based in the > Philippines. As more clouds appear globally, the mobility of > infrastructure will not only become important, but critical to > competing effectively.
> IMO, the most important feature of clouds are the on-demand and rental > nature, not enabling a particular application to scale.
On Thu, Jun 19, 2008 at 2:39 PM, Markus Klems <MarkusKl...@gmail.com> wrote:
> From my experience in discussions with people from the grid community > it does not lead anywhere to discuss about the definition of the cloud > (as they will always tell you that it is only a relabeling of Ian > Fosters original definition of grid computing).
Of course they're going to frame cloud computing in the grid context because it is only addressing a part of their problems (securing raw resources). Virtualization makes it possible to get compute capacity separately and put another layer on top which solves some problems people have with grid computing. See the first couple of pages of this academic paper from Globus: http://workspace.globus.org/papers/Division_Of_Labor_ICSOC.pdf
So maybe grid computing is an organized way to do actually get things done on top of clouds (in the "IaaS" sense of cloud, infrastructure as a service)? Once you have multiple clouds owned by multiple entities and you want to be able to get capacity from each, move data around from place to place, find files automatically out there, what then? That's where grid folk started 10 years ago with multiple supercomputing sites.
I don't mean to be soap-boxy, just think there's stuff to learn there which is why I've been investigating this relationship.
Speaking of "grid people" this looks interesting, announced today on Ian Foster's blog: http://www.cca08.org/
cy
A more interesting
> approach to discuss the differences between grid and cloud was chosen > by the EGEE grid computing research group at CERN.
> own EGEE grid implementation with the Amazon cloud implementation > EC2+S3 (which from their point of view is the core of the cloud). > You can read the paper here: https://edms.cern.ch/document/925013/
> The major idea is that the cloud started off b/c it provides > interfaces that developers can easily use with their applications, > such as REST and BitTorrent. Imho this is an important point, since it > allows third party developers to build their own frameworks on top of > the cloud (such as Scalr), as some of my previous speakers already > pointed out. There are some more pros and cons listed in the paper but > I think that usability / API is the most important one (the cloud is a > developer-facing business).
> The question about standardization is: what would be the incentive for > Amazon, Google et al. to allow people move away from their cloud. As I > understand it, they want to create a vendor lock-in situation. But > perhaps we will see initiatives like in the social network world with > OpenSocial and Facebook Open Platform.
|
