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

Sun Apr 19 14:32:50 CDT 2009

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