Future OCCI extensibility: compute, storage, network, service, application
Evening all, According to NIST<http://csrc.nist.gov/groups/SNS/cloud-computing/index.html> : *Cloud computing is a pay-per-use model for enabling available, convenient,
on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is comprised of five key characteristics, three delivery models, and four deployment models.*
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? Sam
+1 on extensibility. Messaging or network shared memory (cache) would be relevant next resources in my book. -Adrian Cole jclouds On Fri, May 15, 2009 at 6:09 PM, Sam Johnston <samj@samj.net> wrote:
Evening all,
According to NIST<http://csrc.nist.gov/groups/SNS/cloud-computing/index.html> :
*Cloud computing is a pay-per-use model for enabling available,
convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is comprised of five key characteristics, three delivery models, and four deployment models.*
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?
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Sam, Depends what 'at the heart of the protocol' means. a On Fri, May 15, 2009 at 5:09 PM, Sam Johnston <samj@samj.net> wrote:
Evening all,
According to NIST:
Cloud computing is a pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is comprised of five key characteristics, three delivery models, and four deployment models.
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?
Sam
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Fri, May 15, 2009 at 6:15 PM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
Depends what 'at the heart of the protocol' means.
See previous post where I described the core protocol being nothing but extensibility (e.g. the microkernel approach to standards - a "microstandard" if you like). Sam
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. 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. 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. 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). Cheers, Richard.
That is absolutely right. Billing etc are not in scope. If we can get the basics agreed on (compute, storage, network), then billing will become something we can talk about. alexis On Mon, May 18, 2009 at 10:19 AM, Richard Davies <richard.davies@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.
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.
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.
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).
Cheers,
Richard. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
On Mon, May 18, 2009 at 11:27 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
That is absolutely right.
Billing etc are not in scope. If we can get the basics agreed on (compute, storage, network), then billing will become something we can talk about.
This view, while seemingly justifiable, is rather short-sighted. Further, by putting the blinkers on now we are encouraging others (e.g. SNIA) to do the same. Given our place at the head of the cloud computing timeline we'd be basically marching everyone towards a corpse-littered battleground of standards - I've not heard a single coherent argument as to why this would not be the case and how this is any different from the myriad blikered and often competing efforts of WS-*. I agree billing is not in scope now, but it is a pain point that is of a high priority so it will be in scope before long - once problems are solved focus changes quickly and we need to be able to adapt. Sam
Sam, We are not doing billing until we get the basics to work. alexis On Mon, May 18, 2009 at 10:43 AM, Sam Johnston <samj@samj.net> wrote:
On Mon, May 18, 2009 at 11:27 AM, Alexis Richardson <alexis.richardson@gmail.com> wrote:
That is absolutely right.
Billing etc are not in scope. If we can get the basics agreed on (compute, storage, network), then billing will become something we can talk about.
This view, while seemingly justifiable, is rather short-sighted. Further, by putting the blinkers on now we are encouraging others (e.g. SNIA) to do the same. Given our place at the head of the cloud computing timeline we'd be basically marching everyone towards a corpse-littered battleground of standards - I've not heard a single coherent argument as to why this would not be the case and how this is any different from the myriad blikered and often competing efforts of WS-*.
I agree billing is not in scope now, but it is a pain point that is of a high priority so it will be in scope before long - once problems are solved focus changes quickly and we need to be able to adapt.
Sam
On Mon, May 18, 2009 at 11:50 AM, Alexis Richardson < alexis.richardson@gmail.com> wrote:
Sam,
We are not doing billing until we get the basics to work.
Agreed - I didn't say otherwise:
I agree billing is not in scope now, but it is a pain point that is of a high priority so it will be in scope before long - once problems are solved focus changes quickly and we need to be able to adapt.
It may not even be this working group that ends up with the problem, but what is for sure is that someone will. Perhaps we can even reuse some of the work already done - I don't know and I don't care until post October. Sam
On Mon, May 18, 2009 at 11:19 AM, Richard Davies < richard.davies@elastichosts.com> 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
Sm Johnston wrote: 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
participants (4)
-
Adrian Cole -
Alexis Richardson -
Richard Davies -
Sam Johnston