I have thought a lot about how I used to provision traditional IT resources, and how differently I would provision Amazon Web Services resources in the cloud today. Maybe you can benefit from my perspective, based on experience, that keeps it plain and simple.

In the past, I had to think about how much hardware and software I could buy with a given budget. I would over-engineer the architecture, since I would have to live with it for several years. It was better to be safe with more than I could use, than be sorry trying to explain why the money already spent wasn’t enough. Building a whole test system up front to prove it would work would also increase costs, oftentimes completely ruling out that option.

This would give me a system that would leave portions of it underutilized. I would rationalize this away by thinking, “That is OK, now we have room to grow.” But with this rigid architecture, if I guessed wrong and we grew faster than anticipated, I could quickly run out of resources. Obviously, this would make the system, and my work, look bad to customers. On the other hand, if we did not grow, I might be asked to cut costs, but would not have an easy way to downsize to a smaller system. It would require us to buy new smaller hardware, liquidate or repurpose the old hardware, while hoping we might save money in the process. Often, there was just no way to win.

“Rigid” is the keyword of traditional IT hardware resources. It is not easy to reconfigure, expand, or shrink the infrastructure. So, from my perspective as an experienced developer and IT decision maker, this is the biggest advantage of AWS. It is flexible. Building a system architecture in the AWS cloud gives me flexibility that I just didn’t have before. That is worth a lot.

Now I can quickly build a small representative prototype EC2 system storing data in S3 buckets and EBS disk volumes on our VPC in AWS to prove that it will work. I don’t have to compete with other departments for limited resources. And I don’t have to spend much money for a system that I just throw away eventually.

When it is proven that I can achieve what I want with the new design, with minimal work I can leverage that prototype into a production system that can scale to the appropriate size to handle changing computing needs.

By implementing an elastic architecture in AWS, I don’t have to over-spend on more resources than I need right now. And I don’t need to try to make predictions about an uncertain future. As customer demands increase, I can stretch the infrastructure by adding in more resources. I can even configure “on demand” resources that come and go as demand spikes occur. And if we need to shrink, we can do that just as easily.

Buying computers, disk shelves, and networking equipment, and putting that all into big racks in a computer room or co-location facility seems so old-fashioned to me now. And so risky. The flexibility to build and change the system in a virtual cloud environment opens up so many options that just did not exist before.

At IDS, just like most businesses, we like to argue about the dollars and cents. It can get very hard to do an apples-to-apples comparison versus a traditional systems architecture, because you can get architectures and features in AWS you could not get any other way. You have to try to get an idea of the value to you of some of these capabilities in order to really make an informed decision on whether or not AWS is right for your needs.

I plan to cover some of these topics in future posts. Want to know more about AWS (Amazon Web Services)? Here are some links to get you started.




Norman Paul
Senior Database Consultant
AWS Certified Solutions Architect – Associate Level
International Data Science Corporation

Leave a Reply

Your email address will not be published. Required fields are marked *