Plan B

Ten years ago, reports of the decline of OpenStack would have been completely unthinkable. For a while at least, many people thought that OpenStack was a miraculous solution for most of their IT problems. From the perspective of 2022, many, if not most, of the hopes once associated with OpenStack (Figure 1) have not been met for the majority of users.

Figure 1: OpenStack is considered the ultimate in private cloud software, but the complexity of the environment often exceeds what enterprises can realistically achieve. © OpenStack Foundation

In the Kubernetes era, OpenStack has shrunk massively as a project, with nothing like the number of developers actively involved as there were the past. Similarly, many formerly prominent and almost militant OpenStack proponents have scaled back or ended their OpenStack involvement.

This development also has its good side. In the course of the past decade, several large-scale OpenStack projects failed because expectations and requirements were more or less undefined up front. Additionally, it was not clear in some cases what OpenStack is, what it can do, and what it cannot do. Often enough, OpenStack was chosen for projects that could not be implemented at all with this tool, or with massive restrictions.

That many manufacturers have dropped out is not automatically considered a great misfortune. For example, participation of all storage vendors (e.g., HP, Dell EMC, SanDisk) meant great hardware support for numerous devices, but it also meant all the major vendors dispatched as many employees as possible into the fray to determine the fate of the project. OpenStack has now largely freed itself from this stranglehold.

Where OpenStack Fails

Administrators are still skeptical when it comes to storing their data with AWS and the like and face a dilemma: A public cloud doesn't work because people are worried about their data, but when it comes to a private cloud, many administrators automatically think of OpenStack and get cold feet. It makes sense to address the reasons that cause OpenStack projects to fail, because this is the only way to empower admins to evaluate realistically whether OpenStack is suitable for their intended use case. Where the answer to the suitability question is "no," I look at potential alternatives.

The saying "the cloud is just somebody else's computer" stopped being true a long time ago. Today, "cloud" also means infrastructure automation, Infrastructure as Code (IaC), immutable underlay, microarchitecture, and so on. Although OpenStack development has slowed, it still remains a complex construct and today comprises more than 30 individual components; admittedly, not every admin really needs every one of them. If you reduce the number of tools to the absolute minimum, however, you are still left with at least six components. You need to know what they are and clearly understand the basic functionality of tools such as Nova, Cinder, or Glance.

Many large OpenStack projects have failed to make this simple hurdle. In many cases, problems of understanding have led to companies seeing OpenStack as a continuation of VMware by other means. In terms of comfort and ease of administration, however, OpenStack cannot and never wanted to compete with VMware. Moreover, classic VMware setups are often based on completely different premises; for example, software-defined networking (SDN) is missing as a core component. Many companies that adopted OpenStack in the hope of cost savings suddenly found themselves faced with uncontrollable complexity and eventually gave up in total frustration. Often the reason was that the goal of operating some virtual machines (VMs) was out of proportion to the overhead.

OpenStack Is Complex

To this day, OpenStack Summits regularly feature presentations of companies proudly talking about their automated OpenStack, putting the number of servers per admin at 2,000 units and more. In fact, OpenStack can be operated in this way, but before automation and orchestration are set up, adapted, and in operation, a great deal of work must be done – and by personnel who know their stuff.

It is virtually impossible for a company with no OpenStack experience to turn to a boxed solution like Red Hat OpenStack Platform (RHOP) and build a giant cloud with full automation in just a few weeks. After too long a development period without concrete results, quite a few companies are either running out of patience, money, or both to continue working on OpenStack. It is precisely these OpenStack behemoth projects that have done massive damage to the software's reputation over the past decade.

In summary, the reasons for the failure of OpenStack in many organizations are: too little research in advance, unrealistic assessment of OpenStack's complexity, wrong choice of OpenStack in the assumption that all of its features are needed, and excessive overhead for operating the product itself in an automated and therefore efficient way.

Possible Alternatives

The beauty of analysis is that it also shows a way out of the predicament by setting out the parameters that ought to play a role when choosing an alternative to OpenStack.

Many companies, for example, need virtualization with a feature such as high availability, but often multitenancy is not a factor. However, this already accounts for a considerable part of OpenStack's complexity, because it often drags in other features, such as SDN.

Still other companies might need a sophisticated virtual network, but not OpenStack's self-service capabilities. These capabilities frequently play a significant role in the project, because on-demand use is a central characteristic of clouds.

Classical virtualization with minor VM fluctuation, on the other hand, can often do without colorful web interfaces, which in turn contributes significantly to reducing complexity. This pruning to essentials leaves a small but select group of less complex OpenStack alternatives, which I discuss in detail.