Traditional IT environments that are built using physical servers can only scale and grow by buying new hardware and software and taking time to install and rack the hardware, configure the software and the application. If/when the excess capacity is not needed the servers stand idle consuming power, cooling and rackspace. This is inefficient and a waste of money.
Amazon Web Services (AWS) allows customers to scale using elastic demand. Just like a rubber elastic band stretches to accommodate more items , AWS provides elastic computing to allow a customer to scale up (or down); to grow or shrink their architecture quickly efficiently with minimal intervention.
The following is a summary of an AWS whitepaper and webinar that describes how you can use AWS to architect your system for the cloud.
- AWS EC2 - an elastic cloud computing platform that allows you to add/remove virtual servers as needed. These virtual servers (instances) can be configured with an operating system, application software and configuration settings into an AMI (Amazon Machine Image). AMIs can be acquired as needed or reserved.
- Availability Zones - distinct locations within geographical regions that ensure you are insulated from failures in other zones.
- Elastic IP addresses - programmatically and dynamically assign an IP address to an instance.
- Cloud Watch - monitor the performance of instances: CPU, memory, network and disk utilization.
- Autoscaling - automatically scale your environment to grow or shrink based on metrics sourced from Cloud Watch.
- Elastic Load Balancing - distribute traffic between your instances to ensure customers get good response from your application.
- Elastic Block Storage - network attached persistent storage that you attach to your instances, thus if an instance is removed the data is not lost.
- S3 - Simple Storage Service for storage of data in buckets or backups/snapshots of EBS volumes.
- CloudFront - a content delivery service (CDN) for distributing content close to your customers to reduce latency and response times.
- RDS - Relational Database Service - allows you to setup and operate MySQL or Oracle databses without worrying about backups, patches etc.
- SQS - Simple Queue Service for distributed messages.
- SNS - Simple Notificaiton Service to notify applications or people using publish/subscribe protocols.
- Route53- - scalable DNS service
- IAM - Identity and Access Management Service to create multiple users with unique credentials and permissions.
With these components in mind, how do I build a truly scalable application that can operate in an AWS cloud?
First, let's define a scalable application:
- Resources increase as performance or demand increases. Example: I add new hard-drive capacity only when the disk is approaching full, I don't have empty wasted disk on standby "just in case". Similarly, I add additional servers as my server utilization (CPU or memory) approaches capacity, rather than having extra yet idle servers "for when the need arises".
- Heterogenous - diverse. Example, I am not bound to using one operating sytem.
- Efficient - only uses the resources it needs
- Resilient - if any resource in the architecture fails, users experience little if any disruption of the service.
- Cost effective - only buy what you need when you need it, not idle wasted excess.
Be pessimistic! Assume instances will fail and build redundancy into your architecture.
To accomplish this in AWS you can:
- Build AMI packages that get their configuration from AmazonSimple DB and can be started automatically by CloudWatch to either replace failed instance or provide growth to a package of instances. Elastic IPs can also map IP addresses from to new instances.
- Architect your application across several Availability Zones, in case one zone is unavailable another can take over.
- Similarly deploy multiple databases across Availability Zones for redundancies
- Use Amazon EBS to take snapshots of your volumes in case a volume fails you have an instantaneous back up available that can be attached to an AMI.
- Design your software application using loosely coupled SOA components that do not have tight dependencies on one another. Thus if one component fails,the other components are able to operate until the failed component is replaced.
- Message queues, such as SQS (defined above), allow components to be loosely coupled, if one component is unavailable messages simply queue up in the buffer until the component is online again. This differs from tightly coupled systems written in procedural programming languages which depend on other components being available all the time for the entire system to remain functional.
The most important factor in building a scalable application is elasticity. What components of my application can be made elastic and how?
There are three types of elasticity:
- Proactive - at fixed interval perhaps month-end or quarter-end.
- Event based - when traffic surges are expected, example tax season
- On demand - automatically add/remove capacity as needed.
To implement elasticity:
- Automate - the ability to automatically request and start AMIs with minimal manual configuration and intervention.
- Bootstrap - assigns a role to an AMI, such as "web server" or "database server" which allows the AMI to instantiate itself using preconfigured options.
- Store configuration options in Amazon SimpleDB.
- Use AWS CloudWatch to notify you of system metrics which allows you to create new instances to performs event or proactive elasticity.
- AutoScaling allows you to grow your infrastructure, elastically, on-demand.
- Boot instances from EBS volumes for faster elasticity.
- Parallelization - design your architecture to take advantage of executing multiple tasks at the same time, thus you can store and fetch data if the processes are concurrent.
It all boils down to elasticity, flexible compute demand as needed....