Difference between rolling, rolling with additional batch and immutable deployments in AWS?
I think this will help a little bit.
Immutable – starts by deploying your application code to a single newly created EC2 instance. Once the deployment succeeds on the first instance, the remaining number of instances required to create a parallel fleet are created and the application code is deployed to them. After the deployment succeeds on the entire parallel fleet, instances running the old application version are terminated 25% at a time. This deployment policy ensures that the impact of a failed deployment is minimal (i.e.: a single EC2 instance) and enables your application to serve traffic at full capacity during an ongoing deployment.
Rolling with additional batch – starts by deploying your application code to a single batch of newly created EC2 instances. Once the deployment succeeds on the first batch of instances, the application code is deployed to the remaining instances in batches until the last batch of instances remain. At this point the last batch of instances is terminated. This deployment policy ensures that the impact of a failed deployment is limited to a single batch of instances and enables your application to serve traffic at full capacity during an ongoing deployment.
Rolling – starts by deploying your application code to a single batch of existing EC2 instances. Once the deployment succeeds on the first batch, the application code is deployed to the remaining instances, in batches. This deployment policy ensures that the impact of a failed deployment is limited to a single batch. However, since no new instances are created during the deployment, you application can serve traffic at a reduced capacity (i.e.: a single batch of instances are out of service at any given time during the deployment).
I found this post easier to understand than the accepted answer, so here's my take on it.
Ordered by high-to-low risk, and calling the deployed versions v1
to v2
:
- All at once: Replace all
v1
withv2
at the same time. Failure not handled. - Canary: A
v2
is deployed and observed. If successful, all remainingv2
instances are deployed immediately. - Rolling: Replace
v1
instances withv2
instances one at a time. Watch for failures. - Rolling with batch: Create some new
v2
instances. If successful, roll out onv1
instances. When all arev2
instances, scale back to original size. - Immutable: Don't change
v1
instances. Create same number ofv2
instances. Wait for success, then stopv1
instances. - Blue/green: Instead of operating on an environment in-place, create a new environment (network, etc.) fully provisioned with
v2
, and switch over when ready.