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

Sun Apr 19 14:11:49 CDT 2009

Thanks Sam.  That is great.

To borrow a phrase: "No junk, no confusion".

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