Skip to main content

Blue-Green Deployments

Context​

Microservices are being adopted. Multiple microservice instances are being deployed. There is a service discovery mechanism in place.

Problem​

  • Deploying the frequent releases for bug fixes and features of microservices leads to repeating short downtimes

Solution​

Facilitate blue-green deployments for zero-downtime. Despite rolling updates, a blue-green deployment replaces all instances of a microservice at once with the new version. It starts the new version instances side-by-side with the old ones. After the newly created instances were started and configured, all the traffic is directed to the new version instances. Already running requests can be completed in the old version instances.

Cluster managers, cloud platforms, or serverless platforms might offer capabilities for blue-green deployments.

As an alternative, consider rolling updates and canary releases.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L9:

  • Image-based deployment
    • aspire to capabilities as deployment and tracking of different releases simultaneously in different environments, A/B testing and fast rollback

L16:

  • pattern blue green deployment => multiple versions of a service
    • goal: replace application by new version in place, avoid downtime
    • old and new versions run in parallel
      • beginning: all requests to old version, new version started and configured
      • then: router (e.g. load balancer) triggered to route to new version
      • => zero downtime
    • rollback: just route to old version!
  • not yet used in IoT => in combination with containers promising technique

L21:

  • old and new version of microservice can side by side
    • old take care of completing old requests
    • new take care of new requests
    • old can be removed when its job is ended

L58:

  • Context: synapse message broker
  • Mechanism for service version migration
  • just switch load balancer to new application and migration completed with little downtime
  • also for schema migration
    • e.g. after heavy refactoring
    • not update deployed service
    • but deploy new version as different service with own DB to ensure everything was running as expected
    • some period of time: run simultaneously
      • QA of new version
      • possibility to rollback
    • => no downtime procedures