Is Your Team Ready for OpenStack
For many IT organizations looking to reduce their infrastructure cost, Open Source Software frequently provides a spark of hope, and in today’s Open Source marketplace, there are few tools that hold as much promise as OpenStack. Yet, as with any technology that comes with a lot of hype, there are always areas to be cautious about. This is especially true when evaluating how and when a new technology is ready for use and perhaps more importantly, when an entire organization is ready to leverage a new technology and new model for technology use. So how can you determine the right time to transition to OpenStack or whether your organization even should?
At its core, OpenStack provides an Infrastructure as a Service (IaaS) middleware interface to an underlying datacenter environment. Add on all the bells and whistles (and perhaps build a few of your own), and you have an incredibly flexible and powerful infrastructure platform and Software as a Service (SaaS) engine as well. To achieve this potential, it is important to first ensure that your team is ready for the task of operating and managing the infrastructure and OpenStack platform tools; and secondly, that your “customers” (internal or external) are ready to consume the platform as well.
Of these two aspects, the ability for an organization to deploy, operate, and maintain OpenStack is one of the most often underestimated aspects of the process of enabling the service. While a number of efforts have been applied to simplifying the initial deployment of OpenStack, it is now relatively easy to get a basic system running. Nevertheless, the process of keeping that deployment running tidily (and understanding, validating, and cleaning up failures) still comes with a steep learning curve. Typically this means the need for dedicated resources to invest significant up-front time to both understand the interactions of the system, and enable the processes to keep the system running smoothly. As with any OpenSource project, especially one as dynamic and rapidly developing as the OpenStack project(s), it is a challenge to keep on top of the latest changes, let alone the added challenge of understanding the implications and impacts of those changes to a running system.
So how should your organization address the operating requirements of the environment, and gain the benefits and capabilities of the OpenStack platform and its varied services? There are really three paths available today: build and operate your own platform, enable third party operations of your physical platform, and finally, use a standalone third party platform. Which of these you choose really depends on the capacity of IT in your organization to take on the additional responsibilities needed to deploy and manage the new OpenStack environment. If the organization already has a flexible team of development/ automation minded datacenter systems managers, then the ability to build and operate your own platform may be the right choice, and should provide for the best ROI over the long run. If the organization’s datacenter teams are already managing at capacity, adding the additional burden of deploying and managing an OpenStack system may not be the best approach. In this case, having a third party provide the middleware management may be a more viable approach. The IT organization will likely maintain responsibility for the underlying physical platform, but the operations and repair of the OpenStack middleware and its managed services can be passed off to a third party. Lastly, there is the potential to use a fully hosted, 3rd party model. While this removes the need to provide any infrastructure management, it perhaps further increases the importance of being able to manage the consumption of resources, releasing those that are not needed. In all cases, access to the OpenStack APIs is one of, if not the most important capability, given that this enables consistent automation and management of the infrastructure services deployed with OpenStack. This brings us to the other major consideration of OpenStack team readiness.
Who will use the new OpenStack environment you enable? Perhaps more importantly, are they ready to get the most value out of that platform when it is made available to them? OpenStack is a very flexible toolset, and in its simplest format, it can be configured to provide nothing more than a management platform for Virtual Machines, containerized applications and even bare metal compute resources. However, this simple model is really no different from many other datacenter automation tools, and it doesn’t truly leverage the greater benefits available through OpenStack. To get the most value out of your OpenStack environment, it is critical to ensure that the teams developing the applications for use in this environment are enabled with the right tools and understanding of how to use OpenStack services to the best effect.
First and foremost, automation is the cornerstone of OpenStack enabled applications. From template based deployments with the HEAT, OpenStack’s orchestration project, to the automation of individual application components and services via the cloudinit tools, enables the rapid deployment, and more importantly rapid removal or release of services and services components as needed. In addition, the automation of quality assurance and test processes, specifically the actual infrastructure and application components as a whole, leverages OpenStack services fully. This allows for greater utilization of the overall platform and enables efficient reuse and release of unused or completed resources. Automation is the key, and while processes like Agile development methods and Dev/Ops management styles are well suited to this platform, it is more important to automate the deployment and recovery of infrastructure resources to gain the most benefit from OpenStack.
So before you rush to drive your team to deploy or enable OpenStack for your organization, ensure that you have a plan to enable your applications in this new platform. It is best that your developer and application deployment and management teams are all aware of the automation capabilities present in the OpenStack platform, and how they will be able to use them. It is also important to ensure that the application teams in particular are made aware of differences in failure recovery models, and its even better if they learn to automate failure management into their applications, as this will improve business resiliency while most efficiently leveraging the infrastructure deployed.
OpenStack can be an incredibly valuable component of an IT strategy, providing both the hyped cost and time savings, so long as the considerations that have been highlighted in this article are thoughtfully incorporated into the use planning of the platform. First, ensure that application use leverages the automation of both creation and release of resources, so that the greatest utilization efficiency can be realized. Then, ensure that the applications development and management teams make use of the automation and services components provided by the OpenStack services to enhance their application resiliency and recovery. And last but not least, ensure that a solid plan for operating (or engaging a third party to operate) the systems and underlying infrastructure is in place to support a successful OpenStack service.