OpenStack has had a big year so far in 2015. For instance, this past winter Canonical and Juniper teamed up on an OpenStack project designed for carrier-grade clouds, bringing together bits of Ubuntu and Contrail to help with telecoms' ongoing virtualization of core network functions. Other giant steps have followed, including the finalization this May of standards for interoperability testing of any product that would receive an "OpenStack Powered" certification.
Overall, OpenStack has been evolving from a software project that was once a hobby for developers and a pocket of the open source community into something that now holds the interests of vendors, carriers and other contributors. Meanwhile, its testing and implementation within infrastructure environments has resulted in growing complexity that traditional automation tools are too siloed to handle.
Cloud management platforms such as QualiSystems CloudShell have accordingly become vital to making the transition to the cloud. Integration with OpenStack and any other type of infrastructure stacks allows for low-risk evolution of environments as well as ongoing support of any persistent legacy components. Making OpenStack viable requires not just a good set of APIs and standardization, but also effective IT infrastructure automation and DevOps innovation.
The next phase of OpenStack
The recently concluded spring OpenStack Summit in Vancouver showcased a project on the verge of some major changes. In addition to the standardization discussed above, there has been a clear response from the OpenStack community to the possibilities opened up by the containerization technologies of Docker.
"Docker's container technology has become a major factor in the evolution of OpenStack components," explained Charles Lai of Forrester for Computerworld UK. "Docker drivers have been implemented for the key components of Nova and Heat for extended computing and orchestration capabilities, respectively."
"OpenStack is a project on the verge of some major changes."
Containers, as we have discussed a few times here before, provide a low overhead alternative to virtual machines. The Magnum API for OpenStack allows for the creation of both Kubernetes (Google) and Swarm (Docker) clusters, while the Murano component may enable the publication of visual catalogs of applications that can be deployed directly to containers.
As for the standardization effort, it is an important step forward because it may help clear up some of the fragmentation and risk aversion that have so far made it hard for many organizations to get their OpenStack deployments off the ground. Now there's the "OpenStack Powered" initiative, as well as more than 30 vendors signing on to support federated identity. It is now possible to use your home OpenStack cloud ID to spin up instances elsewhere, making it easier to bridge public and private clouds in hybrid architectures.
Although there has been some concern about OpenStack's new direction - especially around the growing control of its largest contributors - the projects seem set for broader appeal in the years ahead. A cloud orchestration platform will be crucial for enabling the DevOps automation needed to make the most of emerging OpenStack infrastructure environments.
"OpenStack networking is a critical issue for large enterprises and service providers to solve, particularly in higher-level areas such as NFV, agility, and automation," Jay Lyman, 451 Research's research manager, noted in February.
The takeaway: The OpenStack community has made a clear play for mass market appeal by standardizing the certification process for OpenStack-compliant products and rolling out federated cloud identities. The evolution of OpenStack APIs also shows the major influences on the project, which right now include containerization. Cloud automation platforms will be central to navigating the transition to cloud applications running in OpenStack environments.
