AWS Immutable Updates for New Application Version

Question

Trying to use immutable deployment strategy for deploying new application version on AWS Elastic Beanstalk. Is there anyway to determine how AWS handles traffic from the old to new instances? Since it looks like there are 2 sets ( old + new ) of instance running behind the load balancer at a given point.

Can this be seen as a variant of Blue-Green Deployment? Since we hit the same Load Balancer and simply change the App-Version running on these instances?

I dont see obvious explanations in the AWS Documentation.

Answer 1

How does an immutable update work?

What happens with an immutable update, is that Elastic Beanstalk will create a new AutoScaling group with exactly the same parameters as the active AutoScaling group. It'll boot 1 instance into this group, checking that it becomes healthy. This instance will hook up to the load balancer, and starts serving traffic along the already active instances. EB will then proceed booting instances until the required amount of instances is present in the AutoScaling group, matching the number in the original AutoScaling group. If all new instances are booted and healthy, EB will move them over to the original AutoScaling group, and clean up the newly created AutoScaling group, as well as the old instances, with connection draining. So, yes, temporarily, you will have the double amount of instances running.

What are the reasons to use immutable updates, as opposed to rolling updates?

• You do not risk a partial deployment, as you risk in a rolling update. It is possible that not all of your batches will have run in an update, causing your environment to be partially upgraded. Very important item to realise here is that rolling updates work in the same autoscaling group, immutable updates create a new autoscaling group.
• When a rolling update fails, it has to update the autoscaling group again, to do a rollback of the update. Rolling back an immutable update is as easy as killing of the new autoscaling group - and done.
• Considering you are doing a rollback of the autoscaling group, it may also happen (based on your parameters) that you have to reboot a certain number of machines with the old application version. It means somewhat a disruption of your Elastic Beanstalk environment.
• Your instances are always replaced. While this may seem trivial, it does hand you a fresh instance on each deploy, as opposed to stay running on the same instance "forever".

The true value of an immutable update lies in the combination of all of these characteristics: each deploy happens at once, "in full", on fresh new instances. Rolling back does not disrupt your running instances.

What is the relation with green/blue deployments? Is it not the same?

Green/Blue is in fact booting a full new environment, doing all sort of checks, and then flipping over the URL's of the load balancers. From an infrastructural point of view, immutable deploys do resemble green/blue deployments a lot. However, if you do all sort of functional checks of your environment (smoke tests, sanity checks, ...) that are not of an infrastructural nature, it differs a lot, since this process is automated. EB only performs health checks when doing this update.

So ... why not always use this form of deployment?

Well, immutable deployments cannot handle resource configuration updates (ie: load balancer settings) and application version updates at the same time. If you want to perform both, you either have to split them up in 2 consecutive updates, or use a green/blue deployment.

Some other random musings that come to mind:

• given that you have a limit of X instances in your account, and you are already using X - 2 instances. Your environment is 5 instances. You cannot perform the immutable update, since it will not fit within your limits.

• if your environment is 50 instances big (I'm just stating a random huge number here). It'll take a lot of time (= money) and resources to boot an entire AutoScaling group of 50 instances alongside your original AutoScaling group to do an update.