BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Many organizations are turning to OpenStack as their next-generation cloud platform. And while many have pilot installations, transitioning from a pilot to a large-scale OpenStack deployment is difficult for some. In part, this is due to rapid OpenStack adoption; it's a popular private cloud approach, but OpenStack skills and training have not kept up with demand.
Adding to the complexity is the fact that OpenStack is a moving target, in terms of both its ongoing evolution and the competitive software ecosystem emerging around it. And since it can be difficult to find OpenStack support, the open source platform can seem daunting to the average IT pro.
One way to address some of these complexities is with OpenStack automation -- which is what OpenStack projects, such as Heat and Graffiti, revolve around. Heat, an orchestration tool, has a template design that is compatible with Amazon Web Services' CloudFormation templates to drive integration with the public cloud. Heat also provides autoscaling services, while Graffiti aims to improve resource metadata collaboration across services.
But even these tools don't make OpenStack deployment and control turnkey. Moreover, meeting any reliability standard or service-level agreement is still a ways off for most OpenStack installations. Many vendors offer automation tools to help solve some of these problems, but the sheer volume of options, combined with the fact that they don't all interoperate, makes the scale-out process for OpenStack a bit of a minefield.
Server and virtual instance orchestration is a key part of Heat, but server vendors, such as Hewlett Packard Enterprise, Dell and IBM, have an interest in gaining OpenStack leadership positions, offering integration services and support, as well as their own secret sauce for OpenStack clouds. One negative all of these players bring to the table is the potential for vendor lock-in.
Another vendor in this space is Red Hat. This year, Red Hat bought IT automation vendor Ansible, which allows users to create configuration "playbooks" in an easy-to-use format. Red Hat is also the leader in Ceph storage, thanks to its Inktank acquisition. These tools make it easier for users to create templates, while codifying repetitive work and reducing manual errors.
The role of SDN in OpenStack automation
A growing trend in networking is the concept of software-defined networks (SDN). Virtual network management can be difficult in the cloud, as performance, security and user experience are still in their early stages. The software-defined movement looks to simplify that issue by virtualizing network services and using bare-metal switches.
Companies such as Big Switch Networks, Nuage Networks and Juniper Networks are firmly aboard the SDN approach, and startups such as CPLANE Networks are taking advantage of the openly published APIs for the switch nodes to add competitive value.
Many view SDN as a policy- and template-driven approach. For instance, a central IT department could set up policies and templates, and then allow end users to build their working configurations from them. This would save time for admins and allow for a much faster OpenStack deployment.
Looking back, it's clear the industry has come a long way in 2015, in terms of building OpenStack private clouds and driving OpenStack automation. We are not where we need to be, but we have outgrown mostly manual processes by using orchestration and templates to offload work.
As we move into 2016, the biggest challenge will be how OpenStack interfaces to public clouds, as well as OpenStack's integration with -- or replacement of -- legacy systems, such as VMware clusters.
A comparison of OpenStack and VMware for private cloud
Where to find OpenStack development support
Reviewing OpenStack networking and orchestration options