OpenStack: The Full Reference Cloud (and What It Costs You)

If the private-cloud intro asked “what would it take to rebuild AWS on your own hardware,” OpenStack is the platform that answers “all of it, and here is the bill.” It is the most complete, most powerful, and most operationally demanding option in this entire series — the only one that genuinely tries to reproduce every capability from the intro’s eight-item table, at a scale that runs CERN and Walmart. It is also the platform most likely to defeat a team that underestimates it. This post is an honest accounting of both halves: the staggering power, and the staggering price.

Recall the series’ dividing line: does it have a real placement scheduler? OpenStack does not merely pass that test — Nova’s filter/weigher scheduler is the reference implementation everyone else is measured against. OpenStack is the cloud platform; the question was never whether it is powerful enough, but whether you can afford to run it.

What OpenStack is: a suite, not a program

The first thing to understand is that OpenStack is not a thing — it is a constellation of independent services, each owning one capability, communicating over APIs and a shared message bus. There are more than thirty services in the broader ecosystem; the core handful you must know map almost one-to-one onto AWS:

                         ┌──────────────┐
   Users ──API/Horizon──►│   Keystone    │  auth + service catalog
                         └──────┬───────┘
        ┌──────────┬───────────┼───────────┬───────────┐
        ▼          ▼           ▼            ▼           ▼
     ┌─────┐   ┌──────┐    ┌──────┐    ┌──────┐    ┌──────┐
     │ Nova │   │Neutron│    │Cinder│    │Glance│    │Swift │
     │compute│  │  SDN  │    │block │    │images│    │object│
     └───┬──┘   └──────┘    └──────┘    └──────┘    └──────┘
         │  (Nova scheduler places instances on compute hosts)
         ▼
   message bus (RabbitMQ) + database (MySQL/MariaDB) under everything

This modularity is simultaneously OpenStack’s greatest strength and its defining curse. You can run exactly the services you need and scale each independently to thousands of nodes — but you must operate every one you run, plus the message bus and database they all depend on.

The current release as of mid-2026 is 2026.1 “Gazpacho”, shipped April 1, 2026. It is a marquee release: Nova gained parallel live migrations (previous releases migrated VMs off a host one at a time, so maintenance windows grew linearly with VM count — now they run concurrently), the project completed its long migration from the old eventlet concurrency model to native threading (a deep modernization), and Neutron’s OVN driver added BGP support and North-South routing. Gazpacho is also a SLURP release (Skip-Level Upgrade Release Process), so operators can upgrade directly from the previous SLURP (Epoxy, 2025.1) without stepping through the intermediate version — a real concession to the upgrade pain that has long dogged OpenStack.

The scheduler: the gold standard for placement

Nova’s scheduler is what the rest of this series is implicitly compared against. When you request an instance — “give me a 4-vCPU, 8 GB VM on a network, from this image” — naming no host, Nova’s scheduler runs a two-stage placement:

1. Filters eliminate every host that cannot satisfy a hard constraint: insufficient capacity (checked against the Placement service’s live inventory), wrong CPU features, missing the requested network, failing affinity/anti-affinity rules, wrong availability zone, absent PCI/GPU device. Dozens of filters ship, and you can write your own.
2. Weighers score the survivors: spread load to the emptiest host, pack onto the fullest, balance by RAM, prefer certain image types — each weigher contributes a weighted value, and the highest total wins.

   Request: 4 vCPU, 8 GB, net=tenant-a, image=ubuntu, anti-affinity group=web
                 │
                 ▼
   ┌──────────────────────────────────────────────┐
   │ Nova scheduler                                │
   │  FILTERS  → drop hosts lacking capacity, the   │
   │             network, the CPU features, or that │
   │             violate anti-affinity              │
   │  WEIGHERS → score survivors (spread? pack?      │
   │             RAM-balanced?)                      │
   └──────────────────┬───────────────────────────┘
                      ▼
        Places on the highest-scoring host, automatically

This is the most configurable, most capable placement engine in the open-source world. Affinity and anti-affinity groups, availability zones, host aggregates, NUMA-aware placement, GPU and SR-IOV scheduling — it is all here. If your requirement is “the platform must make sophisticated placement decisions at scale,” OpenStack is the unambiguous answer. (It does placement at boot and migration time; continuous DRS-style rebalancing is achievable with external tooling like Watcher, but is not the default loop.)

Where OpenStack is unmatched

It is the closest thing to a private AWS, genuinely. Self-service provisioning, a complete API for every resource, real software-defined networking with tenant isolation, block and object storage, image management, orchestration — the full IaaS surface, not a subset. No other platform in this series covers as much of the intro’s capability table.

Multi-tenancy and IAM done properly. Keystone gives you a real projects/domains/roles model with fine-grained RBAC, and quotas are enforced per-project across compute, storage, and network. This is enterprise-grade isolation — the kind that lets a hosting provider safely sell slices of one cluster to mutually-distrusting customers. Most platforms in this series treat multi-tenancy as a feature; OpenStack treats it as a foundation.

Real, deep SDN. Neutron (especially with the OVN driver) delivers overlay networks, distributed virtual routing, security groups, floating IPs, load-balancing, and — as of Gazpacho — BGP and advanced North-South routing. When the intro warned that “real SDN is genuinely complex,” Neutron is where that complexity is fully realized and exposed. For network-centric use cases, nothing else here competes.

It scales to the moon and is proven there. OpenStack runs CERN (around 90 petabytes to an exabyte of storage, millions of cores), Walmart, Vodafone, OVHcloud, and BT, backed by the OpenInfra Foundation and 600-plus contributing companies. The scale ceiling is effectively “as large as you can operate.” If you are building infrastructure for thousands of nodes and many teams, OpenStack is designed for exactly that, and has the production references to prove it.

Bare metal and orchestration included. Ironic provisions physical machines through the same API as VMs (echoing the MAAS post later in this series), and Heat gives you CloudFormation-style declarative stacks. The platform reaches below VMs to hardware and above them to application orchestration.

Where OpenStack will hurt you

Now the honest half, stated as plainly as the strengths.

The operational complexity is real and famous. Thirty-plus services, each with its own configuration, logs, failure modes, and upgrade considerations, all sitting on a shared RabbitMQ message bus and a MySQL/MariaDB database that are themselves critical infrastructure. When something breaks, the cause might live in any service, the bus, the database, or the network fabric beneath them. Diagnosing a wedged control plane at 2 a.m. requires understanding how the whole constellation fits together. This is not FUD — it is the consistently reported lived experience.

Nearly half of OpenStack implementations fail. That statistic, widely cited in the industry, is sobering and worth taking seriously. The failures are usually not the software’s fault per se — they stem from teams underestimating the specialized knowledge required. OpenStack does not forgive being treated as a weekend project at production scale.

It demands a team. Operating a cloud of several hundred nodes with confidence typically requires three to eight trained people whose job is the platform. For a business, that is a real headcount decision — the operational cost the intro called “the actual price.” OpenStack’s no-license-fee is comprehensively offset by its labor cost. This is the single most important sentence in this post: OpenStack is free the way a sailboat is free.

The learning curve is steep, and you survive it via a deployment tool. Nobody hand-installs OpenStack service-by-service in production anymore; it is impractical. You deploy through tooling that automates the constellation:

• Kolla-Ansible — runs every OpenStack service in containers, orchestrated by Ansible. The mainstream production choice; flexible and reliable, with an intuitive configuration model.
• OpenStack-Ansible — Ansible-driven deployment into containers/LXC, another well-trodden production path.
• Canonical Sunbeam / MicroStack — Canonical’s modern, opinionated path; MicroStack in particular runs a multi-node OpenStack (Keystone, Nova, Neutron, Glance, Cinder) on a single workstation with as little as 8 GB RAM, which is the right way to try OpenStack and to use it in CI.

Even with these, the tool deploys the complexity — it does not remove it. You still operate what it stands up.

When the power is worth the pain — and when it absolutely is not

The intro’s framing applies most sharply here: match the platform to the need, not the ambition. OpenStack is the most cloud-like option, which makes it the most tempting and the most over-deployed.

OpenStack is worth it when:

• You are operating at genuine scale — hundreds to thousands of nodes — where the per-node operational overhead amortizes and the scale ceiling matters.
• You need true multi-tenancy and fine-grained IAM because you are serving many teams or external customers from shared infrastructure.
• You need deep, programmable SDN and storage that the lighter platforms cannot match.
• You can fund and retain a team whose job is the cloud — and you are building a durable platform, not a side project.
• You are a telco, a research institution, a public-cloud provider, or a large enterprise standardizing on-prem IaaS — the profile OpenStack was built for.

OpenStack is the wrong choice when:

• You have a handful of nodes. The intro said it and it bears repeating: a small shop is almost always better served by Proxmox, Incus, or OpenNebula than by standing up OpenStack. The operational tax dwarfs the benefit at small scale.
• You do not have, and cannot justify, dedicated platform staff. Without the team, you are in the half of implementations that fail.
• You want to run twenty VMs and occasionally not care which host. That is a job for a scripted Proxmox or OpenNebula, not a thirty-service cloud.
• You are a homelabber who wants to learn OpenStack — in which case, absolutely do it, but with MicroStack on one machine, eyes open that you are studying the technology, not adopting it for convenience.

Trying it without regret

If you want hands-on OpenStack without committing a cluster and a team, the sane on-ramp is MicroStack or a small Kolla-Ansible lab:

1
2
3
4
5
6

# MicroStack: a full single-node OpenStack to learn on (needs ~8GB+ RAM)
sudo snap install openstack --channel 2026.1
sunbeam prepare-node-script | bash -x      # prep the host
sunbeam cluster bootstrap                  # stand up the control plane
sunbeam configure --openrc demo-openrc     # generate credentials
sunbeam launch ubuntu --name test-vm       # boot an instance — scheduler places it

That last command is, once again, the whole point of this series: you asked for an instance and named no host; Nova’s scheduler placed it. The difference with OpenStack is that the same command, backed by a real cluster, scales to placing that instance among thousands of hosts with sophisticated constraints — and that the machinery making it possible is a constellation you must master and staff.

Verdict

OpenStack is the full reference cloud: the most complete reproduction of a public cloud you can run on your own hardware, with the best placement scheduler, the deepest SDN, real multi-tenancy, and a proven path to exabyte scale. It is also the heaviest operational commitment in this series by a wide margin — thirty-plus services, a notorious learning curve, and a real team as the price of admission. Choose OpenStack when you are operating at the scale and with the staffing it was designed for; choose almost anything else in this series when you are not. The power is genuine, and so is the cost, and conflating “most capable” with “right for me” is exactly the mistake the intro warned against.

Next up, the platform that exists largely because of OpenStack’s complexity: Apache CloudStack, the underrated workhorse that delivers much of the same cloud surface with a fraction of the operational pain.

Sources:

• OpenStack Releases: 2026.1 Gazpacho
• OpenStack Gazpacho 2026.1: What’s New for Enterprise Cloud — Open Edge
• OpenStack: complete guide to the open source cloud platform in 2026 — DualMedia
• Kolla-Ansible — OpenStack deployment in containers
• MicroStack vs OpenStack comparison 2026 — Slashdot