[occi-wg] Resource Types: Compute / Network / Storage
Thijs Metsch
Thijs.Metsch at Sun.COM
Mon Apr 20 02:45:26 CDT 2009
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 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
--
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 at sun.com
D-93049 Regensburg http://www.sun.com
More information about the occi-wg
mailing list