OpenStack has, to an extent, become too successful for its own good. Just seven years after its inception, many users are starting to feel frustrated and inhibited in their ambitions which they thought OpenStack would help them realize.

The list of companies using OpenStack now includes eBay, Paypal, Sky, Walmart, AT&T, and Bloomberg. All leaders within their respective industries, using OpenStack to help build and manage their cloud computing platforms for public and private clouds. While they have reaped the rewards of this, with benefits including reduced IT production costs, faster deployment and scalability, some are now beginning to come across problems when trying to upgrade their OpenStack platforms. As OpenStack has become a byword for business enhancement and innovation, stagnating clouds could result in a significant decrease in the amount of industry innovation and disruption that some businesses have become known for.

Do it right

Many of OpenStack’s early adopters modified with the software in small but significant ways which hindered their capacity to upgrade OpenStack at the necessary rate to protect against known security vulnerabilities and issues. This has become a serious problem for those companies left stranded in this situation; it’s thought 77 per cent of OpenStack operators are no longer using a version of the system supported by the upstream OpenStack community in a stable branch.

The importance of this can hardly be overstated; these constant updates and upgrades are what allows businesses to keep ahead of the game in their particular industries. The issues caused by this are often extensive; these companies will be using software we now know has security flaws and vulnerabilities.

However, as these companies have modified their OpenStack to fit their organization, they now find themselves with a somewhat bleak choice; they can either select an expensive upgrade, or turn to their own developers to find an alternative to OpenStack, which in turn could lead to major security vulnerabilities. Canonical has christened this problem ‘Stuck Stack’; the situation where a company’s stack can move neither forward or back without considerable expense or upgrading.

The list of issues which can afflict OpenStack has grown exponentially over the years. At time of writing, there are 172 known vulnerabilities just for OpenStack. This is not unusual, all software projects have issues and the OpenStack community is quick to fix those that affect the stable branches. Ols versions may not get the fixes though as the fix will be to upgrade. Adding in the problems which can affect third party software dependent on OpenStack increases the number of potential vulnerabilities significantly. Any one of these security flaws can result in the loss of crucial system capabilities that enable businesses to engage in innovation and disruption.

While there are of course plenty of reasons for firms now finding themselves in this ‘stuck stack’ situation, closer inspection reveals one overarching factor behind the problem.

Many organizations simply failed to keep up with the rapid release cycle of the various OpenStack updates. With two releases each year and a support cycle which lasts 12 months, many companies inevitably fell behind. A typical company’s approach to updating their system might run something like this; start considering the new release a few months after it appears, then run some tests and evaluations, before considering integration with other products and services. Eventually, after 9/10 months or so the release is ready to be rolled out – just as it’s officially approaching the end of its supported life span. As a consequence, many firms have fallen far behind.

While painful and frustrating, this frantic speed of releases is the price companies pay for requiring OpenStack to stay true to its original ideals to be a continually evolving platform that enables firms to innovate and push the boundaries. For OpenStack to provide a platform that’s able to compete within the public cloud, the releases need to be rolled out thick and fast. This is the continual conversation and conflict that affects the whole idea of OpenStack; the need to have innovation and constant digital disruption on the one hand, but also to have ensured safety and security for your company.

However, for those companies which manage to combine agile technology updates with business change, hope can yet be found. Such companies should be aware they will need to upgrade software without downtime on their websites, and will also need to ensure that when something malfunctions, they don’t just go for a cheap fix on an individual server or process, but actually go into the model itself and fix the definitions. These steps will ensure that their version of OpenStack is still able to provide them with the functionality and agility they need to continue as the pacemakers in their field.

Although there are no magic solutions to becoming unstuck, there are several steps that can be taken. These include building new standardized cloud infrastructure that can be operated efficiently (a good vendor should be able to build the specific package you require and then support it on an ongoing basis), then migrating workloads to the most efficient environment. From that point, a business will be able to upgrade to each new OpenStack release as it comes out. While this process will inevitably take time, doing it as early as possible is advisable, so that the workload being migrated doesn’t swell to unmanageable proportions.

It’s important to note the problem here is not with OpenStack itself; that is merely the tip of the iceberg. It’s the potential continuation of the Stuck Stack issue to affect other software and systems which should be the biggest concern. Companies which made this mistake with OpenStack risk similar issues with all future technology adoption if they don’t act now.

Mark Baker is Ubuntu product manager for OpenStack at Canonical