AWS Architectures start at the heart of many businesses, customers.
The foundation and principles of AWS have been built on Amazon, a company that was envisaged to be the most customer centric company in the world. “There are two kinds of companies, those that work to try to charge more and those that work to charge less. We will be the second.” – Jeff Bezos
These types of requirements are inputs into an ethos that pervades, that underpins the Architecture of AWS.
Core Principles
Elasticity and Scalability are two fundamental cloud architecture principles that guide the AWS Architecture.
Elasticity is the ability to use resources in a dynamic and efficient way so the traditional anti-pattern of over provisioning of infrastructure resources to cope with capacity requirements is avoided. Significantly, elasticity avoids the costs of these over provisioned resources such as power, space and maintenance. This is the AWS pay as you go/pay for what you use model.
Scalability is the ability to scale without changing the design. With AWS, scalability is achieved by scaling-out. Infrastructure and application components are designed with the premise that they will fail, instead of a just being designed around High Availability. The technology components are commodities that can be thrown out when they fail and grown by adding more when demanded. A guiding principle is to have a consistent approach to architecture and growth.
Embracing these core principles requires a number of traditional blockers to be removed to support resilience and growth. Manual Components, Tightly Coupled Components, Stateful Components and Vertical Components.
- Manual – where manual intervention is required to start, scale or control resources
- Tightly Coupled Components – where a single component is dependent on another specific component
- Stateful components – resiliency to a loss of state
- Vertical scaling – ability to scale out horizontally, instead of vertical scaling which will eventually hit limitations
Repeatability is at the heart of removing these blockers so that automation (autoscaling and bootstrapping) can take over and scale transparently as the demand arises.
AWS represents a fork in the road where Infrastructure and Application Technologies meet at a common manageable point, the API. This is the power and revolution of cloud and AWS architectures, largely turning the Datacentre into highly manageable software. The AWS API has SDKs for Java, Python, Ruby, .NET, PHP, iOS and Android.
Architecting technology components as commodities is fundamental. Once blockers are removed Technology building blocks just become interchangeable components, the very definition of a commodity – “A basic good used in commerce that is interchangeable with other commodities of the same type. Commodities are most often used as inputs in the production of other goods or services. The quality of a given commodity may differ slightly, but it is essentially uniform across producers”. In AWS speak quality refers to the instance type and whilst there a number of different flavours of scale from t1.micro to C1.Xlarge they are essentially the same “commodity”.
New Architectural Ethos
Where there are blockers of cloud architecture adoption there are also principles that promote and strengthen cloud architecture. Areas that you need to gravitate towards to successfully leverage the AWS cloud.
- Autoscaling and Bootstrapping – Autoscaling allows you to automatically horizontally scale to accommodate load. Bootstrapping allows you automatically setup your servers after they boot. (Using components such as Amazon Machine Images (AMI’s) and CloudFormation to automate)
- Loosely Coupled
- Stateless
- Horizontal
Changing a legacy architecture to this new pattern can be but isn’t always the first step in adopting the cloud. Sometimes a “lift and shift” of a current application “as-is” can be a suitable and compelling first step into the cloud. It just means that all the capabilities of a cloud architecture will not be fully available until the blockers are removed and the new architecture ethos is more widely adopted. The adoption of new cloud architectures is like dining out. There are many choices, you can choose a la carte options and sample some specific menu items or you can have a banquet and get the full experience.
In AWS Infrastructure becomes code. In this example see how quick it can be to provision infrastructure for a website using CloudFormation: http://www.youtube.com/watch?v=Rg7On-Yx82g