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

Sun Apr 19 14:09:14 CDT 2009

 >> 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<http://en.wikipedia.org/wiki/Cloud_computing#Components>)
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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090419/9f7bba33/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cloud Computing Reference Model.svg
Type: image/svg+xml
Size: 9317 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20090419/9f7bba33/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Cloud Computing Reference Model.png
Type: image/png
Size: 48715 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20090419/9f7bba33/attachment.png 