Entries in api's (3)

Wednesday
Aug292012

DMTF's CIMI v1 Released - How should CloudStack support it?

Now that CIMI has been released as an official DMTF specification, it's time for implementations to start being finalized.  Wearing my CloudStack "hat", I've been thinking about how to best integrate CIMI into that project.  In the press release from DMTF, Sheng Liang says that the Citrix development team will be proposing the inclusion of CIMI into CloudStack itself:

"...Citrix is pleased to see the Cloud Infrastructure Management Interface (CIMI) standard published and will propose inclusion of the CIMI implementation into Apache CloudStack project and Citrix CloudPlatform," said Sheng Liang, CTO Cloud Platforms Group at Citrix.

There is certainly precidence already set within CloudStack for multiple API implementations, specifically the dual support for both the native CloudStack API and the EC2/S3/VPC APIs.  But is this the right choice for CloudStack?  The integrated approach would ensure a unified security model, similified deployment and configuration, as well as a single Apache project community to support the stack.  Potential downsides to this approach are that it could potentially distract the CloudStack project from focusing on key features and infrastructure integration work.

As an alternative solution, the CloudStack project may consider looking to another Apache project, Apache Deltacloud, to act as an API facad layer for CloudStack deployments (a general pattern that I wrote about back in April).  I've already proposed building a CloudStack driver within Deltacloud (and have a very early shell started).  This would allow deployments to use both Apache projects to create choice for users in their prefered API, through the support of CloudStack, EC2/S3/VPC, Deltacloud, CIMI, and potentially others...

Regardless of which path the CloudStack project chooses to take, I firmly believe that supporting CIMI for CloudStack deployments is an important goal.  We remain a long way from the industry truly coalescing around a single IaaS API, but steps like the development of CIMI (and it's adoption) are critical to moving IaaS APIs out of the world of proprietary interface design and into an open environment that fosters collaboration between different industry players.

Which way do you think is the right way?

Tuesday
Apr102012

IaaS APIs - Raw Infrastructure vs. Contextual Configuration

The recent AWS "compatibility" debates, as well as my own early participation in the DMTF's Cloud Management Working Group has me thinking about the IaaS API space quite a bit these days. One of the things that we're not really discussing as an industry is really around the top level approach to IaaS API design.

The way I view this is that the primary question is one of pure infrastructure utility vs contextualizing the infrastructure resources. Simply using the standard AWS EC2 API is an example of the pure infrastructure utility, and the plethora of solutions that layer on top of the standard EC2 configurations prove that this is a viable utility-based model. Many of these higher level solutions aim to solve the contextual relationship issues that arise out of any non-trivial consumption of EC2 resources. Amazon clearly realized that context is critical as well, since they have provided what they hope are the canonical API solutions for adding context with the introduction of the VPC extensions to the EC2 base API and the creation of their CloudFormation wrapper on top of their ever growing infrastructure utility options.

Looking at the VMware side of the ecosystem, the approach was to start with context first.  Within the vCloud API, the VDC is king and all activity takes place within the context of the VDC.  This same focus on context can be seen in the configuration complexity supported within the OVA/OVF format for vApps. One "could" argue that the base vSphere API is a "poor man's" answer to supporting a more utility-focused approach (similar to EC2), but that would be a bit of a stretch.

There are ways to create context from a low level utility API, just as there are ways to force contextualized APIs to behave like they are without context (think about a very large VDC that you don't add any networking complexity to).  The basic difference between discrete infrastructure components and composed environments is level of contextualization delegated from the provider to the consumer. To me, context is king for the users in the end, but deciding where that context is applied remains a question that each user needs to answer for themselves.

Have we put enough thought into these distinct approaches to understand the implications fully?  Amazon seems to have done the right thing, by providing both styles of consumption.  Should other providers follow suit?  That depends on the types of customers, ecosystem partners and use cases they want to support.