Blue-Green Deployment

Two identical environments in parallel, one traffic router that switches from one to the other — the zero-downtime infrastructure deployment pattern, complementary to application feature flags.

Problem

Deploying a new version of an AS2 gateway or a central EDIFACT parser usually requires: stop the process, upgrade binaries, restart, smoke test. During this cycle (5-30 min) the service is down — partners get AS2 timeouts, MDNs do not return, retries pile up. Worse: if the new version has a blocking bug, rollback demands redeploying the old version, another 10-30 min. For a tier-1 EDI hub with SLA < 5 min downtime, this mode is unacceptable.

Forces

• Downtime must be minimal: ideally on the order of a second, by routing switch.
• Rollback must be instant: revert must not require redeployment.
• Double infrastructure has a cost: maintaining two complete environments doubles resources during the switch window.
• Shared state must be managed: DB, message broker, file storage — typically shared between blue and green, thus compatible with both versions.
• Active sessions must be drained: in-flight asynchronous MDNs must reach the right version.

Solution

Provision two complete environments: blue (currently active, version v1.0) and green (newly deployed, version v2.0). Both share stateful resources (DB, Kafka, S3) but are otherwise isolated. The routing layer (DNS, load balancer, service mesh) points to blue. When green is ready: synthetic tests on green with no real traffic, then router switch to green in an atomic operation. If OK, blue becomes idle (and will be updated for the next switch). If KO, instant return to blue. Draining active sessions generally requires a short window (30-60s) of connection draining.

Two parallel environments, one traffic router:

   ┌──────────────────┐
   │ AS2 partner      │
   │ sends INVOIC     │
   └─────────┬────────┘
             │
             ▼
   ┌──────────────────────┐
   │ Load Balancer / DNS  │  ← atomic switch
   │ points at: BLUE      │
   └────────┬─────────────┘
            │
   ┌────────┴────────┐
   ▼                 ▼
┌──────┐         ┌──────┐
│ BLUE │         │ GREEN│
│ v1.0 │         │ v2.0 │
│ (active)       │ (idle, but up)
└──────┘         └──────┘
   │                 │
   ▼                 ▼
shared DB, shared Kafka config, shared partner master

Before switch: tests on GREEN with synthetic traffic.
Switch: LB points at GREEN → real traffic arrives in 1s.
Rollback: LB points at BLUE → traffic returns in 1s.
After stabilisation: BLUE becomes the new "GREEN" for the next rollout.

EDI implementation

Concrete case: upgrade of IBM Sterling B2B Integrator v6.2 to v6.3, which modifies the underlying AS2 lib. Without Blue-Green: 1h maintenance window, partner communication 1 week in advance, high residual risk. With Blue-Green: two Sterling clusters operate in parallel, sharing the Oracle DB and SAN storage. The F5 BIG-IP load balancer routes AS2/HTTPS traffic to the blue cluster (v6.2). Green (v6.3) is deployed, Trading Partners are configured identically, synthetic messages are injected on green to validate parsing, MDN, archive. Then LB switch: set rule /Common/edi_router { ... pool green_pool ... }. Traffic switches in 1-2s, in-flight sessions drain in 30s. Intense monitoring for 24h, then blue is upgraded to v6.3 and becomes the new idle green. Tools: AWS Elastic Beanstalk native Blue-Green, Azure DevOps deployment slots, GitLab CI Blue-Green script, HashiCorp Nomad/Consul, Kubernetes via two Services pointing at two Deployments + Service switch.

Anti-patterns

• Incompatible DB schema: if green requires a schema migration incompatible with blue, the instant-rollback is lost. Solution: migrations always backward-compatible (only additions, no drops).
• Per-environment local state: blue and green must share state, otherwise in-flight MDN/receipts on blue are lost at switch.
• No synthetic tests on green: switching real traffic to an unchecked green = Russian roulette.
• No session draining: brutal switch cuts in-flight AS2 connections, generates mass retries.
• Permanent double spend: leaving both blue and green active (rather than one idle) doubles cost without benefit.

Related patterns

• Canary Release — progressive variant, where Blue-Green is all-or-nothing.
• Feature Flag — application pattern complementary to Blue-Green infrastructure.
• Dark Launch — variant where green receives duplicated traffic without user-facing return.
• Circuit Breaker — independent runtime protection.

Sources

• Fowler M. — BlueGreenDeployment (martinfowler.com, 2010). The canonical definition of the pattern. martinfowler.com — BlueGreenDeployment
• Humble J., Farley D. — Continuous Delivery, Addison-Wesley 2010. Chapter 10 §3 — zero-downtime release techniques, including blue-green.
• Nygard M. — Release It! Design and Deploy Production-Ready Software, Pragmatic Bookshelf, 2nd ed. 2018. Discussion of resilient release strategies.
• AWS Architecture Center — Blue/Green Deployments on AWS. Documentation and cloud implementation patterns. docs.aws.amazon.com — Blue/Green Deployments
• Beda K., Burns B., Hightower K. — Kubernetes Up & Running, O'Reilly 2022 (3rd ed.). Chapter on Services and their blue-green usage.
• Google Cloud Architecture Center — Blue/green deployment patterns on Google Cloud. cloud.google.com — deployment-strategies