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

Krishna Sankar (ksankar) ksankar at cisco.com
Sun Apr 19 11:14:55 CDT 2009


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 at gmail.com]
|Sent: Sunday, April 19, 2009 8:58 AM
|To: Krishna Sankar (ksankar)
|Cc: Sam Johnston; occi-wg at 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 at 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 at ogf.org [mailto:occi-wg-bounces at ogf.org] On
|Behalf Of
|> Sam Johnston
|> Sent: Sunday, April 19, 2009 1:25 AM
|> To: occi-wg at 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 at 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 at ogf.org
|> http://www.ogf.org/mailman/listinfo/occi-wg
|>
|>



More information about the occi-wg mailing list