[occi-wg] Opinion Poll: IaaS or PaaS ?

Fri Jul 3 10:01:07 CDT 2009

Hello Andy,

Am 03.07.2009 um 16:52 schrieb Edmonds, AndrewX:

> Regarding:
> "I do not want to split hairs, but I am interested (from a customer  
> perspective) to be able to deploy arbitrary OS-images inside my  
> virtual machine, so the OS is not part of the service offered by the  
> Iaas-provider."
>
> The OS selection may have dependencies on the IaaS owing to hardware  
> architectures it supports (i386, x86_64, PPC, MIPS etc) so it may  
> not be possible to run arbitrary OS that assume a particular  
> h.architecture. Currently the only sure way to guarantee arbitrary  
> OS deployment could be the provisioning of instruction set emulation  
> within a hypervisor. Other than that as a simpler solution, the IaaS  
> provider would have to state what hardware architectures it could  
> support (though would limit arbitrary OS deployment).
>

again true. What I wanted to say is that I want to be able to deploy  
arbitrary OS-images inside my virtual machine as long as there are no  
physical constraint hindering this deployment and  that I do not want  
to have to take an OS-image from my IaaS-Provider, which might limit  
my configuration freedom and my choice to switch between different  
IaaS-providers.

Best Regards,

André

> .2c
>
> Andy
>
> -----Original Message-----
> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On  
> Behalf Of Andre Brinkmann
> Sent: 03 July 2009 15:35
> To: Randy Bias
> Cc: occi-wg at ogf.org
> Subject: Re: [occi-wg] Opinion Poll: IaaS or PaaS ?
>
> Hello Randy,
>
> thank you for the explanations. Nevertheless, there are still some
> open issues (at least from my side);
>
> Am 30.06.2009 um 19:59 schrieb Randy Bias:
>
>>
>> On Jun 14, 2009, at 11:10 AM, André Brinkmann wrote:
>>> sorry for interfering with your discussion, but I am only reading
>>> your Email list since a week. From my perspective, IaaS (and OCCI)
>>> only deals with an execution platform for (a collection of) virtual
>>> images. The operating system itself and the "virtual" hardware
>>> (Virtual MAC, ...) is part of the virtual image and therefore does
>>> not belong to an IaaS environment.
>>
>> Actually, I think this is provably untrue.  The virtual hardware
>> will almost certainly belong to the infrastructure and not the VM
>> itself.  For example, right now GoGrid provides 3 NICs, but Amazon
>> provides 1.  Both are Xen-based platforms.  Other systems provide
>> arbitrary numbers of NICs.  Since the virtual hardware is supplied
>> by the underlying hypervisor layer and it's configuration the
>> virtual hardware is part of the IaaS platform.
>>
>
> Your point is (in this case unfortunately) correct. I think that this
> is a drawback of current IaaS providers. In principle, the restriction
> to a limited number of NICs leads to vendor lock-in, e.g. it might
> become difficult to port applications from GoGrid back to Amazon.
>
>> In addition, most of the hypervisors request you to use Ethernet
>> MACs that have Vendor IDs relevant to the hypervisor under which
>> they are used.  For example, VMware uses 00:0c:29 for dynamically
>> assigned MACs.  This leaves only 16M possible Ethernet MACs across
>> all VMware installations.  The risk of collision when moving a
>> VMware VM from one cloud to another is very high.  Because of this
>> vendors will almost certainly provide (and hardcode for security
>> reasons) the MAC addresses for servers.
>>
>> In other words, the virtual hardware and the virtual MAC are tied to
>> the IaaS platform and not the VM.
>>
>
> Correct and it also makes sense, as the MAC address in a conventional
> system is also part of a physical machine and therefor part of the
> infrastructure.
>
>> One can certainly argue whether the OS is the bottom layer of PaaS
>> or the top layer of IaaS, but there is absolutely no doubt that it's
>> the primary interface between the two.
>>
>> I would argue that the traditional notion of OS as a platform comes
>> from the idea that the OS provides a set of runtimes (libraries,
>> resources, and facilities) upon which you can 'load-your-code-and- 
>> go'.
>>
>> So, if platforms are 'load-your-code-and-go' systems, then an OS
>> itself is not a platform.  By default not every OS is ready to have
>> code loaded and ready to go after a fresh install.  Most require
>> some significant configuration.
>>
>> So if we want to split hairs, an 'OS' is probably the top layer of
>> an IaaS platform and a 'configured OS' is probably the bottom layer
>> of a PaaS.
>>
>
> I do not want to split hairs, but I am interested (from a customer
> perspective) to be able to deploy arbitrary OS-images inside my
> virtual machine, so the OS is not part of the service offered by the
> Iaas-provider.
>
>> BUT, if we dig deeper and look at runtimes that don't sit on a
>> specific OS (JVM, Mono, CLR, etc.) then one has to assume that while
>> the run times are typically attached to an OS, they don't have to be.
>>
>>> Nevertheless, services like VPNs, DNS, and DHCP are services, which
>>> are typically provided by the infrastructure outside of the virtual
>>> machines and I would be happy if you would include a description of
>>> these services inside OCCI.
>>
>>
>> I wrote this up fairly extensively here:
>>
>> Defining Infrastructure Clouds | Cloudscaling
>>
>
> Thank you for your comments
>
> André
>
>>
>> Thanks,
>>
>>
>> --Randy
>>
>>
>> Randy Bias, Cloud Strategist
>> +1 (415) 939-8507 [m], randyb at neotactics.com
>> BLOG: http://cloudscaling.com
>>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
> -------------------------------------------------------------
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.