DevOps Microservices and Service Mesh

Microservices is an architectural style where a large application is broken into small, independent services. Each service handles one specific business function, runs in its own process, and communicates with others over a network — typically via HTTP/REST or gRPC.

A service mesh is a dedicated infrastructure layer that handles all service-to-service communication in a microservices system — transparently, without changes to the application code.

Monolith vs Microservices

Microservices Design Principles

Single Responsibility

Each service does one thing well. An e-commerce app might have separate services for: user accounts, product catalog, shopping cart, payments, order management, notifications, and recommendations.

Loose Coupling

Services know nothing about each other's internal implementation. They communicate only through well-defined APIs or events.

High Cohesion

Related functionality belongs in the same service. The payment service handles all payment logic — not scattered across multiple services.

Independent Deployability

A change to the notification service can be deployed without touching or restarting the payment service.

Decentralized Data

Each service owns its own database. The user service uses PostgreSQL. The product catalog uses MongoDB. Services never share databases directly — they communicate via APIs.

Communication Patterns

Synchronous – REST / gRPC

Service A calls Service B and waits for a response. Simple but creates tight runtime dependencies.

# REST example: Order service calling Payment service
GET /api/payments/validate
Host: payment-service
Authorization: Bearer token123

Response:
{
  "valid": true,
  "available_credit": 500.00
}

Asynchronous – Message Queues

Service A publishes an event to a message queue. Service B consumes it when ready. No direct coupling. Tools: Apache Kafka, RabbitMQ, AWS SQS.

# Order service publishes event to Kafka
Topic: order.created
Message: {
  "order_id": "ORD-9821",
  "user_id": "USR-441",
  "total": 89.99,
  "timestamp": "2025-03-15T10:30:00Z"
}

# Notification service subscribes to order.created
# and sends a confirmation email asynchronously

Challenges of Microservices

Microservices solve some problems but introduce new ones:

• Network failures: Services communicate over the network — which can fail, be slow, or time out.
• Service discovery: How does Service A find the current IP/port of Service B?
• Load balancing: Traffic distribution across multiple instances of a service.
• Security: Every service-to-service call needs authentication and authorization.
• Observability: A single request touches 10 services — tracing it end-to-end is complex.
• Distributed tracing: Finding where a failure occurred across many services.
• Circuit breaking: Preventing a slow service from cascading failures across the system.

This is where the service mesh comes in.

What Is a Service Mesh?

A service mesh adds a lightweight proxy (called a sidecar) alongside every service container. The sidecar intercepts all network traffic into and out of the service. The application code sends requests normally — the sidecar handles everything else transparently.

What the Sidecar Handles

• mTLS (Mutual TLS): Encrypts all service-to-service traffic and verifies both sides' identities.
• Load balancing: Distributes requests across healthy instances using advanced algorithms.
• Circuit breaking: Stops sending requests to a failing service to prevent cascading failures.
• Retries and timeouts: Automatically retries failed requests with configurable limits.
• Traffic shaping: Routes a percentage of traffic to a new version (canary deployments).
• Observability: Collects metrics, traces, and logs for every service call automatically.

Istio – A Popular Service Mesh

Istio is the most widely adopted service mesh. It uses Envoy as the sidecar proxy and provides a control plane for managing policies.

Istio Architecture

• Data Plane: Envoy sidecar proxies injected into every Pod. Handle all actual traffic.
• Control Plane (Istiod): Manages configuration, certificates, and service discovery. Pushes config to all Envoy proxies.

Enabling Istio Sidecar Injection

# Label a namespace to auto-inject Envoy sidecar into all pods
kubectl label namespace production istio-injection=enabled

# Deploy the application normally — Istio injects the sidecar automatically
kubectl apply -f webapp-deployment.yaml

Traffic Management – Canary Deployment

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: webapp
spec:
  hosts:
    - webapp
  http:
    - route:
        - destination:
            host: webapp
            subset: v1
          weight: 90
        - destination:
            host: webapp
            subset: v2
          weight: 10

This routes 90% of traffic to v1 and 10% to the new v2. Gradually increase the v2 weight as confidence grows.

Circuit Breaker

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: payment-service
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 60s

If the payment service returns 5 consecutive errors, Istio ejects it from the load balancer pool for 60 seconds — preventing the entire system from being dragged down by one unhealthy service.

Deployment Strategies for Microservices

Blue-Green Deployment

Two identical environments exist: blue (current) and green (new). Traffic switches from blue to green instantly. Rollback is instant — just switch traffic back.

Canary Deployment

Roll out the new version to a small percentage of users first. Monitor metrics. Gradually increase the percentage. Roll back immediately if metrics degrade.

Rolling Update

Replace instances of the old version one at a time with the new version. Kubernetes does this natively. Zero downtime, but both versions run simultaneously during the update.

API Gateway

An API Gateway sits in front of all microservices and handles external client requests. It provides: authentication, rate limiting, routing, SSL termination, and request/response transformation — in one place.

Popular API gateways: Kong, AWS API Gateway, NGINX, Traefik.

Summary

• Microservices break applications into small, independently deployable services — each owning its own data and logic.
• Services communicate synchronously (REST/gRPC) or asynchronously (Kafka/RabbitMQ).
• Microservices introduce challenges: network failures, service discovery, security, and observability.
• A service mesh (Istio, Linkerd) solves these challenges transparently using sidecar proxies.
• Istio provides mTLS, circuit breaking, traffic shaping, retries, and automatic observability.
• Canary and blue-green deployments enable safe, controlled rollouts of new versions.