This article is based on reporting originally published at infoworld.com in February 2017.
Kubernetes Arrives as a GA Option on Azure Container Service
In February 2017, Microsoft announced that Kubernetes had reached general availability (GA) on Azure Container Service (ACS), the company’s managed cloud container hosting platform. The release added Kubernetes as a fully supported orchestrator alongside the two options ACS already offered: the Apache Mesos-based DC/OS and Docker Swarm.
The announcement was notable not only for Kubernetes users, but also because it highlighted an unusual point of collaboration between Microsoft and Google — two otherwise fierce competitors in the cloud market.
Why Container Orchestration Matters
Containers package an application and its dependencies into an isolated, portable, and consistent runtime environment — a model that maps particularly well to cloud-native deployments. However, running containers at scale introduces new operational challenges: scheduling workloads, managing failures, scaling services, and handling networking between containers.
Container orchestrators like Kubernetes address these challenges by automating the deployment, scaling, and lifecycle management of containerized applications across clusters of machines. Managed services like ACS go one step further by abstracting away the complexity of setting up and operating the orchestration layer itself, letting teams focus on their applications rather than their infrastructure.
A Unique Multi-Orchestrator Strategy
At the time of this announcement, Microsoft’s approach stood out among major cloud providers. Amazon’s EC2 Container Service (ECS) relied on its own proprietary orchestrator, while Google Container Engine (now Google Kubernetes Engine, or GKE) supported only Kubernetes. Azure Container Service was alone in offering customers a choice of three different orchestration backends under a consistent management experience.
Brendan Burns — a former Google engineer, one of the original Kubernetes project maintainers, and at the time a recent Microsoft hire — explained the rationale. He argued that the ACS value proposition rested on two pillars: access to Microsoft’s broader Azure ecosystem of services layered on top of container orchestration, and the consistent operational experience ACS provides regardless of which orchestrator a team selects.
“And in that way, managing one open source orchestrator versus another open source orchestrator is actually a fairly comparable experience.”
— Brendan Burns, Principal Engineer, Microsoft
Kubernetes: From Google Skunkworks to Cloud-Neutral Standard
Kubernetes originated as an internal Google project, drawing on the company’s experience running large-scale containerized workloads with its internal Borg system. Google open-sourced Kubernetes in 2014, and it was donated to the Cloud Native Computing Foundation (CNCF) in 2016. By the time of this ACS announcement, the project had grown into a genuinely vendor-neutral effort with significant contributions from Microsoft, Red Hat, CoreOS, and many others — making its inclusion in a Microsoft service less surprising than it might once have seemed.
Beta Support for Windows Server Containers
Alongside the Kubernetes GA announcement, Microsoft also launched beta support for using Kubernetes on ACS to manage Windows Server Containers — not just Linux containers. This mirrored the existing beta support for running Windows Server containers via Docker Swarm on ACS, and signaled Microsoft’s intent to bring Kubernetes to Windows-based workloads, an important consideration for enterprise teams running .NET applications.
Timeline and Context
- Mid-2016: Microsoft released Kubernetes support on ACS in public beta.
- February 2017: Kubernetes on ACS reaches general availability.
- February 2017 (simultaneous): Beta support for Kubernetes managing Windows Server Containers on ACS is announced.
Key Takeaways for DevOps Teams
- ACS gave teams the flexibility to choose Kubernetes, DC/OS, or Docker Swarm without being locked into a single orchestrator.
- The GA release meant production-grade SLA backing for Kubernetes workloads on Azure.
- Early Windows Server Container support on Kubernetes opened a migration path for Windows-based enterprise workloads.
- Brendan Burns’s move from Google to Microsoft illustrated how Kubernetes had become a genuinely cross-vendor project, not a Google-exclusive technology.
Note: Azure Container Service has since been superseded by Azure Kubernetes Service (AKS), which focuses exclusively on Kubernetes and offers a more streamlined managed experience. Teams evaluating Azure container orchestration today should refer to current AKS documentation.