[occi-wg] Resource Types: Compute / Network / Storage

Sun Apr 19 14:39:49 CDT 2009

I'd strongly advise you to drop the client / server aspect and in
particular remove the sub-tags such as components / services.

Don't assume that an application won't be used as a component in a mash
up or used as a service to build another application etc. Also platforms
(i.e. GAE) have user interfaces ... you're going to get into all sorts
of confusion.

Keep it really simple - Application / Platform  / Infrastructure.

On Sun, 2009-04-19 at 20:32 +0100, Alexis Richardson wrote:
> Unfortunately 'application layer' in the OSI case could cover Platform
> in our case.
> 
> Nevertheless, I think your diagram is fine.
> 
> 
> On Sun, Apr 19, 2009 at 8:31 PM, Sam Johnston <samj at samj.net> wrote:
> > On Sun, Apr 19, 2009 at 9:11 PM, Alexis Richardson
> > <alexis.richardson at gmail.com> wrote:
> >>
> >> Thanks Sam.  That is great.
> >>
> >> To borrow a phrase: "No junk, no confusion".
> >
> > Thanks. On further investigation it turns out that the "application layer"
> > is a well accepted concept independent of the OSI stack:
> >
> >> Application Layer is a term used in categorizing protocols and methods in
> >> architectural models of computer networking. Both the OSI model and the
> >> Internet Protocol Suite (TCP/IP) contain an application layer.
> >
> > "Software" on the other hand, *is* confusing.
> >
> > So I've attached b/w and colour versions of the stack (calling it a
> > reference model is ambitious) as well as the OmniGraffle sources. I've also
> > removed the CC-BY-SA requirement so it's now under the new CC Zero license
> > (e.g. public domain). That basically means you can use it how you like
> > without even having to give attribution (which is not to say you
> > can't/shouldn't, and claiming it as your own invention would be
> > disingenous).
> >
> > Sam
> >
> >> On Sun, Apr 19, 2009 at 8:09 PM, Sam Johnston <samj at samj.net> wrote:
> >> >>> You could put 'clients' at the top and 'servers' at the bottom.
> >> >
> >> > Ooh, that's almost too clean... the reason for these layers incidentally
> >> > is
> >> > that an effective taxonomy should cater for all subjects and both
> >> > clients
> >> > (like netbooks, next gen browsers, etc.) and servers (unified computing
> >> > et
> >> > al) were left high and dry.
> >> >
> >> > Other comments inline.
> >> >
> >> > On Sun, Apr 19, 2009 at 8:55 PM, Simon Wardley
> >> > <simon.wardley at canonical.com>
> >> > wrote:
> >> >>
> >> >> Absolutely, but I'd never say anyone was stupid.
> >> >>
> >> >> On Sun, 2009-04-19 at 19:52 +0100, Alexis Richardson wrote:
> >> >> > +1
> >> >> >
> >> >> > KISS aaS ;-)
> >> >
> >> > :) KISS aaS goodbye perhaps.
> >> >
> >> >>
> >> >> > On Sun, Apr 19, 2009 at 7:48 PM, Simon Wardley
> >> >> > <simon.wardley at canonical.com> wrote:
> >> >> > > My $0.0001 cents work
> >> >> > >
> >> >> > > Back in 2006 we used to describe the computing stack (when it came
> >> >> > > to
> >> >> > > utility computing) in terms of three layers :-
> >> >> > >
> >> >> > > Software : the provision of complete user applications [no-one
> >> >> > > wanted
> >> >> > > to
> >> >> > > call it applications because the acronym would have been
> >> >> > > "Application
> >> >> > > as
> >> >> > > a Server or "AaaS"]
> >> >> > >
> >> >> > > Framework: includes development platform, messaging queue,
> >> >> > > databases
> >> >> > > and
> >> >> > > all the common elements used in the creation of an application.
> >> >> > >
> >> >> > > Hardware : the provision of raw compute resources, storage and
> >> >> > > networks.
> >> >
> >> > AaaS, FaaS and HaaS were never going to fly :) But now we're talking
> >> > about
> >> > de-aaSing it matters less. I prefer Infrastructure and Platform... I'm
> >> > just
> >> > stuck on Application (my first choice) vs Software (more a concession
> >> > for
> >> > the "software services"/SaaS bandwagon).
> >> >
> >> > I'd be interested in hearing thoughts on having an application vs a
> >> > software
> >> > layer. Application fits with the OSI stack and earlier concepts like
> >> > "Application Service Provider"... "Software Services" is easily confused
> >> > with "Software + Services" but is less of a stretch from "SaaS".
> >> >
> >> > If we can find something which is generally acceptable (and get people
> >> > to
> >> > accept it) then our users are going to be less confused/scared about
> >> > adopting cloud computing.
> >> >
> >> >>
> >> >> > > These ideas were based upon the concepts of componentisation.
> >> >> > > Obviously
> >> >> > > since that time we've had all the renaming games and as Lefkowtiz
> >> >> > > described back in July 2007 the "aaS" wars caused by the appearance
> >> >> > > of
> >> >> > > Jedi thought masters.
> >> >> > >
> >> >> > > By the beginning of 2009 we had settled once again on a three layer
> >> >> > > structure of application / platform / infrastructure.  Obviously
> >> >> > > above
> >> >> > > these are additional layers such as data, process, organisation and
> >> >> > > ....
> >> >> > > but let's not get into it.
> >> >> > >
> >> >> > > Can we please stick to the three layers of application, platform
> >> >> > > and
> >> >> > > infrastructure and not introduce any NEW concepts.
> >> >
> >> > That mostly works for me, and that's why those three layers are
> >> > highlighted
> >> > in my diagrams, but see comments above about effective taxonomies.
> >> >
> >> >>
> >> >> > > As for fabric or instance based - all three layers can be provided
> >> >> > > either on a fabric or instance basis. SOLO is an example of an
> >> >> > > instance
> >> >> > > based PaaS whereas Azure is a fabric based PaaS etc. EC2 might be
> >> >> > > instance based IaaS but there is no reason why we can't (with SSI)
> >> >> > > more
> >> >> > > of a fabric based IaaS.
> >> >
> >> > The fabric vs instance argument is bogus - there's a whole spectrum
> >> > (consider for example an app running in a single virtual instance which,
> >> > thanks to fancy hardware, has an obscene amount of memory and processor
> >> > cores). That's ok becuase differentiating is not particularly helpful
> >> > anyway.
> >> >
> >> >>
> >> >> > > Of course this is from an user perspective. From an operator
> >> >> > > perspective
> >> >> > > you might end up with bare bones -> SSI (providing a large fabric)
> >> >> > > ->
> >> >> > > virtual instances (for end users).
> >> >> > >
> >> >> > > All sorts of combinations are possible. This is why we always tried
> >> >> > > to
> >> >> > > keep it simple. I'd suggest you focus on instance based
> >> >> > > infrastructure
> >> >> > > and keep it simple.
> >> >
> >> > All this stuff looks the same anyway - you can start, stop and restart a
> >> > fabric based platform workload just as much as you can an instance based
> >> > infrastructure workload.
> >> >
> >> > Sam
> >> >
> >> >> > > Just my thoughts ...
> >> >> > >
> >> >> > > Kindest
> >> >> > >
> >> >> > > Simon W
> >> >> > >
> >> >> > >
> >> >> > > On Sun, 2009-04-19 at 19:19 +0100, Alexis Richardson wrote:
> >> >> > >> You could put 'clients' at the top and 'servers' at the bottom.
> >> >> > >>
> >> >> > >>
> >> >> > >> On Sun, Apr 19, 2009 at 6:03 PM, Sam Johnston <samj at samj.net>
> >> >> > >> wrote:
> >> >> > >> > On Sun, Apr 19, 2009 at 6:47 PM, Krishna Sankar (ksankar)
> >> >> > >> > <ksankar at cisco.com> wrote:
> >> >> > >> >>
> >> >> > >> >> Going back, I think, first the Compute, Storage, Network should
> >> >> > >> >> be
> >> >> > >> >> under
> >> >> > >> >> infrastructure. The Platform comes next. There is something
> >> >> > >> >> that
> >> >> > >> >> the
> >> >> > >> >> PaaS provides more than IaaS and that need to go there.
> >> >> > >> >
> >> >> > >> > OK so there are 5 layers here (there were 6 but "storage" has
> >> >> > >> > been
> >> >> > >> > consumed
> >> >> > >> > by "infrastructure" and "services" by "software" - "fabric" was
> >> >> > >> > spawned
> >> >> > >> > primarily in response to Cisco's "unified computing" foray into
> >> >> > >> > the
> >> >> > >> > server
> >> >> > >> > space):
> >> >> > >> >
> >> >> > >> > Client
> >> >> > >> > Software
> >> >> > >> > Platform
> >> >> > >> > Infrastructure
> >> >> > >> > Fabric
> >> >> > >> >
> >> >> > >> > The idea is that fabric delivers raw computing power to the
> >> >> > >> > infrastructure
> >> >> > >> > layer, which in turn delivers neatly packaged compute / network
> >> >> > >> > /
> >> >> > >> > storage to
> >> >> > >> > the platform layer, which delivers components (e.g. queues,
> >> >> > >> > persistence,
> >> >> > >> > etc.) and services (e.g. search, data feeds) to the software
> >> >> > >> > which
> >> >> > >> > in turn
> >> >> > >> > delivers machine and user interfaces to the clients (e.g.
> >> >> > >> > twitter
> >> >> > >> > web vs
> >> >> > >> > api).
> >> >> > >> >
> >> >> > >> > In any case the thing I care about for OCCI is that
> >> >> > >> > Infrastructure
> >> >> > >> > ~=
> >> >> > >> > Compute / Network / Storage and I don't think we've got any
> >> >> > >> > contention
> >> >> > >> > there.
> >> >> > >> >
> >> >> > >> > Sam
> >> >> > >> >
> >> >> > >> >>
> >> >> > >> >> |-----Original Message-----
> >> >> > >> >> |From: Alexis Richardson [mailto:alexis.richardson at gmail.com]
> >> >> > >> >> |Sent: Sunday, April 19, 2009 9:43 AM
> >> >> > >> >> |To: Krishna Sankar (ksankar)
> >> >> > >> >> |Cc: Sam Johnston; occi-wg at ogf.org
> >> >> > >> >> |Subject: Re: [occi-wg] Resource Types: Compute / Network /
> >> >> > >> >> Storage
> >> >> > >> >> |
> >> >> > >> >> |Ha, indeed :-)
> >> >> > >> >> |
> >> >> > >> >> |Standards don't need window dressing ...
> >> >> > >> >> |
> >> >> > >> >> |
> >> >> > >> >> |On Sun, Apr 19, 2009 at 5:39 PM, Krishna Sankar (ksankar)
> >> >> > >> >> |<ksankar at cisco.com> wrote:
> >> >> > >> >> |> And say "Cloud has no clothes" ;o)
> >> >> > >> >> |>
> >> >> > >> >> |> Cheers
> >> >> > >> >> |> <k/>
> >> >> > >> >> |> |-----Original Message-----
> >> >> > >> >> |> |From: Alexis Richardson
> >> >> > >> >> [mailto:alexis.richardson at gmail.com]
> >> >> > >> >> |> |Sent: Sunday, April 19, 2009 9:39 AM
> >> >> > >> >> |> |To: Sam Johnston
> >> >> > >> >> |> |Cc: Krishna Sankar (ksankar); occi-wg at ogf.org
> >> >> > >> >> |> |Subject: Re: [occi-wg] Resource Types: Compute / Network /
> >> >> > >> >> Storage
> >> >> > >> >> |> |
> >> >> > >> >> |> |Fabric is also used to refer to PaaS:
> >> >> > >> >> |> |http://redmonk.com/sogrady/2008/11/14/cloud-types/
> >> >> > >> >> |> |
> >> >> > >> >> |> |I suggest we drop the word 'fabric'.
> >> >> > >> >> |> |
> >> >> > >> >> |> |
> >> >> > >> >> |> |On Sun, Apr 19, 2009 at 5:37 PM, Sam Johnston
> >> >> > >> >> <samj at samj.net>
> >> >> > >> >> wrote:
> >> >> > >> >> |> |> On Sun, Apr 19, 2009 at 6:14 PM, Krishna Sankar (ksankar)
> >> >> > >> >> |> |> <ksankar at cisco.com> wrote:
> >> >> > >> >> |> |>>
> >> >> > >> >> |> |>> But then SaaS is Software over PaaS; PaaS is fabric over
> >> >> > >> >> IaaS;
> >> >> > >> >> |IaaS
> >> >> > >> >> |> |is
> >> >> > >> >> |> |>> compute, storage and network. Isn't fabric the P is PaaS
> >> >> > >> >> ?
> >> >> > >> >> and in
> >> >> > >> >> |> |IaaS, we
> >> >> > >> >> |> |>> see raw compute/storage/network ?
> >> >> > >> >> |> |>>
> >> >> > >> >> |> |>> If we want to maintain the
> >> >> > >> >> Software-Platform-Infrastructure
> >> >> > >> >> |> |terminology
> >> >> > >> >> |> |>> hierarchy I am fine with that. Then we should switch the
> >> >> > >> >> fabric
> >> >> > >> >> |and
> >> >> > >> >> |> |the
> >> >> > >> >> |> |>> Compute-Storage-Network.
> >> >> > >> >> |> |>
> >> >> > >> >> |> |> [Ab]use of the term "fabric" to refer to software
> >> >> > >> >> platforms
> >> >> > >> >> like
> >> >> > >> >> |> Azure
> >> >> > >> >> |> |is so
> >> >> > >> >> |> |> far as I can tell a fairly recent trend (and one I'm
> >> >> > >> >> relatively
> >> >> > >> >> |> |unconvinced
> >> >> > >> >> |> |> by). Granted the contept (whereby many interconnected
> >> >> > >> >> nodes,
> >> >> > >> >> when
> >> >> > >> >> |> |viewed
> >> >> > >> >> |> |> from a distance, appear to be a single coherent "fabric")
> >> >> > >> >> could be
> >> >> > >> >> |> |applied
> >> >> > >> >> |> |> to both hardware and software, but it is most often
> >> >> > >> >> applied
> >> >> > >> >> to low
> >> >> > >> >> |> |level,
> >> >> > >> >> |> |> interconnected hardware such as SANs and InfiniBand...
> >> >> > >> >> and
> >> >> > >> >> servers:
> >> >> > >> >> |> |>
> >> >> > >> >> |> |>> What is fabric computing and how does it improve upon
> >> >> > >> >> current
> >> >> > >> >> |server
> >> >> > >> >> |> |>> technology?
> >> >> > >> >> |> |>> The simplest way to think about it is the
> >> >> > >> >> next-generation
> >> >> > >> >> |> |architecture for
> >> >> > >> >> |> |>> enterprise servers. Fabric computing combines powerful
> >> >> > >> >> server
> >> >> > >> >> |> |capabilities
> >> >> > >> >> |> |>> and advanced networking features into a single server
> >> >> > >> >> structure.
> >> >> > >> >> |> |>
> >> >> > >> >> |> |> We do need something to refer to the underlying
> >> >> > >> >> hardware/firmware
> >> >> > >> >> |but
> >> >> > >> >> |> |I'm
> >> >> > >> >> |> |> even less convinced by proposed alternatives ("unified
> >> >> > >> >> computing"
> >> >> > >> >> |> |being the
> >> >> > >> >> |> |> most obvious example). Perhaps "Hardware Fabric" would
> >> >> > >> >> clarify?
> >> >> > >> >> |> |>
> >> >> > >> >> |> |> Sam
> >> >> > >> >> |> |>
> >> >> > >> >> |> |>
> >> >> > >> >> |>
> >> >> > >> >
> >> >> > >> >
> >> >> > >> _______________________________________________
> >> >> > >> occi-wg mailing list
> >> >> > >> occi-wg at ogf.org
> >> >> > >> http://www.ogf.org/mailman/listinfo/occi-wg
> >> >> > > --
> >> >> > > Simon Wardley
> >> >> > > Software Services Manager,
> >> >> > > Canonical Ltd.
> >> >> > > TEL: +44 (0)207 630 2451
> >> >> > > MOB : +44 (0)7972 911 449
> >> >> > > TWITTER: http://www.twitter.com/swardley/
> >> >> > >
> >> >> > >
> >> >> --
> >> >> Simon Wardley
> >> >> Software Services Manager,
> >> >> Canonical Ltd.
> >> >> TEL: +44 (0)207 630 2451
> >> >> MOB : +44 (0)7972 911 449
> >> >> TWITTER: http://www.twitter.com/swardley/
> >> >>
> >> >
> >> >
> >
> >
-- 
Simon Wardley
Software Services Manager,
Canonical Ltd.
TEL: +44 (0)207 630 2451
MOB : +44 (0)7972 911 449
TWITTER: http://www.twitter.com/swardley/