OpenStack gives operators everything they need and gives developers a form for every resource. This guide sets out the layer that closes that gap: what it has to provide, how tenancy and managed services fit on top of an existing deployment, and the honest build-or-buy arithmetic.
A healthy OpenStack deployment is a genuine achievement. Nova schedules, Cinder attaches, Neutron routes, Keystone authenticates, and the operators running it have a complete API and a dashboard that exposes all of it. By any infrastructure measure the job is done.
Then a development team asks for a Kubernetes cluster with a Postgres database behind it, and the gap appears. Nothing in the deployment refuses the request; it simply has no concept of it. What exists is instances, volumes, networks and security groups, and somebody has to know how to compose those into the thing that was actually asked for. That somebody becomes a queue, and the cloud starts behaving like the ticket-driven infrastructure it was meant to replace.
This is not an OpenStack defect. It is a scope boundary: OpenStack builds infrastructure, and the layer that turns infrastructure into consumable services was always going to be somebody else's. In public clouds that layer is so tightly integrated it is invisible. On-premises, its absence is the whole problem.
Horizon gets unfairly blamed here. It is a well-built dashboard that exposes OpenStack's primitives clearly, and for an operator diagnosing a scheduling problem or checking a volume's state it is exactly right.
The mismatch is one of audience. Horizon organises the world the way OpenStack does, by component and by resource. A developer organises it by outcome: an environment, an application, a database. Asking that developer to pick a flavor, choose an image, create a network, attach a floating address and configure security groups is asking them to learn your infrastructure's internal model before they can do their job.
So the goal is not to replace Horizon. It is to add a second surface for a different audience, and to leave the operator surface alone. Any project that starts by taking Horizon away from the people who run the cloud is solving the wrong problem.
Across deployments, the same five gaps come up. Anything calling itself a self-service platform for OpenStack should close all of them, and it is worth checking each one specifically rather than accepting the category label.
Projects are the usual answer to multi-tenancy on OpenStack, and they are not quite enough. A project is a container for resources with quotas attached. What organizations actually need to express is a customer or a business unit that owns several projects, has its own users and roles, has limits that apply across all of it, and whose consumption can be reported as a unit.
Modelling that with projects alone produces naming conventions doing the work of a data model, which holds until someone needs a per-client total or a role that spans projects. A proper tenancy layer puts organizations above projects, applies roles and quotas at both levels, and enforces them for every managed service rather than per component. The users, projects and quotas guide covers the Keystone model underneath this: domains, projects, groups, role scopes, policy, and why quotas live in three services.
The reason this matters more for OpenStack than for a hyperscaler is that OpenStack is often chosen precisely by the organizations with the hardest tenancy requirements: service providers with real clients, and enterprises with business units that need genuine separation.
Kubernetes and PostgreSQL are the two services almost every deployment ends up needing, and both are easy to stand up once and expensive to run properly. The difference between a cluster and a managed cluster is upgrades, autoscaling, healing and the on-call rota behind them; the difference between a database and a managed database is failover, backups, tested restores and version lifecycle. The databases on OpenStack guide covers the routes to that, Trove included.
Building this on OpenStack means declarative provisioning (Cluster API with the OpenStack provider is the standard route for Kubernetes), a lifecycle controller that reconciles desired state continuously rather than running scripts on request, and integration with Cinder and Neutron so storage and load balancing are native rather than bolted on. The control plane guide covers the density decision, and the PostgreSQL DBaaS guide covers HA topology and volume layout. The Kubernetes on OpenStack architecture guide does the same for clusters: components, provisioning routes and day-2 work.
The test of whether a service is genuinely managed is simple: when a minor version needs applying at 2am on a Sunday, whose phone rings.
Organizations rarely have exactly one OpenStack. They have a main deployment, something inherited from an acquisition, a lab, and increasingly a set of small installations at physical sites. Managed separately, each is its own operational island.
Treating them as regions and availability zones under one platform changes that: teams choose placement rather than choosing a login, and policy applies uniformly. For edge estates the requirement goes further, because sites must survive losing their link. The architecture that works is one agent per facility pulling desired state and reconciling locally, so the site keeps provisioning and healing while disconnected and resynchronises when the link returns. That property, rather than raw scale, is what makes hundreds of sites operable by a small team.
The first version is not the expense, and that is what makes this decision easy to get wrong. A portal over the OpenStack API is a quarter's work for a good team and it will demo well. Everything after it is the real commitment: lifecycle controllers for every service you offer, a tenancy model that holds under audit, upgrade automation, an image and template pipeline, a marketplace, and then keeping all of it current against OpenStack releases and Kubernetes releases, indefinitely, with somebody on call when a reconcile loop wedges at 3am. If you are pricing the buy side of that decision, the OpenStack management platform is the product, and what it adds to an OpenStack you already run is the architectural answer.
Priced properly that is a standing platform team, not a project. And it carries a risk that rarely appears in the business case: ask what happens if the two engineers who built it leave. If the honest answer is that the platform freezes, what you built was not a platform, it was a dependency on two people.
edgeContinuum is that layer, as a product. It connects to the OpenStack you already operate through its standard APIs, so there is no reinstall and no migration, and it is usually running in hours rather than weeks. Your teams get a self-service console, an API and a Terraform provider; you get managed Kubernetes and managed PostgreSQL, VM catalogs and networking, an app marketplace you curate, and organizations, projects, roles and quotas enforced by the platform's IAM, with usage tracked per tenant. Nothing is forked, your operators keep Horizon, and the subscription is per managed resource rather than per core, so consolidating onto denser hardware does not cost you more.
Building still makes sense in two cases, and they are narrow: your requirements are genuinely unusual, or platform engineering is itself the product you sell. Outside those, the question is whether you want to own the layer or own the outcome. If it is the outcome, see what the platform does or talk to our engineers with your deployment in front of you, and they will tell you plainly where it does not fit.
Connect the deployment you already run and give your teams managed Kubernetes, PostgreSQL and VMs behind quotas you set. No reinstall, no fork, usually running in hours. Book a call and we will scope it against your estate.
