Deploying a new application or updating an existing one isn’t always as simple as one might think. Sure, you can set up some fancy CI/CD pipeline to achieve the deployment but that’s not all there is to it. What if while your pipeline is running and instances are being updated on the cloud, your users face downtime? Or if you have a new version of your app and you just want some of your users to experience the new features you rolled out without removing your old version, how do you do that?

I have been using the AWS Elastic BeanStalk service for quite a while now and luckily this service provides great deployment modes to handle the above scenarios and more. Let’s dive into more details of what these modes are and how I have used one for a real world project.

Here’s a list of all the deployment modes:

• All at once (deploy all instances in one go)
• Rolling
• Rolling with Additional Batches
• Immutable
• Traffic Splitting

All at once:

As the name explains, this mode of deployment destroys all your old instances with new ones. Although the deployments are fast, if you have a lot of users surfing your app, this might not be the ideal deployment mode for you since your app will face downtime.

This mode is preferable for development purposes since your only concern is to get the new version out for testing as soon as possible. Doesn’t incur any additional costs.

Scenario: A small e-commerce website wants to release a minor update that fixes backend bugs without introducing new features.

Example:

• Pros: The deployment process is simple and fast.
• Cons: All users experience downtime during the update.

Rolling:

In this mode, the application is running below capacity. A bucket size is specified which represents the number of instances to be replaced at a time. Consider, the max capacity is 4 instances at a time and the bucket size is specified to be 2. Elastic Beanstalk will only update 2 instances at a time out of the 4 and once these two instances are up and running, it will move on to the next two.

The rolling update runs both versions simultaneously until all instances are updated with the newer versions. No downtime, unless the app is being utilized more than its capacity. No additional cost but the deployment times are much longer. Preferable for production use cases.

Scenario: A social media platform wants to introduce a new feature, like a new way to comment on posts, without causing complete service interruptions.

Example:

• Pros: Partially maintains service availability and reduces the risk compared to the "All at Once" method.
• Cons: Some users might experience temporary inconsistencies (seeing/not seeing the new feature).

Rolling with Batches:

This mode is quite similar to the previous one but instead of updating the existing instances to the new version, it creates additional instances with the new version according to a bucket size and then starts updating the old instances. This is done to make sure the app is always at capacity and there are no down times.

It does incur some small additional costs since a new batch of instances is created. The deployment times are much longer than rolling updates. Recommended for production use cases.

Scenario: A streaming service wants to update its video playback engine to a new version which is expected to consume more resources.

Example:

• Pros: Allows testing the new version with actual traffic without exhausting resources or affecting all users.
• Cons: More complex and can be resource-intensive as it requires additional instances.

Immutable:

Elastic Beanstalk uses Autoscaling groups (ASG) behind the scenes to scale the capacity in and out. This mode uses the ASG to roll out the new version. It creates a new temporary ASG containing instances with the new version. Once all new instances are provisioned and configured with the new version, they are moved to the main ASG, and the old instances are terminated.

This mode of deployment takes the longest and is costly, but ensures that there are no downtimes and the app is running at double capacity during deployment. Great for production use cases.

Scenario: A financial institution wants to update its user interface without risking the stability of its current environment.

Example:

• Pros: Ensures that the current environment is not altered during the deployment, minimizing risks.
• Cons: Resource-intensive since it requires doubling the environment.

Traffic Splitting:

This mode helps direct a small traffic of users to a newly deployed app version, to test it out. This approach is often referred to as Canary Testing. New instances containing new app versions are deployed to a temporary ASG. A small percentage of user traffic is routed to the new ASG for a specified amount of time which can be configured.

Deployment health is monitored and in case there is a failure the rollback is almost immediately ensuring zero downtime. Once, the specified duration for the temp ASG exceeds the new instances are moved to the main ASG, and the old instances are terminated.

Scenario: A food delivery app wants to test a new user interface (UI) by gradually exposing it to a certain percentage of users before a full rollout.

Example:

• Pros: Enables A/B testing and gradual feature release, mitigating potential risks.
• Cons: More complex to manage and monitor due to traffic distribution.

In conclusion, AWS Elastic Beanstalk offers a versatile set of deployment modes to cater to various scenarios and requirements. Whether you need a quick development deployment, require a seamless transition for production applications, or want to perform controlled canary testing, Elastic Beanstalk has you covered. These deployment modes not only ensure flexibility but also enable efficient resource utilization and minimal downtime, making it a valuable tool for managing application deployments on the AWS cloud platform. By choosing the appropriate deployment mode, you can optimize your application's performance and user experience while maintaining a high level of control over the deployment process.