Modernizing the enterprise container platform
Moving Medavie Inc.'s containers off a capacity- and licence-constrained Mirantis platform onto VMware vSphere Kubernetes Service, instead of growing the old platform or borrowing capacity from non-production.
- Medavie Inc.
- 2025–2026
- Manager, IT Services: the decision and its delivery
- All work
Where it started
Medavie Inc. ran its container workloads on Mirantis, across Docker Swarm and Kubernetes, on a mix of physical and virtual infrastructure. By May 2026 its capacity was essentially flat year over year: Mirantis licensing limited further horizontal scaling, the physical nodes were fully allocated, and the virtual environment was close to its practical overcommit limits. The Linux and Windows estates were under the same pressure.
The newer VMware vSphere Kubernetes Service (VKS) environment, meanwhile, had room for everything then running on Mirantis, with headroom to spare.
The problem
Growing the legacy platform meant putting more money into something already constrained, and accepting rising delivery, stability and scaling risk. Virtualizing the remaining physical Mirantis nodes helped operationally, but it didn't fix capacity.
There was an operating-model problem too. As teams adopted containers, gaps in their troubleshooting skills were making them more and more dependent on SRE and Platform Engineering: incomplete diagnostics, early escalation, and Kubernetes expertise concentrated in a few specialists. That threatened both delivery and how long the platform could be sustained.
The decisions
Migrate to VKS now, rather than grow Mirantis
I recommended accelerating the move to VKS. It had the capacity, Platform Engineering was ready to support the application migrations, and Enterprise Architecture already had a migration playbook.
Turned down: reclaiming capacity from non-production to keep production growing on Mirantis. It was a break-glass option needing director-level agreement, and it put Dev/Test capability, environment separation, production stability and disaster recovery at risk. It would have solved a strategic platform problem by cannibalizing capacity.
VKS as the strategic platform
VKS became the container platform the migrations were aimed at.
Turned down: Rancher and OpenShift, mainly on their learning curve for the teams, and also on cost.
Make application teams own the first tier
Rather than make Platform Engineering and SRE permanent application support, I pushed for clearer first-tier troubleshooting responsibilities, standard intake, and stronger ownership by the application teams.
Turned down: moving the workloads and leaving the support model as it was, which would have carried the dependence on a few specialists onto the new platform.
Check the benefits against real tickets
The expected benefits were reassessed against actual ticket and support-channel data from the VKS and Mirantis channels, not assumptions alone. When a reviewer challenged how some of the estimated time savings had been calculated, the environment and hour figures were revised after validation with the platform engineering team.
Turned down: a business case resting on estimates.
The outcome
Every workload moved to VKS, and the Mirantis MKE infrastructure has been shut down and decommissioned. Production Kubernetes, 9 nodes and 181 pods, now runs on VKS, on a platform with room to grow.
The support model changed with it: clearer first-tier troubleshooting, standard intake, and application teams owning more of their own applications, so Kubernetes knowledge no longer sits with a few specialists.