Reflections on OpenStack: Past, Present, and Future from a User Perspective
This article examines OpenStack’s evolution over the past eight years, analyzes its current positioning against VMware and AWS, discusses the challenges of its “big tent” model and core services, and speculates on possible future paths for the platform from a user’s viewpoint.
In October 2010 OpenStack released its first version and by last month the eighteenth release, Rocky, had been launched. After years of hype the community now wonders whether OpenStack is dying or being replaced by Kubernetes.
As a user, I reflect on the past eight years of OpenStack’s journey and look ahead to the next eight years to assess its prospects.
Who are we as users?
Our team, part of the HH Group cloud platform team, built an internal cloud platform with the architecture shown below.
The platform’s main features include:
Compute: KVM, ESXi, and bare‑metal resource pools.
Network: Neutron + VLAN + OVS for virtual networking.
Storage: Ceph and SAN for block storage; Ceph for object storage.
Zones: Three regions across two cities and three data centers, each with resource pools and availability zones, plus a small public‑cloud zone.
Components: Glance, Nova, Neutron, Cinder, Keystone, Heat, Telemetry, OVSvAPP, Trove, Ironic, etc., from the Mitaka release.
Management: A self‑developed cloud management console.
Container platform: A Kubernetes‑based cloud running on our own physical machines.
Team: Up to eight developers and three operations engineers.
Overall, the system runs well, supports hundreds of internal applications, and has become stable with low operational pressure. However, we have encountered stability issues such as occasional Neutron VR switches, KVM VM reboots or crashes, and poor Windows support.
Monitoring and logging components are immature and often require extensive rework. Many non‑core projects, like Trove, needed substantial code rewrites to achieve basic functionality. OpenStack still lags far behind public‑cloud requirements.
What should OpenStack’s positioning be?
The original 2010 mission was to provide an open‑source cloud platform for both public and private clouds, essentially an open‑source AWS. User surveys since 2014 show that OpenStack cannot compete in the public‑cloud market; its primary battlefield is private cloud, which accounts for about 80% of deployments.
In the private‑cloud arena, VMware dominates. Therefore, OpenStack should aim to match VMware’s virtualization capabilities while also offering AWS‑style cloud APIs. While OpenStack has done a decent job replicating AWS cloud APIs, its virtualization features fall short of VMware’s offerings.
Comparative tables (shown in the original article) illustrate that many vSphere functions are missing or only partially implemented in OpenStack, limiting its ability to replace VMware.
Problems with the “big tent” model
Since 2015 OpenStack split projects into core and non‑core services. Although the six core services have high usage rates (>90% in 2017 surveys), they still receive frequent complaints. The core service scope is too narrow, lacking essential capabilities such as robust orchestration (Heat), monitoring (Ceilometer), bare‑metal provisioning (Ironic), logging, and one‑click deployment tools.
Many newer projects—Magnum, Sahara, Trove, Kolla—receive interest but see very few production deployments, and their adoption is declining.
Private‑cloud environments differ from public clouds: they often have a unified physical layer but fragmented management platforms, making automated creation and destruction of services less critical. Consequently, OpenStack’s attempts to provide “cloud‑native” services for containers, big data, and databases are often seen as pseudo‑requirements.
Why OpenStack faces a mid‑life crisis
Key reasons include the disruptive impact of containers, lack of clear positioning, community’s scattered focus, over‑ambitious but under‑delivered projects, and competition from mature VMware solutions. Many startups chased contribution metrics and hype rather than solid product delivery.
Future scenarios for OpenStack
Two possible paths emerge: (1) OpenStack becomes a simple orchestrator for KVM VMs and Ceph volumes, eventually fading like CloudStack; (2) OpenStack evolves into a foundational, native‑cloud platform supporting serverless workloads, akin to AWS or VMware. Current trends suggest the first path is more likely.
Personal reflections
I have deep affection for OpenStack; it introduced me to cloud concepts and connected me with many peers. Despite its shortcomings, OpenStack remains a key private‑cloud solution in China and has left a lasting mark on IT history.
Warm reminder: Scan the QR code or search “ICT_Architect” for the original link and more e‑book details.
Architects' Tech Alliance
Sharing project experiences, insights into cutting-edge architectures, focusing on cloud computing, microservices, big data, hyper-convergence, storage, data protection, artificial intelligence, industry practices and solutions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.