Cloud Standards Roadmap

[Sam Johnston]

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 <sa...@samj.net>
Date: Tue, Mar 24, 2009 at 11:06 AM
Subject: [Sam Johnston] Cloud Standards Roadmap
To: sa...@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.

[Paulo Calcada]

Hello Sam,

I think that it would be very important adding to your "model" a layer dedicated to the Calculus (CPU or computing power) question, such as GRID computing or things like AMD Render Fusion.  I think that both IaaS, PaaS or SaaS are layers well defined, but none of them contains attributes that could be considered useful to the computing or calculus power paradigm.

In the follow up of other things that I've presented, and also in the same perspective that others also have done, I could resume my (naive) view or model in the following layered sequence:

SaaS - end-users
PaaS - developers and entrepreneurs
IaaS - IT administrators
GRID or other  complex processing solutions that would deploy specific large amount of computing power - scientific or technical advance solutions

Paulo
www.cloudviews.org

2009/3/24 Sam Johnston <sa...@samj.net>

[Alexis Richardson]

GRID is a tricky one. When it defines an application execution model
(eg "tasks") it is PaaS. When it speaks to the management of general
infra, I think it is IaaS. And of course, you could have a SaaS
offering for grid computing. So IMO, GRID is orthogonal and "a
technology".

a

[Paulo Calcada]

Yes, definitely, GRID is something that could be "sold" directly to any of the upper layers, but that is not a problem, the same is
happening with IaaS, you could use it directly as a service or you could use it to provide the supporting layer to and PaaS and the to the SaaS :)

I come from an Higher education Institution and for me we could perfectly use the wikipedia definition:

"Grid computing (or the use of a computational grid) is the application of several computers to a single problem at the same time – usually to a scientific or technical problem that requires a great number of computer processing cycles or access to large amounts of data."

So, GRID, in my prespective is something that we must have inside a Cloud Computing diagram, and for me is also clear that we should put here all the questions related to the "heavy" computing power.


Paulo

2009/3/24 Alexis Richardson <alexis.r...@gmail.com>

[Alexis Richardson]

IMHO:

We should look at what cloud / vitual data center providers are
actually DOING and work from there. People have done good work
summarising APIs as a starting point for the next steps. GRID people
will know how to position GRID around this.

[Lori Mac Vittie]

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

 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cloud Standards" group.
To post to this group, send email to cloud-s...@googlegroups.com
To unsubscribe from this group, send email to cloud-standar...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cloud-standards?hl=en
-~----------~----~----~----~------~----~------~--~---

[Paulo Calcada]

What you are suggesting is that we could remove GRID from the  Cloud Computing diagram, because GRID guys will use Cloud / virtual data centers?

Is not a bad idea :)

[Alexis Richardson]

Yes - at least for now.

Trust me, if it is important for this initiative then it will come
back, at the right time.

[Alexis Richardson]

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.

[Sam Johnston]

Hi Lori,

I haven't got around to announcing it yet but I've refined last year's 6 layer stack already (see attached), adding a 'Fabric' layer below infrastructure, collapsing "Services" and "Applications" into "Software" and "Storage" into "Infrastructure" and emphasising the three universally accepted layers: Infrastructure (IaaS), Platform (PaaS) and Software (SaaS). This "stack" is effectively a "taxonomy" and (simple) "ontology" in one and so far as I can tell it covers all solutions available today; the hard part was making it simple. So far as I can tell it now covers all the solutions that the previous one did not.

I've attached SVG and PNG versions which are CC0 licensed to avoid "not invented here" problems associated with attribution requirements.

Orchestration APIs are an interesting idea too - most of the APIs we've spoken about are user-facing and while providers could also benefit from such standardisation we have to start somewhere.

Cheers,

Sam

[Lori Mac Vittie]

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

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Cloud Standards" group.
> To post to this group, send email to cloud-s...@googlegroups.com
> To unsubscribe from this group, send email to cloud-

> standards+...@googlegroups.com

[Alexis Richardson]

Lori,

On Tue, Mar 24, 2009 at 11:42 AM, Lori Mac Vittie <L.Mac...@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.

Cool. Understood. I think the keyword here is 'future'.

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

Excellent -- and your voice will be critical to making sure that
happens. If you see APIs that you think will not admit of
orchestrability, speak out.

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

Proponents of REST would argue that HATEOAS gives the latter while
staying within the metaphor of the former.

a

[pnrasm]

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...@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-s...@googlegroups.com [mailto:cloud-
> > stan...@googlegroups.com] On Behalf Of Alexis Richardson
> > Sent: Tuesday, March 24, 2009 4:21 AM
> > To: cloud-s...@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...@f5.com>

>  smime.p7s
> 4KViewDownload

[Alexis Richardson]

Well right now we have one API per provider. Is that too many or too few?

[pnrasm]

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...@gmail.com>
wrote:

> Well right now we have one API per provider.  Is that too many or too few?
>

[Alexis Richardson]

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".

[Jason Meiers]

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.

[Alexis Richardson]

Exactly!

That is a great example. Thanks Michael.

On Fri, Jun 16, 2017 at 12:16 AM, Michael Richardson
<m...@sandelman.ottawa.on.ca> wrote:
>
>>>>>> "Lori" == Lori Mac Vittie <L.Mac...@F5.com> writes:
>    Lori> The APIs can't be purely resource based, there should be
>    Lori> application/operational APIs as well, which is a good place to
>    Lori> keep in mind an orchestration layer might need to use it.
>
>  It's worth reading this comment from Seth Ladd
>       http://www.tbray.org/ongoing/When/200x/2009/03/20/Rest-Casuistry#c1237592841.237066
>  on Tim Bray's blog.
>
> --
> ]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
> ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
> _______________________________________________
> Capi-bof mailing list
> Capi...@ogf.org
> http://www.ogf.org/mailman/listinfo/capi-bof
>