The Final Version

[Doug Tidwell]

Friends, I just posted the _final version_ of the paper to the Files
section. This is the synthesis of lots of hard work and insight from
lots of people. I hope it will be a great resource for the community
and a foundation for the hard work ahead of us. Our common goal is to
keep cloud computing open, and the use cases and requirements we've
developed will help us drive that forward. Whenever someone says, "We
don't need an open way of doing X," we can respond, "So tell us how to
implement use case Y without being locked in to your platform."

The title page lists the people who contributed to the forum and
agreed to put their names on there. The user IDs of the people we
didn't hear back from are Adrius42, Pat Ransil, Riemaxi, RoyJ, and
Lanora Bonasio; I want to acknowledge their contributions to the
discussion. (And encourage them to let us know if they want to be on
the list of contributors.)

I also want to acknowledge the graphics work done by IBM's David
Barnes, who put the diagrams together despite having other things to
do. All of the graphics are under a Creative Commons license, as you
would expect. Sometime in the next few days we'll post the .png files
for whomever wants to use them.

Let us know what you think; if there are any major changes, we can
post an update next week. For now, I'm naming it the final draft and
looking forward to a weekend off :-)

We've accomplished a lot in a couple of months, I'm really proud of
what we've done.

Thank you thank you thank you,
-Doug

[Reuven Cohen]

Nice work guys, I would suggest publishing another version in a more modifiable format. PDF isn't the easiest format to edit. 

I've also put a copy on scribd, it's easier to include in blog posts that way.

see > http://www.scribd.com/doc/17929394/Cloud-Computing-Use-Cases-Whitepaper

So what's next? ;)

R/c

[Sam Johnston]

Thanks Doug - enjoy your weekend.

Have some first feedback already courtesy @Beaker regarding contradictions in the "private cloud" use case (everyone's favourite topic).

Is there some sensible source for the document (e.g. DocBook) and ideally the diagrams too (e.g. SVG) or is it all Word (or Symphony or OpenOffice or whatever it is IBM uses for word processing)?

Sam

[Yutaka Sasaki]

Hi Doug,

Thank you very much for your effort.
The white paper looks great!

Regards,

Yuta

[Erik]

Thanks for the work. I just posted it on OpenStandards.net. Cloud
computing will be an important focus of OpenStandards.net in the year
ahead.

[Dirk Nicol, IBM]

Thanks to everyone for contributing to this project. I think it has
been a big success!

Regarding the final format. Doug and I thought it would make sense to
publish the final version and let the community take a look at it for
a few days and make sure we have all the contributors mentioned.

By mid next week, we will re-post for redistribution, in multiple
formats, removing the numbering on the left side, etc. We also planned
to cut up the graphics so people could easily grab and reuse as Sam
suggest. I like the idea of scribd. I also thought of eventually
creating a presentation that is a summary of the whitepaper so others
can reuse if they want (perhaps in slideshare also). Any other
suggestions for file format / or best ways to redistribute...let us
know.

So next week would be the best time to do any re-posting /
distribution of the document. (Starting Aug 5th ).


Thanks again,
- Dirk

[Babak Hosseinzadeh]

Thank you for an insightful document. I just finished reading it and
would like to make the following comments:

2.1.2 Deployment Models
What is the purpose of "Community Cloud"? From a standardization and
interoperability perspective, does it really have to be called out
here?
It seems that it may be a pattern and its specific requirements for
standardization/interoperability (if any) can be served by underlying
Cloud infrastructure.

2.1.4 Other Terms
I don't think "Cloud Bursting" belongs to such a document. It is a
vendor marketing term.

2.1.2 Taxonomy
I think the following items are missing from the diagram and are
relevant to standardization:
* Registry: I would add this under Service Provider. From a
standardization perspectives, requirements for a common metamodel that
describes Cloud services (categories, policies, provider, etc) should
be reviewed against existing standards...There may also be usecases
around registries interoperability & synchronization.

* Quota: I didn't see this in the diagram. I think this has
implications on standardization and interoperability in the areas of
deployment, provisioning, and automation.

* Automation: I think there are also a set of standardization and
interoperability considerations missing around scheduling &
automation.

2.2.1 Service Consumer
Programming model: In addition to standardization around user &
programming interfaces, I would also add common programming model.

2.2.3 Service Developer
Just as a note, I am not sure Service Analytics is the best term to
describe the capabilities needed for testing & debugging.
On an IaaS, folks create their own virtual images that maps to their
development & testing methodology. On PaaS, you get seats for sandbox
and use the platform-specific tools for testing & debugging. Is there
any particular requirement for standardization?

3 Usecase Scenarios
I couldn't tell if this was covered somewhere, but the usecase would
be as follows:
An enterprise may develop on PaaS A, but deploy (or have the option to
deploy) to different Cloud vendors. In this case, the standards and
interoperability issues would be around account & environment
provisioning.

3.2.1 Requirements
This isn't related to standardization, but I wanted to add a comment
here, because it is misleading.
Under Management & Governance (page 18), it is stated that Cloud
providers make it very easy to open an account and begin using Cloud
Services; the ease creates the risks....
I don't know about you guys, but this is highly unlikely. In some
organizations, there may be a network security hole allowing people to
use GoogleTalk, but it is highly unlikely for an employee to put an
enterprise application in the Cloud without technical reviews and
approvals by steering committees, review boards, etc... For a lot of
companies, after technical review and approval, you still have to work
out twists in the procurement by accounting and vendor management
team...

-----
Governance
* In addition, I would add Cloud standardization & interoperability
concerns around exception, performance monitoring, and SLA management.

Development & Packaging
* In addition to standardization around VM, I would like to add
standardization around packaging & deployment units for PaaS.


Regards,
Babak Hosseinzadeh

[Eric Windisch]

>
> * Quota: I didn't see this in the diagram. I think this has
> implications on standardization and interoperability in the areas of
> deployment, provisioning, and automation.

I think quotas are certainly something to discuss and consider. I
often hear contradictory things like, "you can scale as much as you
want to on X" and, "I'm not sure you could really launch 5 billion
instances on X". Primarily, it's an SLA issue.

If cloud infrastructure providers claim that deployment rates are
unlimited, that is pure deception, that's just impossible. However,
they could certainly provide an SLA that accounts for the deployment
of physical resources. As such, it might be best to define quotes not
in terms of hard limits, but in terms relative to time. Provider X
could specify in its SLA a quota/rate as "10,000 instances per day",
or "10TB per day".

Regards,
Eric Windisch

[Wil Sinclair]

Congrats, all! And a special thanks to Doug Tidwell for his skillful and steadfast cat herding. The doc looks great.

Of course, the important question is where we go from here.

Forgive me if this has already been covered- I'm pretty new to the effort- but what are the plans for this doc going forward? Is it a living doc? Will it have regular 'releases'? Are we going to make sure that section numbers don't change when the doc is edited so that we can confidently reference them directly in other literature? If so, should/how will we enforce that? Will this list continue to exist? Is there a better way to collect feedback now that we have more structure in our collective thinking? Does Google Groups offer the infrastructure we need, or should we move to a custom site or a forge?

And then there's the question of what we work on next. :)

I think others are likely to have the same questions, and- assuming that it's not a PICNIC- the answers aren't currently offered on the Google Groups site. If the answers can be found in past discussions, I think it makes sense to collate them and put them on the site- if not the paper itself. Maybe in a FAQ format.

Thanks again from at least one part of the open source community for all the effort you've put in to this doc. I'm looking forward to working with all of you on the next initiative!

,Wil

[Reuven Cohen]

A little extra visabilty for the whitepaper. For what it's worth, I
was just informed that the Cloud Computing Use Cases Whitepaper has
made it into the Scribd hotlist.

http://www.scribd.com/explore

r/c

[Dirk Nicol]

Reuven,

This is very cool. Thanks for posting to Scribd. Looks like over 580
reads just over the weekend.....a great start! Thanks for your help!

- Dirk

On Aug 2, 6:46 pm, Reuven Cohen <r...@enomaly.com> wrote:
> A little extra visabilty for the whitepaper. For what it's worth, I
> was just informed that the Cloud Computing Use Cases Whitepaper has
> made it into the Scribd hotlist.
>
> http://www.scribd.com/explore
>
> r/c
>
>
>
> On Sat, Aug 1, 2009 at 6:17 PM, Wil Sinclair<w...@me.com> wrote:
>
> > Congrats, all! And a special thanks to Doug Tidwell for his skillful and steadfast cat herding. The doc looks great.
>
> > Of course, the important question is where we go from here.
>
> > Forgive me if this has already been covered- I'm pretty new to the effort- but what are the plans for this doc going forward? Is it a living doc? Will it have regular 'releases'? Are we going to make sure that section numbers don't change when the doc is edited so that we can confidently reference them directly in other literature? If so, should/how will we enforce that? Will this list continue to exist? Is there a better way to collect feedback now that we have more structure in our collective thinking? Does Google Groups offer the infrastructure we need, or should we move to a custom site or a forge?
>
> > And then there's the question of what we work on next. :)
>
> > I think others are likely to have the same questions, and- assuming that it's not a PICNIC- the answers aren't currently offered on the Google Groups site. If the answers can be found in past discussions, I think it makes sense to collate them and put them on the site- if not the paper itself. Maybe in a FAQ format.
>
> > Thanks again from at least one part of the open source community for all the effort you've put in to this doc. I'm looking forward to working with all of you on the next initiative!
>
> > ,Wil
>

> >>-Doug- Hide quoted text -
>
> - Show quoted text -

[Joseph Stein]

I just joined this group the other day and having "arrived to the
party late" the quickest contribution I could make was to post the use
case document on the Cloud Security Alliance LinkedIn group and also
email all of the members of two of the working groups of the Cloud
Security Alliance http://www.cloudsecurityalliance.org/.

I will continue to promote the document as I believe it could provide
a solid foundation and helpful path forward towards collaborative work
efforts of cloud based solutions. These use cases can very much
provide a common ground to stakeholders as they engage with each other
in regards to "the cloud".

/*
Joe Stein
http://www.linkedin.com/in/charmalloc
*/

[Sam Johnston]

Dirk,

On Sat, Aug 1, 2009 at 5:27 PM, Dirk Nicol, IBM <nic...@us.ibm.com> wrote:

By mid next week, we will re-post for redistribution, in multiple
formats, removing the numbering on the left side, etc. We also planned
to cut up the graphics so people could easily grab and reuse as Sam
suggest.  I like the idea of scribd.  I also thought of eventually
creating a presentation that is a summary of the whitepaper so others
can reuse if they want (perhaps in slideshare also).  Any other
suggestions for file format / or best ways to redistribute...let us
know.

I agree that this should be a living document and to that end I have three suggestions:

• To keep the "whitepaper" look and feel use DocBook (which is relatively difficult to edit but easily translated to many formats - plain text, html, pdf, etc.)
• To maximise "editability" use a wiki (ideally MediaWiki)
• For a more structured (but still editable) approach use a CMS with a "use case" type (e.g. Drupal)

Let's get the document done first...

Sam

[Where are you?]

Thank you for allowing me to be a witness to this discussion, from
which I learned a lot. The Cloud is a less nebulous concept in my mind
now. I joined this group out of curiosity, with no technical
background, and a vague notion that the project might need specific
case studies to serve as illustrations - and that our social
networking format (whereareyou.uk.com) might be of interest to the
group. When I discovered the purpose of this white paper to be more
general and technical, I continued to follow because, although I did
not understand that much, I got enough to indicate that the Cloud is
going to have effects on all of us who are in the virtual world,
whether for business or pleasure. Kudos to all who collaborated,
especially Doug who showed great dedication and competence.

Lanora Whitted Bonasio

[Erik Sliman]

While I missed the collaborative process that created the document, I can say the same for the current document.  It has helped me to compartmentalize the various aspects of cloud computing.  Of course, I love the clear and non-controversial way it presents the need for open standards (e.g., portability of VM images.) 

Thanks for a informative and clear doc. 

Erik Sliman
OpenStandards.net

[Erik Sliman]

Can anyone tell me if any of the contributors to the doc from Google, Amazon or SalesForce.com?

[wjhuie]

Wow,
I'm astounded at how quickly this has come together. It seemed like
I'd just get a version printed when there'd be a new one out!

So sorry for the batched participation but I've been grateful to help
out.

Here's some comments on the 'final' version (line 4 says - July 31st,
2009)

p5, line 96 - The Delivery Models listed here don't match what NIST
has. I'm not sure if the intent was to quote directly or just
'paraphrase' but whatever the goal, I think it's caused a bit of a
divergence.

Specifically, I disagree with line 105 & 106 (and think NIST does
too) that "[PaaS] is typically a virtual machine...". I think the
interpretation of VM's is typically that those are IaaS and that PaaS
is "typically an application framework".
I hesitate to re-write these if the intent was they be quoted
from NIST, but my suggestion would be to try to distill the
definitions here down to 1 sentence each and let NIST be a further
reference for specificity.
Maybe something like:

Cloud Software as a Service (SaaS):
-Usually provided as a self-contained application, either
specialized in nature or replaces a common service.
-Accessible via common technologies, i.e. the web.
Cloud Platform as a Service (PaaS):
-A deployment platform which typically requires customers to
create their own applications.
-The provider controls a large portion of the service, but
leavesthe consumer responsible for the higher-level application.
Cloud Infrastructure as a Service (IaaS):
-Purchase or rent computing resources such as processors,
storage, and network bandwidth.
-Services are often operating systems, with full
administrative responsibility, leaving the user responsible for
further configuration.

p8, line 198 - Here's another mention of PaaS == VM, which relates to
the previous clarification

p9, line 202: Just for the record this is one of the best graphics
I've seen trying to depict this. I think I'd suggest removing the
"Kernel" and "Firmware" sections as they seem fairly trivial (or
subsets of the virtualized resource) at the cloud level

p 10, line 250: Another reference of PaaS == VM. There are clearly
interpretations of this, but with Google App Engine & Force.com as
examples, I think PaaS is typically an application environment

p11, line 255: "ordinary" seems misleading here. I know you don't use
S3 as an 'ordinary' storage device. I think the intent is to convey
that the 'paradigm' doesn't change much, but you could argue with
buckets, etc. that it kinda does. So I'd just strike the word from
here and avoid the verbal jousting to let the reader figure it out
later.

p11, line 283&284 - "cloud middleware" and "cloud platforms" make
(what I think) are their first appearance. I know what they mean and
think they fit the tone fairly well, but they start to sound like
'concepts' that weren't defined earlier. So it might be worth working
those phrases into the earlier definitions, or trying to reword this
slightly to avoid 'loaded' terms.

p11, line 289 - "developers are creating a SaaS application" ... This
one's tough... In my experience, developers do indeed typically create
a SaaS application, but typically "SaaS applications" == "end-users"
and people think of 'development' as a PaaS activity.
So, I don't really have any advice here without some
clarification.

p 13, line 325 - "Map Reduce" should be written "MapReduce" (no space)
to conform to Google's practice

p 13, line 333: "open standards apply at the application level"
Just wanted to comment that I love this point!

p 13, line 337 - "support in a word processing application has nothing
to do...".
This is a great point but somewhat misleading. I'd write: "... in
a word processing application has less to do with whether the
application is running in the cloud and more to do with features like
formatting. However, some features such as collaboration services, may
be affected even enhanced by the mode of delivery".

That's my $.05 up till Section 3. Hopefully, I'll work on that after
lunch depending on how to day goes but I know the cases themselves
have seen a lot of attention already.

[wjhuie]

[Wil Sinclair]

DocBook has served us well on the Zend Framework project- we've been able to render our reference guide in several formats with few problems. Of course, there are some formatting limitations that you have to accept, but DocBook and should be expressive enough for this white paper and the available stylesheets can be configured/tweeked as necessary to get the desired results.

One of our contributors actually wrote a stylesheet to render the manual in one of the wiki markup formats (can't remember exactly which one- one of the markups that's supported by Confluence). That might help in this case, although putting it back in to DocBook could prove much more difficult.

I've never used the use case feature in Drupal, although I have some PHP experience I could bring to bear. ;)

Have we thought about where the source might live? I'm assuming a some kind of source code repository somewhere, although there are certainly alternative solutions that may be simpler.

,Wil

On Monday, August 03, 2009, at 12:48AM, "Sam Johnston" <sa...@samj.net> wrote:
>

[Doug]

Hi everybody, thanks so much to all of you for publicizing our work,
I'm very happy to see our work getting a wide distribution, and I'm
sure everyone else who contributed to the paper feels the same way.

I wanted to say a few words about the community. A common approach to
writing white papers is to get people from big companies to put their
names on the cover so there's lots of press coverage when the paper is
done. This group went the opposite way, reaching out to individuals
instead. The great thing about this approach is that if a person
contributes good ideas, those ideas go into the paper regardless of
their employer or affiliation. A side effect (I won't call it a
disadvantage) is that we only know what our fellow members chose to
say about themselves. Some people identified their employers, some
didn't.

If company names were on the cover, the press and analysts would focus
on who was part of the discussion (and who wasn't); we want everybody
to focus on the _ideas_ in the paper instead.

Some other things I think I should mention:

* Wil Sinclair's name should be on the cover. Wil, my apologies.
Again, there are several people who contributed but haven't given us
approval to use their names. It's important to acknowledge everybody's
contributions, please let us hear from you.

* Please, please, please, please don't refer to this as "Doug's
paper" (or "IBM's paper") or anything similar. I'm one of many names
on the cover. This was a community effort, I think it's really
important that we emphasize that. And it's kind of embarassing, to be
honest.

* I'll post a final version of the paper by Wednesday.

Thanks again for all your hard work!
-Doug

[Andrew de Andrade]

@Everyone

I'm not familiar with DocBook.

I like the idea of the Use Case content type with Drupal.

However whatever you guys do, avoid the Confluence wiki markup. From a
semantic perspective it's an absolute disaster. It tries to marry
WYSIWYG with Document structure. Once you put it into Confluence
markup, it will be hard to get it back out without performing surgery
or clever scripting.

I'm partial to MediaWiki markup because it obliges people to form and
maintain a well structured document. Plus the learning curve is
relative smooth and it's a become a bit of the de facto standard in
opensource wiki markups.

Andrew

Andrew J. L. de Andrade
andrew.d...@gmail.com
home: +55 (11) 3285-1225 --- cell: +55 (11) 8922-4014

[Hoff]

Doug:

Apologies for ever pointing to the document as such, but you should
know
that this came from:

http://cloudcomputing.sys-con.com/node/1023950

Further, some of those who contributed to this document refer to it as
such.

I have some comments about some inconsistencies. To whom should I
send them?

/Hoff

[wjhuie]

Here are some comments on Section 3:

It might be nice to define some "actors" up-front before getting into
the scenarios. "End-user" seemed to fluctuate between meaning what I
thought it should, and only meaning "public cloud SaaS end-
users" (where as end-users could also access PaaS or IaaS services).
Also "Enterprise" was unclear, if it meant a business or "enterprise-
end-users".

Also, the pictures in the table seem pretty small although it's fairly
obvious what's intended.

Table on p14, 2nd Row, 2nd Column (aka "Enterprise to Cloud to End
User") - "public" does not seem like it belongs here (especially when
considered according to p17, lines 382 - 286).
I'll use this 1st comment as an example of my earlier confusion.
"Enterprise to Cloud" (i.e. what does that mean?). This could be "A
business" who's purchased cloud services (but in this case "cloud
service" could be anything... so do we talk about SaaS requirements,
or IaaS requirements...) and "Cloud to end-user" ... does "end-user"
only apply to public clouds (I don't think so)?
It might be useful to define who's providing what service (and on
behalf of whom)?
AKA: "Cloud" provides a service on behalf of the "Enterprise" to
the "End-User", who in this example happens to be an employee of the
"Enterprise".

Table on p15, 1st Row, 2nd Column (aka "Enterprise to Cloud to
Enterprise") - another example where "public" probably doesn't belong
(this could be a community cloud or a private cloud via VPN).

p15, line 359 & 360 - "... the Private Cloud use case does not involve
the End User ..."
I don't see why private clouds don't have end-users, they'd just
be individuals internal to the enterprise. So this is probably another
indication of my confusion.
Also, I think "disclaimers" like this are wasted "after the fact".
It's good to explain the graying out, but maybe do this w/o the
'specific' example so it doesn't confuse the point.

"Notice that the graphics in this section have common elements
throughout. However, if a given element does not predominantly apply
to a particular use case than he has been grayed out or drawn with a
dashed line."

Seems sufficient for explanation.

p16, 3.1.1 Requirements (for "End User to Cloud").

My comment here has a lot to do with my earlier confusion. If this
"Cloud" is a SaaS application then I'd expect "Requirements" to
include a statement about Open Protocols & API's (e.g. JSON, HTTP).
I would also expect a statement of them supporting "Open
Fileformats" for uploading and downloading (as opposed to allowing me
to upload anything but locking me in so I can only download some
esoteric proprietary DRM'd junk).

p17, line 384 - "retrieve data and /or manipulate..." there's a space
missing after the '/' aka "and / or"

p18, line 417 (Security) - It might be worth adding something about
Centralized control of Authentication / Authorization here. "However,
a common requirement is the need to centrally control authentication
and authorization credentials. Whereas many public cloud services rely
on the individual users to enforce control, an enterprise model will
require a point of centralized policy control and administration".

p18, line 421 & 422 - This "Common File Format for VMs" is definitely
a requirement but I'm unclear if "Cloud" here is SaaS, or IaaS... and
if both, then why do requirements for PaaS seem to be missing? (Common
languages, debugging tools, logging, capacity planning, cost
constraining, etc...).

p22, line 500 - I'd take out "to buy", because although cloud clearly
contains a heavily cost focused aspect, in a private cloud model,
extended capacity may not need explicit purchase agreements (e.g. you
don't need credit-card approval prior to a HA/DR roll-out).

p24, line 528 "Scenarios 1: Changing SaaS Vendors" - This is another
confusion for me, occasionally "Cloud" is used, to seemingly mean
"SaaS" but then other times SaaS is explicitly called out (but I don't
see IaaS and PaaS examples to complete the symmetry).

Regardless, assuming this is SaaS specific the question I had
about "might need to use the two vendors interchangeably" would be
what would happen if the vendors are not interchangeable? For example,
suppose I was using a SaaS email solution from Microsoft and things
worked great with my existing outlook user base, but then I wanted to
move to GMail. Now I know google supports outlook as a front-end, but
does it have to? Is feature support an inviolate ? Iff so, then we're
dooming the small vendors who can't afford to fund (and keep up) with
the rapid "embrace and extend" that larger institutions can maintain.

p24, line 542 - 544 - This is a good paragraph but I think could be
extended to mention two important (to me) features:

a) Open / Standard Document Formats
b) Bulk Downloads

Open Document Formats is important, because imagine I upload a txt
file but I'm only allowed to download PDF. That would then force me to
purchase an Acrobat Editor in order to make future changes to
documents I authored!!

Bulk downloads is important because if I use a service and build up
1000's of documents but they require me to select and download each
one individually, then I'm locked in de facto, by my inability in
invest that much time to switching providers.

p25, line 578 - "Scenario 4: Changing VM hosts" - This should probably
read "Changing IaaS Providers" since "VM host" really isn't one of the
models of cloud (though it's clearly a feature)

p31, line 613 - 615 - "Notice that the communication ... but access is
not via the public Internet".
I disagree with this statement. A community cloud might have a
publicly accessible login page, protected by ID. Similar to the
bulletin boards or gaming-community sites. For example, you could have
a community of CERN scientists who gain access to their private data
and computation via a public splash page.

[Reuven Cohen]

I asked the Sys-con folks to edit the title of the post and remove the
mention of IBM.

http://cloudcomputing.ulitzer.com/node/1056403

/rc

[Wil Sinclair]

Of course you can use my name. I'd be honored.

,Wil

[Erik]

On Aug 3, 11:29 am, Doug <dtidw...@us.ibm.com> wrote:

> If company names were on the cover, the press and analysts would focus
> on who was part of the discussion (and who wasn't); we want everybody
> to focus on the _ideas_ in the paper instead.

You mean like the reaction to the Open Cloud Manifesto? It is a bit
late for that. Everyone will wonder what Google, SFDC and Amazon's
reaction to this will be, because their reaction matters to us. It
can give us hope, or frustrate us. It can certainly impact our
decisions about which vendors to use. The reality is we are all
watching for any sign that they will embrace the open standards needed
to benefit the consumers of cloud computing. You and I can't change
that.

As for the ideas in the paper, I don't believe investing in reading
the paper and the ideas it holds is mutually exclusive with wanting to
be informed about what the large vendors are doing. In fact, the more
you embrace the ideas in the paper, the more you care about its impact
on the vendors.

> * Please, please, please, please don't refer to this as "Doug's
> paper" (or "IBM's paper") or anything similar. I'm one of many names
> on the cover. This was a community effort, I think it's really

> important that we emphasize that. And it's kind of embarrassing, to be
> honest.

I love the humility. I'm glad the paper starts with attribution for
all the contributors.

Honest reporting does require the facts, embarrassing or not. You, a
Cloud Computing Evangelist from IBM, did create the Google Group and
have clearly lead it to today and continue to lead it, with the help
of Dirk and Dave, the Managers of the Google Group. The group should
be proud to have such talent helping with a good cause to create this
balanced collaboration.

Those who are proponents of the ideas of the paper will be compelled
to point out both IBM's participation and the widespread contributions
of ideas from many individuals from various companies and backgrounds,
as both help build the creditability of the paper.

One sidenote... I looked yesterday for news on cloud computing and
was really dismayed that the bulk of recent "news" is negative
opinions on cloud computing. To be sure, some authors were proponents
of cloud computing itself, but had a less than positive perspective on
how it was likely to be utilized over the next 5 years.

Despite the negative news and opinions, the positives today include:
this paper, the collaboration of the individuals that went into it,
and the fact that IBM continues to be a proponent of open standards
and open cloud computing; and, of course, the many other collaborative
efforts today to drive open cloud computing.

Erik

[Sam Johnston]

On Mon, Aug 3, 2009 at 5:26 PM, Wil Sinclair <wl...@me.com> wrote:

DocBook has served us well on the Zend Framework project- we've been able to render our reference guide in several formats with few problems.

DocBook definitely stands out if it's a relatively static whitepaper that we want (and right now it looks like that's what it is, for the time being at least).
 

Have we thought about where the source might live? I'm assuming a some kind of source code repository somewhere, although there are certainly alternative solutions that may be simpler.

I've created a Google Code project by the same name as the Google Group at http://code.google.com/p/cloud-computing-use-cases/ and converted the first half a dozen pages to DocBook 5 (which I've uploaded to the subversion repository). I figured there wasn't much point doing much more right now given the document is a moving target (and we don't yet have consensus re: the format), but the issue tracker will be good for tracking errata. We also get a rudimentary wiki (which backs onto subversion in a relatively simple wiki markup) and download hosting/tracking.

Does this sound sensible to the rest of you?

Sam

PS I also created a 'cloudcomputingusecases' Google Account and will send the random password to Doug/Dirk for safe keeping. We can also assign write permissions to other Google Accounts on request.

[Wil Sinclair]

I don't think that vendors are relevant for a use case document such as this. I can certainly understand why people might be interested in whether Amazon, MS, Google, etc. have contributed to the effort, but I agree with Doug that associating any vendor's name with this document will compromise the work that we have all put in to it.

No one is hiding the fact that Doug started the effort and that he's from IBM. For that matter, I'm from Zend Technologies, and I'm also doing this on the clock. But these are really interesting historical footnotes; an open effort is an open effort. Having run a popular open source, company-backed PHP framework project, I am convinced that it's about the ecosystem around the effort, and not the origins.

I do understand and appreciate your points, but as for the matter of vendor names on the doc or whether it should be associated with one primary author, I agree 100% with Doug.

,Wil

[wjhuie]

Comments on "Section 4 - Customer Scenarios"

I think this is a great section and would consider moving it prior to
Section 3, so all those situations have a bit more context around
them.

As an editorial question, should specific products be used? I know
they're actual scenarios I'm just wondering if it's better to say
"storage service" (i.e. more generic) vs. a specific "S3".

Table on p29, 3rd Column, 1st and 5th Row - I don't think PaaS is the
appropriate model here, and instead think it should be "IaaS". From
the descriptions is seems like EC2 and S3 are being used, which most
people accept as IaaS.

p30, line 649 - "virtual machines (PaaS)", again I think that's IaaS

p30, line 654 - "S3 cloud storage API" maybe should just read "cloud
storage infrastructure API"

p30, line 659 - Another mention of S3 which could say "storage"

p31, line 676 & 677 - Another specific product mention, "GAE" which
could be more generic. The "RDF" mentions on line 677 seem like
application-level "enforcements" and not GAE related.

p31, line 682 - "silos" this word pops up 3 times in this paragraph
but it really doesn't have a specific meaning (it seems like an
application level criteria)

p32, line 709 - Specific mention of "Google App Engine" but it's good
to see a platform service I agree with! :)

p32, line 714 & 715 - Both instances of "Big Table" should be
"BigTable"

p32, line 716 - "achieves scalability by prioritizing denormlization
over normalization" ... this is a somewhat true statement but a little
backwards.
However, it's more accurate to say "BigTable is a sparse,
distributed, persistent, multi-dimensional sorted map that prioritizes
scalability over normalization or other typical ACID-compliant
criteria."

p32, line 731 and p33, line 733 - "(Some front ... scope of this
project.)" I'd take the "(" and ")" out and make this sentence stand
as a sentence.

p33, line 749 - This scenario "Local Government Services in a Hybrid"
seems like a copy / paste of 4.3 with only lines 754-758 changed.
I think it needs a bit of tweaking to better show why the Hybrid
Cloud is important vs. the previously mentioned Private one.
In addition, on line 756-757: "Some local data will be stored in
the government's private cloud while other data will be stored
locally" could use some sorting out (too many "locals") there.
I'd take a shot at cleaning it up, but I'm confused by the next
line "Wherever possible, existing systems will be ... hosted in the
private cloud".
So why would anything be stored not privately? Why is this a
Hybrid at all?

p35, line 797 - 803 - "VM" is repeated a lot here
"... equivalent to running a grid of 20 VM's for 40 hours... will
require running the 20 node cluster for... extra large systems. With
each image running ..."

Also, it's a little unclear if "VM" is EC2 or a Java VM... I
suspect the former but reacting appropriately will depend on what
decision is made about specifying products.

p35 - line 818 - "were attached to teh database VM." How about making
that last VM "server" ?

[Naveen]

Hi Doug,

Great work and thanks to all of you for putting efforts in getting it
done. What would be the process for adding new use cases as I was
thinking of submitting one for provide a use case for using single
sign-on. Please advise

Thanks,

Naveen

[wjhuie]

Last comments - Section 5:

p36 for everything

line, 831 - "Web" should probably be "web community"

834 - 835 - I fall in those categories but thought maybe it might be
worth adding something like: "as well as many participants concerned
with ensuring their personal rights were represented" just to be a bit
less "industry" biased.

(love lines 836-840)

842 - Can we move away from explicitly calling out VM's and just say
"Common Formats and API's"?
Or say something a bit less loaded / specific like "Common
resource definitions" ? Since "virtual machines" is listed in the
definition, I don't think making the leading 'title' broader would be
bad.

I also don't think "... should run on another cloud provider
without changes" is really what we're after. Well it is, but I don't
care if I have to convert my [doc, VM, DB file] from one format to the
other in order to use it so long as it's easy (i.e. automatic) to do.

How 'bout:

"resource specifications including virtual machines and data"
which were created or used for one cloud provider must be made openly
accessible to the user for downloading and migrating to another
provider in whatever formats and standards, including intermediary
conversions, are appropriate. In addition the provider should not make
the act of such migrations or bulk downloads of the user's own data
(including data created in the cloud service itself, such as capacity
metrics or logging info) prohibitively expensive whether from a cost
or time and effort perspective."

That's my suggestion for a start at least.

849 - 850 - I understand the need to be generic here but let's flesh
this out a bit more.
"However, all cloud services will need to maintain the standards of
accountability and auditability necessary to ensure services are
rendered as required to their users" (i.e. I don't want them to tell
me all my data will be on my native country's soil w/o them giving me
a way to verify that premise... this is kinda covered in Location
Awareness).

WOOT, yay the end!

[Sam Johnston]

On Mon, Aug 3, 2009 at 7:42 PM, Wil Sinclair <wl...@me.com> wrote:

I don't think that vendors are relevant for a use case document such as this. I can certainly understand why people might be interested in whether Amazon, MS, Google, etc. have contributed to the effort, but I agree with Doug that associating any vendor's name with this document will compromise the work that we have all put in to it.

Agreed but it's a bit late for that as right now when you search for "cloud computing use case" you get Reuven's mugshot and half a dozen references to this project being "IBM's": http://yfrog.com/5a29ip Granted most of those are SYS-CON and therefore hardly reliable but perception is still very important - to be considered valid the process needs to be open and neutral and while it has been for the most part that's not the way it looks right now. We need to be a lot more careful about this.

No one is hiding the fact that Doug started the effort and that he's from IBM. For that matter, I'm from Zend Technologies, and I'm also doing this on the clock. But these are really interesting historical footnotes; an open effort is an open effort. Having run a popular open source, company-backed PHP framework project, I am convinced that it's about the ecosystem around the effort, and not the origins.

Exactly - and it's as much about what we do from here as what has been done to date. Many participants (including IBM) have both a lot to lose and a lot to gain from cloud computing so we need to be inclusive of use cases and careful to keep it well balanced (that is, avoid overemphasising or sidelining use cases).
 

I do understand and appreciate your points, but as for the matter of vendor names on the doc or whether it should be associated with one primary author, I agree 100% with Doug.

 
Me too, though including company names is probably helpful. Assuming we'll be formally announcing the final version we may want to do a press release with members, quotes, etc.

Sam

[Sam Johnston]

On Mon, Aug 3, 2009 at 6:44 PM, Reuven Cohen <r...@enomaly.com> wrote:

I asked the Sys-con folks to edit the title of the post and remove the
mention of IBM.

http://cloudcomputing.ulitzer.com/node/1056403

Ruv, as we've not yet published the "final version" wouldn't it be better to remove the post(s) altogether and leave the group to do the official announcement?

There's also still this post and this one referring to us as the "IBM Cloud Computing Use Cases Group".

Sam

[santosh padhy]

Hi All. 

This document looks great. explain clearly without any doubts. 

Congrats Doug and others for brilliantly scripted this document. 

I have few suggestion here. 

 

1. Why can't we have a place where we can have all documents, drafts and presentations. 

2. Also we can have the discussion forum, updating everyone with current development, future plans. 

There are few things that would really be helpful if we could able to discuss to get more info on that. 

1. Service Level Agreement

2. The agreement between the service developers and providers. 

3. How we can serialize hosting a new application in any cloud environment. 

4. Unified set of common APIs for cloud 

   

5. File format of VM

Kindly forgive if I am missing out something.

 

Thanks 

Santosh 

[Yutaka Sasaki]

Hi Wjhuie,

I'm the contributor of the Central government and local government section.

What I tried to describe is what is the difference between Central
government and Local government in Japan.
Basically, government's business is alike whichever Central or Local, so
this is the reason why they look copy/paste, however, in Japan, The Central
government decided to move local government servers to Hybrid could because
to own and operate 100% private cloud is a too heavy job for local
governments.

Does it make sense?

Regards,

Yuta

[thomask...@gmail.com]

My suggestion would be to use a format that is easily edited.

After all, the NIST definition of cloud computing has gone through 14
drafts, and those of us who attended the OMG meeting a few weeks ago
received a heads-up that additional modifications to the definition
are being considered.

Tom

On Aug 3, 2:48 am, Sam Johnston <s...@samj.net> wrote:
>
> I agree that this should be a living document and to that end I have three
> suggestions:
>

>    - To keep the "whitepaper" look and feel use DocBook (which is relatively

>    difficult to edit but easily translated to many formats - plain text, html,
>    pdf, etc.)

>    - To maximise "editability" use a wiki (ideally MediaWiki)
>    - For a more structured (but still editable) approach use a CMS with a

[Alfonso Olias Sanz]

I just want to point something.... and I do not want to put more wood
in the fire.

But is there anybody who contributed to the paper with a use case or a
paragraph and he doesn't appear as a contributor? Because that is my
case, I contributed with a use case and I have been ignored. I wonder
if the brownie point is only for the IBM folks, and that is not fair
from the aim of this group.

All the best



2009/8/4 ThomasK...@gmail.com <thomask...@gmail.com>: