Phase 5: DevOps & Deployment

Blue-green, canary & rolling deployment strategies

Intermediate ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you run a super popular pizza shop, and your delicious pizzas are flying out the door! You want to make your shop even better – maybe get new, super-fast ovens, or a new way to take orders. The challenge is how to update without ever closing, because customers want their pizza right now! That's what "deployment strategies" are all about: smart ways to update your online apps and games. One common way is like replacing your ovens one by one. Let's say you have five pizza ovens. You swap out just one old oven for a new, shiny one. While that's happening, the other four ovens are still baking pizzas. Once the new oven works perfectly, you move on. Your shop stays open, and most customers barely notice! But, if your new oven accidentally burns all the pizzas, that problem could slowly spread. Then you’d have to swap them back, which takes time. This is often called "rolling deployment."

For super important apps, where even a tiny burnt pizza could be a disaster, you might use "blue-green deployment." Imagine you build an entire second, identical pizza shop right next door! Your current, busy shop is "Blue," and the brand-new one is "Green." You set up all your new ovens and kitchen gear in "Green" and test everything inside, away from customers. Only when you're 100% sure "Green" is perfect, you simply open its doors and instantly tell all customers to go there instead. "Blue" is still there, just empty. If a customer finds a problem in "Green," you can instantly tell everyone to go back to "Blue" while you fix "Green."

Sometimes, you're not sure if customers will love a new idea, like a really unusual pizza topping. That's where "canary deployment" comes in. Instead of replacing all ovens at once or opening a whole new shop, you might only offer the new topping at one or two of your ovens, or perhaps only to a small group of your loyal customers – your "canaries." You watch very closely. If your canaries love the new topping, you slowly offer it to more ovens and more customers. If they don't like it, you can stop offering it right away. So, when you build your own amazing apps and games one day, you'll choose the best way to update them. These strategies ensure your users always have a great experience, with minimal interruptions!

In CI/CD, how you deploy new versions of your backend application significantly impacts reliability and user experience. Rolling deployment is the most common and often default strategy. When you deploy a new version, old instances of your application are gradually replaced by new ones. For example, if you have 5 instances running v1, the orchestrator (like Kubernetes) will replace them one by one or in small batches with v2. This ensures your application remains available throughout the update, but if v2 has a critical bug, it could gradually spread to all instances, requiring a rollback, which itself can be a complex and time-consuming process.

For higher-stakes applications demanding near-zero downtime and quick recovery, Blue-Green deployment is powerful. You maintain two identical, full production environments: "Blue" (the current live version, e.g., v1) and "Green" (the new version, e.g., v2). Once the Green environment is fully deployed and tested internally, all incoming user traffic is instantly switched from Blue to Green. This provides an immediate, atomic switch. If v2 proves problematic after going live, you can instantly switch traffic back to the stable Blue environment (v1) with minimal impact. The trade-off is higher infrastructure cost, as you temporarily run two full environments.

When you want to test a new feature or version with a small subset of real users before a full rollout, Canary deployment is your choice. With Canary, you deploy the new version (v2) alongside the old (v1), but only a small percentage of user traffic (e.g., 5-10%) is routed to v2. You then closely monitor performance, error rates, and user feedback for this "canary" group. If v2 performs well, you gradually increase the traffic percentage directed to it until v1 is fully phased out. This strategy significantly reduces the blast radius of potential bugs, allowing you to catch issues early with minimal user impact. However, it requires more sophisticated traffic routing and robust monitoring capabilities.

Key Takeaways

  • Rolling updates replace instances gradually; simple but risks spreading bugs.
  • Blue-Green switches traffic between two full environments; offers instant rollback and zero downtime but costs more.
  • Canary deploys to a small user subset first; minimizes risk and gets real-world feedback but needs advanced traffic management.
  • Choose a strategy based on your application's downtime tolerance, risk appetite, and infrastructure resources.

Code Example

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-backend-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-backend-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 # Max 1 pod unavailable during update
      maxSurge: 1       # Max 1 extra pod created during update
  template:
    metadata:
      labels:
        app: my-backend-app
    spec:
      containers:
      - name: backend-container
        image: myrepo/backend-app:v1.0.0 # Update to :v1.0.1 for new version
        ports:
        - containerPort: 8080

How this code works

This configuration defines a Kubernetes Deployment for a backend application, ensuring it runs reliably and can be updated smoothly without downtime. It instructs Kubernetes to maintain three replicas of the application, labeled my-backend-app. The key part is strategy.type: RollingUpdate, which dictates how the application transitions to new versions. Instead of shutting down the entire application to apply an update, new versions are introduced gradually, replacing old instances one by one, preserving service availability throughout the process.

Within the rollingUpdate section, maxUnavailable: 1 means only one application instance can be unavailable at any moment during the update process. Simultaneously, maxSurge: 1 allows Kubernetes to create one extra Pod beyond the desired three replicas while the update is ongoing. This combination ensures that the application never drops below two running pods (three desired, minus one unavailable), and often runs with three or four during the transition, minimizing disruption. A subtle but crucial detail is how selector and template.metadata.labels must explicitly match; this linkage tells the Deployment which Pods it manages, enabling it to correctly identify and update instances when the image tag (e.g., from v1.0.0 to v1.0.1) changes.

Resources

Related Articles

Hand-picked reads to go deeper on ci/cd pipelines.

Back to Backend Developer Roadmap