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>:

[Sam Johnston]

Alfonso,

On Tue, Aug 4, 2009 at 9:59 AM, Alfonso Olias Sanz <alfonso.o...@gmail.com> wrote:

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.

That is absolutely not the intention - for things like this I would suggest creating an issue in the Google Code site.

Sam (not IBM)

[Alfonso Olias Sanz]

Ok sorry about that Sam

I'll open the issue.


2009/8/4 Sam Johnston <sa...@samj.net>:

[Doug]

Alfonso, my apologies, this was an oversight on my part. I read your
comment at 9:48 this morning, your name was on the cover by 9:49.

As for the names on the cover, I know six of them are from IBM, but
most are not. It's possible that some of the others are IBMers I don't
know, but I think the vast majority of them are not from IBM. There
was absolutely no intention of excluding you or any other
contributor.

Again, my apologies for not properly acknowledging your contributions.
For everyone else out there, if I've omitted you, please let me know
and I'll correct the problem.

Cheers,
-Doug

[Alfonso Olias Sanz]

Thanks Doug no problem :)


2009/8/4 Doug <dtid...@us.ibm.com>:

[wjhuie]

Just for weighing in (since a silent opinion doesn't help), I'm of the
same opinion that vendors should probably be removed from the use
cases. It's helpful to know S3 was used, but 'storage service' would
fit the same bill. I liked the last use case which had a URL for the
"for more information go here" view, but it seems to me that if we're
making the claim that these needs and standards are ubiquitous then we
ought to back that up in our verbiage too.

[wjhuie]

Hey Yutaka-san,

That does help but I was struggling trying to understand what the
compelling case for "hybrid" was when it said everything possible
would go into the private cloud.

To me, it seems that by default everything possible should go into the
public cloud (better costs, etc) and the private cloud should be for
private info, and other things that should be kept in such a cloud.

I guess I just wanted to see more info about "we're leveraging a
hybrid cloud in order to be cost and resource conscientious" or
something like that, and then go into the details. Because if the
details are the same as the private cloud use case, then I think
people might be confused as to when / why to select which.

Did that make better sense?

[Andrew de Andrade]

@everyone

I think that having the examples are very helpful. I think you can
take into account wjhuie's concerns while still preserving this useful
information by adding a section with the many examples. i.e. extract
all the examples from the use cases, stick them in an appendix with
references to the use cases that particular example uses.

Then just add to the header of the appendix "This section is current
as of <DATETIME>", which would represent the last time someone went
through and confirmed that the examples are still linked to the
correct use cases (i.e. nothing changed) and that all the examples are
still "live" (fully functioning and in business).

This way the examples can be linked to more than one use case and
notes can be added regarding each example.

Andrew

[Sam Johnston]

Case studies (which should reference specific products) are not the same as use cases (which should not) - references to specific products should be removed. I'd also prefer the document was largely self-contained (e.g. not referencing content that we don't control).

Sam

[Andrew de Andrade]

@Sam,

That's pretty much what I had in mind with my suggestion, except that
the appendix I suggested would simply be a collection of mini use
cases hyperlinking back to the relevant use cases.

Andrew

[Sam Johnston]

Largely, yes. Some random thoughts:

• Virtually all clouds are "hybrid clouds" (including the "private" ones) as they almost always consume services from the Internet even if they are not accessible from it.
• Generators are still used as "off-grid" power sources... same applies to "private cloud".
• "Public cloud" is RealCloud™ - "private cloud" is a knock off.
  
• The implication that "private cloud" is in fact "private" does not always hold true (after all, most information theft is internal and external providers don't have a stake in the info)

Ultimately it's not our job to give guidance or recommendations, rather to enumerate the possibilities from a neutral point of view.

Sam

[ScottyD]

Here are some thoughts for consideration:
Many of the group have touched on key parts of the document. Here is
an item that is small, but is key for us (I believe).
Line 320 -- IaaS - suggest that at this level the architecture is
sharing "load" of which databases is one part. While DBMS is key,
the
architecture would broker / provision applications as whole across/on
multiple providers? Therefore, we need APIs for compute, storage, and
network to include facilitating SLAs (performance, quality),
metering,
etc....
Line 356 -Table of Use Case Scenarios - suggest we consider "changing
cloud vendors" to "services broker" or something related to the
orchestration to reflect changes at SaaS, PaaS, and IaaS. At the
highest level in this scenario we monitor performance (SLA, cost,
quality, etc), decide to change, invoke the change, and continue
monitoring.
Not to introduce a "rat hole" but from the softer, business side,
organizations will likely stand-up an organization to decide the
business rules of invoking such a change (governance). The
discussion
is good here specific to API needs, but may benefit from broadening a
bit.
-Scott

[Andrew de Andrade]

@Sam,

At the VMware Partner Exchange, VMware made a point of using the term
"private cloud" for what we are calling "public cloud" in the
whitepaper.

Their argument paraphrased: "We discovered that generally people don't
like terms with the word 'public' in it, such as 'public pool' and
'public bathroom'. As a result we are using the term 'private cloud'
to mean a closed cloud hosted by a third-party such as a hosting
provider"

Basically, the question I raise here is: as the popular media (not the
blogosphere) is largely driven by press releases (such as those from
VMware, the most widely used hypervisor among Fortune 500 companies)
and whatnot, will this whitepaper end up using a term that is not
aligned with popular usage. Even with this whitepaper, it's very
likely that the media will continue to use the term "private cloud".

My company sells a "private cloud" product. We used to call it
"dedicated cloud" but changed the name to reflect the more popular
usage of "private cloud". From what I recall we based this decision on
SEO research. If you check out Google Trends, "public cloud" barely
even registers. <http://www.google.com/trends?q=%22private+cloud%22%2C+%22public+cloud%22
>

It may be worth making note of this so that we accurately present the
popular usage. The point I'm making here is about making sure we use a
ubiquitous language.

Andrew

[Jian Zhen]

Seriously? VMware has always talked about "internal cloud", "external cloud" and "private cloud" where private cloud spans both internal and external for management and federation.

Take a look at the graphics here: http://www.vmware.com/solutions/cloud-computing/

--

http://zhen.org/zen20

http://twitter.com/zhenjl

[KLC...@aol.com]

I agree with Jian.  A private cloud can be an internal cloud (within an enterprise's walls) or an external cloud (housed at an external service provider) or a hybrid (part within enterprise and part at provider).  A private cloud, in my opinion, is simply a cloud that is wholly inside an enterprise's dedicated network.

 

I also hold what is possibly a controversial view in that I believe an external private cloud can co-reside with another private or public cloud (AS LONG AS THE CORRESPONDING NETWORKS ARE ISOLATED!)  Example:  I'm an enterprise that builds an INTERNAL PRIVATE CLOUD. I am faced with a huge expansion. Do I grow my Internal cloud or obtain expansion capacity for an external provider?  For the sake of argument, let's say, I really need 20-40 virtual instances (windows or Linux).  Why don't I simply acquire those instances from a vendors VMWare pool?  I am taking a vendors shared resources and moving them into my private cloud (creating a hybrid cloud?).

 

Ken

[Andrew de Andrade]

@Jian

I don't think that what I said really impacts their idea of calling
the "internal cloud"/"external cloud" hybrid a "private cloud".

However, I know for sure is that they are avoiding the usage of the
term "public cloud" entirely. i.e. in cases where it's purely an
"external cloud", it may also be referred to as a "private cloud".
They certainly are not referring to "external clouds" as "public clouds"

It's also possible that I am recalling this incorrectly, it's been a
few months since the conference. VMware 2009 is at the end of this
month, this usage may appear in the keynote then.

In the whitepaper, we may want to mention that a "public cloud" may
also be referred to as an "external cloud", and that a "private cloud"
located on-premise (hosted on an enterprise's infrastructure) may be
referred to as an "internal cloud".

Either way, I think footnote number 2 on page 6 I think covers this
usage.

Andrew

[Andrew de Andrade]

@Ken,

While I don't have personal contact with the clients contracting our
"private cloud", I get the impression that these "private clouds" are
sold to clients that want the assurance that they are isolated. The
only way to get that assurance is to contract the cloud in the same
way to contract dedicated servers.

In addition to that, a lot of the clients who contract the "private
cloud" have greater expectations of customizability of the cloud to
suit their needs.

From what I know BlueLock in the United States also sells "private
clouds" based on this model. Basically these "private clouds" are
being sold now to customers who have greater demands and more precise
needs than are currently met by the market and that they don't have
the expertise to manage internally.

Then again this is also a case where it really doesn't fit the
definition of cloud computing as we've outlined in the whitepaper. Our
company calls it a cloud. The client calls it a cloud. But at the end
of the day, it's dedicated hardware that is virtualized with VMware.
VMware, I'm sure will call it a cloud as well.

The question then is if we want to consider this case or simply forget
it as it is an artifact of the transition from dedicated servers to
true cloud computing.

I hope all that made sense.

Andrew

[KLC...@aol.com]

Andrew, et al:

 

How do we distinguish between a corporate employee accessing a corporate application in a Private Cloud versus an everyday "Public" consumer accessing some Internet application for private use?  Doesn't the latter have to be considered a "Public Cloud"? Or are you saying it is NOT a cloud at all?

 

In My (Humble) Opinion:

If the Enterprise owns/controls the security, access/ID management, it is Private.

If the vendor owns/controls the security, access/ID management, it is Public.

 

Again, IMHO:

An enterprise can have:

Private Cloud (completely within the corporate firewalls). That Private Cloud is either:

Internal 

External 

What about part internal, part external (see below)?

 

ISSUE: is a "Hybrid" Cloud:

A Cloud that combines both Internal and External resources?

OR

Do we use it to describe the combo of a Private Cloud and a Public Cloud.

 

In either case, we need a name.  Again, IMHO, a Private/Public Cloud is a pretty complex beast from a security and administration viewpoint.  Maybe we ought to call a Private/Public Cloud a "Complex Cloud".

 

Ken Cameron

 

In a message dated 8/4/2009 6:00:49 P.M. Eastern Daylight Time, andrew.d...@gmail.com writes:

@Jian

I don't think that what I said really impacts their idea of calling 
the "internal cloud"/"external cloud" hybrid a "private cloud".

However, I know for sure is that they are avoiding the usage of the 
term "public cloud" entirely. i.e. in cases where it's purely an 
"external cloud", it may also be referred to as a "private cloud". 
They certainly are not referring to "external clouds" as "public clouds"

It's also possible that I am recalling this incorrectly, it's been a 
few months since the conference. VMware 2009 is at the end of this 
month, this usage may appear in the keynote then.

In the whitepaper, we may want to mention that a "public cloud" may 
also be referred to as an "external cloud", and that a "private cloud" 
located on-premise (hosted on an enterprise's infrastructure) may be 
referred to as an "internal cloud".

Either way, I think footnote number 2 on page 6 I think covers this 
usage.

Andrew

On Aug 4, 2009, at 5:31 PM, Jian Zhen wrote:

[Andrew de Andrade]

@Ken

I think we can both agree that for the types of clouds that we are
both talking about, it is only IaaS and does not include PaaS and SaaS.

If I am correct and we are only talking about IaaS, then a regular
employee accessing whatever is hosted on the cloud is passing through
the enterprise's security.

However, when the enterprise's SysAdmins accessing the cloud, he may
be going through the vendor's security or the enterprise's depending
on what he is trying to access. If the SysAdmin wants to administer
the infrastructure, he is using the vendor's security. If he is
accessing whatever is hosted on the cloud, he is using his
enterprise's security.

Assuming these private clouds are hosting an enterprise application,
then I agree with you point that it is private if it is within the
firewall.

However, not all "private clouds" are contracted for hosting internal
enterprise apps.

For example, we have one "private cloud" which is used by a startup to
host the service he provides to the public. Basically he used our
"private cloud" product offering to consolidate all his dedicated
hosting infrastructure to realize a cost savings. If you think about
what he's doing, he's basically leasing the equipment and the
hypervisor licenses and paying for management, collocation and energy.

I think that the problem I was raising initially is that the term
"public cloud" is generally being avoided in the market place. As a
result, our whitepaper uses what would be the ideal term, but may not
reflect the reality of popular usage.

I think we could use a more self explanatory term: "Hybrid Public/
Private Cloud". Just compound them to include the concepts of both.
That's what they do in the German language. There's no need to create
a new term that's not in common usage.

What do you think?

Andrew

[KLC...@aol.com]

@Andrew

 

First:  I'll have to sleep (or drink some wine) on your IaaS vs PaaS.  My gut says you are right.

 

Second:  employee vs SysAdmin is very valid point.  It scares me, but still very valid.  I am trying to imagine how you would manage this in a real world situation (which doesn't really exist today...I don't think). Could be a nightmare trying to manage an end-to-end application that spans internal/external resources.  Yet I see this as one of the biggest and most near term requirements from the BIG enterprises (using external providers for top-end scaling). 

 

I have no problem with using combined wording to name a scenario.  Might improve understanding.  So, we now have variations on Hybrid?

1.  "Hybrid Public / Private Cloud".

2.  "Private Internal / External Hybrid Cloud" 

 

Personally, I see a huge initial market for all clouds in SMB.  I think the larger enterprises will go full force into Private Internal Clouds, followed by brining in external resources to supplement the internal clouds, and, finally, they will turn their clouds over to external providers.

 

Ken Cameron

[Andrew de Andrade]

(continued from my last email)

Lines 457-459
Do you guys think that maybe "cloud databases" should be presented as
its own use case?

Line 464
again, "common file format for the VM and its associated metadata"

Line 468-471
It should also be possible to download and upload standard format VM
images. Do you guys consider these specifics to be covered by "move"?

Section 3.4
Is there any need to mention ownership of the contracted cloud service?

Lines 497-498
Per the discussion Ken and I are having, should we instead say that a
private cloud "is logically contained within the enterprise (i.e.
behind the same firewall, on the same network, connected by a VPN)".
Or will our usage of "private cloud" only include those that
physically located within the enterprise?

Lines 508-510
Add "Chargeback". I also think that interoperability here needs to
address linking specifically to a billing system such as SAP.

Lines 3.6.4.1
Add "Common API for VM Management". Without this, cloud users will
have to adapt their applications to each cloud provider.

========

In the customer scenarios section, I think we have completely left out
one of the most common uses of Amazon EC2 and Google AppEngine --> Web
Startups.

The 5 scenarios listed are extremely big enterprise and government
focused. What about individuals and SMBs?

Also, given that nearly 25% of the US workforce is self-employed (and
this is growing), what about considering the cloud needs of these free
agents? Most free agent needs I imagine will be met by SaaS solutions
such as Plaxo, Google Docs, Zoho, MobileMe, etc.

If this document becomes an introductory reference answering the
question "what is cloud computing?", I think it's important that the
customer scenarios vary a bit more.

Andrew

[Andrew de Andrade]

@Ken,

As far as big enterprises going full force, I believe VMware is
already in use in about 495 of the Fortune 500 companies.

Beyond that you have Citrix XenServer seeing adoption for private
clouds.

The most interesting development in on-premise private clouds at the
moment is Eucalyptus. I know that NASA and Eli Lily already have
projects with Eucalyptus.

On your fear about the employee/sysadmin thing, I think that a pre-
requisite from the enterprise side is a fully functional single sign-
on system on both sides (the vendor and the client). The public cloud
vendor should support open single sign-on systems for individuals. And
the client needs to have their own single sign-on system that are
interoperable with open single sign-on systems so that their employees
can move seemlessly from inside to outside the enterprise.

For those that have information leakage concerns, the best solution to
this is VDI (yet another cloud case we haven't covered). This way you
clamp down on security with IP and MAC addresses and the user only
need login to a virtual desktop. This way the enterprise can maintain
security and reduce fixed capital costs (users bring their own laptops
to the job the same way a construction worker brings his own toolbelt
or a car mechanic brings his own tools to the workshop)

Anyways, I'm hoping that all these transaction costs associated with
large enterprises means that the free agent market grows greater and
greater. (recommended reading, Daniel Pink's "Free Agent Nation")

Andrew

[wjhuie]

Andrew,

I like that idea, especially about linking examples to more than one
use case. For example, SaaS provided email in a Public Cloud, should
overlap strongly on more then some requirements with SaaS provided
email in a Private Cloud!

[wjhuie]

@Andrew, that's news to me but I think since "Public" and "Private"
match NIST we should stick with them, but I think I'll start using
"Internal" and "External" more...

Hmm, then that begs the question; "What do you call a cloud I run
(i.e. internally) that provides access to the public at large?"

> > andrew.de.andr...@gmail.com

[Andrew de Andrade]

I think the answer to your question may depend on whether you are a
vendor or a consumer. Can you give a more concrete example of this case?

I would say that if you are running it internally and providing it to
the public at large (not simply employees of your firm), then you are
acting as a vendor and it would be a public cloud.

The way I see it:
"Private cloud" = a IaaS, PaaS, or SaaS cloud service for internal
consumption whether it is hosted internally or outsourced.

However I think that a cloud can be both public and private on
different levels. i.e. I own a company that runs a blog SaaS service
like blogger. I contract a IaaS private cloud and then offer it as a
SaaS public cloud. I think this is the use case we are having
difficulty with; the consumption of an outsourced private cloud
services that are then resold as a public cloud service. From the
point of view of the IaaS client it's private, but from the end-user's
point of view it's public.

whoa!... I'm now confusing myself here. That all make sense?

andrew

andrew.d...@gmail.com

[Andrew de Andrade]

For this reason, I'm kind of partial to a wiki format for this
"whitepaper"

As cloud computing is such a nebulous term (forgive the pun), and as
it is constantly evolving, I see a wiki as the best choice.

On the other hand if we really start to get into defining standards,
the best model will be a W3C/IEEE type model, whereby you have greater
formality, a benevolent dictator and official revisions.

Andrew

[wjhuie]

wiki might be interesting, since you get the "inter linking" for free,
I'd love to try a collaborative paper with something like google docs.

I've only used it for small scale stuff, and don't think the
commentary / revision could / would work really well but might be
fun :)

On Aug 5, 11:31 am, Andrew de Andrade <andrew.de.andr...@gmail.com>
wrote:

> andrew.de.andr...@gmail.com

[Andrew de Andrade]

Having messed with Google Docs for small scale-stuff as well, I still
prefer a wiki for three reasons:

(1) Talk/discussion page to elaborate the finer points and reach
agreements on content

(2) Semantic structure. MediaWiki markup more or less forces people to
maintain the correct structure (I don't know if this is as relevant
for a whitepaper with "benevolent dictator(s)" maintaining its
structure)

(3) Automatic table of contents.

Andrew de Andrade

andrew.d...@gmail.com

[Erik Sliman]

@Andrew @wjhuie

Check out the commenting tab for GPLv3. I thought for sure this type of online document collaboration would take off, but I have yet to see it quite like this anywhere else.

Note that they also use a wiki. 
 

[Gaston Fourcade]

Team, 

General Q, we are talking in general for de different parts of the Cloud but we never talked about the Service concept which is  (some procesing, storage, and a particular SW Stack) I will say the entity that put this stuff together.

This entity should reside in a Service Catalag that I believe must be part of the chart.

Do you agree?

My 2 cents.

G.

--
Gastón Fourcade
54 911 6941 8057

[Andrew de Andrade]

I'm not sure I understand your question?

Are you talking about companies like Rightscale that don't have their
own cloud but instead do federation?

Can you give an example of a company that does this today to make this
a bit more concrete?

Andrew

[Gaston Fourcade]

I´m pointing that I did not see a Service Catalog in the paper and I believe there is a need of one.

 

Definition of the kind of service could vary but could be like a product definition (and Image could be a service and should reside in what in service Management is called a Service Catalog).

- Server Type A (x86)

- Software Stack X (Linux on X86, MySQL, JBOSS, etc...

 

Somebody says, this is the Service Calatog from AWS:

http://aws.amazon.com/ec2/

 

Regards.-

 

G.

[Sam Johnston]

On Wed, Aug 5, 2009 at 4:55 PM, wjhuie <wjh...@gmail.com> wrote:

@Andrew, that's news to me but I think since "Public" and "Private"
match NIST we should stick with them, but I think I'll start using
"Internal" and "External" more...

Hmm, then that begs the question; "What do you call a cloud I run
(i.e. internally) that provides access to the public at large?"

Or one run externally by a provider (e.g. Rackspace) that is only accessible within a single entity...

Christofer Hoff did some interesting work on this subject a while back but it's still all a bit complex for my liking... "intercloud" vs "intracloud" works for me, and we have "hosted intranet" so why not "hosted intracloud".

Don't get me wrong - providing computing internally on a self-service basis and billing back to business units is advantageous, but something we've been doing for a *long* time. If the same entity (and for those of you who are immediately thinking about groups of companies, I mean "entity" in the "autonomous system" sense which would include a multi-national group) still has to worry about what's on the other side of the demarcation point (e.g. the web interface or API) then it may look like cloud so far as the consumer (BU) is concerned but it's still that entity's problem.

Sam

[wjhuie]

@Andrew

Good distinction, I'm not sure I had a specific example in mind

@Sam down below has a good example.

I was thinking more about how "internal" and "external" are almost too
"commonplace" words (i.e. used a ton in architecture documents) and it
seems trying to overload those with new (and functionally specific)
meanings would be ripe for documentation disaster... i.e.;

Wait, did they mean external cloud as in they're using one, or
providing one, or just that it's external to the team but still
internal to the company?



On Aug 5, 11:25 am, Andrew de Andrade <andrew.de.andr...@gmail.com>
wrote:

[wjhuie]

I do think that commenting system is fairly nice. Looks like it might
be tricky for tracking actual textual changes though?

On Aug 6, 10:14 am, Erik Sliman <erikslima...@gmail.com> wrote:
> @Andrew @wjhuie
>
> Check out the commenting

> tab<http://gplv3.fsf.org/comments/gplv3-draft-4.html#3326:3340:3357:>for

> GPLv3. I thought for sure this type of online document collaboration
> would take off, but I have yet to see it quite like this anywhere else.
>

> Note that they also use a wiki<http://gplv3.fsf.org/wiki/index.php/Main_Page>.

[Wil Sinclair]

This is very similar to the Django online manual and is often cited as a big part of Django's appeal. They seem to work well, but are there any tools here to integrate comments in the original text? Or would this be a copy-and-paste affair? Or done outside the commenting system?

I ask because we are currently collecting a lot of new use cases and additions to those that are already there.

,Wil

[Kristoffer Walker]

I would add that commenting on the PHP documentation multiplies it's
value many times over.

You can see how it works here:

http://us.php.net/manual/en/function.fopen.php

Comments are at the bottom of the page.