What's the difference between Red/Black deployment and Blue/Green Deployment?

I've heard both used to describe the idea of deploying an update on new machines while keeping old machines active, ready to rollback if an issue occurs. I've also heard it used to describe sharing load between updated services and old service, again for the purpose of a rollbacks —sometimes terminating inactive older patches and sometimes not.

My understanding also is that it is strictly for cloud services.

Can someone help to demystify these terms?

Blue-green deployment

Classic deployment technique described in the Continuous Delivery book by Jez Humble and David Farley:

> The idea is to have two identical versions of your production environment, which we’ll call blue and green... Users of the system are routed to the green environment, which is the currently designated production. We want to release a new version of the application. So we deploy it to the blue environment... This does not in any way affect the operation of the green environment. We can run smoke tests against the blue environment to check it is working properly. When we’re ready, moving to the new version is as simple as changing the router configuration to point to the blue environment instead of the green environment. The blue environment thus becomes production. This switchover can typically be performed in much less than a second. If something goes wrong, we simply switch the router back to the green environment.'

Humble and Farley then go on to mention the main challenge: dealing with database schema changes between green and blue versions.

The main benefit of blue-green deployment is zero or near-zero downtime when releasing a new version. And blue-green deployment enables canary releasing.

Red-black deployment

The Red version is live in production. You deploy the Black version to one or more servers. When the Black version is fully operational, you switch the router to direct all traffic to it (or you scale Red to 0 instances and Black to N). If anything goes wrong, you revert the operation. So, it's similar to blue-green deployment, but there's a slight difference: in blue-green deployment, both versions may be getting requests at the same time temporarily, while in red-black only one of the versions is getting traffic at any point in time. Here's some corroboration:

> At any time, only one of the environments is live, with the live environment serving all production traffic. For this example, Red is currently live and Black is idle (in this case we have kept the Black down-scaled to zero servers)...

Therefore, red-black is a specialization of blue-green. But red-black deployment is a newer term being used by Netflix, Istio, and other frameworks/platforms that support container orchestration. The actual meaning can vary and many people are using "red-black" as another term for "blue-green", maybe just because their team colors are red and black. :^)

Both blue/green and red/black deployment represent the same concept.

While the first is the most common term, the latter seems to be used mainly in Netflix and their tools (like Spinnaker).

They apply only to cloud, virtualized or containerized services in the sense your infrastructure has to be automatable in order to make sense of this approach.