I think one of the big things within presentation is the usage of OVF and its status as a “1^st class citizen” in their API (no surprises considering Vmware along with others proposed it). From looking at the specification, I’ve found it to be quite comprehensive and extensible for forming an infrastructure model that you can request to be provisioned. Now there are some weaknesses (I made some note of this here [1] and Lori MacVittie[2] had some stronger opinions) but I believe there is an OVF2.0 spec in draft. Certainly sounds like they’re using the semantics of REST and using OVF as the XML schema as the body of requests. The nouns will be quite aligned to the Sun Cloud API but with their (VMware) model based on a standardised DMTF schema. Their “VApp” is most likely a VirtualSystem and their “VDCs” & “Organizations” are represented by VirtualSystemCollections in various configurations. What would be interesting to know (but so much to this mailing lists goals) is what schemas they use to pass about  on the message bus.

 

On another note, I looked through Abiquo [3] code yesterday and found it to be chock-a-block with DMTF schemas, OVF being one.

 

Andy.

 

[1] http://sla-at-soi.eu/?p=403

[2] http://www.infra20.com/post.cfm/ovf-a-few-layers-short-of-a-full-stack

[3] http://www.abiquo.com

 

 

This is (unsurprisingly) really raising the bar. FWIW I'm not one of the people who's seen the API so it's interesting to see they too went for OVF over a REST based API... it seems that OVF is in fact at the heart of this protocol (or is it vice versa?). That may or may not be a good thing.

Object model looks like this (courtesy pp59):

• Organisation
• Virtual Data Center (VDC)
• vApp (multiple VMs, "internal" network, n-tier app in a box)

Other observations:

• Flexible networking (like ours) - multiple tagged networks ("foo", "bar", "VDCnet", "Public", "Private")
• Persistent VMs (we want to allow for both)
• SLA on vApp (to be implemented as an extension)
• Overprovisioning (interesting area, from user PoV means hiding size of storage pools, etc. which most providers will want to do anyway)
• Both serialization and configuration via OVF
• Talk about scaling to 10k hosts and 100k VMs
• "HTTP based resource oriented interface" (just like OCCI!)
• "All the characteristics of the WWW
  • Extensible without breaking client. (like OCCI)
  • Client only has to know about what it cares about. (like OCCI)
  • Can route, proxy, cache <- interesting, useful, can be difficult to achieve
• Interestingly uses Spring Framework
• Injects dependencies and wires together Spring beans
• Forces programmer into maintainable design pattern; isolates dependencies
• OSGI: Standard dynamic module framework (Global registry of interfaces to instances - Dynamically load, unload, start, stop bundle)... not sure how interesting this is really
• JMS publish/subscribe messaging bus isolates end points (message buses will be a key component of most successful cloud architectures IMO - something to consider when we're talking about formatting)
• Hibernate simplifies DB code & DB independence

The actual VMware architecture (pp76) I found less interesting because it varies from provider to provider and is the detail that the cloud conceals from end users.

Sam

 

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