Comparison
Progressive deliveryvsTraffic splitting
Progressive delivery
the release goes to one percent, then five, then twenty-five, and each step is only taken if the metrics stayed flat.
Releasing to progressively larger portions of traffic with automated analysis deciding whether to continue, pause or revert. It is canarying with the judgement automated and formalised into steps. It requires two things most teams lack before they start: routing that can split traffic by percentage, and a metric trustworthy enough to abort a release on.
Full entry →Traffic splitting
five percent of requests go to the new version and the rest to the old, decided by the proxy rather than by your code.
Sending a configured proportion of requests to different backend versions, at the routing layer. It is the infrastructure primitive that progressive delivery is built from, and moving it out of the application means the split applies to every language and every service uniformly. Weighted routing is per request, so sticky behaviour has to be added deliberately if a user must not flip between versions mid-session.
Full entry →