Scalability is one of the most important aspects to consider for modern web application deployments. With the advancement of Cloud technologies, it has never been easier to design solutions for scalability. The elasticity of Cloud provides the basic foundation and flexibility to design practical solutions.

Using AWS, it is possible to provision EC2 instances and pay only for the time of usage and also allowing to automate the scaling out (Creating more instances) for the demand automatically, with tools like Auto Scaling Configurations, Launch Configurations, Load Balancers, Amazon Machine Images (AMIs) and more.

However, there are various factors that involve in building a reliable and efficient scaling platform for your application deployments which is worth to consider. Therefore it is required to design the auto-scaling appropriately to address the following,

• Scaling efficiently on demand (reducing new instance provisioning time).
• New deployment support with near zero downtime.
• Rollback support.
• Disaster recovery.

Auto-Scaling and Load Balancing Tools in AWS

There are several fundamental services required for autoscaling and load balancing deployments. Most of these services are readily available as managed services from AWS.

• Load Balancer - Requires to balance the load coming from clients and fairly distribute to the healthy EC2 instances. It also requires to identify unhealthy instances and stop sending the traffic. In AWS, there are multiple types of Load Balancers available (Classic Load Balancer, Application Load Balancer & Network Load Balancer) which can be used for different purposes. However, Application Load Balancer is commonly used for general Web Applications.
• Auto-Scaling Tools - These tools are needed to identify the limitations of existing capacity and trigger provisioning of new instances (Scale-out) and also to terminate instances (Scale-in) when the load is less. AWS provides a combination of tools to support this including CloudWatch (To monitor), Auto-Scaling Configurations, Launch Configurations (Instructions to bootstrap new instance).

Using Custom AMIs

One of the common approaches is to create an AWS EC2 instance with the required operating system and application inside and create a Custom AMI (Virtual Machine Image). This allows defining the AMI reference in AWS EC2 Launch Configuration to instruct AWS auto-scaling tools to bootstrap new instances using the custom AMI.

Pros

• Straightforward to configure the provisioning rules.
• Easy to rollback and update new instances (AWS provides support for rolling updates).
• Support for deploying a large number of instances.
• Relatively fast bootstrap process.

Cons

• Requires to have a relatively complex build process and required to build new AMIs for each update.

However, it is also possible to have a Custom AMI and do minor configurations upon the EC2 instance bootstrap process.

Dynamically Bootstrap EC2 Instances

In this approach, it is possible to use a base AMI provided by Amazon which contains only the operating system and general software. There are several approaches to implement dynamically bootstrapping EC2 instances for an application deployment.

Use a Base AMI from Amazon and bootstraps its application when the instance is starting using the AWS Launch Configurations.
Create a Custom AMI that is capable of loading a specified version of the application upon bootstrap.
It is also possible to use a base Amazon AMI with Docker where the container image is pulled or built upon bootstrapping of the instance.

Pros

• Not required to keep AMIs for each deployment.
• Base AMI software patching can be done independently from the application.
• Straightforward to configure the provisioning rules.
• Build process and deployment is straightforward (Without the need for the AMI build).

Cons

• For large applications, bootstrapping can take more time causing problems for spike loads (Taking too much time to provision and handle the excess load).
• Supporting rollback would be difficult unless following an approach to keep track of bootstrap code with deployment version (e.g Store each deployment in S3 and bootstrap process will retrieve the relevant version).

However, using Docker can solve some of the problems of deployment versioning and rollback which requires to containerize the applications and have a unique docker build process.