A Closer Look at Microsoft Azure’s Managed Kubernetes Service

Microsoft’s initial version of Azure Container Service, its a Containers as a Service (CaaS), offered a choice of orchestration engines in the form of Mesosphere DC/OS, Docker Swarm, and Kubernetes. But none of them were truly managed, which meant that the customers had to maintain the environment including patching, upgradation, scaling, and managing the clusters. In many ways, Microsoft only automated the initial setup and configuration of container orchestration tools without really managing the post-deployment phase.

After a couple of years of announcing the initial version of ACS, Microsoft has joined the bandwagon of cloud providers with managed Kubernetes service. Google was the first to deliver Google Kubernetes Engine (GKE) followed by IBM with its IBM Cloud Container Service. Microsoft became the third major cloud provider to offer managed Kubernetes as a Service. It has also rebranding Azure Container Service to AKS to prominently highlight the inclusion of Kubernetes.

Apart from branding, what has changed since the initial version of ACS is the core architecture of Azure CaaS offering. In the earlier versions, customers had visibility of Kubernetes master servers and nodes. They had to mention the number of master servers included in the cluster. Once deployed, administrators could SSH into one of the master nodes to take control of the deployment. With managed Kubernetes on Azure, Microsoft no longer exposes the master servers. Since Azure manages the multi-tenant master servers, they are completely obscured from customer deployments. What customers end up seeing in their subscriptions is only the set of nodes running their containerized workloads.

Read the entire article at The New Stack

Janakiram MSV is an analyst, advisor, and architect. Follow him on Twitter,  Facebook and LinkedIn.