Microsoft recently announced support for Docker and Kubernetes technology on the Azure platform. Docker is an open source technology that enables developers to “build, ship, and run distributed applications” by means of container technology that facilitates application migration and deployment. Meanwhile, Kubernetes is an open source cluster management platform that can be used to deploy Docker containers. Azure customers can now use the Kubernetes platform to create and publish Docker containers to the Azure storage platform. In addition, Azure customers can deploy and configure Azure clusters using container images from Azure Storage or the Docker Hub. The Microsoft Azure team also built the Azure Kubernetes Visualizer which provides developers with a visual representation of the status of Kubernetes when managing Docker technology as illustrated below:
The Azure Kubernetes Visualizer is intended to “visually demonstrate some Docker and Kubernetes concepts such as containers, pods, labels, minions, and replication controllers.” Given that Kubernetes was open-sourced by Google in June, Microsoft’s decision to support Kubernetes and Docker represents a stunning example of the way in which container technology promises to drive product development as it relates to Infrastructure as a Service cloud computing. Amazon Web Services, for example, has yet to embrace Docker technology, and given its history of ignoring open source projects with the exception of Apache Hadoop, is likely to continue to withholding support for Docker. Meanwhile, Microsoft’s decision to support Kubernetes in conjunction with Google and its IaaS Google Compute Engine opens the door for the possibility of increased inter-operability between Azure and GCE, and subsequently promises to assert the criticality of Docker and Kubernetes to conversations about cloud computing inter-operability. The real winner from Azure’s support for Kubernetes and Docker, however, is Docker, whose container technology is likely to continue skyrocketing in adoption and affecting market dynamics not only within the IaaS space, but also the Platform as a Service (PaaS) landscape given its ability to reduce the gap between application development and operations by streamlining application migration across different cloud environments.
Whereas healthcare IT can boast inter-operability standards in the form of HL7 compliant standards that regulate the transmission of structured, electronic health data, the cloud computing space has yet to finalize analogous protocols for the exchange of data. As a result, the Open Data Center Alliance (ODCA) has become one of several organizations pushing for cloud computing inter-operability standards that promise to enable customers to avoid vendor lock-in or inaccurate transformations of their data resulting from data migration from one vendor to another. Featuring a steering committee composed of representatives from BMW, Capgemini, China Life, China Unicom, Deutsche Bank, JPMorgan Chase, Lockheed Martin, Marriott International, Inc., National Australia Bank, Terremark, The Walt Disney Company and UBS, the Open Data Center Alliance represents enterprise customers whose annual spending on IT totals $100 billion. In an effort to accelerate the adoption of cloud inter-operability standards, on June 7, the ODCA elaborated eight use cases and a vision of inter-operable cloud computing that is intended to spur standards bodies to collaborate with vendors to define a set of standards across the industry. Topics addressed by four of the eight use cases include:
•Cloud Provider Security Assurance and Security Monitoring
•Standardized Units of Measurement for IaaS to enable meaningful comparisons of price and functionality across vendors
•Environmental standards regarding the CO2 footprint of cloud computing products and services
•Technical architecture of virtual machine inter-operability and I/O controls
More generally, the use cases address the topics of secure federation, automation, common management, policy transparency and solution transparency. The Open Data Center Alliance has pledged to share these uses cases with the Cloud Security Association (CSA), The Distributed Management Task Force (DMTF), The Organization for the Advancement of Structured Information Standards (OASIS) and TM Forum’s Enterprise Cloud Leadership Council (ECLC).
Apache LibCloud’s May 19 graduation from the Apache Incubator signifies that the race toward cloud inter-operability is firmly underway. Libcloud provides an open source Python library of back-end drivers that enables developers to connect to APIs of over 20 cloud computing platforms such as Amazon EC2, Eucalyptus, GoGrid, IBM Cloud, Linode, Terremark and vCloud. Developers can write code once and then re-deploy their applications on other cloud environments in order to avoid vendor lock-in and create redundant architectures for disaster recovery purposes. LibCloud was originally developed by the Rackspace acquisition CloudKick but subsequently migrated to the Apache Incubator Project in November 2009. LibCloud’s graduation from the Apache Incubator as a Top Level Project means that the product will be managed by a Project Management Committee that assumes responsibility for its evolution and subsequent releases. LibCloud is currently available under version 2.0 of an Apache Software License.
The principal drawback about LibCloud is its exclusive use of Python as the programming language to connect drivers to vendor APIs. Red Hat’s DeltaCloud, in contrast, leverages a REST based API that offers more flexibility than LibCloud’s Python library for the purpose of migrating software deployments from one cloud infrastructure to another. Like LibCloud, DeltaCloud is being groomed through the Apache Incubator project but has a few more steps to travel before graduation and the achievement of top level status. Nevertheless, open source options are clearly leading the charge toward cloud inter-operability although they all presently require the withdrawal of a cloud instance to a holding database followed by re-deployment through the activation of the linking API. In other words, neither LibCloud nor DeltaCloud enable developers to connect Amazon EC2 to Rackspace without an intermediary database as a preliminary step.