Managing modern applications has become increasingly complex as organizations transition from monolithic systems to distributed microservices architectures. This shift has brought tremendous scalability and flexibility, but it has also introduced new challenges in ensuring reliable, secure, and efficient communication between services.

In this blog, we’ll explore Service Mesh, a solution specifically designed to tackle these challenges. You’ll learn what a Service Mesh is, why it’s a game-changer for managing microservices communication, and how it integrates seamlessly with Azure Kubernetes Service (AKS). We’ll also provide a step-by-step guide to set up and demo a Service Mesh, so you can see it in action.

A Service Mesh is a dedicated infrastructure layer designed to manage and optimize communication between microservices within a distributed application. It acts as a network of lightweight proxies that oversee how services interact, enabling secure, reliable, and observable communication without requiring significant changes to the application code.

In simpler terms, a Service Mesh is like a traffic control system for microservices. It ensures that requests are routed efficiently, securely, and with full visibility, handling tasks like retries, load balancing, and encryption. This allows developers to focus on building features, while operational complexities such as service discovery and traffic management are handled transparently by the mesh.

At the core of a Service Mesh is the sidecar proxy model. Instead of microservices communicating directly with each other, each service is paired with a small, independent proxy (known as a sidecar) that runs alongside it. These sidecars handle all communication on behalf of the microservice, intercepting requests and responses to provide features like:

With these components, a Service Mesh provides a robust foundation for building scalable, secure, and maintainable microservices architectures.

The Service Mesh ecosystem is rich with solutions tailored to diverse operational needs. While all Service Mesh technologies share common goals—improving service-to-service communication, enhancing security, and providing observability—they differ in their implementation, ecosystem integration, and complexity.

Here’s a high-level comparison of the most popular Service Mesh solutions:

While these solutions differ in approach and complexity, they share several foundational capabilities:

Azure Kubernetes Service (AKS) is a managed Kubernetes offering that supports deploying and managing Service Mesh solutions seamlessly. Here’s how these Service Meshes integrate with AKS:

Azure’s support for Kubernetes-native tools, combined with its integration with Azure Monitor and Azure Policy, makes it an excellent platform for running Service Mesh solutions. Whether you prioritize simplicity or advanced features, AKS provides the scalability and flexibility to deploy your preferred Service Mesh effectively.

The adoption of Service Meshes is growing rapidly in distributed microservices architectures due to the significant advantages they bring in managing inter-service communication. However, they are not a one-size-fits-all solution, and their value depends heavily on the specific challenges and scale of your application.

A Service Mesh provides built-in security features, such as mutual TLS (mTLS), to encrypt service-to-service communication. This ensures:

Monitoring microservices can be daunting due to their distributed nature. A Service Mesh provides out-of-the-box observability features, enabling developers and operators to:

Managing traffic between microservices is critical to ensure high availability and reliability. A Service Mesh automates:

Service Meshes streamline service discovery by automatically detecting services as they are deployed and updating routing rules accordingly. This ensures:

While a Service Mesh can be a game-changer, it’s not suitable for every scenario. Here are situations where it adds the most value:

Despite its benefits, a Service Mesh introduces certain trade-offs that should be considered:

A Service Mesh may not be necessary if you have a monolithic application or a small number of microservices, your architecture doesn’t require advanced traffic management or security features, or if your team lacks the bandwidth or expertise to manage the additional complexity.

A Service Mesh can be transformative for modern, distributed systems, providing robust features like enhanced security, observability, and traffic control. However, its adoption should be guided by a clear understanding of its trade-offs. By carefully evaluating your architecture and operational needs, you can determine whether a Service Mesh is the right fit for your application.

In this step-by-step walkthrough, we’ll create an AKS cluster that supports the Istio-based Service Mesh add-on, and configure the Service Mesh add-on, which simplifies the deployment of Istio in your cluster. We’ll then deploy a sample microservices application into the AKS cluster. After, we’ll set up traffic management policies such as retries and load balancing. Lastly, we’ll implement secure communication using mTLS.

By the end of the walkthrough, you’ll have a working example of Istio on AKS, along with insights into its capabilities and integration with Azure-native services.

Microsoft offers an Istio-based Service Mesh add-on for Azure Kubernetes Service (AKS) that simplifies the deployment and management of Istio. While it builds on the open-source Istio project, the add-on introduces several enhancements tailored for Azure users:

However, there are limitations to keep in mind:

Before setting up the Service Mesh, ensure the following requirements are met:

If you don’t already have an AKS cluster, you’ll first need to create one. The following steps show how to set it up using Azure CLI.

Step 1: Log in to Azure by running the command below:

az login

This will authenticate you to your Azure account. If you have multiple subscriptions, you can select the one you want to use by running the command below:

az account set --subscription "Your-Subscription-Name"

Step 2: Create a resource group to organize your AKS resources by running the command below:

az group create --name myResourceGroup --location northeurope

Step 3: Create a new AKS cluster within the resource group by running the command below:

az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 3 --enable-addons monitoring --generate-ssh-keys

This command creates an AKS cluster named myAKSCluster with 3 nodes and enables monitoring (for Azure Monitor). The –generate-ssh-keys option generates SSH keys if you don’t already have them.

Step 4: Once your AKS cluster is created, you need to configure your kubectl to use the cluster’s credentials. Run the commands below to do so:

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Now you can interact with the AKS cluster using kubectl.

Now that we have our AKS cluster set up, we can enable the Istio-based Service Mesh add-on.

Step 5: To enable the Istio-based Service Mesh add-on, run the following command:

az aks mesh enable --resource-group myResourceGroup --name myAKSCluster

This command will install the Istio add-on, which simplifies the process of deploying Istio in your AKS cluster. Azure will handle the scaling and configuration of the Istio control plane.

Step 6: Check the status of the Istio components using kubectl, by running the command below:

kubectl get pods -n aks-istio-system

You should see the Istio pod has a status of Running, like the example below:

With the Istio-based Service Mesh set up, it’s time to deploy a sample application that will use the Service Mesh features. We’ll deploy a simple microservices application to illustrate the Service Mesh’s capabilities.

For this demo, we’ll use a simple Bookinfo application that includes a frontend service, multiple backend services, and a database. This application is widely used to demonstrate Istio capabilities, which consists of the following services:

Step 7: Deploy the Bookinfo application by running the command below:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/platform/kube/bookinfo.yaml

Step 8: To check if the application has been successfully deployed, use the command below:

kubectl get services

You should see the services like productpage, reviews, and ratings running in your cluster.

Now, let’s configure some of the core features of the Service Mesh to enhance traffic management and security.

Step 9: We’ll configure Istio’s traffic management capabilities to control the flow of requests between services. We’ll create a VirtualService and a DestinationRule to control traffic routing between different versions of the reviews service. Create a reviews-traffic.yaml file, like below:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
    - route:
        - destination:
            host: reviews
            subset: v1
          weight: 80
        - destination:
            host: reviews
            subset: v2
          weight: 20
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Step 10: Apply this configuration by running the command below:

kubectl apply -f reviews-traffic.yaml

You can verify that the traffic distribution is working by accessing the productpage service and observing the different versions of the reviews service being called.

Step 11: To ensure secure communication between services, we’ll enable mutual TLS (mTLS), which automatically encrypts traffic between services in the mesh. You can enforce mTLS by creating a PeerAuthentication resource for the default namespace, by running the command below:

kubectl apply -f - <<EOF
apiVersion: authentication.istio.io/v1alpha1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT
EOF

This will require all services in the default namespace to communicate using mTLS. Once mTLS is enabled, all communication between the services will be encrypted, ensuring confidentiality and integrity. You can verify the mTLS status by checking the communication policies in Istio.

Now that we’ve deployed the demo application and configured key Service Mesh features, it’s time to test the setup.

Step 12: Use the following command to retrieve the external IP address of the Istio ingress gateway:

Open your browser and navigate to http://<EXTERNAL-IP>/productpage, replacing <EXTERNAL-IP> with the IP address you retrieved in your terminal.

Step 13: You can also check the logs of the productpage service to verify the versions of the reviews service it is contacting. Get the Pod name for productpage by running the command below:

kubectl get pods -l app=productpage

Step 14: Use the pod name to view logs, by running the command below:

kubectl logs <productpage-pod-name>

Look for requests routed to reviews and observe the version being contacted (e.g., reviews-v1, reviews-v2).

By using the browser interface, distributed tracing tools, or application logs, you can confirm that traffic is being routed as specified in your VirtualService configuration.

We’ll now delete all resources after completing this walkthrough, to ensure that you avoid unnecessary costs.

Step 15: Run the command below to delete the resource group and all resources within this resource group entirely:

az group delete --name myResourceGroup --yes --no-wait

Step 16: To ensure the resources are deleted, you can list all active resource groups, by running the command below:

az group list --query "[].name"

The resource group should no longer appear in the list.

Step 17: Make sure you delete downloaded credentials (kubeconfig file) by running the command below:

rm -rf ~/.kube/config

Your environment is now cleaned up, and you won’t incur any further charges.

We’ve explored how a Service Mesh, specifically Istio on Azure Kubernetes Service (AKS), enhances the management of microservices communication. A Service Mesh simplifies traffic management, enforces security policies like mTLS, and provides deep observability and traffic control. By abstracting the complexity of service-to-service communication, it empowers developers and DevOps professionals to focus on application logic rather than infrastructure.

However, as we’ve seen, implementing a Service Mesh comes with its own set of challenges, such as added complexity and resource overhead. These are important considerations before introducing a Service Mesh into your architecture. Nevertheless, for large-scale, distributed systems with multiple microservices, the benefits—especially in terms of security, observability, and traffic control—far outweigh the drawbacks.

The best way to understand and leverage a Service Mesh is by getting hands-on experience with it. To learn more about and to continue your journey with Service Mesh and Istio on AKS, you can start with reading some of the resources below:

Thank you for taking the time to go through this post and making it to the end. Stay tuned, because we’ll keep continuing providing more content on topics like this in the future.