How to Plan Your Deployment
I have been talking with some friends about setting up AWS instances and the general considerations for networking and server setup. Two decades ago hosting an application on the internet might have been challenging and required a significant investment, however, with the advent of AWS, this became easier, and definitely a lot cheaper. In addition, it’s easier than ever to drive traffic to your applications, and having more traffic than you can handle is a great problem to have. But you should ask yourself, can you handle that spike in traffic quickly and easily? What should you do from the beginning to set yourself up for scale? This article will focus on the AWS services, but the other hyper-scalers have some of the same capabilities. Let’s dig in.
Basic Setup
To host an application on AWS you could use 4 of their basic services to build your foundation. The first is Route 53, which gives you DNS (Domain Name Service) capabilities. This delivers the basics of taking a domain name, something like cloudywithachanceofsaas.com, and pointing it to an IP address bound to a server running your site. You can provision servers, via EC2 (Amazon Elastic Compute Cloud) instances, which allow you to run the custom software you have written. Second, you will have some sort of data store or database. AWS has many different options, but MySQL is a tried and true offering available from within AWS RDS (Amazon Relational Databases). I like this stack and have set it up a ton of times. Luckily for us and where we are headed Route 53 is already highly available and bakes in worldwide capabilities. However, there are a few things to be aware of for EC2 and RDS setups like this. It does not have any redundancy as you only have one instance of EC2 and RDS running. Since you only have one instance of each, software and hardware maintenance windows and doing updates is a challenge. While you can mitigate some of this with an in-elastic IP address, and for many deployments, you can stop here. But your users can experience slight outages as you move this IP address to a new server. For maintenance, software, or server updates, you can inadvertently shut off access to your users. As I noted in a prior article if you have an Application available in an app store, it should handle the backend being down for short periods, but how do you engineer a more robust infrastructure? Enter the fourth piece of the stack, the AWS Application Load Balancer.
AWS Application Load Balancer
There are several reasons to use the application load balancer. First, it offloads the updating and processing of the HTTPS/SSL requests from your end users. You no longer have to have anything configured or running to keep that current. This means you’re putting one less burden on already stretched teams. Second, it allows you to run multiple EC2 instances to handle spikes in load and allows you to perform server updates and maintenance on your server instances without adversely affecting your end users. Third, with the Geolocation routing available from Route 53, you can route your users to infrastructure located closer to them, giving them better performance. At the same time, if a region has to be taken down for maintenance, or has an outage, other regions can, and will automatically pick up the slack. Fourth, you can stand up multiple servers to handle system failures and to handle more workload. Fifth, it allows you to stand up new instances of your software as test or validation instances, which ensures everything is running correctly before you switch all of your users over to the new EC2 instance. While the Application Load Balancers are not super expensive, you probably just need one for your application infrastructure at the beginning of your project across the typical loads of dev, test, integration, and production.
By beginning your infrastructure layout with an application load balancer you are setting up your infrastructure for future growth and scale.
1 Tip:
Be ready to grow easily and simply via an AWS Load Balancer with the suggestions above.
Thank You
Jim ‘The Designatic’ Tyrrell