[Capi-bof] Cloud Standards Roadmap

Tue Mar 24 09:38:21 CDT 2009

SWIFT actually works, it would be good to understand how that got started 
and accepted. Although they have delays and for curreny exchange some banks 
cheat on curreny exchange.

----- Original Message ----- 
From: "Alexis Richardson" <alexis.richardson at gmail.com>
To: <cloudforum at googlegroups.com>
Cc: "capi-bof" <capi-bof at ogf.org>
Sent: Tuesday, March 24, 2009 3:36 PM
Subject: Re: Cloud Standards Roadmap

I think it is for the consumer.  Providers should back this in order
to get more consumers.

What you are describing in your bank example, points at "SWIFT for the 
Cloud".

On Tue, Mar 24, 2009 at 1:00 PM, pnrasm <paul.rasmussen at oracle.com> wrote:
>
> I suppose that depends on the purpose of the standard. This group's
> description is
>
> "The Cloud Computing Interoperability Forum is a group of industry
> stakeholders that are active in cloud computing. The groups goal is to
> define an organization that would enable interoperable enterprise-
> class cloud computing platforms through application integration and
> stakeholder cooperation."
>
> In recent discussions I've seen comments about interoperability. So
> is the standard for the cloud consumer or the cloud provider?
>
> If for the cloud consumer requires 1 API. Example, I have my money in
> the bank. I can go to any ATM and get service. If I want to change
> banks (clouds) I submit a request and all my money is moved BY THE
> BANKS from one to another.
>
> If for the cloud provider then I want many more APIs. I'm not writing
> my own code, nor do I necessarily want to buy the entire cloud suite
> from a single supplier. I'd like to pick and choose the best customer
> interface, with the best provisioning piece(s), and the best
> operational maintenance, and the best automated system balancing, and
> the best reporting piece, etc. Is this clear?
>
>
> On Mar 24, 1:12 pm, Alexis Richardson <alexis.richard... at gmail.com>
> wrote:
>> Well right now we have one API per provider. Is that too many or too few?
>>
>> On Tue, Mar 24, 2009 at 12:04 PM, pnrasm <paul.rasmus... at oracle.com> 
>> wrote:
>>
>> > I am in favor of too many APIs as opposed to too few.
>>
>> > There is a tendency to say that an API is only needed where "My App"
>> > meets "The Other App". The pitfall there is that you tend to lose
>> > sight of where one function within your app interfaces with a
>> > different function. This is how companies try to trap consumers into
>> > their product for life.
>>
>> > There should be an accessible API between each function, then I can
>> > put together the best pieces that I like from whoever built them.
>>
>> > On Mar 24, 12:42 pm, Lori Mac Vittie <L.MacVit... at F5.com> wrote:
>> >> Agreed that orchestration requires well-formed APIs for resources. But
>> >> keeping in mind that orchestration may be a good place to go in the 
>> >> future
>> >> may help when considering those well-formed APIs. It would really be
>> >> disappointing to have to try to retrofit an orchestration layer later 
>> >> on
>> >> because the APIs just don't support it for one reason or another.
>>
>> >> I'm not necessarily suggesting tackling such a thing now, just that it
>> >> should be kept in mind as a goal when working through the other APIs.
>>
>> >> The APIs can't be purely resource based, there should be
>> >> application/operational APIs as well, which is a good place to keep in 
>> >> mind
>> >> an orchestration layer might need to use it.
>>
>> >> Lori
>>
>> >> > -----Original Message-----
>> >> > From: cloud-standards at googlegroups.com [mailto:cloud-
>> >> > standards at googlegroups.com] On Behalf Of Alexis Richardson
>> >> > Sent: Tuesday, March 24, 2009 4:21 AM
>> >> > To: cloud-standards at googlegroups.com
>> >> > Cc: CCIF; capi-bof
>> >> > Subject: Re: Cloud Standards Roadmap
>>
>> >> > That is an interesting idea. However in the words of the Specials, 
>> >> > it
>> >> > comes across as "Much too much, much too young". Orchestration will
>> >> > be predicated on well formed APIs for resources that are *to be
>> >> > orchestrated*. So let's deal with the latter first.
>>
>> >> > On Tue, Mar 24, 2009 at 11:03 AM, Lori Mac Vittie 
>> >> > <L.MacVit... at f5.com>
>> >> > wrote:
>> >> > > Hi Sam,
>>
>> >> > > I’m wondering, too, if there isn’t a place – perhaps in “Fabric” –
>> >> > for an
>> >> > > overall common orchestration overlay layer. There is no such 
>> >> > > effort
>> >> > that I
>> >> > > am aware of, but I think it’s a necessary component of the cloud.
>> >> > Basically
>> >> > > I think there needs to be a standard mechanism for orchestrating
>> >> > > provisioning and processes around the collaboration necessary 
>> >> > > between
>> >> > the
>> >> > > disparate components in the cloud. Having management and
>> >> > configuration APIs
>> >> > > for the different layers is great, but being able to tie them
>> >> > together in a
>> >> > > standards-based way would be beneficial.
>>
>> >> > > I also don’t have all the links handy so I won’t edit the wiki, 
>> >> > > but
>> >> > under
>> >> > > “Vendor owned standards | Fabric” Citrix, Cisco, Radware, and Zeus
>> >> > > Technologies all have accessible APIs for management similar to F5
>> >> > iControl.
>>
>> >> > > Zeus Technologies
>>
>> >> > >http://www.zeus.com/products/zxtm/manage/control_api.html
>>
>> >> > > Radware (APSolute API)
>>
>> >> > >http://www.radware.com/Customer/default.aspx
>>
>> >> > > Thanks,
>>
>> >> > > Lori
>>
>> >> > > From: cloud-standards at googlegroups.com
>> >> > > [mailto:cloud-standards at googlegroups.com] On Behalf Of Sam 
>> >> > > Johnston
>> >> > > Sent: Tuesday, March 24, 2009 3:21 AM
>> >> > > To: Cloud Standards; CCIF; capi-bof
>> >> > > Subject: Cloud Standards Roadmap
>>
>> >> > > Morning all,
>>
>> >> > > I have added the Cloud Standards Roadmap to the Cloud Computing
>> >> > Community
>> >> > > Wiki. Please review it and let me know if there are any efforts I
>> >> > have
>> >> > > missed (or better yet, add them to the wiki). We can use this
>> >> > document as an
>> >> > > authorative source to track standardisation efforts and hopefully
>> >> > prevent
>> >> > > duplication/proliferation.
>>
>> >> > > Thanks,
>>
>> >> > > Sam
>>
>> >> > > ---------- Forwarded message ----------
>> >> > > From: Sam Johnston <s... at samj.net>
>> >> > > Date: Tue, Mar 24, 2009 at 11:06 AM
>> >> > > Subject: [Sam Johnston] Cloud Standards Roadmap
>> >> > > To: s... at samj.net
>>
>> >> > > Almost a year ago in "Cloud Standards: not so fast..." I explained
>> >> > why
>> >> > > standardisation efforts were premature. A lot has happened in the
>> >> > interim
>> >> > > and it is now time to start intensively developing standards, 
>> >> > > ideally
>> >> > by
>> >> > > deriving the "consensus" of existing implementations.
>>
>> >> > > To get the ball rolling I've written a Cloud Standards Roadmap 
>> >> > > which
>> >> > can be
>> >> > > seen as an authorative source for information spanning the various
>> >> > > standardisation efforts (including identification of areas where
>> >> > effort is
>> >> > > required).
>>
>> >> > > Currently it looks like this:
>>
>> >> > > Cloud Standards Roadmap
>>
>> >> > > The cloud standards roadmap tracks the status of relevant 
>> >> > > standards
>> >> > efforts
>> >> > > underway by established multi-vendor standards bodies.
>>
>> >> > > Layer
>>
>> >> > > Description
>>
>> >> > > Group
>>
>> >> > > Project
>>
>> >> > > Status
>>
>> >> > > Due
>>
>> >> > > Client
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > Software (SaaS)
>>
>> >> > > Operating environment
>>
>> >> > > W3C
>>
>> >> > > HTML 5
>>
>> >> > > Draft
>>
>> >> > > 2008
>>
>> >> > > Event-driven scripting language
>>
>> >> > > ECMA
>>
>> >> > > ECMAScript
>>
>> >> > > Mature
>>
>> >> > > 1997
>>
>> >> > > Data-interchange format
>>
>> >> > > IETF
>>
>> >> > > JSON (RFC4627)
>>
>> >> > > Mature
>>
>> >> > > 2006
>>
>> >> > > Platform (PaaS)
>>
>> >> > > Management API
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > Infrastructure (IaaS)
>>
>> >> > > Management API
>>
>> >> > > OGF
>>
>> >> > > Cloud Infrastructure API (CIA)
>>
>> >> > > Formation
>>
>> >> > > 2009
>>
>> >> > > Container format for virtual machines
>>
>> >> > > DMTF
>>
>> >> > > Open Virtualisation Format (OVF)
>>
>> >> > > Complete
>>
>> >> > > 2009
>>
>> >> > > Descriptive language for resources
>>
>> >> > > DMTF
>>
>> >> > > CIM
>>
>> >> > > Mature
>>
>> >> > > 1999
>>
>> >> > > Fabric
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > ?
>>
>> >> > > Other standards efforts
>>
>> >> > > Cloud Standards Group
>>
>> >> > > Cloud Computing Reference Model
>> >> > > Cloud Computing Stack
>> >> > > Cloud Platform Reference Architecture
>>
>> >> > > CCIF UCI - A "singular programmatic point of contact that can
>> >> > encompass the
>> >> > > entire infrastructure stack as well as emerging cloud centric
>> >> > technologies
>> >> > > all through a unified interface"
>>
>> >> > > Vendor-owned standards
>>
>> >> > > Infrastructure
>>
>> >> > > Amazon EC2 API
>> >> > > AppNexus API
>> >> > > ElasticHosts API
>> >> > > Eucalyptus (which uses the Amazon EC2 API)
>> >> > > FlexiScale API
>> >> > > Globus Numbus (which uses the Amazon EC2 API and WSRF)
>> >> > > GoGrid API
>> >> > > OpenNebula API
>> >> > > SliceHost API
>> >> > > Sun Cloud APIs
>>
>> >> > > Fabric
>>
>> >> > > F5 iControl (Networking)
>>
>> >> > > Other resources
>>
>> >> > > Apache Tashi
>> >> > > OASIS Reference Model for Service Oriented Architecture
>>
>> >> > > Please check the Cloud Computing Community Wiki for the latest
>> >> > version as
>> >> > > this information will be quickly dated. If you have any updates
>> >> > please feel
>> >> > > free to contribute them.
>>
>> >> smime.p7s
>> >> 4KViewDownload
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Cloud Computing Interoperability Forum (CCIF)" group.
To post to this group, send email to cloudforum at googlegroups.com
To unsubscribe from this group, send email to
cloudforum+unsubscribe at googlegroups.com
For more options, visit this group at
http://groups.google.com/group/cloudforum?hl=en

-----
Join our Twitter Group at www.twitter.com/cloudforum
Or Our Linkedin Group at http://www.linkedin.com/e/gis/927567
-~----------~----~----~----~------~----~------~--~---