Difference between rolling, rolling with additional batch and immutable deployments in AWS?

Question

I am using elastic beanstalk to handle my deployments. I read the explanation for these deployment options but it was not quite clear. Could someone explain it in more simpler

Answer 1

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 with v2 at the same time. Failure not handled.
• Canary: A v2 is deployed and observed. If successful, all remaining v2 instances are deployed immediately.
• Rolling: Replace v1 instances with v2 instances one at a time. Watch for failures.
• Rolling with batch: Create some new v2 instances. If successful, roll out on v1 instances. When all are v2 instances, scale back to original size.
• Immutable: Don't change v1 instances. Create same number of v2 instances. Wait for success, then stop v1 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.

Answer 2

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).