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

Sun Jun 14 21:57:58 CDT 2009

My classic blog post on this is here:

	http://cloudscaling.com/blog/cloud-computing/defining-infrastructure-clouds

I don't cover OS directly, but my $0.02 are this:

	- Platforms are run time environments ('load-your-code-and-go')
	- Traditionally folks have lumped OS and run time environments together
	- Run time environments don't have to be tightly coupled to OS (e.g.  
JVM and .NET/Mono)
	- Confusion comes from runtime environments an OSes being tightly  
coupled historically

So, bottom line is the OS is probably (ultimately) the top of the IaaS  
stack and interfaces directly to the run time platform environments.   
It's the infrastructure (compute, storage, network) abstraction layer  
for the run time environment in effect.

--Randy

On Jun 14, 2009, at 11:15 AM, André Brinkmann wrote:

> Dear Gary,
> 	dear All,
>
> 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.
>
> 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.
>
> Best Regards,
>
> André
>
> --
> ---------------------------------------------------------------
> Jun.-Prof. Dr.-Ing. Andre Brinkmann
> Managing Director
>
> Paderborn Center for Parallel Computing
> University of Paderborn
> Fürstenallee 11
> 33102 Paderborn
>
> Germany
> ---------------------------------------------------------------
> Email:   Andre.Brinkmann at uni-paderborn.de
> Phone:   +49-5251-60 62 90
> Fax:        +49-5251-60 62 97
> ---------------------------------------------------------------
>
>
>
>
>
>
> Am 14.06.2009 um 18:52 schrieb Gary Mazz:
>
>>
>> I was on the same wavelength as you are until about a 3 days ago, I
>> was
>> getting xVM working on opensolaris. xVM para-virtualization has a
>> concept of a virtual MAC address not tied to a physical MAC. This
>> allows
>> them to create virtual HBA devices that can request IP addresses from
>> DHCP. The virtual MAC helps routers and switches find the VM when its
>> instantiated or transported to another rack or facility.
>>
>> I'm reconsidered my past position on what's relegated to fabric in
>> lieu
>> of a more comprehensive definition of IaaS.
>>
>> Lets look at some provider models:
>> 1) A provider has hard iron that they physically provision for a
>> customer ( the dedicated hw model/ no sharing of anything)
>> 2) A provider has pooled iron that they logically provision (fixed
>> resources/dedicated hw) specific for a customer ( the LPAR model).
>> This
>> includes blades, minis, 100 cpu racks.
>> 3) A provider has pooled iron that shared resource provisioning  
>> occurs
>> across customers ( the dynamic model).
>>
>> Irrespective of how the provider model fulfills its services, each  
>> are
>> providing specific items: CPUs, memory, network adapters, storage
>> HBAs,
>> raw disk, filers, networks, VPNs, load balancers, web caches, name
>> servers, edge firewalls, etc...
>>
>> In the first case --- physical partitioning providers, the
>> infrastructure is hard iron and no doubt fabric. In the second two
>> models, LPAR and VM, all of the servers may be partially or  
>> completely
>> visualized. We need to address what this really means for the both  
>> the
>> providers and the consumers.
>>
>> Providers have a pool of resources they provision for each  
>> customer. I
>> assume each set of resources would/can be organized into one or more
>> federated accounts. Federations can be further subdivided into
>> administrative resources groups (zones).  Each federation is  
>> logically
>> isolated from all other accounts for security and privacy constraints
>> and possibly quality agreements.  The quality, availability,
>> responsiveness, besides types of services offered are several ways
>> providers differentiate themselves.
>>
>> Consumers receiving federated pool of resources, can administer them
>> according to their IT and business requirements. The administration
>> can
>> include fire walling internal to the federation, VPN connections
>> between
>> federations and zones, and balancing external workload across  
>> multiple
>> applications servers, Essentially, executing the same organizational
>> and
>> administrative tasks occurring in private data centers.
>>
>> Unless there are hard requirements for physical isolation or  
>> dedicated
>> hardware, consumers will not care whether their infrastructure is
>> physically partitioned, implemented as LPARs, floating VMs or how
>> closely services are linked to fabric resources.. Consumers will
>> expect
>> or require certain levels of quality from their service..
>>
>> Bottom line:
>> Consumer services are defined by the providers; not all providers
>> offer
>> the same services; and how a provider implements of their services,  
>> as
>> far as occi concerns,  are unrelated to their service offerings.
>>
>> IMO, I don't think we can exclude cloud service providers because
>> their
>> services are too "close" to the fabric. We need to include  
>> virtualized
>> hardware parameters like MACs as well as other infrastructure  
>> services
>> including DNS, firewalls and VPNs.
>>
>> In the world, there are going to be varying degrees of compatibility
>> betweens cloud provider technologies and service offerings. Some
>> differences can be easily be worked around, while other may be
>> irreconcilable; while all supporting and implementing occi.
>>
>> For example, virtual MACs are a hard reality and a critical attribute
>> for some providers. Even though they are not required by all
>> providers,
>> it may not be a good idea to exclude them. In this case, the OCCI can
>> accommodate both type of providers by acting as a superset for  
>> network
>> adapter configurations. A provider not requiring a MAC address for
>> their
>> operations can ignored the parameter.
>>
>> The idea that ALL occi cloud providers will be 100% inter-operating  
>> in
>> the face of differentiated (missing or incompatible)  service  
>> offering
>> is unrealistic.  For example, if a consumer has an application
>> requiring
>> infrastructure provided load balancing services, they cannot engage a
>> provider not offering those services. The OCCI cannot reconcile
>> providers with incompatible infrastructures. In this example, the  
>> OCCI
>> can only provide a vehicle  for the consumer to assess the
>> capabilities
>> of a provider.
>>
>> Reiterating, I think we need to include more virtualized services and
>> vituralized hardware configurations.
>>
>> lemme get a few more cups of coffee...
>>
>> -gary
>>
>>
>>
>>
>> Sam Johnston wrote:
>>> On Sun, Jun 14, 2009 at 1:35 PM, Gary Mazz <garymazzaferro at gmail.com
>>> <mailto:garymazzaferro at gmail.com>> wrote:
>>>
>>>   The question is: " Do operating systems belong in IaaS or PaaS. "
>>>
>>>
>>> Definitely IaaS. When you start talking about MAC addresses, VLAN
>>> IDs,
>>> etc. you're venturing well into the underlying hardware fabric which
>>> is ultimately someone else's problem - I don't see any of these
>>> things
>>> appearing in current IaaS APIs[1].
>>>
>>> Basically think of infrastructure services as everything up to the
>>> operating system interface (be that an API, CLI or a GUI).
>>>
>>> Platform services (PaaS) on the other hand include [most of] the
>>> solution stack... any app servers, databases, script/bytecode
>>> interpreters, etc. - think LAMP. You can just take your app and use
>>> it
>>> (in many was like it were a virtual machine - which is why the next
>>> step for us will be a small one).
>>>
>>> Software services (SaaS) then add the application itself.
>>>
>>> OCCI is most definitely IaaS.
>>>
>>> Sam
>>>
>>> 1. That is not to say they're not important - they are, particularly
>>> for "I can't believe it's not cloud" moreso than public cloud, but  
>>> if
>>> they appear in OCCI they'll be optional.
>>>
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg

Randy Bias, Cloud Strategist
+1 (415) 939-8507 [m], randyb at neotactics.com
BLOG: http://cloudscaling.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090614/9d6300bc/attachment.html 