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

[Sam Johnston]

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 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<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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090419/4c1c2618/attachment.html