A financial group in Asia was running three infrastructures in parallel — OpenNebula, VMware and Kubernetes-as-a-Service — each with its own way in, and every service request landing on the support team as manual work. We built one self-service portal above all three: a single catalogue, one login, automated provisioning, ticketing and billing in the same place. It reached production in four months, roughly twice as fast as the nearest comparable projects, and the underlying estates were never replaced.
About the project
The client is a financial group operating its own infrastructure for internal teams and for customers. Over the years it had accumulated the usual layering: an OpenNebula estate, a VMware estate, and a newer Kubernetes-as-a-Service offering. Each was competently run. None of them shared a front door.
For a user, ordering anything meant knowing which system it lived in, finding the right way in, and asking someone. For the support team, every request was manual work: provisioning, access, quotas, the follow-up questions. The volume of that work was growing with the estate, and hiring against it was not a strategy.
Goals and objectives
- Give users one catalogue and one login covering services from all three systems, instead of several disconnected entry points.
- Automate the provisioning operations that support was performing by hand, so the team’s load stops scaling with the estate.
- Keep OpenNebula and VMware in place — the portal integrates with them rather than displacing them.
- Deliver billing, usage reporting, ticketing and audit as part of the same surface, not as separate tools bolted on later.
- Leave the group able to run and extend the platform itself.
Proposed solution
A portal built on the Kubernetes API rather than beside it. The API server acts as the aggregation layer and the single data bus: frontends talk to it, backend controllers and services sit behind it, and external databases and systems hang off those.
That choice does more work than it first appears to:
- Consistency — every operation, from ordering a VM to issuing an invoice, goes through the same standard API.
- Security — RBAC and audit are properties of the platform, not something each service reimplements.
- Scalability — horizontal scaling out of the box.
- Real time — the Watch API pushes changes to the frontends as they happen, so the console reflects reality rather than the last poll.
Portal components. User registration and SSO; a personal dashboard; the service catalogue covering virtual machines and Kubernetes-as-a-Service through OpenNebula; a ticket centre; a knowledge base and documentation; logging and audit; billing and invoicing; and a platform-administrator interface.
Modular architecture. Each module solves one business problem and is an independent service integrated through the Kubernetes API, scaling on its own:
- Frontend — Accounting Portal (billing, users, usage), Console Portal (VMs, networks, IP addresses), Support Portal (tickets, knowledge base).
- Backend — Accounting; Files (S3); Apps, the adapters for OpenNebula and VMware; Usage, for reports and tariffs; Support; Notification; Logging.
Results and current state
- Four months from the start of work to production — around twice as fast as the comparable projects the group had benchmarked against.
- A single self-service surface acts as the control point for the whole infrastructure, whichever system a service physically runs on.
- Integration with the tools the team already knew, VMware and OpenNebula, with the same pattern available for any further provider or external service.
- Provisioning that used to be manual now runs as automation, which is where the support-load reduction actually came from.
- Training and accompaniment for the customer’s team, L3 support for the first year, and a deliberate handover of competence.
Why this case matters
You do not have to replace the estate first
OpenNebula and VMware stayed exactly where they were. The portal went above them, and the business got what it asked for in months rather than years.
The Kubernetes API as the data bus
One API for every operation means RBAC, audit, real-time updates and horizontal scale come from the platform instead of being written, and rewritten, per service.
Billing belongs in the portal
Usage, tariffs and invoicing sit in the same surface as ordering and support — the thing most self-service projects postpone and then bolt on.
Support load is an automation problem
The team was not short of people; it was short of automated provisioning. Fixing that is what changed the workload.
This case study is published in anonymized form (Tier-3 evidence): the customer is described by profile, not by name. A customer reference is available under NDA on request — talk to Ænix sales.
Ænix is the team behind Cozystack — a CNCF project (Sandbox today; Incubating expected late summer 2026), Apache 2.0. Ænix commercializes it as Ænix Platform, as three platforms on one engine — Public Cloud, Private Cloud and AI — that combine rather than exclude each other.