To Istio and beyond: Azure’s Service Mesh Interface

Microsoft’s latest Kubernetes development is set to change the way we deploy distributed applications

Modern, cloud-first application development, at least on Azure, has become almost dependent on Kubernetes. Technologies such as Virtual Kubelets, the AKS (Azure Kubernetes Service), and the Azure Service Fabric Mesh are key to building scalable distributed applications on Azure, using containers to deploy and manage microservices.

Looking at Azure’s Kubernetes tools, it’s clear that Microsoft is doing a lot of work in and around the Cloud Native Computing Foundation, working on all aspects of the open source framework. We shouldn’t be surprised; Microsoft hired one of the founders of the Kubernetes project and then acquired Deis, a significant vendor. The Deis team is behind one of the latest Azure contributions to the Kubernetes ecosystem, the Service Mesh Interface (SMI).

Introducing service meshes

It’s perhaps best to first explain what a service mesh is and why it’s important to any Kubernetes-based application.

Modern IT architectures are all about abstraction. With cloud services we no longer need to think about the underlying hardware. If we’re using IaaS we define virtual machines to host our code. With PaaS we’re even further from the hardware, using the services and APIs we chose, picking an appropriate performance level for our applications and budgets. With container-based architectures such as Kubernetes, we’re at a point somewhere in between the two: using services like AKS we can define the underlying virtual machines, which then host our container pods and scale out with changes in compute and memory (and now with KEDA (Kubernetes-based event-driven autoscaling), on receipt of events).

To continue reading this article register now