In the context of the RESERVOIR project (http://www.reservoir-
fp7.eu/), one of the main aims is to define an API specification to
access both an infrastructure site (cloud system) from, for example, a
service management layer and to federate infrastructure sites. The
promotion of this specification as standard will be done in the
context of the OGF WG on Grid and Virtualization chaired by SAP and
IBM. The first deliverable with the architecture of the infrastructure
and a brief description of the APIs will be released in few days.
Regards,
--
Ignacio M. Llorente, Full Professor (Catedratico): web http://dsa-research.org/llorente
and blog http://imllorente.dsa-research.org
DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
On 05/06/2008, at 16:48, Tony Lucas wrote:
>
> There is two problems here, firstly (and most simply), Cloud providers
> providing an API interface that does allow this degree of control.
> Some
> do at the moment, some don't, but I'm sure it's something most will do
> in time. The bigger problem is making them work to a common standard,
> which is unlikely to happen (and that is a good and a bad thing). I
> would imagine this is where people like RightScale, CohesiveFT,
> Enomaly,
> Elastra etc come in. They are providing a management layer in one way
> or another over cloud providers, and thus can be independant of them.
>
> We at FlexiScale fully support the adoption of open standards and
> interoperability, but I can't see any provider making it ridiculously
> easy to move away, as it is a danger to their revenue model (not that
> I'm a fan of lock in problems at all).
>
> Some people would also say it's a benefit to the revenue model, as it
> enables people to start using these services with less of a risk, what
> if provider x goes bust/stops providing services/doubles pricing etc/
> has
> major technical issues etc, and I can certainly see their point, and
> is
> a question we have been asked on a number of occasions.
>
> Just my 2c
>
> Look forwarding to seeing a lot of you at Structure 08.
>
> Regards,
>
> Tony Lucas
> Chief Executive Officer
> XCalibre Communications Ltd / FlexiScale
> www.flexiscale.com
>
>
>
>> Michael,
>> Not exectly, I would draw a parallel between START/STOP/PAUSE and
>> GET/PUT/DELETE (in a sense of HTTP's simplicity), so I'm just making
>> assumptions on possible match. Not sure if this is valid or viable
>> comparison, goal was just to convey my viewpoint of Joyent's
>> suggestion.
>>
>> KS
>>
>> On Thu, Jun 5, 2008 at 10:36 AM, Michael Moran
>> <professor.moran@gmail.com <mailto:professor.moran@gmail.com>> wrote:
>>
>> Khaz,
>>
>> By HTTP Get/Put/Delete/etc., you mean RESTful web services
>> support?
>>
>> Thanks,
>> -Michael
>>
>>
>>
>> On Thu, Jun 5, 2008 at 10:35 AM, Khazret Sapenov
>> <sapenov@gmail.com <mailto:sapenov@gmail.com>> wrote:
>>
>> Larry,
>> In theory most cloud vendors(given they offer
>> considerably homogenuos services) should have some common set
>> of features, that comply to some protocol. I would compare it
>> to webservers using HTTP. So what Joyent proposes is something
>> like HTTP (GET/PUT/DELETE etc) for cloud computing.
>> --
>> Khaz Sapenov,
>> Director of Research & Development
>> Enomaly Labs
>>
>> US Phone: 212-461-4988 x5
>> Canada Phone: 416-848-6036 x5
>> E-mail: khaz@enomaly.net <mailto:khaz@enomaly.net>
>> Get Linked in> http://www.linkedin.com/in/sapenov
>> On Thu, Jun 5, 2008 at 8:44 AM, Larry Ludwig
>> <larrylud@gmail.com <mailto:larrylud@gmail.com>> wrote:
>>
>>
>>
>> In particular he says "a developer should be able to
>> move between Joyent, the Amazon Web Services
>> <http://finance.google.com/finance?q=amzn>, Google
>> <http://finance.google.com/finance?q=goog>, Mosso,
>> Slicehost, GoGrid, etc. by simply pointing the "deploy
>> gun" at the cloud and go." I think he nailed it dead
>> on with this statement.
>>
>>
>> Hi Reuven,
>>
>>
>> I've read that article also, I too think it would
>> be great to move service between different
>> providers. I think reality will set in how
>> different each cloud provider will be. Yes I
>> think you will find some application to convert
>> between providers, but I also think that will be
>> the key differentation between providers. One
>> provider will only have feature X, while another
>> provider will only have feature Y. In order for
>> each cloud provider to exist, they has to be some
>> barrier of entry from other providers and also a
>> method to not make it too easy for customers to
>> leave. Otherwise why would a cloud provider exist
>> and offer service? Geolocation of the cloud isn't
>> enough of a reason.
>>
>>
>> -L
>>
>> --
>> Larry Ludwig
>> Empowering Media
>> 1-866-792-0489 x600
>> Managed and Unmanaged Xen VPSes
>>
http://www.hostcube.com/
>>
>>
>>>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-computing@googlegroups.com
To unsubscribe from this group, send email to cloud-computing-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.ca/group/cloud-computing?hl=en
-~----------~----~----~----~------~----~------~--~---
No comments:
Post a Comment