How to Succeed When '50 Percent of all Enterprises Fail in OpenStack'
A recent report from open-source software company, SUSE, shows “half of all enterprises that tried to implement an OpenStack cloud have failed and 65 percent of companies report they have found the implementation experience difficult.” Yet, “81 percent of senior IT professionals are planning to move or are already moving to OpenStack private cloud.”
It’s clear that OpenStack is one of the most popular choices for private cloud infrastructure—and rightfully so—but its complexity and perceived unreliability have been major barriers to adoption. Having assisted many companies through their OpenStack implementation process, there are three major considerations to understand before making the big move.
Understand the Shift
Customers adopt the cloud from two main platforms, physical server infrastructure and virtualization infrastructure, though most customers have already made the leap to virtualization.
One of the major reasons companies struggle with OpenStack is because they don’t understand the jump from virtualized infrastructure to the cloud, which is not just an OpenStack-specific issue. For organizations who have run legacy applications on a VM, moving to the cloud can feel much lonelier, particularly when things go wrong.
One of the major reasons companies struggle with OpenStack is because they don’t understand the jump from virtualized infrastructure to the cloud, which is not just an OpenStack-specific issue
One of the reasons for the premium cost of virtualization software is because fault tolerance is provided by that virtualization infrastructure. An application doesn’t have to understand the infrastructure it’s on and the organization does not have to design applications to be fault tolerant or cloud aware, nor do they have to design them to consume the infrastructure, be self-healing or self-managing; the infrastructure does all of that automatically.
Once those apps are moved to the cloud, and a component failure occurs—let’s say you lose a hypervisor that was running an application VM— the workload does not “fail over” on its own. You have to move from failure scenarios being automatically handled by virtualization logic (such as vMotion), to a situation where the developer is writing the application to recognize the failure and redirect the application to another resource (OpenStack node).
Prepare for the Transition Period
While it will make sense to move many existing applications to OpenStack, it’s not as simple as lifting and shifting those applications in one fell swoop.
There will likely be legacy applications that don’t warrant the shift at all because there is no business case for updating them. It’s critical then that organizations are prepared for their move to the cloud to take time, and many organizations will need to manage multiple platforms to handle the different use cases and workloads they are currently running.
One scenario we recommend to help ease the transition is setting up a staging environment where customers can test applications to see how they handle failures (of individual cloud components) before moving them to production. In this safe environment, developers can simulate the physical failure of compute or storage resources and evaluate/rewrite how the application responds.
It’s not realistic for a company to fully transition to OpenStack overnight, it takes time and there is an interim period where different apps are running concurrently in different environments.
Find the Right Pit Crew
The skills shortage is serious. According to SUSE, “86 percent of respondents said the lack of skills in the market is making their companies reluctant to pursue private cloud. In addition, 78 percent of companies that have yet to adopt private cloud are deterred by the skills shortage.”
Before an organization begins to implement, they must prepare to maintain. An organization has to consider how much expertise they’re going to bring in-house as a part of their cloud journey.
One side of that scale is a complete do-it-yourself model while the other is as-a-service model. Organizations have to figure out where on that continuum they’re going to be. One way to do that is to determine if cloud and OpenStack expertise are a core competency to their business.
Many companies believe they need to hire all of their expertise, have that knowledge inside their walls and depend on themselves to do everything when it’s not core to their business. Very few customers will see the value in hiring 20 OpenStack engineers to run a private cloud, and having that expertise in-house is not going to help grow their business. Furthermore, these engineers are incredibly difficult to recruit, train and retain.
The as-a-service model on the other hand enables business innovation and speed to revenue while protecting them from risk. It also allows you to focus your resources and hiring on revenue-generating applications—all the things that make your customers happy and make money for the business.
This third and most important consideration is really about picking where time is spent—it’s not to say an organization should have no cloud or OpenStack expertise in-house at all, but it’s about finding that middle ground. At Rackspace, we strongly believe that the as-a-service model is the superior way to consume OpenStack leveraging expertise at scale.
Companies are rapidly moving to the cloud and OpenStack as their platform of choice, and while some remain hesitant due to the concerns mentioned above, others are succeeding in their transition because they’ve considered the shift, how long it will take and the amount of expertise they need to have in-house to make it all work.