Eine Finanzgruppe in Asien betrieb drei Infrastrukturen parallel — OpenNebula, VMware und Kubernetes-as-a-Service — jede mit eigenem Zugang, und jede Service-Anfrage landete als Handarbeit beim Support. Wir haben ein Self-Service-Portal über alle drei gelegt: ein Katalog, ein Login, automatisiertes Provisioning, Ticketing und Billing an derselben Stelle. Nach vier Monaten produktiv, etwa doppelt so schnell wie vergleichbare Projekte — und kein Bestand musste dafür ersetzt werden.
Über das Projekt
Der Kunde ist eine Finanzgruppe, die eigene Infrastruktur für interne Teams und für Kunden betreibt. Über die Jahre hatte sich die übliche Schichtung angesammelt: ein OpenNebula-Bestand, ein VMware-Bestand und ein neueres Kubernetes-as-a-Service-Angebot. Jedes für sich kompetent betrieben. Keines mit einer gemeinsamen Eingangstür.
Für Nutzer hieß eine Bestellung: wissen, in welchem System die Sache lebt, den richtigen Zugang finden und jemanden fragen. Für den Support war jede Anfrage Handarbeit — Provisioning, Zugriffe, Quotas, Rückfragen. Dieser Aufwand wuchs mit dem Bestand, und dagegen anzustellen war keine Strategie.
Ziele
- Ein Katalog und ein Login über Services aus allen drei Systemen statt mehrerer getrennter Einstiege.
- Automatisieren, was der Support von Hand provisionierte, damit seine Last nicht mit dem Bestand mitwächst.
- OpenNebula und VMware bleiben im Betrieb — das Portal integriert sie, statt sie zu verdrängen.
- Billing, Verbrauchs-Reporting, Ticketing und Audit als Teil derselben Oberfläche, nicht als später angeflanschte Werkzeuge.
- Die Gruppe soll die Plattform selbst betreiben und erweitern können.
Lösung
Ein Portal auf der Kubernetes-API statt daneben. Der API-Server ist Aggregationsebene und einziger Datenbus: Frontends sprechen mit ihm, Backend-Controller und -Services liegen dahinter, externe Datenbanken und Systeme hängen daran.
Diese Entscheidung leistet mehr, als sie zunächst aussieht:
- Einheitlichkeit — jede Operation, vom Bestellen einer VM bis zur Rechnung, läuft über dieselbe Standard-API.
- Sicherheit — RBAC und Audit sind Eigenschaften der Plattform, nicht etwas, das jeder Service neu implementiert.
- Skalierbarkeit — horizontale Skalierung ab Werk.
- Echtzeit — die Watch-API schiebt Änderungen sofort an die Frontends; die Konsole zeigt den Ist-Zustand, nicht den letzten Poll.
Portal-Komponenten. Registrierung und SSO; persönliches Dashboard; Servicekatalog mit virtuellen Maschinen und Kubernetes-as-a-Service über OpenNebula; Ticket-Center; Wissensdatenbank und Dokumentation; Logging und Audit; Billing und Rechnungsstellung; Administrator-Oberfläche der Plattform.
Modulare Architektur. Jedes Modul löst eine Geschäftsaufgabe, ist ein eigenständiger Service, integriert sich über die Kubernetes-API und skaliert für sich:
- Frontend — Accounting Portal (Billing, Nutzer, Verbrauch), Console Portal (VMs, Netze, IP-Adressen), Support Portal (Tickets, Wissensdatenbank).
- Backend — Accounting; Files (S3); Apps, die Adapter für OpenNebula und VMware; Usage für Berichte und Tarife; Support; Notification; Logging.
Ergebnisse
- Vier Monate von Arbeitsbeginn bis Produktion — etwa doppelt so schnell wie die Vergleichsprojekte, an denen sich die Gruppe orientiert hatte.
- Eine Self-Service-Oberfläche als Steuerpult für die gesamte Infrastruktur, unabhängig davon, in welchem System ein Service physisch läuft.
- Integration mit den Werkzeugen, die das Team kannte — VMware und OpenNebula — nach einem Muster, das für jeden weiteren Anbieter genauso funktioniert.
- Provisioning, das früher Handarbeit war, läuft als Automatisierung. Daher kommt die geringere Support-Last.
- Schulung und Begleitung des Kundenteams, L3-Support im ersten Jahr, bewusster Kompetenztransfer.
Warum dieser Fall zählt
Der Bestand muss nicht zuerst weg
OpenNebula und VMware blieben unangetastet. Das Portal kam darüber — und das Geschäft bekam sein Ergebnis in Monaten statt Jahren.
Die Kubernetes-API als Datenbus
Eine API für alles heißt: RBAC, Audit, Echtzeit und horizontale Skalierung kommen von der Plattform, statt pro Service geschrieben zu werden.
Billing gehört ins Portal
Verbrauch, Tarife und Rechnungen in derselben Oberfläche wie Bestellung und Support — genau das, was Self-Service-Projekte sonst vertagen.
Support-Last ist ein Automatisierungsproblem
Dem Team fehlten keine Leute, sondern automatisiertes Provisioning. Das zu ändern hat die Last verändert.
Diese Case Study erscheint anonymisiert (Tier-3-Evidenz): Der Kunde wird über sein Profil beschrieben, nicht über seinen Namen. Eine Kundenreferenz ist unter NDA auf Anfrage möglich — sprechen Sie mit dem Ænix-Vertrieb.
Ænix ist das Team hinter Cozystack — einem CNCF-Projekt (heute Sandbox, Incubating erwartet im Spätsommer 2026), Apache 2.0. Ænix kommerzialisiert es als Ænix Platform in drei Plattformen — Provider und Enterprise — mit den Modulen AI Platform und Developer Self-Service.