So, you want to build an application? But perhaps you’re unsure where to go next in configuring AWS environments? Elastic Beanstalk is here to support you though by handling configuration details for you. By using preconfigured CloudFormation templates and scalable, load-balanced provisions, ELB creates a reliable environment for your application. This may all sound simple, but AWS Elastic Beanstalk is so much more than that and has a choice of deployment options based on your needs.
Not just any Beanstalk
Simply put, AWS Elastic Beanstalk is the fastest way to deploy your application on AWS.
Just use the AWS Management Console, a Git repository, or an IDE such as Eclipse or Visual Studio to upload your application and Elastic Beanstalk automatically takes care of deployment details and in minutes your application will be ready to use.
As the time of writing, Elastic Beanstalk supports Apache, Passenger, Internet Information Services (IIS) and Nginx servers and Java, .NET, PHP, Node.js, Python, Ruby and Go programming languages plus Docker containers to host custom applications in addition to .ebextensions for custom platforms and a customizable environment.
There are two types of environments in AWS Elastic Beanstalk, web server environments and worker environments, your application can run on multiple environments but only one application version can run on an environment. When an environment is created, Elastic Beanstalk creates a CloudFormation stack on your behalf which is viewable in the CloudFormation console, if you update the environment configuration or make a deployment additional stacks are created or updated accordingly.
Elastic Beanstalk is here to simplify your deployment, but it also has more complex deployment methods and below we’ll go over which methods may best suit your needs.
All At Once Deployment
This option is a bit tricky because, as the name suggests, all deployments are done at the same time. Let’s ,say you are deploying to three EC2 instances, in this case, all three will begin deployment. This is a great idea in theory as it is the simplest and fastest version, but what if your deployment has an error and fails? These things do happen and now all your instances will fail, leading to downtime and disaster and you’ll have to revert to a previous deployment version and wait for it to complete. So why deploy all at once? It’s a great and quick way to test your environment purposes but let’s look at some more cautious methods.
Here we can see our base scenario, in this case, three instances.
Deployment starts on all instances.
Deployment also fails on all instances.
As seen above, an all at once deployment approach has some drawbacks, but we can mitigate that with our next option: rolling deployment.
Let’s assume you’ve set a batch size of one, in rolling mode, your application will only deploy to the first batch and proceed to the next after it’s successful, but what of failed deployments? If your batch fails to deploy only the first instance will be down and your remaining instances will continue to operate. If your deployment fails in later batches then your environment will continue to serve two versions, the new version on successful deployments and the previous version past the fail point. The downsides being your instance fleet will decrease in size per failed batch as they will no longer be able to process traffic but on the upside, there will be no downtime.
Deployment starts in the first instance.
Deployment continues onto the next instance.
If your deployment fails on the first instance, the remaining instances will continue running the previous version.
If deployment fails on the second instance, your environment will continue to run two versions.
Rolling with additional batch: Just a little bit more
But what if you don’t want to reduce your fleet size during deployment? Then rolling with additional batch can help.
Using this mode means that AWS Elastic Beanstalk will provision an extra batch of instances and begin deploying on them and successful deployments on instances will be registered the load balancer and will move on to deployments on the next instance. Once this is done, additional instances created in this mode will be terminated. If for some reason, your first deployment fails, then the instance will be terminated when you cancel the deployment and since this happened on an instance created on an additional batch, your fleet size will not be affected
If a failure occurs on the following batch, the instance will be terminated and two versions will continue to run similar to rolling deployments without additional batch.
In this case, a new instance is created and deployment starts on it.
And deployment continues on the next instance.
Upon successful deployment, the created instance is terminated.
If deployment fails, your instances will continue to run the previous version.
Immutable: Don’t update, Replace!
The word ‘Immutable’ is defined as something that is unchanged or will not change over time, and that applies to Immutable deployments too, here, your instances are considered Immutable, and are not changed or updated, but replaced. AWS Elastic Beanstalk will duplicate your fleet size for a short time and begin deployments to them, once that step is successful, old instances will be terminated. A failed deployment will result in no downtime, and the created instances will be terminated.
Just keep in mind that you subject to AWS account limits, and new instances may fail to deploy if your fleet size is large.
New instances are duplicated and deployment begins on them.
And upon completion, older instances are terminated.
With a failure, instances are terminated and traffic continues as normal
Blue/Green: Copy all the things
Blue/Green deployments are very different from the methods described to above, and we’ll go over why further down but simply put, a blue/green deployment duplicates your entire current environment, and when deployment is finished on your cloned environment, traffic is redirected to the duplicated environment. If the deployment fails, you terminate the clone and there will be no issues with your current instance. In these cases, it would best to keep your old environment available as some worst-case scenarios could apply and you could solve this by redirecting traffic to your old environment. This method has close to zero downtime and is best used for deployments of a critical nature.
But what sets blue/green deployments apart from the rest is that it is not a deployment type in Elastic Beanstalk as you’ll be duplicating an environment, including Elastic Load Balancers. However, Elastic Beanstalk makes this process simple and straightforward.
First, in AWS Management Console, AWS CLI or EB CLI you have the option to clone your current environment, including Elastic Load Balancers, Auto Scaling groups, and other resources, and then deploy the current version. Next, when the environment is ready, deploy your new version and test it to make sure it’s successful. Finally, you can swap URLs of the two environments (again, AWS Management Console, AWS CLI or EB CLI) and traffic will direct to your new environment.
Like with Rolling with additional batch, you may still have to consider your AWS account limits, your instance limit must take into account new instances created using this method.
Most importantly, there should be no RDS instances in your environment, the data will not be copied when duplicating your environment.
Here, you can see your cloned environment begin deploying.
And once tested to ensure your deployment is successful, traffic can be redirected to your new environment.
As you can see, AWS Elastic Beanstalk is a truly versatile system for your deployment whichever method you choose.
Ibexlabs is an experienced DevOps & Managed Services provider and an AWS consulting partner. Our AWS Certified DevOps consultancy team evaluates your infrastructure and makes recommendations based on your individual business or personal requirements. Contact us today and set up a free consultation to discuss a custom-built solution tailored just for you.