Microservices Architecture on Azure

Microservices architecture is a software development approach where an application is composed of small, independent services that communicate over well-defined APIs. Each service is self-contained, implements a single business capability, and can be developed, deployed, and scaled independently. This contrasts with monolithic applications where all functionality is tightly coupled and deployed as a single unit.

Azure provides a comprehensive set of services to build and run microservices, including: - Azure Kubernetes Service (AKS) for container orchestration. - Azure Container Instances (ACI) for serverless containers. - Azure Service Fabric for stateful microservices. - Azure Functions for event-driven, serverless compute. - API Management for API gateway functionality. - Azure DevOps for CI/CD pipelines.

The exam expects you to know when to choose each service and how they integrate.

Microservices communicate via synchronous protocols (HTTP/REST, gRPC) or asynchronous messaging (Azure Service Bus, Event Grid, Event Hubs). Each service runs in its own process, often inside a container. Containers provide isolation and consistency across environments. Orchestrators like Kubernetes manage container lifecycle, scaling, networking, and service discovery.

Service Discovery: In a dynamic environment where services scale up/down, a service registry (e.g., Azure DNS, Kubernetes DNS) maintains the current IP addresses of service instances. When Service A needs to call Service B, it queries the registry to get a healthy endpoint.

API Gateway: An API gateway acts as a single entry point for external clients. It handles authentication, rate limiting, request routing, and protocol translation. Azure API Management is a fully managed service that provides these capabilities.

Circuit Breaker Pattern: To prevent cascading failures, if a downstream service is failing, the circuit breaker trips and returns a fallback response instead of waiting endlessly. This is implemented using libraries like Polly or Istio's circuit breaker.

Load Balancing: Traffic is distributed across service instances using round-robin, least connections, or consistent hashing. In AKS, the kube-proxy component manages load balancing within the cluster.

To create an AKS cluster:

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

To deploy a microservice:

kubectl apply -f deployment.yaml

To verify cluster status:

az aks show --resource-group myGroup --name myCluster --query provisioningState

To check pods:

kubectl get pods -o wide

Microservices often integrate with: - Azure DevOps for CI/CD: Build pipelines create container images, push to ACR, and deploy to AKS. - Azure Monitor for observability: Collects metrics, logs, and traces from containers. - Azure Policy for governance: Enforces tagging, ensures only approved images are used. - Azure Active Directory (Azure AD) for authentication: AKS can integrate with Azure AD for Kubernetes RBAC. - Azure Key Vault for secrets management: Pods can mount secrets from Key Vault using CSI driver.

Horizontal Pod Autoscaler (HPA) in Kubernetes automatically scales pods based on CPU/memory metrics or custom metrics. For example:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

For high availability, deploy AKS clusters across availability zones (minimum 3 zones). Use Azure Traffic Manager or Azure Front Door to route traffic to multiple clusters in different regions.

The AZ-305 exam tests your ability to recommend appropriate Azure services for microservices. Key objectives include: - Objective 4.1: Recommend a compute solution (AKS, Container Instances, Service Fabric). - Objective 4.2: Recommend a container orchestration solution (AKS vs. Service Fabric). - Objective 4.4: Design for application architecture (microservices, API management, messaging). - Objective 5.1: Design for high availability (multi-region AKS, load balancing).

You must understand trade-offs: AKS is best for stateless microservices, Service Fabric supports stateful services, Container Instances are for simple, short-lived tasks. The exam also tests integration with API Management, Service Bus, and Event Grid.

A large online retailer migrated from a monolithic .NET application to microservices on AKS. They decomposed the monolith into 50+ services: product catalog, shopping cart, order processing, payment, inventory, shipping, and user management. Each service runs in its own Kubernetes namespace with resource limits (e.g., 500m CPU, 512MB memory). They use Azure API Management as the gateway for external clients (web and mobile apps) and internal services communicate via Azure Service Bus for order events. The cluster has 20 nodes (Standard_D8s_v3) across three availability zones. They implemented HPA to scale based on CPU and custom metrics (e.g., queue depth). The biggest challenge was managing data consistency across services; they adopted the saga pattern using Azure Service Bus and compensating transactions. Misconfiguration of network policies initially caused connectivity issues—they had to explicitly allow traffic between services using Kubernetes Network Policies.

A bank built a real-time fraud detection system using Azure Service Fabric for stateful microservices. The system processes credit card transactions in near real-time, maintaining user session state and fraud models. Service Fabric was chosen over AKS because it provides built-in support for stateful services with reliable collections and low-latency communication. The cluster runs on 10 nodes (Standard_D4s_v3) across two regions for disaster recovery. They use Azure Event Hubs to ingest transaction events, and Service Fabric actors to update user profiles. The key performance metric is latency under 10ms per transaction. A common mistake was not configuring partition schemes correctly, leading to hot partitions. They resolved this by using a consistent hash based on user ID.

A manufacturing company built a serverless backend for IoT device data ingestion. Each device sends telemetry to Azure IoT Hub, which triggers an Azure Function that processes and stores data. For compute-intensive tasks like image recognition, they use Azure Container Instances (ACI) with GPU support. ACI was chosen because it's simple, starts in seconds, and scales to zero when idle. They use Azure Logic Apps to orchestrate workflows. The challenge was managing container lifecycle—they implemented a custom scheduler using Azure Functions to start ACI containers based on queue length. Misconfiguration of container groups (e.g., not setting resource limits) caused cost overruns. They now enforce tags and budgets.