AWS Learn In Public Week 8, Elastic Beanstalk

This has been an exciting week as London is starting to open up little by little. We agreed with the rest of my team at work that whoever wants can start to the office twice per week. Finally after a long winter of staying at home the whole day every day, we can start seeing some people again. The only downside of it is that it broke my routine of tweeting about AWS services.

In this blog post we're going to talk about Beanstalk which is a really interesting service as it can glue the majority of the stuff you need when creating an environment. I don't understand why not everyone uses it.

Definitely once I finish this project and get my certification this will be one of the first services that I'm going to dive deep into it. Without further ado let's check it out.

AWS Beanstalk

What is AWS Elastic Beanstalk?

• A platform as a service for deploying applications to AWS
• It is a layer for configuring how to use other services like EC2, Auto Scaling Groups, Load Balancers, RDS etc.
• Using Elastic Beanstalk is free but you only pay for the underlying resources
• Elastic Beanstalk is a managed service and can also be used for deployment strategies
• The idea behind it is that the developer is responsible for the code and Beanstalk for the infrastructure

There are 3 architecture models

1. Single Instance Deployment which is great for dev environments
2. Load Balancer with Auto Scaling Groups which is the standard model for production web apps
3. Auto Scaling Groups only which is mainly for analytics and workers services

We can version our applications to environments and promote them to the next environment until we reach production. We can customise these stages to whatever we want. e.g. dev - staging - prod. Rollback feature is also available

Deployment options

All at once

We have the "all at once" option where you can deploy all instances in one go.

• This option has downtime but it is the fastest way to deploy
• It is great for dev environments that require quick iterations and also there are no additional costs to it

Rolling

We have the rolling option where slow update the current instances with new once until our application only contains the new code. Let's say our app has 4 instances. 2 of them are going to be updated (below capacity) with the new version and then the next 2.

Rolling with additional batches

We have the rolling with additional batches option. Here we use the same logic as before but instead of updating the current instances, we add a few extra. The deployment is longer, has small extra costs but is good for production

Immutable

We have the immutable option where we spin up a complete new set of instances (double the amount in total) and once the new version is out and running, we terminate the old ones. This option has 0 downtime, is great for prod but is quite costly.

Blue / Green deployments

Finally we have the blue / green deployment option

• We create a new env with the new app version (green) and direct 10% of the traffic to it
• The old env (blue) will handle 90% of the traffic
• We setup weighted policies in Route53
• Once we are happy, Beanstalk can swap urls

Beanstalk under the hood

Let's talk a bit more about how AWS Beanstalk works under the hood. It basically relies on AWS CloudFormation to provision any other AWS services (Infrastructure As Code). To do that we can define a .ebextensions folder inside which we provision any service we want

Running Docker with Beanstalk

Single Docker Container

Single Docker for simple setups where we run our app as a single Docker container.

We provide:

• A Dockerfile which will be used to build and run our container
• A Dockerrun.aws.json v1 file for existing images which can be in ECR or Dockerhub
• Uses EC2 under the hood

Multi Docker Container

Multi Docker which runs multiple containers per EC2.

• It will create and ECS cluster, EC2 instances for it, a Load Balancer in High Availability mode, task definitions and execution.
• It requires a Dockerrun.aws.json v2 config file at the root of the project.

Multi Docker also uses the Dockerrun.aws.json v2 config file to generate the ECS task definition. We need to have our docker images prebuilt and stored in ECR

Summary

I really don't understand why not more people use Beanstalk. It really simplifies the whole deployment process and putting all the services together.

On the surface this looks really really simple but Beanstalk is just the tip of the iceberg. Next week we are going to talk about CloudFormation and a little bit of Cloudfront.