Architectural Decision Framework — Choosing Your 'Ops Velocity'
Compare Kolla-Ansible, OSISM, Canonical Sunbeam, and OpenStack K8s Operators. Understand why platform engineering is driving toward the Kubernetes Resource Model (KRM).
On this page
The fastest way to fail an OpenStack deployment in 2026 isn’t picking bad software. It’s picking an abstraction layer your team isn’t built to run.
If you hand an Ansible-heavy sysadmin team a complex Kubernetes-native operator stack with fifty Custom Resource Definitions, they will drown in CNI failures and reconciler loops. Conversely, if you force a cloud-native platform team back into writing custom SSH playbooks, they will hate you.
There is no “one true way” to deploy OpenStack. There is only operational alignment.
You need to pick the deployment engine that matches your team’s existing skill sets today, while understanding where the platform engineering landscape is irrevocably headed: the Kubernetes Resource Model (KRM).
The Four Operational Paths
Instead of inventing custom bash glue, modern OpenStack operations cluster around four distinct deployment frameworks.
+-------------------------------------------------------------------+
| OPENSTACK DEPLOYMENT SPECTRUM |
+-------------------------------------------------------------------+
[Imperative Bare-Metal] ➜ Kolla-Ansible
[Full-Stack Sovereign] ➜ OSISM
[Zero-Touch Micro-Cloud] ➜ Canonical Sunbeam
[Declarative KRM Paradigm] ➜ OpenStack K8s Operators / OSHKolla-Ansible: Raw Imperative Containers
- The Paradigm: OpenStack services packaged as Docker/Podman containers and orchestrated over SSH using standard Ansible playbooks.
- The Reality: It’s straightforward, well-understood, and un-opinionated. But it’s imperative. You execute playbooks, sweep nodes over SSH, and manually fix things when an Ansible run fails halfway through a multi-node deployment.
Best For: Teams with deep Ansible roots who want raw host visibility without extra abstraction layers.
OSISM: The Sovereign Infrastructure Engine
- The Paradigm: The unified deployment engine behind the Sovereign Cloud Stack (SCS). It wraps Kolla-Ansible, Ceph-Ansible/cephadm, NetBox (as a Single Source of Truth), and host networking into a coherent operational framework.
- The Reality: OSISM solves the “glue” problem. It stops you from writing messy bash scripts to connect physical switch ports to NetBox and Ceph pools. It manages the whole physical datacenter lifecycle, not just the OpenStack API containers.
Best For: Enterprise datacenters and sovereign cloud providers that need full-stack lifecycle management compliant with European sovereignty standards.
Canonical Sunbeam: The Lightweight Micro-Cloud
- The Paradigm: A zero-touch OpenStack control plane packaged into snaps running on a low-overhead MicroK8s footprint.
- The Reality: Fast. You can go from a fresh machine to a running OpenStack API in under 30 minutes. But it is opinionated. The moment you try to heavily customize underlying Python daemons or deviate from its reference layout, you will fight the abstraction boundaries.
Best For: Edge deployments, developer sandboxes, PoCs, and small SRE teams with zero bandwidth for complex deployment plumbing.
OpenStack K8s Operators: The KRM End Goal
- The Paradigm: The entire OpenStack control plane managed as native Kubernetes Custom Resource Definitions (
CRDs) using active operator reconcilers. - The Reality: Continuous, declarative state loops replace SSH scripts. You declare
kind: KeystoneAPI, and the operator continuously ensures reality matches your Git repository.
Best For: Organizations already operating production Kubernetes who want to manage IaaS identically to application workloads via GitOps (ArgoCD/Flux).
Architecture Flow: Decision Tree Matrix
Comparative Analysis: Ops Matrix
| Metric | Kolla-Ansible | OSISM | Canonical Sunbeam | OpenStack K8s Operators |
|---|---|---|---|---|
| Control Substrate | Docker / Podman Containers | Docker / Podman + Ceph + NetBox | MicroK8s / Snaps | Production Kubernetes (Pods) |
| Execution Model | Imperative SSH Playbooks | Standardized Lifecycle Framework | Opinionated CLI / YAML | Declarative KRM Reconcilers |
| Day-2 Operations | Manual Ansible inventory runs | Structured OSISM CLI commands | Automated Snap / Juju updates | kubectl / ArgoCD GitOps |
| Minimum Footprint | 3 Control + 1 Compute | Multi-rack Datacenter | 1 Single Node or Multi-Node | 3 K8s Masters + Computes |
| Primary Target | Raw SysAdmin operations | Full Sovereign Cloud Stack (SCS) | Edge / Sandbox Labs | Cloud-Native Platform Teams |
Why the Industry is Driving Direct to KRM
Tools like Kolla-Ansible and OSISM exist because they solved real problems on physical bare metal when Kubernetes wasn’t mature enough to host IaaS control planes.
They work. They run production clouds today.
But platform engineering is undergoing a quiet unification. The Kubernetes Resource Model (KRM) is winning.
When your IaaS control plane is represented as Kubernetes CRDs, infrastructure management stops being a series of fragile SSH scripts run from an operator’s laptop. It becomes a continuously reconciled loop. If a database config drifts or an API service crashes, the operator reconciles it back to state asynchronously.
— — —
NDLR: While commercial OpenStack distributions and enterprise vendor packages exist across the market (e.g., Red Hat OpenShift Service on OpenStack, Mirantis OpenStack, Platform9), our philosophy at ape factory is strictly open source first. We prioritize pure, community-driven, vendor-neutral architectures that preserve digital sovereignty and eliminate proprietary lock-in.
