Ignacio,
So then does that mean the language used to write-apps-for your cloud would be irrelvant because the infrastructure provider would handle that detail by providing multi-language support (say, via VMs that support one or more languages, or by routing any language-specific call to the appropriate sub-cloud that supports that language in question)?
Thanks,
Michael
On Thu, Jun 5, 2008 at 12:05 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es> wrote:
What we try to do is to provide infrastructure on-demand for the
execution of any service. The interface provides functionality for the
submission and control of service, where a service is a set of VMs
with requirements and rules for affinity, interdependencies... So, the
infrastructure provider manages the execution of the VMs according
infrastructure policies that could eventually delegate the execution
of the VM to a remote infrastructure site.
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 17:57, Sassa NF wrote:
>
> :-) There is no problem to move the services... the problem is to move
> the service state = resource + data.
>
> but I like the view that the standard would allow interop of clouds,
> i.e. super-cloud or federation as a business model? So to speak, buy
> data as a service from Amazon, buy search as a service from Google,
> and make them work together. However, for this to make sense, there
> must be a task that the other clouds cannot solve sufficiently well
> alone, or where the integrity level of a cloud is not sufficient
> (integrity level here being like the level of detail seen in the
> Universe). This is what drove the Grid standardisation efforts to
> where they are now.
>
> Someone already complained here that the Grid standardisation effort
> is not heading in the direction of applied IT. But this is exactly the
> reason why: do we see the same scale of the problems in applied IT as
> seen in the academic community? (use CERN Hydron Collider as the data
> provider, and NESC Condor pool as the CPU provider for my simulations)
>
>
> Sassa
>
> 2008/6/5 Khazret Sapenov <sapenov@gmail.com>:
>> you don't do it after event, but prepare for it.
>>
>> On Thu, Jun 5, 2008 at 10:59 AM, Sassa NF <sassa.nf@gmail.com> wrote:
>>>
>>> How do you move apps from the cloud that went down?.. ;-)
>>>
>>>
>>> Sassa
>>>
>>> 2008/6/5 Khazret Sapenov <sapenov@gmail.com>:
>>>> Ray,
>>>> I guess this is nice-to-have feature to manage risk of cloud
>>>> provider
>>>> going
>>>> down (just one possible scenario).
>>>>
>>>> KS
>>>>
>>>> On Thu, Jun 5, 2008 at 10:47 AM, Ray Nugent <rnugent@yahoo.com>
>>>> wrote:
>>>>>
>>>>> This question is for all the platform folks out there. Just out of
>>>>> curiosity, how many of your customers are asking for these
>>>>> portability
>>>>> features? Is there really a pent up demand to move apps from one
>>>>> cloud
>>>>> platform to another?
>>>>>
>>>>> Ray
>>>>>
>>>>> ----- Original Message ----
>>>>> From: Larry Ludwig <larrylud@gmail.com>
>>>>> To: cloud-computing@googlegroups.com
>>>>> Sent: Thursday, June 5, 2008 5:44:17 AM
>>>>> Subject: RE: The Business of Building Clouds
>>>>>
>>>>>
>>>>>
>>>>> In particular he says "a developer should be able to move between
>>>>> Joyent,
>>>>> the Amazon Web Services, Google, 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