There's a growing, worrying phenomenon emerging in OpenStack. It has emerged out of OpenStack's nature as free software. It's costing the enterprise more to run their clouds, while holding them back from the latest advances. And, it affects 73% of OpenStack cloud operators.
It's called a "Stuck Stack."
A Stuck Stack is the inability to upgrade an OpenStack cloud to a newer version, leaving companies on older, unsupported versions with known vulnerabilities and issues that require increasingly specialized skill sets to maintain the longer they're stuck.
Meanwhile, their competitors leap ahead with enhanced security features, simplified cloud operations and improved container support on the newest OpenStack release.
The latest OpenStack user survey showed that, already halfway through Newton's lifecycle, only 27% of OpenStack users are running the latest release. So, what's keeping so many OpenStack deployments on older versions?
Some might argue that the very nature of OpenStack makes upgrading a challenge. Others suggest that newer versions aren't compelling enough to make the jump. But, there's a different theory behind the Stuck Stack.
Coming to grips with OpenStack
OpenStack, in its purest form, is not difficult to upgrade. Each release is designed for seamless rollover and goes through reams of community testing to ensure that the process is as painless as possible. But, the average deployment isn't pure, untouched OpenStack.
One of OpenStack's strongest characteristics is its customizability. An OpenStack cloud can be built exactly how an enterprise needs it, to fit into the existing processes and technologies within an organization. It was that flexibility that had so many IT teams rubbing their hands with glee at the prospect of building their own clouds to fit their needs. Finally, they could catch up with their rivals who had the freedom to work in public cloud.
However, this very characteristic set in motion a chain of events that -- seven years on -- has resulted in an overwhelming number of Stuck Stacks. It is here we encounter the ghost in the machine of free software. By its very nature, it encourages freedom of development. After all, if a cloud and its applications cost nothing to run, what could be the harm of building, testing, deploying and patching, a hundred times over?
So it has been with OpenStack, as the enterprise worked to build private clouds that would fit precisely into their existing infrastructure. Each element of customization added another piece to what eventually became a hulking beast, a bespoke, OpenStack-based cloud with months, if not years, of custom features and specifications built in.
Building your cloud
When a new release came along, those IT teams looked at their beast of a private cloud and were faced with two options. The first was to tear down the custom features to upgrade and rebuild, or the second was to take up the bare minimal end-of-life security support to stay safe, and protect the organization from $100,000-an-hour downtime
All the while, accepting that this custom OpenStack cloud would require increasingly specialized skills to maintain and improve internally, at a time of near-full employment in the IT industry. Suddenly, free software looked very expensive indeed.
As soon as an organization chose the latter, they set out on a path that would only cement their Stuck Stack problem.
Each new development would add to the work needed to upgrade their OpenStack cloud. Each new release would put their original OpenStack version further out of date. And, with each release, the business assessment of upgrading would take longer, and come to the same conclusion: With the capabilities we have, it will cost us less to stay behind than it will to try to catch up.
A better way
What's an IT shop to do?
What now? Abandon OpenStack and start from scratch? Throw caution to the wind and make the jump to the public cloud?
These are hardly appealing options for million- and billion-dollar enterprises, especially ones that have bought into the promise of OpenStack at its core, which is the promise of scalable, open infrastructure that can deliver agility and cost efficiencies for the next generation of applications.
So, how to unstick a Stuck Stack?
First, the team must accept that it has a problem -- one that requires a new approach. The practices that create Stuck Stacks take time to become ingrained, and the first step to undoing them is to acknowledge their existence, and their flaws.
Keep up with the latest enterprise cloud news and insights. Sign up for the weekly Enterprise Cloud News newsletter.
That can mean cultural and organizational change -- change that could be difficult to swallow, but necessary to succeed.
That new approach should be model-driven, putting an end to a focus on machines and instead, focusing on the services that run across them. A model-driven approach makes it far simpler to lift and shift applications between different environments. Software models can be tested across infrastructure without changing the core of the implementation, making the implementation and the software themselves reusable, and turning applications from ingrained pieces of a cloud into functions that can be dragged-and-dropped into new environments.
With this new approach in place, an organization can now migrate its workloads to the most efficient environment, rather than being beholden to its one outdated OpenStack cloud. And, it can migrate those workloads over to one cloud while it upgrades another, keeping the engine running while embracing new capabilities.
With these steps in place, a Stuck Stack can be unstuck, and future versions of OpenStack are within reach.
An organization can transform its custom-built, out-of-date OpenStack cloud into an efficient, up-to-date deployment with model-driven software running on top of it. The key, above all, is recognizing when a Stack is Stuck, accepting that there is a better way and taking the steps to achieve it.
— Mark Baker is the Ubuntu product manager for OpenStack at Canonical.