EN
RU
ES
ZH
FR
DE
PT
AR
HI
Canary Deployments with Java: How to Release New Versions Without Risk to Production
\n\nImagine: you are the captain of a submarine. You need to test a new sonar, but you can't just turn it on at full power — what if it blinds the entire crew or, worse, triggers a false alarm? What do you do? You release a canary (the bird that, in the old days, warned miners about gas leaks). If the bird is alive — the system is fine.
\n\nIn the world of Java development, this principle is called canary deployments. It's a strategy where a new version of an application is first sent to a small percentage of users (usually 1–5%). If everything is fine — traffic is gradually increased. If not — we roll back without a catastrophe.
\n\nIn this article, we'll break down how to implement canary deployments in Java with real examples: from simple configurations to advanced techniques with Kubernetes and Spring Cloud. Let's go!
\n\nWhy Canary, and Not Blue-Green or Rolling Update?
\n\nLet's quickly compare three popular deployment strategies:
\n\n- \n
- Blue-Green: You have two identical environments (blue and green). You switch all traffic at once. Fast, but if a bug appears — everyone suffers. \n
- Rolling update: You update pods/servers one by one. Slower, but also mass-scale. \n
- Canary: You send the new version to only 2% of users. If they don't complain — you expand to 10%, then to 50%, then to 100%. \n
Canary is the only strategy that allows you to A/B test a new version on real users without risk to everyone. This is especially critical for Java microservices, where one error can cause a cascading failure.
\n\nHow Does It Work in Java? Technical Architecture
\n\nLet's imagine a typical Java system: a Spring Boot application serving a REST API. To implement canary, we need:
\n\n- \n
- Traffic routing: Direct part of the requests to the new version (v2), the rest to the old one (v1). \n
- Metrics and monitoring: Collect errors, latency, request count. \n
- Automatic rollback: If the error rate exceeds a threshold — roll back the canary. \n
- Gradual increase: If everything is ok — increase the canary weight. \n
The simplest way to do this is to use Kubernetes with a Service Mesh (e.g., Istio) or Spring Cloud Gateway with routing weights. Below are examples for both approaches.
\n\nExample 1: Canary with Spring Cloud Gateway (Without Kubernetes)
\n\nIf you don't have Kubernetes but do have Spring Cloud, you can use Spring Cloud Gateway with weight configuration. Here's what it looks like:
\n\n// application.yml\nspring:\n cloud:\n gateway:\n routes:\n - id: my-app-canary\n uri: http://my-app-v2:8080\n predicates:\n - Weight=my-app, 10 # 10% traffic\n filters:\n - SetPath=/api/v2/**\n - id: my-app-stable\n uri: http://my-app-v1:8080\n predicates:\n - Weight=my-app, 90 # 90% traffic\n filters:\n - SetPath=/api/v1/**\nHere we use the Weight predicate — a built-in feature of Spring Cloud Gateway. It randomly distributes requests in a 10/90 ratio. If v2 runs stably, we change the weight to 50/50, then to 100/0.
Pros: simple, no external tools required.
\nCons: no automation — weights are changed manually or via API.
Example 2: Canary with Kubernetes and Istio (Advanced)
\n\nThis is the gold standard for Java microservices. We use Istio VirtualService
Blogs
Book Recommendations
Read also
