Nattrio's Garden

deployment-strategies

4 min read

Deployment Strategies

Back to Infrastructure Index

Core Philosophy

The whole point of microservices is to enable teams to develop, deploy and scale independently

Deployment Fundamentals

Artifacts

  • Result of things you build
  • Can depend on different platform you use
  • Can be many formats: Container image, Binary, Jar, etc.

Environment

We can deploy to different environments, each environment serves different purpose:

  • Development - For active development
  • Staging - Pre-production testing
  • Production - Live environment for end users
  • QA/Testing - Quality assurance environment

Configuration

  • Services need configuration, e.g., Database username and password
  • Ideally small amount of configuration
  • Different environments also need different config
  • Start from small config file, maybe different for each environment

Deployment Risks ⚠️

Deployment can take your prod down

Key Risk Factors

  1. Capacity - Not enough resources to handle load
  2. Bad version, Bugs - Code issues in new version
  3. Statefulness - Data consistency during deployment
  4. Redundancy - Lack of backup systems

Deployment Strategy Patterns

In the end we can use multiple deployment strategies for your needs

1. In-Place vs Replace

In-Place Deployment

Replace old version in the same server

Pros:

  • Fast deployment
  • Simple process

Cons:

  • Downtime during deployment
  • Higher risk

Replace Deployment

Spin up new server with new version

Pros:

  • Use load balancer for zero downtime
  • Less risk - easy rollback
  • Clean separation

Cons:

  • Expensive in case of non-cloud infrastructure
  • More complex setup

2. All at Once vs Rolling

All at Once

Deploy to all servers simultaneously

Pros:

  • Fastest deployment
  • Simple coordination

Cons:

  • Higher risk
  • Full outage if something goes wrong

Rolling Deployment

Deploy gradually to servers in batches

Characteristics:

  • Slower deployment speed
  • Must consider capacity
  • x% or x servers at a time
  • Example: 10 servers → (3 - 3 - 3 - 1)

Pros:

  • Reduced risk
  • Can pause/rollback mid-deployment
  • Maintains partial capacity

Cons:

  • Longer deployment time
  • Mixed versions running temporarily

3. Blue-Green Deployment

Having 2 identical environments, load balancer distributes traffic to appropriate environment

┌─────────────┐
│Load Balancer│
└──────┬──────┘
       │
   ┌───┴───┐
   │       │
┌──▼──┐ ┌──▼──┐
│Blue │ │Green│
│(Old)│ │(New)│
└─────┘ └─────┘

Process:

  1. Blue environment serves production traffic
  2. Deploy new version to Green environment
  3. Test Green environment
  4. Switch traffic to Green
  5. Keep Blue as backup

Pros:

  • Instant rollback
  • Zero downtime
  • Full testing before switch

Cons:

  • Requires double infrastructure
  • Cost intensive

4. Canary Deployment

Deploy to small set of users for some period of time

┌─────────────┐
│Load Balancer│
└──────┬──────┘
       │
   ┌───┴────────┐
   │            │
┌──▼──┐      ┌──▼──┐
│Old  │      │Canary│
│(95%)│      │(5%) │
└─────┘      └─────┘

Process:

  1. Deploy to small percentage (5-10%)
  2. Monitor metrics and errors
  3. Gradually increase traffic
  4. Full rollout if successful

Pros:

  • Early detection of issues
  • Minimal user impact
  • Data-driven decisions

Cons:

  • Complex monitoring required
  • Longer deployment time
  • Mixed versions for extended period

Deployment vs Release 🔄

Key Concept: We can decouple deployment from release

Definitions

  • Deployment - Installing new version of software on production infrastructure
  • Release - Serving production traffic to new piece of code

Benefits of Decoupling

  1. Safety - Deploy without immediately exposing to users
  2. Testing - Test in production environment safely
  3. Feature flags - Control feature rollout independently
  4. Gradual rollout - Progressive exposure to users

Implementation Techniques

  • Feature Flags/Toggles
  • Dark Launches - Deploy but don’t activate
  • A/B Testing - Release to specific user segments
  • Ring Deployment - Progressive rings of users

CI/CD Pipeline

Continuous Integration (CI)

Goal: Keep everyone in sync with each other

Key Practices:

  • Frequent code commits
  • Automated builds
  • Automated testing
  • Fast feedback loop

Continuous Deployment (CD)

Goal: Get changes to customers and feedback loop from production readiness

Key Practices:

  • Automated deployments
  • Infrastructure as Code
  • Monitoring and alerting
  • Rollback procedures

CI/CD Flow

Code → Build → Test → Deploy → Monitor
  ↑                              |
  └──────────Feedback────────────┘

Deployment Checklist ✅

Before deploying:

  • Automated tests pass
  • Code review completed
  • Rollback plan ready
  • Monitoring configured
  • Team notified
  • Database migrations tested
  • Configuration validated
  • Capacity checked

During deployment:

  • Monitor error rates
  • Check application metrics
  • Verify functionality
  • Watch user feedback

After deployment:

  • Confirm success metrics
  • Document any issues
  • Update runbooks
  • Team retrospective

Best Practices

  1. Automate Everything - Reduce human error
  2. Test in Production-like Environments - Catch issues early
  3. Monitor Actively - Know your system’s health
  4. Plan for Rollback - Always have an escape route
  5. Deploy Frequently - Smaller changes = lower risk
  6. Use Feature Flags - Control releases independently
  7. Practice Deployments - Make it routine
  8. Document Procedures - Share knowledge

Related:

Graph View

Backlinks