Entries in cimi (2)

Sunday
May052013

Google Hangout on Tuesday: Open Cloud Infrastructure and Service Portability

I'm excited to have an opportunity to participate in the Linux.com sponsored Google Hangout titled "Open Cloud Infrastructure and Service Portability" this Tuesday at 10 AM PT (1 PM ET). According to the folks at Linux.com, the chat will also include leaders from Eucalyptus, Gluster, OpenShift, OpenStack, Puppet Labs, Rackspace and Red Hat. CloudStack's own Joe Brockmeier will be moderating the event.

The agenda that's being published includes topics around workload portability, tools and methods for security, hypervisor support, AWS API compatibility and, of course, any live questions from the audience. Cloud "portability" has been an important topic for me over the years, from both the perspective of cloud platform software APIs, as well as dealing with the fundamental problems that come up when working with customer migrations into an environment.

As the market has evolved, we've learned more and more about the importance of portability, and some of the forces causing users to stick with one provider. Portability is more than just API compatibility: it's APIs, data formats, injestion and extraction techniques, differences in runtime environments, contextual relationships between consumable entities, service composition models, etc... Just think about the simple question of how to handle a move from a provider that uses one hypervisor to a different provider using a different hypervisor. Or consider what application deployment options a PaaS environment has vs other PaaS environment. Certainly, many (if not all) of these individual compatibility issues have been solved with point solutions... but the complexity is still there, and the aggregate challenge is getting more difficult as organizations increase their use of cloud services over time.

It should certainly be an interesting conversation!  Be sure to join us.

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?