[occi-wg] Future OCCI extensibility: compute, storage, network, service, application

[Sam Johnston]

On Mon, May 18, 2009 at 11:19 AM, Richard Davies <
richard.davies at elastichosts.com> wrote:

> Sm Johnston wrote:
> > Is it obvious to anyone else what the next resource extensions after
> > compute, network and storage should be? Is there still someone who needs
> > convincing that we need to have extensibility at the heart of the
> protocol
> > and build incrementally?
>
> and elsewhere:
> > billing, SLAs, monitoring, etc.
> ...
> > <deployment of applications>
>
> I do understand that extensibility is important, but believe we're running
> a
> long way ahead of ourselves here.
>
> I believe that compute, storage and networking can be standardized and
> adopted today, but that anything else is likely years off.
>

I think you'll be surprised at how quickly the focus will shift -
hypervisors are already commoditised and it won't be long before management
of them is too. Amazon have just announced
CloudWatch<http://aws.amazon.com/about-aws/whats-new/2009/05/17/monitoring-auto-scaling-elastic-load-balancing/>-
<question type="rhetorical">what more do you need?</question> :)

Point is that cloud infrastructure services will be commoditised before you
know it and we'll be looking for new challenges. Providers will need some
way to differentiate (location, features, formats supported, etc.) and I'm
proposing a way to give them that. Not to forget enterprise with their
myriad diverse requirements.


> Even with just compute, storage and networking, if OCCI gets adoption and
> is
> genuinely interoperable, then we have a massive win. Today even a simple
> call like "start server" is different on every IaaS public cloud.
>

Sure, and then we'll be painted into a corner and will have to revise the
entire protocol in an almost certainly !backwards compatible fashion. Let's
not forget too that it will be incapable of exposing much of the
functionality of VMware/Citrix/Microsoft/etc. solutions and that there will
be service providers offering these
products<http://www.citrix.com/English/NE/news/news.asp?newsID=1690241>.
Result: yet another divider between public (OCCI) and private (DMTF) cloud
infrastructure and a blow to the hybrid cloud.


> Topics like billing, SLAs, monitoring, etc. are issues which we won't be
> able to standardize for a long time yet. Whilst most public clouds do have
> these capabilities, they use take noticeably different approaches to them
> (compare Amazon vs. GoGrid vs. ElasticHosts on billing, for instance).
> More importantly, none of these actually expose any of these topics through
> their APIs, so any attempt to produce a standard API will be very premature
> for some time to come.
>

Sure, but even the minimum of information delivers incredible value to end
users so it makes sense that we would be focusing on this sooner rather than
later (think for OGF 28).

What you're basically saying is that because it's not in our charter each
provider needs to work out a way to expose this information, and will
probably need to create their own APIs to do so. Then if I want to create a
desktop client I need to talk multiple APIs, knowing that I already have to
talk XML based OVF, plus some mongrel home-grown OCCI-specific protocol,
plus some even more obtuse single-vendor billing protocol. No thanks - I'll
just target DMTF's stuff and won't bother offering support for public cloud.


> So, for me a tight specification of compute, storage and networking with
> good interoperability is much more important than any detailed thinking
> about extensions (though obviously we should have some rough concept on how
> extensions would fit in when they come).


Extensions will be here from day one... consider GoGrid's load balancers for
example - we have no interest in supporting them explicitly but they will
need some mechanism to expose the functionality.

The best part is it comes at zero cost, provided we make good design
decisions now.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090518/738fc8c8/attachment.html