Situation at a glance
- Industry: workspace, hospitality, and venue technology.
- Platform decision: use AKS for microservices and multi-tenant hosting.
- Operating model: combine ingress, registry, identity, and CI/CD into one platform path.
Context and split-system pressure
Core points
- The provider was operating across split systems that created scalability constraints and operational inefficiency.
- The platform had to support many customers while keeping tenant data isolated and controls understandable.
- The goal was not only to host applications, it was to create a platform that could absorb product growth.
AKS architecture and service choices
Core points
- Azure Kubernetes Service hosted a unified microservices architecture for the multi-client platform.
- Azure Load Balancers, ingress controllers, Azure Container Registry, CI/CD pipelines, and SAML federation supported traffic, image flow, deployment, and identity.
- The architecture connected cloud platform work to the AWS Managed Platform, so operations could be supported beyond launch.
Delivery milestones and operating controls
Core points
- The implementation merged separate platform concerns into one controlled AKS direction.
- Multi-tenant hosting requirements shaped the access, environment, and isolation model.
- Deployment automation made platform changes easier to promote and review.
Skunk tip
- For multi-tenant AKS work, treat identity and environment isolation as product requirements, not infrastructure details.
Measured outcomes and lessons
Core points
- The provider gained a more scalable and secure platform foundation for workspace and venue services.
- The platform became better prepared for rapid feature integration and market changes.
- The lesson is that Azure partner services work succeeds when tenant isolation, delivery automation, and support ownership are designed together.
Multi-tenant platforms fail quietly when isolation is treated as a configuration detail instead of a design principle.
