By Josh Symonds, March 7, 2017, AppDynamics.
Auto Scaling, Repeatability, and Consistency
Amazon’s software-as-a-service (SaaS) offerings, such as RDS, are extremely convenient and very powerful. But they’re far from perfect. Generally, AWS products are much slower to provision compared to running the software directly yourself. Plus, they tend to be several software versions behind the most recent releases.
In databases, this is a fine tradeoff. You almost never create databases so slow that startup doesn’t matter, and you want extremely stable, well-tested, slightly older software. If you try to stay on the bleeding edge, you’ll just end up bloody. But for other services, being locked into Amazon’s product offerings makes less sense.
Once you have an RDS instance, you need some way for customers to get their data into it and for you to interact with that data once it’s there. Specifically, you need web servers. And while Amazon’s Elastic Beanstalk (AWS’ platform to deploy and scale web applications) is conceptually good, in practice it is extremely slow with middling software support, and can be painfully difficult to debug problems.
But AWS’ primary offering has always been the Elastic Compute Cloud (EC2). Running EC2 nodes is fast and easy, and supports any kind of software your application needs. And, unsurprisingly, EC2 offers exceptional tools to mitigate downtime and failure, including auto scaling groups (ASGs). With an ASG, Amazon keeps as many servers up as you specify, even across availability zones. If a server becomes unresponsive or passes other thresholds defined by you (such as amount of incoming traffic or CPU usage), new nodes will automatically spin up.
New servers by themselves do you no good. You need a process to make sure new nodes are provisioned correctly and consistently so a new server joining your auto scaling group also has your web software and credentials to access your database. Here, you can take advantage of another Amazon tool, the Amazon Machine Image (or AMI). An AMI is a saved copy of an EC2 instance. Using an AMI, AWS can spin up a new node that is an exact copy of the machine that generated the AMI.
Packer, by Hashicorp, makes it easy to create and save AMIs, and is also free and open-source. But there are lots of amazing tools that can simplify AMI creation. They are the fundamental building blocks of EC2. With clever AMI use you’ll be able to create new, functional servers in less than 5 minutes.
It’s common to need additional provisioning and configuration even after an AMI is started—perhaps you want to make sure the latest version of your application is downloaded onto your servers from GitHub, or that the most recent security patches have been applied to your installed packages. In cases such as these a provisioning system is a necessity. Chef and Puppet are the two biggest players in this space, and both offer excellent integrations with AWS. The ideal use case here is an AMI with credentials to automatically connect to your Chef or Puppet provisioning system, which then ensures the newly created node is as up to date as possible.
You can view the full infographic here. In out next installment Josh covers the additional segments of the infographic not covered in this second installment.
Read part 1 of this 3 part series by clicking here.
