Cloud Definitions
trevoro
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'?
-Trevor
http://layerboom.com
Randy Bias
On Jun 17, 2008, at 3:34 PM, trevoro 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.
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.
Yes. I took a stab at it here:
http://neotactics.com/blog/technology/short-sighted-about-cloud-computing
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
Chris Marino
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.
Liked this one:
http://www.joyeur.com/2008/05/08/cloud-nine-specification-for-a-cloud-co
mputer-a-call-to-action
Hated this one:
http://direct2dell.com/cloudcomputing/archive/2008/04/10/cloud-computing
-model.aspx
I called it the 'Spinal Tap Model for Cloud Computing' It's got twelve
layers and vertical slices too.
More here if you're interested... http://blog.snaplogic.org/?p=189
CM
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 -
http://download.boulder.ibm.com/ibmdl/pub/software/dw/wes/hipods/Cloud_computing_wp_final_8Oct.pdf)
-----BEGIN QUOTE-----
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.
Brian M. JUNG # Peace Love Empathy & a Rose @}`-,--
brian....@gmail.com
http://blifelog.blogspot.com/
Tross
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?
Brian MyungJune JUNG
"IBM Google Announcement on Internet-Scale Computing : Cloud Computing Model"
http://user.chol.com/~forlinux/Library/20080219/03._Cloud_Computing_Oct_03_Ext.pdf
Some parts quoted from the above material:
What is Cloud Computing?
services reside in massively scalable data centers and
can be ubiquitously accessed from any connected
devices over the internet.
Characteristics of Cloud Computing:
+ 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
Andrew Rogers
> 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
> 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.
Cheers,
Andrew
Tross
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:
Markus Klems
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.
- Markus
http://markusklems.wordpress.com/
Jim Peters
Isn't a compute cloud simply a set of documented interfaces, with no idea how those interfaces are implemented?
+J
Jim Peters
+415-608-0851
Chaz.
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?
Chuck Wegrzyn
Markus Klems
> 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?
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.
- Markus
http://markusklems.wordpress.com/
Christoph Marloh
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. "
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.
Christoph
--
Für Rückfragen stehe ich Ihnen persönlich unter 0172 870 33 73 zur Verfügung.
Mit freundlichen Grüßen
Christoph Marloh
Geschäftsführer
---------------------------------
M: +49 (172) 870 33 73
E: cma...@marvenda.com
W: www.marvenda.com
MARVENDA GmbH
Heilwigstraße 39
20249 Hamburg
Phone +49 (40) 410 8113
Fax +49 (40) 1805 4630
HRB Hamburg 99949, Geschäftsführer: Christoph Marloh. Es gelten unsere AGB in der Fassung vom 01.03.2008
Badestraße 35
D-20148 Hamburg
S. Masoud Sadjadi
Very interesting topic and many thanks for the inspiring discussion.
If you have not seen Ian Foster's blog on this topic, it definitely worth looking.
http://ianfoster.typepad.com/blog/2008/01/theres-grid-in.html
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: sad...@cs.fiu.edu
Web: www.cs.fiu.edu/~sadjadi
Tel: 305-348-1835
Fax: 305-348-2336
------------------------------------------------------------------
Alistair
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-youre-using/
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? ;-)
Alistair Croll
www.bitcurrent.com
On Jun 20, 11:36 pm, "S. Masoud Sadjadi" <sadj...@cs.fiu.edu> wrote:
> Hello Everyone,
>
> Very interesting topic and many thanks for the inspiring discussion.
>
> If you have not seen Ian Foster's blog on this topic, it definitely worth looking.
>
> http://ianfoster.typepad.com/blog/2008/01/theres-grid-in.html
>
> 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
>
> Tel: 305-348-1835
> Fax: 305-348-2336
> ------------------------------------------------------------------
>
> -----Original Message-----
> From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Chris Marino
> Sent: Tuesday, June 17, 2008 8:20 PM
> To: cloud-c...@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.
>
> Liked this one:
>
> http://www.joyeur.com/2008/05/08/cloud-nine-specification-for-a-cloud-co
> mputer-a-call-to-action
>
> Hated this one:
>
> http://direct2dell.com/cloudcomputing/archive/2008/04/10/cloud-computing
> -model.aspx
>
> I called it the 'Spinal Tap Model for Cloud Computing' It's got twelve
> layers and vertical slices too.
>
Kent
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
Reuven Cohen
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.
Reuven
www.elasticvapor.com
--
--
Reuven Cohen
Founder & Chief Technologist, Enomaly Inc.
www.enomaly.com :: 416 848 6036 x 1
skype: ruv.net // aol: ruv6
blog > www.elasticvapor.com
-
Get Linked in> http://linkedin.com/pub/0/b72/7b4
Randy Bias
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.
More here.
http://neotactics.com/blog/technology/cloud-values/
Best,
--Randy
http://neotactics.com/blog
Reuven Cohen
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
--
Andrew Rogers
> 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.
Andrew
Andrew Rogers
> 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.
Andrew
Randy Bias
> 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.
Thanks,
Ray Nugent
Ray
Reuven Cohen
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.
ruv
--
C. Y.
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
rich.wolski@gmail
On Jun 24, 11:26 am, "C. Y." <cty....@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).
who really haven't tried to do both.
>
> 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).
driving the design of the grid when its first implements were first
emerging compared to the requirements now being identified by
potential cloud customers. First, I think it is important to realize
that there is a bright-line difference between the concept of the grid
(which is broad sweeping, usually somewhat vague, and quite bold) and
the way grid were eventually implemented. Having now participated in
the cloud computing space for a few months now, I observe the same
relationship to be true. Thus it is probably only profitable to
discuss how the realizations of grids and the realizations of clouds
differ rather than their relative conceptual scopes.
From an implementation perspective, the grid was designed to allow a
(relatively) small user population (usually under 10,000) to make
large allocation requests from a small, heterogeneous, and
geographically distributed set of big resources (i.e. large
clusters). There were many great ideas about how to make planetary
sized grids, but the eventual realiztions turned out to be on the
order of this scale. Think 10,000 users, 50 sites (all different --
really different), with 1000 processing elements per site as a back of
the envelope approximation. There are two important characteristics
of this design point that are distinct from where clouds are today.
1) The sites each support a unique machine, machine configuration and
software stack, and access policy (right down to the users ids).
2) A single user can request a large fraction of all of the resources
in a single request.
Contrast this state of affairs with the current cloud offereins.
Imagine, for example, what EC2 would be like if it ran on a much
smaller set of clusters, each of which was almost completely unique,
and if a single user could routinely allocate as much as 3/4 of the
capacity in a single request. I suspect that Amazon would have
deployed a rather different infrastructure than the one they designed
if this was their target service point.
In contrast, cloud computing offernings (at all levels of abstraction
from the application as a service down to infrastructure as a service)
seem to anticipate a differet usage pattern in which the user
community is large (10^6 or bigger) no single user can absorb a
debilitating fraction of the total available capacity, and the cloud
provider has the power to control how the resources are configured and
managed. In this environment, the software services (called
middleware in the grid community) are really different.
How so?
First, on a grid, because the resources are all different, and an the
way in which an individual user must access them is unique to each
resource, the resource topology needs to be exposed to the user or
programmer. The grid tried to develop a whole bunch of different ways
of hiding this complexity from its users, but in my opinion, none of
them have turned out to be all that successful. For large scale
parallel computing using hetereogeneous resources with different local
access policies, commoditizing parallel execution has just turned out
to be really hard. OSG has managed to commoditize it for high-
throughput workloads, but that is a subset of what is needed.
In a cloud, users get a much more abstract view of resources (even in
EC2) but the cloud provider has had to do some work to commoditize the
lower levels. Consequently, a smaller set of programming models can
be supported well (try computational fluid dynamics with Rails some
time) although the ones that are supported can be made to work very
well.
Secondly, in a cloud, resource admission is usually controlled so that
demand does not exceed supply. On most grids, the reverse is true.
The resouce pool is usually underprovisioned (scientists have no money
to spend) and individual users have huge resource requirements. This
conditions naturally drives grids toward a batch or throughput model
where as in the cloud, allocation latency (the time between resource
request and when the resources are allocated) needs to be kept low.
To ensure that this latency is bounded, cloud providers need to be
careful about admission control and in a way that grids usually don't.
Thus, in my mind, the two approaches have been instantiated to meet a
sifferet set of operating criteria even if they share high-level
conceptualizations with each other, and with other approaches that
predate them both.
Is it possible to unify these two approaches? Perhaps. I think that
is quite an interesting question. For the moment, though, I don't
believe they manefest in the same way. Put another way, I think grid
computing and cloud computing are, for the moment, quite distinct and
neither can really claim to be a progenotor of the other.
Cheers,
Rich
Greg Pfister
Very good discussion. I was involved in a discussion of cloud
computing at HPDC 2008 (just held), and I think most people there
would agree.
One item that I think needs to be added, though: From its outset,
grids were also interested in portability of applications between
different clusters, as well as applications spanning multiple
clusters. This drove, and still drives, a large emphasis on industry-
wide standards for grid applications.
Those same forces aren't present in clouds. Portability would be nice,
but it's not required at this time; and as you point out, typical
cloud use has many users per cloud, not giant applications spanning
multiple clouds.
--
Greg Pfister
Sassa NF
> ...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).
"Scalability being *resilience* of the software to the increasing
number of CPUs" (c) not mine.
Sassa