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 - <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. 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