Evening, So one thing I did see validated by the rm-wg document was the trend towards compute/network/storage that we're fast settling on ourselves. Our current terminology however is far more specific - we've picked up "Drive" and "Server" from ElasticHosts for example. While this does make sense a lot of the time there's nothing to say that OCCI can't be used for VDI for example, where the "servers" are in fact "clients". Take it a step further and you've got things like Dreamhost PS<http://dreamhost.com/hosting-vps.html>which kind of like a virtual provate server in that it behaves like one (it can be restarted via their API<http://wiki.dreamhost.com/API#dreamhost_ps-reboot>etc.), only it refers to resource allocations in a shared hosting environment or MySQL instances. Granted that's outside of our remit but ther'es no point stopping them from using it by choosing our terminology poorly. In fact a lot of these functions can apply equally to physical machines as they can to lightweight threads in an Apache process (and everything in between including, of course, virtual machines which are currently our primary target). I've been trying to think of other resources outside of these three main types but even strange things like ISDN interfaces (yes, this sort of thing does appear in enterprise data centers) can be handled via PCI passthrough parameters on a virtual machine. All in all, unless anyone has any concerns about this approach I'd like to adopt this terminology throughout. Sam
Morning, Turns out this isn't such a bad idea as between writing and sending that post Andy Edmonds independently suggested exactly the same thing via the wiki (*suggestion: change workload to compute - workload might be something ran on a compute resource*). This is such a good (albeit obvious) idea - thanks David/RM-WG - that I've even updated my cloud computing reference model (attached) by adding "network' to it. Sam On Sun, Apr 19, 2009 at 10:08 AM, Sam Johnston <samj@samj.net> wrote:
Evening,
So one thing I did see validated by the rm-wg document was the trend towards compute/network/storage that we're fast settling on ourselves.
Our current terminology however is far more specific - we've picked up "Drive" and "Server" from ElasticHosts for example. While this does make sense a lot of the time there's nothing to say that OCCI can't be used for VDI for example, where the "servers" are in fact "clients". Take it a step further and you've got things like Dreamhost PS<http://dreamhost.com/hosting-vps.html>which kind of like a virtual provate server in that it behaves like one (it can be restarted via their API<http://wiki.dreamhost.com/API#dreamhost_ps-reboot>etc.), only it refers to resource allocations in a shared hosting environment or MySQL instances.
Granted that's outside of our remit but ther'es no point stopping them from using it by choosing our terminology poorly. In fact a lot of these functions can apply equally to physical machines as they can to lightweight threads in an Apache process (and everything in between including, of course, virtual machines which are currently our primary target).
I've been trying to think of other resources outside of these three main types but even strange things like ISDN interfaces (yes, this sort of thing does appear in enterprise data centers) can be handled via PCI passthrough parameters on a virtual machine.
All in all, unless anyone has any concerns about this approach I'd like to adopt this terminology throughout.
Sam
Now, it looks complete :) -- Ignacio M. Llorente, Full Professor (Catedratico): web http://dsa-research.org/llorente and blog http://imllorente.dsa-research.org/ DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org On 19/04/2009, at 10:25, Sam Johnston wrote:
Morning,
Turns out this isn't such a bad idea as between writing and sending that post Andy Edmonds independently suggested exactly the same thing via the wiki (suggestion: change workload to compute - workload might be something ran on a compute resource).
This is such a good (albeit obvious) idea - thanks David/RM-WG - that I've even updated my cloud computing reference model (attached) by adding "network' to it.
Sam
On Sun, Apr 19, 2009 at 10:08 AM, Sam Johnston <samj@samj.net> wrote: Evening,
So one thing I did see validated by the rm-wg document was the trend towards compute/network/storage that we're fast settling on ourselves.
Our current terminology however is far more specific - we've picked up "Drive" and "Server" from ElasticHosts for example. While this does make sense a lot of the time there's nothing to say that OCCI can't be used for VDI for example, where the "servers" are in fact "clients". Take it a step further and you've got things like Dreamhost PS which kind of like a virtual provate server in that it behaves like one (it can be restarted via their API etc.), only it refers to resource allocations in a shared hosting environment or MySQL instances.
Granted that's outside of our remit but ther'es no point stopping them from using it by choosing our terminology poorly. In fact a lot of these functions can apply equally to physical machines as they can to lightweight threads in an Apache process (and everything in between including, of course, virtual machines which are currently our primary target).
I've been trying to think of other resources outside of these three main types but even strange things like ISDN interfaces (yes, this sort of thing does appear in enterprise data centers) can be handled via PCI passthrough parameters on a virtual machine.
All in all, unless anyone has any concerns about this approach I'd like to adopt this terminology throughout.
Sam
<Cloud Computing Reference Model.svg><Cloud Computing Reference Model.png>_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Sam, Isn't the platform and infrastructure reversed ? IMHO, Infrastructure should be above the platform. Also shouldn't we have a VM layer just below the software ? Cheers <k/> From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: Sunday, April 19, 2009 1:25 AM To: occi-wg@ogf.org Subject: Re: [occi-wg] Resource Types: Compute / Network / Storage Morning, Turns out this isn't such a bad idea as between writing and sending that post Andy Edmonds independently suggested exactly the same thing via the wiki (suggestion: change workload to compute - workload might be something ran on a compute resource). This is such a good (albeit obvious) idea - thanks David/RM-WG - that I've even updated my cloud computing reference model (attached) by adding "network' to it. Sam On Sun, Apr 19, 2009 at 10:08 AM, Sam Johnston <samj@samj.net> wrote: Evening, So one thing I did see validated by the rm-wg document was the trend towards compute/network/storage that we're fast settling on ourselves. Our current terminology however is far more specific - we've picked up "Drive" and "Server" from ElasticHosts for example. While this does make sense a lot of the time there's nothing to say that OCCI can't be used for VDI for example, where the "servers" are in fact "clients". Take it a step further and you've got things like Dreamhost PS <http://dreamhost.com/hosting-vps.html> which kind of like a virtual provate server in that it behaves like one (it can be restarted via their API <http://wiki.dreamhost.com/API#dreamhost_ps-reboot> etc.), only it refers to resource allocations in a shared hosting environment or MySQL instances. Granted that's outside of our remit but ther'es no point stopping them from using it by choosing our terminology poorly. In fact a lot of these functions can apply equally to physical machines as they can to lightweight threads in an Apache process (and everything in between including, of course, virtual machines which are currently our primary target). I've been trying to think of other resources outside of these three main types but even strange things like ISDN interfaces (yes, this sort of thing does appear in enterprise data centers) can be handled via PCI passthrough parameters on a virtual machine. All in all, unless anyone has any concerns about this approach I'd like to adopt this terminology throughout. Sam
Krishna (I think that ..) This is meant in the sense of: SaaS PaaS IaaS .. which is I think now an accepted stack. PaaS would include things like Google App Engine which provides application services that abstract storage, network, and compute, for example database, messaging, and scheduling respectively. alexis On Sun, Apr 19, 2009 at 4:45 PM, Krishna Sankar (ksankar) <ksankar@cisco.com> wrote:
Sam,
Isn’t the platform and infrastructure reversed ? IMHO, Infrastructure should be above the platform. Also shouldn’t we have a VM layer just below the software ?
Cheers
<k/>
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: Sunday, April 19, 2009 1:25 AM To: occi-wg@ogf.org Subject: Re: [occi-wg] Resource Types: Compute / Network / Storage
Morning,
Turns out this isn't such a bad idea as between writing and sending that post Andy Edmonds independently suggested exactly the same thing via the wiki (suggestion: change workload to compute - workload might be something ran on a compute resource).
This is such a good (albeit obvious) idea - thanks David/RM-WG - that I've even updated my cloud computing reference model (attached) by adding "network' to it.
Sam
On Sun, Apr 19, 2009 at 10:08 AM, Sam Johnston <samj@samj.net> wrote:
Evening,
So one thing I did see validated by the rm-wg document was the trend towards compute/network/storage that we're fast settling on ourselves.
Our current terminology however is far more specific - we've picked up "Drive" and "Server" from ElasticHosts for example. While this does make sense a lot of the time there's nothing to say that OCCI can't be used for VDI for example, where the "servers" are in fact "clients". Take it a step further and you've got things like Dreamhost PS which kind of like a virtual provate server in that it behaves like one (it can be restarted via their API etc.), only it refers to resource allocations in a shared hosting environment or MySQL instances.
Granted that's outside of our remit but ther'es no point stopping them from using it by choosing our terminology poorly. In fact a lot of these functions can apply equally to physical machines as they can to lightweight threads in an Apache process (and everything in between including, of course, virtual machines which are currently our primary target).
I've been trying to think of other resources outside of these three main types but even strange things like ISDN interfaces (yes, this sort of thing does appear in enterprise data centers) can be handled via PCI passthrough parameters on a virtual machine.
All in all, unless anyone has any concerns about this approach I'd like to adopt this terminology throughout.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Good, makes sense. Saw Sam's e-mail as well. Am fine with SaaS, PaaS and IaaS. I also had a similar diagram at http://doubleclix.wordpress.com/2008/08/03/cloud-computing-and-grids/. It is a little outdated. 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. Cheers <k/> |-----Original Message----- |From: Alexis Richardson [mailto:alexis.richardson@gmail.com] |Sent: Sunday, April 19, 2009 8:58 AM |To: Krishna Sankar (ksankar) |Cc: Sam Johnston; occi-wg@ogf.org |Subject: Re: [occi-wg] Resource Types: Compute / Network / Storage | |Krishna | |(I think that ..) This is meant in the sense of: | |SaaS |PaaS |IaaS | |.. which is I think now an accepted stack. PaaS would include things |like Google App Engine which provides application services that |abstract storage, network, and compute, for example database, |messaging, and scheduling respectively. | |alexis | | |On Sun, Apr 19, 2009 at 4:45 PM, Krishna Sankar (ksankar) |<ksankar@cisco.com> wrote: |> Sam, |> |> Isn't the platform and infrastructure reversed ? IMHO, |> Infrastructure should be above the platform. Also shouldn't we have a |VM |> layer just below the software ? |> |> Cheers |> |> <k/> |> |> |> |> From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On |Behalf Of |> Sam Johnston |> Sent: Sunday, April 19, 2009 1:25 AM |> To: occi-wg@ogf.org |> Subject: Re: [occi-wg] Resource Types: Compute / Network / Storage |> |> |> |> Morning, |> |> Turns out this isn't such a bad idea as between writing and sending |that |> post Andy Edmonds independently suggested exactly the same thing via |the |> wiki (suggestion: change workload to compute - workload might be |something |> ran on a compute resource). |> |> This is such a good (albeit obvious) idea - thanks David/RM-WG - that |I've |> even updated my cloud computing reference model (attached) by adding |> "network' to it. |> |> Sam |> |> On Sun, Apr 19, 2009 at 10:08 AM, Sam Johnston <samj@samj.net> wrote: |> |> Evening, |> |> So one thing I did see validated by the rm-wg document was the trend |towards |> compute/network/storage that we're fast settling on ourselves. |> |> Our current terminology however is far more specific - we've picked up |> "Drive" and "Server" from ElasticHosts for example. While this does |make |> sense a lot of the time there's nothing to say that OCCI can't be used |for |> VDI for example, where the "servers" are in fact "clients". Take it a |step |> further and you've got things like Dreamhost PS which kind of like a |virtual |> provate server in that it behaves like one (it can be restarted via |their |> API etc.), only it refers to resource allocations in a shared hosting |> environment or MySQL instances. |> |> Granted that's outside of our remit but ther'es no point stopping them |from |> using it by choosing our terminology poorly. In fact a lot of these |> functions can apply equally to physical machines as they can to |lightweight |> threads in an Apache process (and everything in between including, of |> course, virtual machines which are currently our primary target). |> |> I've been trying to think of other resources outside of these three |main |> types but even strange things like ISDN interfaces (yes, this sort of |thing |> does appear in enterprise data centers) can be handled via PCI |passthrough |> parameters on a virtual machine. |> |> All in all, unless anyone has any concerns about this approach I'd |like to |> adopt this terminology throughout. |> |> Sam |> |> |> |> _______________________________________________ |> occi-wg mailing list |> occi-wg@ogf.org |> http://www.ogf.org/mailman/listinfo/occi-wg |> |>
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 <http://en.wikipedia.org/wiki/Fabric_computing>" 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<http://www.webopedia.com/TERM/f/fabric.html>to low level, interconnected hardware such as SANs and InfiniBand... and servers<http://www.itbusinessedge.com/cm/community/features/interviews/blog/fabric-computing/?cs=22018> : *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
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
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 |> |>
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 |> |>
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. Cheers <k/> |-----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 |> |> |> |> |>
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 |> |> |> |> |>
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 |> |> |> |> |>
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. 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. 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. 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. 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/
+1 KISS aaS ;-) 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.
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.
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.
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.
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/
Absolutely, but I'd never say anyone was stupid. On Sun, 2009-04-19 at 19:52 +0100, Alexis Richardson wrote:
+1
KISS aaS ;-)
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.
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.
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.
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.
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/
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<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@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
infrastructure. The Platform comes next. There is something that
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,
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
under the persistence, 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/
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@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/
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<http://en.wikipedia.org/wiki/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<http://en.wikipedia.org/wiki/Computer_network>. Both the OSI model <http://en.wikipedia.org/wiki/OSI_model> and the Internet Protocol Suite <http://en.wikipedia.org/wiki/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 <http://en.wikipedia.org/wiki/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<http://creativecommons.org/publicdomain/zero/1.0/>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
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
> 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
On Sun, 2009-04-19 at 19:19 +0100, Alexis Richardson wrote: the 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/
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/
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@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/
-- 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, On Sun, Apr 19, 2009 at 9:39 PM, Simon Wardley <simon.wardley@canonical.com>wrote:
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.
Unfortunately by doing so your taxonomy no longer functions as a taxonomy - important components are left unclassified (or worse, inappropriately classified), including client operating systems (like Android, gOS/Cloud), hardware (netbooks, nettops) and next-gen browsers (chrome) as well as underlying hardware like cisco's unified [fabric] computing gear. "no junk" doesn't imply "no complexity" and here I think we've got just enough. FYI the process of generating the last stack involved classifying everything cloud-related I could find afterwards and I'll do the same now when I find a spare moment. The observation that an application can feed another is exactly the thing that wrecked my head with the service layer<http://en.wikipedia.org/wiki/Cloud_computing#Service>- and a large part of the reason it was dropped. Trying to represent that an application can also serve as part of a platform results in both junk and confusion. I'm hoping that by covering everything concisely as we have here the result won't be rejected as "too simplistic". If however it makes sense to boil it down further for your particular application then go right ahead. Sam 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@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".
Sam, I think your diagram shows the three *service* layers that Simon also distinguishes. The 'client' and 'server' layers are context. You could IFF you wanted to make two cosmetic changes to reflect Simon's concern: (a) add 'services' to each layer heading (eg "Infrastructure Services", "Platform Services"); (b) grey out the top and bottom a bit (client and server). Simon, You are right that any layer can have a client; that is consistent with the diagram IMO. alexis On Sun, Apr 19, 2009 at 8:54 PM, Sam Johnston <samj@samj.net> wrote:
Simon,
On Sun, Apr 19, 2009 at 9:39 PM, Simon Wardley <simon.wardley@canonical.com> wrote:
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.
Unfortunately by doing so your taxonomy no longer functions as a taxonomy - important components are left unclassified (or worse, inappropriately classified), including client operating systems (like Android, gOS/Cloud), hardware (netbooks, nettops) and next-gen browsers (chrome) as well as underlying hardware like cisco's unified [fabric] computing gear. "no junk" doesn't imply "no complexity" and here I think we've got just enough. FYI the process of generating the last stack involved classifying everything cloud-related I could find afterwards and I'll do the same now when I find a spare moment.
The observation that an application can feed another is exactly the thing that wrecked my head with the service layer - and a large part of the reason it was dropped. Trying to represent that an application can also serve as part of a platform results in both junk and confusion.
I'm hoping that by covering everything concisely as we have here the result won't be rejected as "too simplistic". If however it makes sense to boil it down further for your particular application then go right ahead.
Sam
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@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".
Unfortunately by doing so your taxonomy no longer functions as a taxonomy.
Of course it does, there is no specific set rules about how defined a taxonomy must be just consensus around a set of terms. In my opinion you're making things unnecessarily complex.
FYI the process of generating the last stack involved classifying everything cloud-related
I'm not sure what you're talking about here?
The observation that an application can feed another
A taxonomy to identify discrete layers of the computing stack says nothing about how those layers can interact with each other. You don't need to make things this complex.
Trying to represent that an application can also serve as part of a platform results in both junk and confusion.
This is only true if you're trying to create a description which enforces how something is used. An application can happily be built upon a platform which also consumes feeds from multiple applications that themselves are built upon .... this is fine. A taxonomy doesn't have to define order of use or operation. Keep it simple.
I'm hoping that by covering everything concisely as we have here the result won't be rejected as "too simplistic".
Simplicity is key. You've gone to far and created a rod for your own back.
If however it makes sense to boil it down further for your particular application then go right ahead.
I now don't know what you're talking about. -- 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/
On Sun, Apr 19, 2009 at 10:20 PM, Simon Wardley <simon.wardley@canonical.com
wrote:
FYI the process of generating the last stack involved classifying everything cloud-related
I'm not sure what you're talking about here?
<snip>
If however it makes sense to boil it down further for your particular application then go right ahead.
I now don't know what you're talking about.
There are various bits that need to go in various boxes. Where do the gOS Cloud <http://www.thinkgos.com/index.html> operating system (or Ubuntu Netbook Remix for that matter) and Cisco's unified computing offering fit in the Application/Platform/Infrastructure stack? They don't, hence we need something [marginally] more complex to cover what's above and below... enter the "Servers" and "Clients" layers. If for the sake of your presentations/documentation/whatever you prefer to drop these then go for your life, but they do make sense (and are important) to some of us. Sam
So Sam, I think we agree.
:) KISS aaS goodbye perhaps.
If we could kiss goodbye to the language complexity which provides no benefit, then that would be good.
AaaS, FaaS and HaaS were never going to fly :)
This is why we had SaaS / FaaS and HaaS (we avoided the AaaS acronym). Unfortunately by mid-end 2007 this simple model of three layers had degenerated into about 15 "aaS"es, mainly due to the appearance of Jedi "thought leaders". Now, after almost two years we're back to a simple three layer model - Application / Platform / Infrastructure. Same concepts, just different names. It wouldn't surprise me with all the interest, that we get another round of "aaS" wars. I'd be very grateful if everyone could avoid changing names or layers or imposing various dodgy geometries.
Application fits with the OSI stack
Yes just no-one liked the acronym "AaaS"
"Application Service Provider"
ASP is no different from SaaS - however, that's another discussion and not for this forum.
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.
Agreed. This is why I argued that the one good thing the CCIF could do is come up with a standard taxonomy - so far, it still hasn't :-(
That mostly works for me,
That's good, but we need to encourage everyone to stick to the same terminology and not go about creating new stuff.
The fabric vs instance argument is bogus
Agreed, so let's keep it simple. 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/
All, Please heed Simon's point: On Sun, Apr 19, 2009 at 8:34 PM, Simon Wardley <simon.wardley@canonical.com> wrote:
That mostly works for me,
That's good, but we need to encourage everyone to stick to the same terminology and not go about creating new stuff.
In discussions with folks over the last few days, I have noticed a tendency to assume that OCCI is a premature exercise. The argument made is that creating an open (standard) API will either stifle innovation or simply miss the point, because clouds and cloud APIs are still evolving. A concomitant claim is that an open API will necessarily attempt to invent something new, or introduce complexity where it is unwarranted. To such people, I have been saying: At this stage, we are not trying to invent anything. IMO: our focus is on carefully representing existing art, towards a progressively simpler model. At this time, this means codifying commonality across *existing* cloud APIs and models, at the IaaS layer. Our hope is that the result of this will be something very easy to implement, with only a few verbs, and a model that is obviously consistent with other standards. The exact number of 'core' verbs is TBD - we don't yet agree on this - but my *own* hope is that the core OCCI spec is surprisingly short in pagelength if nothing else. alexis
Alexis, I completely agree with you - 100%. If you could achieve this, it would be very beneficial. On Sun, 2009-04-19 at 20:45 +0100, Alexis Richardson wrote:
All,
Please heed Simon's point:
On Sun, Apr 19, 2009 at 8:34 PM, Simon Wardley <simon.wardley@canonical.com> wrote:
That mostly works for me,
That's good, but we need to encourage everyone to stick to the same terminology and not go about creating new stuff.
In discussions with folks over the last few days, I have noticed a tendency to assume that OCCI is a premature exercise. The argument made is that creating an open (standard) API will either stifle innovation or simply miss the point, because clouds and cloud APIs are still evolving. A concomitant claim is that an open API will necessarily attempt to invent something new, or introduce complexity where it is unwarranted.
To such people, I have been saying: At this stage, we are not trying to invent anything. IMO: our focus is on carefully representing existing art, towards a progressively simpler model. At this time, this means codifying commonality across *existing* cloud APIs and models, at the IaaS layer. Our hope is that the result of this will be something very easy to implement, with only a few verbs, and a model that is obviously consistent with other standards.
The exact number of 'core' verbs is TBD - we don't yet agree on this - but my *own* hope is that the core OCCI spec is surprisingly short in pagelength if nothing else.
alexis -- 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, Thank-you for your support. And if this is our goal, then let's take it seriously. It sounds easy but it isn't. Nothing beneficial is trivial; "simplicity and generality" is often hard to achieve. a On Sun, Apr 19, 2009 at 8:55 PM, Simon Wardley <simon.wardley@canonical.com> wrote:
Alexis,
I completely agree with you - 100%.
If you could achieve this, it would be very beneficial.
On Sun, 2009-04-19 at 20:45 +0100, Alexis Richardson wrote:
All,
Please heed Simon's point:
On Sun, Apr 19, 2009 at 8:34 PM, Simon Wardley <simon.wardley@canonical.com> wrote:
That mostly works for me,
That's good, but we need to encourage everyone to stick to the same terminology and not go about creating new stuff.
In discussions with folks over the last few days, I have noticed a tendency to assume that OCCI is a premature exercise. The argument made is that creating an open (standard) API will either stifle innovation or simply miss the point, because clouds and cloud APIs are still evolving. A concomitant claim is that an open API will necessarily attempt to invent something new, or introduce complexity where it is unwarranted.
To such people, I have been saying: At this stage, we are not trying to invent anything. IMO: our focus is on carefully representing existing art, towards a progressively simpler model. At this time, this means codifying commonality across *existing* cloud APIs and models, at the IaaS layer. Our hope is that the result of this will be something very easy to implement, with only a few verbs, and a model that is obviously consistent with other standards.
The exact number of 'core' verbs is TBD - we don't yet agree on this - but my *own* hope is that the core OCCI spec is surprisingly short in pagelength if nothing else.
alexis -- 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/
Simplicity is extremely difficult to get right. On Sun, 2009-04-19 at 21:05 +0100, Alexis Richardson wrote:
Simon,
Thank-you for your support.
And if this is our goal, then let's take it seriously. It sounds easy but it isn't. Nothing beneficial is trivial; "simplicity and generality" is often hard to achieve.
a
On Sun, Apr 19, 2009 at 8:55 PM, Simon Wardley <simon.wardley@canonical.com> wrote:
Alexis,
I completely agree with you - 100%.
If you could achieve this, it would be very beneficial.
On Sun, 2009-04-19 at 20:45 +0100, Alexis Richardson wrote:
All,
Please heed Simon's point:
On Sun, Apr 19, 2009 at 8:34 PM, Simon Wardley <simon.wardley@canonical.com> wrote:
That mostly works for me,
That's good, but we need to encourage everyone to stick to the same terminology and not go about creating new stuff.
In discussions with folks over the last few days, I have noticed a tendency to assume that OCCI is a premature exercise. The argument made is that creating an open (standard) API will either stifle innovation or simply miss the point, because clouds and cloud APIs are still evolving. A concomitant claim is that an open API will necessarily attempt to invent something new, or introduce complexity where it is unwarranted.
To such people, I have been saying: At this stage, we are not trying to invent anything. IMO: our focus is on carefully representing existing art, towards a progressively simpler model. At this time, this means codifying commonality across *existing* cloud APIs and models, at the IaaS layer. Our hope is that the result of this will be something very easy to implement, with only a few verbs, and a model that is obviously consistent with other standards.
The exact number of 'core' verbs is TBD - we don't yet agree on this - but my *own* hope is that the core OCCI spec is surprisingly short in pagelength if nothing else.
alexis -- 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/
Dear colleagues, Thanks for this quite interesting thread!. I think that we all have a clear and common vision of the challenges, scope and goal of this working group, as it is described in its charter. Let us now resume the technical work. Ignacio -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org On 19/04/2009, at 22:22, Simon Wardley wrote:
Simplicity is extremely difficult to get right.
On Sun, 2009-04-19 at 21:05 +0100, Alexis Richardson wrote:
Simon,
Thank-you for your support.
And if this is our goal, then let's take it seriously. It sounds easy but it isn't. Nothing beneficial is trivial; "simplicity and generality" is often hard to achieve.
a
On Sun, Apr 19, 2009 at 8:55 PM, Simon Wardley <simon.wardley@canonical.com> wrote:
Alexis,
I completely agree with you - 100%.
If you could achieve this, it would be very beneficial.
On Sun, 2009-04-19 at 20:45 +0100, Alexis Richardson wrote:
All,
Please heed Simon's point:
On Sun, Apr 19, 2009 at 8:34 PM, Simon Wardley <simon.wardley@canonical.com> wrote:
That mostly works for me,
That's good, but we need to encourage everyone to stick to the same terminology and not go about creating new stuff.
In discussions with folks over the last few days, I have noticed a tendency to assume that OCCI is a premature exercise. The argument made is that creating an open (standard) API will either stifle innovation or simply miss the point, because clouds and cloud APIs are still evolving. A concomitant claim is that an open API will necessarily attempt to invent something new, or introduce complexity where it is unwarranted.
To such people, I have been saying: At this stage, we are not trying to invent anything. IMO: our focus is on carefully representing existing art, towards a progressively simpler model. At this time, this means codifying commonality across *existing* cloud APIs and models, at the IaaS layer. Our hope is that the result of this will be something very easy to implement, with only a few verbs, and a model that is obviously consistent with other standards.
The exact number of 'core' verbs is TBD - we don't yet agree on this - but my *own* hope is that the core OCCI spec is surprisingly short in pagelength if nothing else.
alexis -- 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/
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
One recent post by one analyst which concedes that it's a "*problematic term, perhaps, because a few of the vendors employ it towards different ends *" isn't reason enough to scuttle it (which has been in fairly widespread use for well over a decade<http://www.dominopower.com/issuesprint/issue199810/fabric.html>), especially in the absence of an alternative proposal. Appistry have dropped the term and Microsoft's Azure is now a "Services Platform<http://www.microsoft.com/azure/default.mspx>" (someone's dyslexic perhaps), even if they still use fabric sporadically with developers. This is what Cisco have to say about Unified Fabrics<http://www.cisco.com/en/US/netsol/ns945/index.html> :
*
The typical data center environment supports two to three parallel networks: one for data, one for storage, and possibly one for server clustering. In addition, servers often have dedicated interfaces for management, backup, or virtual machine live migration. Supporting these interfaces imposes significant costs related to interfaces, cabling, rack space, upstream switches, and power and cooling.
Unified fabric consolidates these different types of traffic onto a single, general-purpose, high-performance, highly available network that greatly simplifies the network infrastructure and reduces costs. To do all this, a unified fabric must be intelligent enough to identify the different types of traffic and handle them appropriately.
In addition to reducing total cost of ownership, unified fabric supports broader data center virtualization by providing consistent, ubiquitous network and storage services to all connected devices. *
I'd like to see us get some clarity here one way or another because it's a source of significant confusion (if we can't get it right between us then what are customers meant to think?). Sam On Sun, Apr 19, 2009 at 6:38 PM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
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 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
On Sun, Apr 19, 2009 at 5:37 PM, Sam Johnston <samj@samj.net> wrote: the
most obvious example). Perhaps "Hardware Fabric" would clarify?
Sam
Our current goal is to settle on an API for IaaS. Anything remotely confusing needs to be parked. In the context of this goal: "Compute", "Storage", "Network", inasmuch as they have an API, are *infrastructure services* provided by folks who are in the IaaS business. They abstract the infrastructure so that it can be consumed. Hence I suggest that 'infrastructure' is the right word to put below the three infrastructure services. We don't care what happens below that. On Sun, Apr 19, 2009 at 5:52 PM, Sam Johnston <samj@samj.net> wrote:
One recent post by one analyst which concedes that it's a "problematic term, perhaps, because a few of the vendors employ it towards different ends" isn't reason enough to scuttle it (which has been in fairly widespread use for well over a decade), especially in the absence of an alternative proposal. Appistry have dropped the term and Microsoft's Azure is now a "Services Platform" (someone's dyslexic perhaps), even if they still use fabric sporadically with developers.
This is what Cisco have to say about Unified Fabrics:
The typical data center environment supports two to three parallel networks: one for data, one for storage, and possibly one for server clustering. In addition, servers often have dedicated interfaces for management, backup, or virtual machine live migration. Supporting these interfaces imposes significant costs related to interfaces, cabling, rack space, upstream switches, and power and cooling.
Unified fabric consolidates these different types of traffic onto a single, general-purpose, high-performance, highly available network that greatly simplifies the network infrastructure and reduces costs. To do all this, a unified fabric must be intelligent enough to identify the different types of traffic and handle them appropriately.
In addition to reducing total cost of ownership, unified fabric supports broader data center virtualization by providing consistent, ubiquitous network and storage services to all connected devices.
I'd like to see us get some clarity here one way or another because it's a source of significant confusion (if we can't get it right between us then what are customers meant to think?).
Sam
On Sun, Apr 19, 2009 at 6:38 PM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
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
Thanks. Got it and agreed. We need to focus. But we should make sure we depict the world that is above and below us in a realistic way. |-----Original Message----- |From: Alexis Richardson [mailto:alexis.richardson@gmail.com] |Sent: Sunday, April 19, 2009 9:59 AM |To: Sam Johnston |Cc: Krishna Sankar (ksankar); occi-wg@ogf.org |Subject: Re: [occi-wg] Resource Types: Compute / Network / Storage | |Our current goal is to settle on an API for IaaS. Anything remotely |confusing needs to be parked. | |In the context of this goal: | |"Compute", "Storage", "Network", inasmuch as they have an API, are |*infrastructure services* provided by folks who are in the IaaS |business. They abstract the infrastructure so that it can be |consumed. Hence I suggest that 'infrastructure' is the right word to |put below the three infrastructure services. We don't care what |happens below that. | | | |On Sun, Apr 19, 2009 at 5:52 PM, Sam Johnston <samj@samj.net> wrote: |> One recent post by one analyst which concedes that it's a "problematic |term, |> perhaps, because a few of the vendors employ it towards different |ends" |> isn't reason enough to scuttle it (which has been in fairly widespread |use |> for well over a decade), especially in the absence of an alternative |> proposal. Appistry have dropped the term and Microsoft's Azure is now |a |> "Services Platform" (someone's dyslexic perhaps), even if they still |use |> fabric sporadically with developers. |> |> This is what Cisco have to say about Unified Fabrics: |>> |>> The typical data center environment supports two to three parallel |>> networks: one for data, one for storage, and possibly one for server |>> clustering. In addition, servers often have dedicated interfaces for |>> management, backup, or virtual machine live migration. Supporting |these |>> interfaces imposes significant costs related to interfaces, cabling, |rack |>> space, upstream switches, and power and cooling. |>> |>> Unified fabric consolidates these different types of traffic onto a |>> single, general-purpose, high-performance, highly available network |that |>> greatly simplifies the network infrastructure and reduces costs. To |do all |>> this, a unified fabric must be intelligent enough to identify the |different |>> types of traffic and handle them appropriately. |>> |>> In addition to reducing total cost of ownership, unified fabric |supports |>> broader data center virtualization by providing consistent, |ubiquitous |>> network and storage services to all connected devices. |> |> I'd like to see us get some clarity here one way or another because |it's a |> source of significant confusion (if we can't get it right between us |then |> what are customers meant to think?). |> |> Sam |> |> On Sun, Apr 19, 2009 at 6:38 PM, Alexis Richardson |> <alexis.richardson@gmail.com> wrote: |>> |>> 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 |>> > |>> > |> |>
Sam, Terminology of Iaas is defenitely tilted toward soft view, hence why it seems to fall into SaaS terminology. I recommend we make sure that terminology is consistent from a software and system administrator stand-point who often our the "owners" of this infrasture. - Colleen On Sun, Apr 19, 2009 at 9:37 AM, 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<http://en.wikipedia.org/wiki/Fabric_computing>" 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<http://www.webopedia.com/TERM/f/fabric.html>to low level, interconnected hardware such as SANs and InfiniBand... and servers<http://www.itbusinessedge.com/cm/community/features/interviews/blog/fabric-computing/?cs=22018> :
*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
-- ========== Colleen Smith email: colleen1@gmail.com
G'day Krishna, Actually no, that's by design and the deviation from last year's 6 layer stack (see Wikipedia <http://en.wikipedia.org/wiki/Cloud_computing>) was to take into account a trend towards the (overly simplistic IMO) infrastructure (IaaS) / platform (PaaS) and software (SaaS) three-layer stack. I think this model finds a good balance without going overboard<http://rationalsecurity.typepad.com/blog/2009/01/cloud-computing-taxonomy-ontology-please-review.html>*. Software runs on a platform which runs on infrastructure. Regarding terminology, I think we've all had more than enough *aaS so I generally push the following terminology: - Software as a Service -> Cloud Software [Services] -> Software Services - Platform as a Service -> Cloud Platform [Services] -> Platform Services - Infrastructure as a Service -> Cloud Infrastructure Services -> Infrastructure Services I'm imagining that before too long we'll have "Cloud" in front of everything (because everything is cloud computing, right?) and then it will just fade away as has been the case with previous paradigm shifts. I'm also imagining that infrastructure will fast become boring and "cloud as an operating environment" with loosely coupled components connected by queues and the like will take over. Sam * more complex modelling is useful for implementors moreso than consumers. On Sun, Apr 19, 2009 at 5:45 PM, Krishna Sankar (ksankar) <ksankar@cisco.com
wrote:
Sam,
Isn’t the platform and infrastructure reversed ? IMHO, Infrastructure should be above the platform. Also shouldn’t we have a VM layer just below the software ?
Cheers
<k/>
*From:* occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] *On Behalf Of *Sam Johnston *Sent:* Sunday, April 19, 2009 1:25 AM *To:* occi-wg@ogf.org *Subject:* Re: [occi-wg] Resource Types: Compute / Network / Storage
Morning,
Turns out this isn't such a bad idea as between writing and sending that post Andy Edmonds independently suggested exactly the same thing via the wiki (*suggestion: change workload to compute - workload might be something ran on a compute resource*).
This is such a good (albeit obvious) idea - thanks David/RM-WG - that I've even updated my cloud computing reference model (attached) by adding "network' to it.
Sam
On Sun, Apr 19, 2009 at 10:08 AM, Sam Johnston <samj@samj.net> wrote:
Evening,
So one thing I did see validated by the rm-wg document was the trend towards compute/network/storage that we're fast settling on ourselves.
Our current terminology however is far more specific - we've picked up "Drive" and "Server" from ElasticHosts for example. While this does make sense a lot of the time there's nothing to say that OCCI can't be used for VDI for example, where the "servers" are in fact "clients". Take it a step further and you've got things like Dreamhost PS<http://dreamhost.com/hosting-vps.html>which kind of like a virtual provate server in that it behaves like one (it can be restarted via their API<http://wiki.dreamhost.com/API#dreamhost_ps-reboot>etc.), only it refers to resource allocations in a shared hosting environment or MySQL instances.
Granted that's outside of our remit but ther'es no point stopping them from using it by choosing our terminology poorly. In fact a lot of these functions can apply equally to physical machines as they can to lightweight threads in an Apache process (and everything in between including, of course, virtual machines which are currently our primary target).
I've been trying to think of other resources outside of these three main types but even strange things like ISDN interfaces (yes, this sort of thing does appear in enterprise data centers) can be handled via PCI passthrough parameters on a virtual machine.
All in all, unless anyone has any concerns about this approach I'd like to adopt this terminology throughout.
Sam
Hi, Regarding the terminology I would still suggest to use *aaS so everybody know what we are talking about and we do not need to explain our-selfs in footnotes or similar. I know somebody might get bored of the *aaS think but let's not create a new terminology for something that already exists. Cheers, -Thijs On Sun, 2009-04-19 at 18:00 +0200, Sam Johnston wrote:
G'day Krishna,
Actually no, that's by design and the deviation from last year's 6 layer stack (see Wikipedia) was to take into account a trend towards the (overly simplistic IMO) infrastructure (IaaS) / platform (PaaS) and software (SaaS) three-layer stack. I think this model finds a good balance without going overboard*. Software runs on a platform which runs on infrastructure.
Regarding terminology, I think we've all had more than enough *aaS so I generally push the following terminology: * Software as a Service -> Cloud Software [Services] -> Software Services * Platform as a Service -> Cloud Platform [Services] -> Platform Services * Infrastructure as a Service -> Cloud Infrastructure Services -> Infrastructure Services I'm imagining that before too long we'll have "Cloud" in front of everything (because everything is cloud computing, right?) and then it will just fade away as has been the case with previous paradigm shifts.
I'm also imagining that infrastructure will fast become boring and "cloud as an operating environment" with loosely coupled components connected by queues and the like will take over.
Sam
* more complex modelling is useful for implementors moreso than consumers.
On Sun, Apr 19, 2009 at 5:45 PM, Krishna Sankar (ksankar) <ksankar@cisco.com> wrote: Sam,
Isn’t the platform and infrastructure reversed ? IMHO, Infrastructure should be above the platform. Also shouldn’t we have a VM layer just below the software ?
Cheers
<k/>
From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Sam Johnston Sent: Sunday, April 19, 2009 1:25 AM To: occi-wg@ogf.org Subject: Re: [occi-wg] Resource Types: Compute / Network / Storage
Morning,
Turns out this isn't such a bad idea as between writing and sending that post Andy Edmonds independently suggested exactly the same thing via the wiki (suggestion: change workload to compute - workload might be something ran on a compute resource).
This is such a good (albeit obvious) idea - thanks David/RM-WG - that I've even updated my cloud computing reference model (attached) by adding "network' to it.
Sam
On Sun, Apr 19, 2009 at 10:08 AM, Sam Johnston <samj@samj.net> wrote:
Evening,
So one thing I did see validated by the rm-wg document was the trend towards compute/network/storage that we're fast settling on ourselves.
Our current terminology however is far more specific - we've picked up "Drive" and "Server" from ElasticHosts for example. While this does make sense a lot of the time there's nothing to say that OCCI can't be used for VDI for example, where the "servers" are in fact "clients". Take it a step further and you've got things like Dreamhost PS which kind of like a virtual provate server in that it behaves like one (it can be restarted via their API etc.), only it refers to resource allocations in a shared hosting environment or MySQL instances.
Granted that's outside of our remit but ther'es no point stopping them from using it by choosing our terminology poorly. In fact a lot of these functions can apply equally to physical machines as they can to lightweight threads in an Apache process (and everything in between including, of course, virtual machines which are currently our primary target).
I've been trying to think of other resources outside of these three main types but even strange things like ISDN interfaces (yes, this sort of thing does appear in enterprise data centers) can be handled via PCI passthrough parameters on a virtual machine.
All in all, unless anyone has any concerns about this approach I'd like to adopt this terminology throughout.
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
I've never liked the word 'server' which we (EH) expose in our public API docs, so please don't feel any pressure from me to use this term. I'd prefer something more general too. (I wrote the infrastructure layer of our system, and consistently throughout the code they're called 'guests' instead, by analogy with 'hosts' which actually run the virtual machines. Our customer-facing api offers this as an alternative, but we felt it was a bit too technical a word to use in the web interface.) I'm happy with any reasonable choices here, except that to avoid an ugly API, whatever set of words we pick should be single shortish words (not multiple words, and preferably not abbreviations) of a grammatically equivalent type: compute, storage, networking work, as do {computers,guests,instances,servers,machines}, {stores,drives}, networks but mixing between the groups is less good---I can create 'a drive' or 'a computer' but not 'a compute'. Whatever happens, we don't want to leave an illiterate legacy like HTTP's ghastly 'Referer:' header! Cheers, Chris.
participants (8)
-
Alexis Richardson -
Chris Webb -
colleen smith -
Ignacio Martin Llorente -
Krishna Sankar (ksankar) -
Sam Johnston -
Simon Wardley -
Thijs Metsch