Deployment & Infrastructure

Deployment & Infrastructure

1. Containerization & Orchestration: The Foundation

Before you can deploy or scale microservices effectively, you need a standardized way to package and run them.

  • Containerization (Docker): Solves the “it works on my machine” problem. Docker packages an application and all its dependencies into a single, immutable container image. This ensures consistency across development, testing, and production environments.

  • Orchestration (Kubernetes): If Docker manages individual containers, Kubernetes (K8s) manages the ecosystem. It automates deployment, scaling, load balancing, and self-healing (restarting crashed containers).

How They Work Together

Docker provides the bricks; Kubernetes is the architect building and maintaining the house. K8s groups Docker containers into Pods, manages their lifecycle, and ensures your desired state (e.g., “always keep 5 replicas of the billing service running”) matches the actual state.

2. Deployment Strategies: Minimizing Downtime

Once your services are orchestrated, you need to update them without disrupting users. Kubernetes natively supports or integrates with tools to enable these strategies:

Strategy How it Works Pros Cons
Rolling Update Replaces old pods with new ones gradually (e.g., 1-by-1). Zero downtime; low resource overhead. Hard to roll back quickly if a bug is found late; two versions run simultaneously.
Blue-Green Maintains two identical environments. Blue is live; Green gets the new build. Traffic is flipped instantly via a router/load balancer. Instant rollback; isolated testing. Costs double the infrastructure resources during deployment.
Canary Rolls out the new version to a tiny subset of users (e.g., 5%) first. If metrics look good, it scales to 100%. Safest for testing real-world impact and performance under load. Complex routing logic and monitoring required.

3. Strangler Fig Pattern: Migrating the Monolith

You rarely get the luxury of shutting down a business to rewrite a monolithic application into microservices. The Strangler Fig pattern solves this by breaking the monolith down incrementally.

  1. Introduce an API Gateway / Reverse Proxy: Place it in front of your existing monolith. Initially, all traffic passes straight through to the monolith.

  2. Carve out a Domain: Identify a single bounded context (e.g., the “Notification” service) from the monolith and build it as a new microservice (containerized and deployed on K8s).

  3. Reroute Traffic: Update the API Gateway to route notification requests to the new microservice, while all other traffic still goes to the monolith.

  4. Repeat: Repeat this process for other domains until the monolith shrinks to nothing and is safely decommissioned.

4. Infrastructure as Code (IaC): Managing the Chaos

Managing microservices means dealing with dozens of repositories, databases, K8s clusters, and networking rules. Doing this manually in a cloud console is a recipe for disaster.

Infrastructure as Code (IaC) treats your infrastructure setup exactly like application software—written in code, version-controlled (Git), and automated.

  • Provisioning Tools (Terraform, OpenTofu, Pulumi): Used to spin up the actual infrastructure, such as cloud servers, managed Kubernetes clusters (EKS, GKE), databases, and VPC networks.

  • Configuration & GitOps (Helm, ArgoCD): While Terraform sets up the K8s cluster, tools like Helm package your Kubernetes manifests, and ArgoCD automates the deployment of those manifests using a GitOps approach (where Git is the single source of truth for your infrastructure state).

Bringing It All Together

In a mature DevOps lifecycle, these components form a seamless pipeline:

  1. A developer pushes code changes to Git to replace a piece of a monolith (Strangler Fig).

  2. A CI/CD pipeline builds a new Docker image.

  3. IaC ensures the underlying cloud infrastructure and Kubernetes manifests are up to date.

  4. Kubernetes deploys the new image safely using a Canary or Blue-Green strategy to ensure users experience zero downtime.