OpenStack has now potentially become too successful for its own good, with many users now starting to feel irritated and inhibited in growth goals and ambitions which they originally thought OpenStack would help them achieve.

PayPal, eBay, Sky, Walmart, AT&T – the list of companies now using OpenStack is both extensive and impressive. These trend-setters within their industries have all been using OpenStack to build and manage their cloud computing platforms, for both private and public clouds.

>See also: OpenStack is great but ‘vendor nonsense’ is corrupting it

While on the one hand they have experienced plenty of benefits from this, such as faster deployment, quicker scalability and reduced IT production costs, some problems are now starting to appear when these companies attempt to upgrade their OpenStack platforms.

This is clearly a considerable problem; clouds that are unable to upgrade could see a considerable decrease in the innovative disruption that some companies have become known for.

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.

>See also: Open source technology in enterprise

However, as these companies have modified their OpenStack to fit their organisation, 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. Old 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 organisations 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.

On the other hand, hope is still out there for firms that manage to combine business change with agile technology updates. These companies need to be aware that they’ll have to upgrade software without downtime on their websites.

>See also: Apache: 17 years on in the open source community

They need to know that when something malfunctions, they actually go into the model itself and fix the definitions, instead of just going for the cheap option and replacing the individual sever or process.

By doing this, they will ensure that their version of OpenStack is still able to provide them with the agility and functionality that pacemakers in this field require. Despite there being no quick or particularly easy ways to become unstuck, companies can take several steps.

These include building new standardised cloud infrastructure that’s easy and efficient to operate (this is something that a good vendor should be able to do, as well as supporting it on an ongoing basis), and then moving across relevant workloads to the most efficient environment.

From this point on, the business should be able to simply upgrade to each new OpenStack release as it comes out. Although this process will clearly take some time, it’s best to do it as early as possible so that the migrating workload doesn’t become too out-of-control and unwieldy.

>See also: Autonomous agents make up the living network in enterprise

A key point to note here is that while OpenStack may look like the main issue here, it is in fact just the tip of the iceberg. It’s any potential continuation of this, which could affect other software and other systems, which should be the biggest concern. Companies that committed this error with OpenStack are in danger of bringing similar issues down on themselves if they don’t act now, before it’s too late.

Sourced from Mark Baker, Ubuntu Product Manager for OpenStack, Canonical