Join Jeff Winesett for an in-depth discussion in this video Understanding elasticity, part of Amazon Web Services Essential Training.
When you think about the word elastic you tend to think about something that is stretchy, something that can expand and contract when it needs to. Like an elastic waistband on a pair of pants or a rubber band. Referring to the cloud as elastic has the same meaning. Just as the elastic waistband of your pants is able to accommodate you both before and after a large meal, the elastic nature of the cloud refers to its ability to accommodate changes in load and demand of the system.
Let's use some graphs to better illustrate the scaling concepts we touched on in the previous section. First, let's look at a more traditional, that is to say, non-elastic hosting environment, where we have a fairly fixed capacity and if changes in the capacity are needed, much planning, time and money are needed to make this change. So here, we have our capacity along the y-axis and let's just think of this as the number of web servers as an example.
And we are representing time along the x-axis. OK, now imagine you are on a team who is launching a new application soon and you are tasked with configuring the production environment to support this new application. Through much planning and estimation you have predicted you need to have five web servers. Now the team launches your cool new thing and you begin monitoring the usage of the capacity as customers start using it. The first thing that we notice is that we have extra capacity.
That's this area between the allocated capacity and actual usage labeled-one. I guess better to have too much capacity and happy customers than to have planned poorly and not enough capacity but at this point this is wasted money because our allocated capacity at times far outweighs demand. Happy customers but angry accounting department and you cant stay in business long by wasting a lot of money. Now imagine the marketing team starts advertising and as this marketing team is really good we get an unexpected spike in traffic.
This spike actually exceeds our allocated capacity and now customers trying to access the application are being denied. The application is down, everyone is complaining, this is not a happy place to be. So you do some more planning, more predicting, make another large up-front investment and decide to get five more servers in place, that is to say we decide to scale out by five servers. OK, now your capacity is at 10 and you are happily accommodating the marketing spikes but we also have dips in demand that cause considerable waste, even worse than before and of course this cycle keeps going as demand fluctuates, so there's got to be a better way.
Enter the cloud, now let's take a look at the same scenario but this time you have deployed on cloud infrastructure and are able to take advantage of its elastic nature. So we have our same graph and are starting in the same place. We of course still have to do some planning and we have to decide to start with some capacity for launch. So your predictions are the same as before and you decide to again to start with five servers. Now as you watch your actual demand you may decide at the beginning that five servers is more than what was needed, no problem.
You can take advantage of the cloud's elasticity and quickly and by quickly I mean literally in a matter of minutes, scale in the web server tier from five servers to four servers thereby reducing the waste and saving money. So of course your monitoring continues and when the marketing team starts to have their success we notice that our four servers are now approaching full utilization. You can once again, very quickly scale things out to accommodate and can do so in a manner to always stay a step ahead and outpace the demand.
You can monitor server statistics such as CP utilization and when it rises above a certain threshold you add more servers or scale out and keep customers happy. And if levels again dip below certain thresholds you can remove servers and keep the accounting department happy. Elasticity is one of the fundamental properties of the cloud. This power to scale computing resources up and down easily, will ultimately drive most of the benefits of the cloud. So you really should work to internalize this concept and always be thinking of ways to work it in to your application architecture in order to maximize the benefits of the cloud.
This elastic nature of the cloud really changes the way you think about your architectures and designs and as such, you will need to let go of some of your old habits and old ways of thinking. So I'm going to touch on some of those in the next section as I discuss letting go of constraints.
- The benefits of cloud architecture
- Core cloud-based architectural principles
- Monitoring resources and applications with CloudWatch
- Using Amazon Machine Image (AMI)
- Using Elastic Beanstalk
- Implementing message queues, Simple Workflow Service, and Simple Notification Services
- Setting up security groups
- Launching and connecting to an EC2 instance
- Elastic Load Balancing
- Virtual Private Cloud (VPC)
- Using the AWS SDK