In AWS - difference between Immutable and Blue/Green deployments?

user_11919198 0
Viewed 3016

Per AWS documentation, I get the impression that Immutable and Blue/Green are the same thing, just a different name. In both cases you are creating an entirely new set of servers and transitioning to those servers at the final step of deployment.

Perhaps there are some fine details that differentiate these two. But if so fine, what is the point of making them distinct when they are practically the same thing?

Per AWS docs: (source: https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/immutable-and-bluegreen-deployment.html)

The immutable pattern specifies a deployment of application code by starting an entirely new set of servers with a new configuration or version of application code. This pattern leverages the cloud capability that new server resources are created with simple API calls.

The blue/green deployment strategy is a type of immutable deployment which also requires creation of another environment. Once the new environment is up and passed all tests, traffic is shifted to this new deployment. Crucially the old environment, that is, the “blue” environment, is kept idle in case a rollback is needed.

The "crucially" sentence makes it sound like that is the differentiating factor but in immutable deployments you can keep the old instances in their target group idle post deployment too, if you wanted.

aws-code-deploy amazon-elastic-beanstalk amazon-web-services
4 Answers

they are executed differently:

immutable: in the same environment (so under the same load balancer) a new autoscaling group is created alongside the old one. As soon as the first new instance is created it starts to serve traffic. When the new instances are all healthy the old ones are switched off.

blue/green: a new environment is created from scratch (so another load balancer). The switch is performed at DNS level routing the traffic from the OLD to the NEW when the new environment is ready and healthy.

The main difference is that in the immutable update, the new instances serve traffic alongside the old ones, while in the blue/green this doesn't happen (you have an instant complete switch from old to new).

So, in certain cases, for example:

  • if your application depends on some configuration that has to change from the old version to the new one
  • the new version cannot run at the same time as the old one because of application constraints
  • "you want to update an environment to an incompatible platform version" (taken from the AWS doc)

you have to use the Blue-Green Deployment strategy.

user_11924480

To add to the above answer:

Immutable vs Rolling

Immutable deployment is actually considered to be an alternative to Rolling Deployment. The main differences are as follows:

Rolling Immutable
New new ASG is created Second ASG is created and it serves traffic
alongside first ASG until deployment is done
Deployment takes place on batches of existing instances Only one but a brand new instance is created first
If passes health check, additional instances are created
until the number of instances matches with the first ASG
Failure requires manual redeploy of old version Rollback is achieved by terminating the second ASG
How Rolling Deployments work? How Immutable Deployments work?

Immutable/Rolling vs Blue-Green

A blue-green deployment is quite different from both the above deployments.

  • In this deployment, a new environment will be created and labeled as Green (the already existing environment is considered as Blue).
  • When the Green environment meets the requirements (health checks/capacity) then a CNAME swap will be performed to switch the traffic to the Green environment from the Blue environment.
  • If the new code is not compatible with the old code (no backward compatibility or interface breaking change), the Blue-Green deployment is the only option

In all these deployments, there is a zero-downtime, and the impact of failure will be minimal.

Canary Deployments

  • Traffic-splitting deployment allows you to perform canary testing. From what I understood, a traffic-splitting deployment is the closest to Immutable deployment.
  • From what I see in the documentation, canary testing can be performed using Blue/Green deployment as well.

Summary of differences from AWS documentation

user_24423960

Immutable deployment for EC2 is only available for Elastic Beanstalk whereas Blue/Green deployment is for lambda/ec2 as well.

user_133114770

IMPORTANT: The Immutable deployment type is present for AWS Elastic Beanstalk and not for EC2 instances directly.

  • Blue/Green deployment is used to update the app with minimum interruptions. The behavior of the deployment depends on which computer platform you use:

    • ECS Service: Traffic is shifted from ECS Tsk set to replacement tasks set within the same ECS Service
    • Lambda: Traffic is shifted from one version of a Lambda to another version of the same function

  • Immutable deployments perform an immutable update to launch a full set of new instances running the new version of the application in a separate Auto Scaling group, alongside the instances running the old version

user_25909600
Related