The Cloud APIs Storm II: vCloud

vCloud is an initiative led by VMware and counts with the collaboration of more than 100 partner including  BT, Rackspace, SAVVIS, Sungard, T-Systems and Verizon Business. The main aim of vCloud is to provide a complete solution to deliver enterprise cloud services based on VMware technologies. The vCloud API will allow application providers to deploy their application among a cloud service provided by one of the vCloud partners.

The vCloud API is based on the principles of Representational State Transfer (REST).

The vCloud resource model includes next entities: the Organization that owns the applications, the Virtual Data Centre where different Resource Entities (Virtual Applications Templates, Media devices, and the Virtual Application) and Networks are instantiated. A Virtual Application is an aggregation of one or more Virtual Machines.

There are number of operations to query existing resources or summary of the Organiztation’s resources (GET <entity-uri>) and to delete an specific resource from a Virtual Application (DELETE <vapp-entity-uri>).

There is a Catalog  where users can register, get a summary, down/upload or delete a catalog item (vApp templates, media files such as ISO images, etc.).

vCloud application lifecycle model defines a number of steps where a number of operations can be performed:

  • Provisioning: creation of clonning of VApps, instantiation of the vApp templates, upload or facilitate the location of vApp parts and instantiation of VApps defined in an OVF package.
  • Configuration:  a client can reconfigure vApps by adding, removing or modifying OVF sections.
  • Deployment: Reservation of all the resources requested by the vApp (POST <vapp-uri>/action/deploy)
  • State Operations: once the resources are reserved the vApp have to be started by powering on all the resources (POST <vapp-uri>/power/action/powerOn), and later on it can be powered off, reset, suspended, shutdown, rebooted, etc.

As some of the previous operations can take time,pending task can be retireved (GET <task-list-uri>/<task-uri>) and cancelled (POST <task-uri>/action/cancel).

There are some other administrative operations to manage Organizations, Virtual Data Centres,  users, etc.

As conclusion, we see that the basic service lifecycle management is very well covered, but advanced features (dynamic scalability, SLA management, monitoring or usage accounting) that has been researched in projects as RESERVOIR are not included but it would not be difficult to extend this API to support them: the RESERVOIR’s OVF extensions could be adopted and some other operations or reporting data should be extended.

The Cloud APIs Storm I

We are witnessing a new technology race about the definition  APIs to access to IaaS Cloud services. With this post series, we would like to start a review series of the most relevant specifications trying to to analyse their status outstanding aspects  of them.

We are starting this analysis with two initiatives that follows different specification models: VMware’s vCloud in a vendor-driven model (aiming to be the “de facto” standard), and OGF’s OCCI in a open standardization body-driven model.

vCloud is an initiative led by VMware and counts with the collaboration of more than 100 partner including  BT, Rackspace, SAVVIS, Sungard, T-Systems and Verizon Business. The main aim of vCloud is to provide a complete solution to deliver enterprise cloud services based on VMware technologies. The vCloud API will allow application providers to deploy their application among a cloud service provided by one of the vCloud partners.

The OGF’s OCCI (Open Cloud Computing Initiative) Working Group is aiming to deliver an API specification for remote management of cloud computing IaaS.  The proliferation of IaaS providers with their own APIs (Amazon AWS, GoGrid, Flexiscale, …) requires an standardization effort on defining an common API to avoid vendor-locking and to guarantee interoperability.