Building for Scale in AWS – Tricks of the Trade

Building for Scale in AWS Tricks of the Trade

Building for Scale in AWS; Tricks of the Trade

Written by David Linthicum exclusively for Nelson Hilliard

Even back in 1999, building and deploying enterprise applications was so frustrating that the use of cloud-based resources seemed like a breath of fresh air. Yes, I have been in cloud computing for a long time.

What frustrated me was the fact that I had to plan out how the application would scale. More users, larger data sets, and more loading meant that I had to think well ahead of the wall that the application would soon hit.

I had to make sure that enough hardware resources were on order, as well as make sure they had a place in the data center, were tested, and in a good operational state.

AWS, like other public clouds, provides the feature of “Auto Scaling.” You can think of it as renting a Prius that can automatically convert into a Corvette when you slam down on the gas peddle. Then, back to a Prius again when you slow down.

AWS Auto Scaling allows you to automatically scale up your Amazon EC2 instances up or down using parameters you define. This means you can ensure that the number of Amazon EC2 instances you use increases auto-magically during demand spikes.

What’s more, it auto-magically reduces the number of instances when the spikes subside. Thus, this feature is most useful for applications that have a lot of variability in loading. Auto Scaling is managed by Amazon CloudWatch.

Beyond the auto-scaling features of AWS, there are some tricks of the trade that those who build on the AWS public cloud platform should consider. Here is my short list:

First, design your infrastructure by delegating tasks to independent services. This means leveraging service-oriented architecture as a foundation to decompose your application and/or technology instances (e.g., a database) as sets of services that are bound together to form an application.

This provides you with more options when you scale the application. Once you separate things into services, you can scale them independently. I thought so much of this approach that I wrote a book about it a few years ago.

Second, make sure your application and its components are stateless. This provides more options for scaling the application, and is a good idea in general. Moreover, make sure the application is idempotent.

Third, as we covered above, make sure that your application is in an Autoscaling group, and thus EC2 will adjust the number of instances required to meet the needs of an increasing or declining load. Also, make sure to leverage Elastic Load Balancer to make sure you leverage each instance as equally as possible. Turn sticky sessions off.

Forth, make sure to leverage caches, when it makes sense. Typically, data intensive services will benefit the most, thus where and when will depend on the application.

Finally, test and profile. This means testing the application on AWS. Determine where the bottlenecks occur, and then design around them. This will allow you to decide how to best leverage AWS, and even design your application with scaling on AWS in mind. AWS can certainly accommodate the scaling needs of most applications. However, in some instances, you need to design the application to take the best advantage of the scalability features of AWS.

Remember to Subscribe to our Youtube Channel for the Latest Cloud Computing Tech Jobs, News, and Cloud Shows.


David S. Linthicum is a managing director and chief cloud strategy officer at Deloitte Consulting, and an internationally recognized industry expert and thought leader.

Connect with David on LinkedIn and Twitter:

At Nelson Hilliard we specialise in cloud technologies, sourcing the top 20% of cloud professionals inspired to work for you through our specialised marketing and profiling. If you are interested in having a quick talk to me regarding your employment needs please feel free to reach out.

You can also check my availability and book your 15 minute discovery call here.

Brad Nelson