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@samj.net> wrote:
On Sun, Apr 19, 2009 at 9:11 PM, Alexis Richardson <alexis.richardson@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@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@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@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@samj.net> > wrote: > > On Sun, Apr 19, 2009 at 6:47 PM, Krishna Sankar (ksankar) > > <ksankar@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@gmail.com] > >> |Sent: Sunday, April 19, 2009 9:43 AM > >> |To: Krishna Sankar (ksankar) > >> |Cc: Sam Johnston; occi-wg@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@cisco.com> wrote: > >> |> And say "Cloud has no clothes" ;o) > >> |> > >> |> Cheers > >> |> <k/> > >> |> |-----Original Message----- > >> |> |From: Alexis Richardson > >> [mailto:alexis.richardson@gmail.com] > >> |> |Sent: Sunday, April 19, 2009 9:39 AM > >> |> |To: Sam Johnston > >> |> |Cc: Krishna Sankar (ksankar); occi-wg@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@samj.net> > >> wrote: > >> |> |> On Sun, Apr 19, 2009 at 6:14 PM, Krishna Sankar (ksankar) > >> |> |> <ksankar@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@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/