Skip to main content

Canary Releases

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 canary releases for zero-downtime deployment. A canary release mechanism complements the blue-green deployment mechanism with a more sophisticated routing switch mechanism. Instead of rerouting all traffic to the new instances at once, the routing is changed gradually. At first, only a very minor part of the traffic reaches the new version instances limiting the impact of faulty service versions. If issues arise, the canary release can be aborted by routing the traffic back to the old instances.

Cluster managers, cloud platforms, or serverless platforms might offer capabilities for canary releases.

As an alternative, consider rolling updates and blue-green deployments.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L8:

  • canary release as one of the execution environments next to testing and staging

L16:

  • slightly modified version of blue-green deployment
    • instead of routing any traffic immediately to new service
    • iteratively raise fraction of traffic that is routed to the new services
  • (+) keep impact of faulty new service smaller => not everyone is immediately affected by new version
  • not yet used in IoT => in combination with containers promising technique

L30:

  • extensive system testing not feasible => need for compensation by fine-grained monitoring techniques in prod env
  • deploy to production and monitor failures => quick releases to fix
  • canary deployment as example
  • essential to foster loose coupling between microservices

L35:

  • canaries = copies of a microservice dedicated to handle test request
  • to cope with state cleanup issue in Gremlin