Skip to main content

Rolling Updates

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 rolling updates for zero-downtime deployment. Rolling updates replace the old instances of a microservices with the new one instance by instance. Therefore, it creates an instance of the new microservice version while still running the old one. Once the newly deployed instance is available, the traffic is switched to the new version of the microservice.

Cluster managers, cloud platforms, or serverless platforms might offer capabilities for rolling updates. By utilizing containers as microservice deployment artifacts, update times can be significatly reduced compared to a monolith LN48.

As an alternative, consider blue-green deployments and canary releases.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L5:

  • Rolling upgrades as keyword for deployment operations
    • Platform and container orchestration tools provide various features that make deployment and operations trivial activities

L9:

  • Rolling updates to facilitate zero-downtime deployments
    • Container and microservice style DevOps
    • Goal: Replace existing VM/container with new instance, minimize interruption of provided service
    • Procedure
      • Step 1: Pull and start new container image (v2)
      • Step 2: Change active version in CSM (Configuration State Manager)
      • Step 3: Update configuration file in proxy
      • Step 4: Redirect traffic to new container
      • [Notes from picture] both container versions exist in parallel for a short amount of time; resembles interplay of service discovery mechanism + routing
    • (+) Image-based DevOps simplifies rolling upgrade
      • Containers faster than VMs, but also works with VMs

L24:

  • Key challenges of deploying microservices applications: service discovery, load balancing, rolling upgrades
  • Automated support by container orchestration for rolling upgrades

L30:

  • Sophisticated virtualization (containers) + infrastructure technology as Docker + K8s
    • rolling updates, automated scaling, rebalancing in case of node failure
    • deployments much more volatile and dynamic => challenges for monitoring and performance modeling

L31:

  • MP14
    • made redeployment really easy
    • provides capabilities like rolling updates
      • = gradually replace service's instances
    • also rolling back

L34:

  • rolling upgrades as keyword for Deployment operations as main category for research challenges

L41:

  • Docker Swarm automation for rolling updates

LN48:

  • Context: service update
  • virtualization (VM or container) helps to reduce effort for rolling updates
  • ensure for every update previous version is up and running
    • => in case of failure: roll back to previous state
  • rolling updates
    • allow microservices to continuously be integrated whenever there is update for any microservice
    • used automated system to deploy update for "login" service in both microservice and in monolithic applicaiton
      • monolith: 400 sec with compile and redeployment
      • microservices: 160 sec
      • => reduce down time of application and continuosuly deliver updates with minimum efforts
  • Context: while rolling updates
  • whenever modification A' to microservice A => deployment server compiles, tests, and creates cotainer image
  • image is pushed to container repository with new tag; command to production server to deploy A'
  • failure during compilation: deployment server stops the updated container and system is restored to previous state
  • when A' container is up and running, deploymet server will change configuration in config storage to IP of newly created container
  • Now all requests to A' container; dpleoyment server stops A container and removes from production server
  • => minimum downtime

LM48:

  • Context: microservice migration describes an examples project (FX Core) and compares back to monolith
  • Docker Swarm handles different functionality
    • among others: rolling updates via CLI
  • Active/active failover mode (parallel active replicas) can be used for rolling updates
    • update one at a time