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

[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.
>