Jinesh Varia Technology Evangelist jvaria@amazon.

com

Architectural
Design Patterns in
Cloud Computing
 They sent me here to talk
But I am here to listen

Please Send Feedback

jvaria@amazon.com
Twitter: @jinman
 Cloud Best Practices Whitepaper
Prescriptive guidance to Cloud Architects

Just Google for “Cloud Best

Practices” to find the link
 Cloud Computing Attributes
What makes the Cloud so attractive

Abstract Focus on your needs, not on hardware specs. As your

Resources needs change, so should your resources.

On-Demand Ask for what you need, exactly when you need it. Get rid
Provisioning of it when you don’t need

Scalability Scale out or in depending on usage needs.

No Up-Front No contracts or long-term commitments.

Costs Pay only for what you use.

Efficiency of
Experts
Utilize the skills, knowledge and resources of experts.
 TheCloud
The “Living and Evolving” Cloud
AWS services and features
Most Applications Need:
1. Compute
2. Storage
3. Messaging
4. Payment
5. Distribution
6. Scale
7. Analytics
 “At Amazon, Every
The “Living Day is a Cloud
and Evolving” Launch Day”
New Features and Services
» Amazon EC2 with Windows Server
2008,
» AWS Multi-Factor Authentication Spot Instances,
» Virtual Private Cloud Boot from Amazon EBS
» Reserved Instances in EU Region » Lower Reserved Instance Pricing » Amazon CloudFront Streaming
» Elastic MapReduce » Amazon VPC enters Unlimited Beta
» SQS in EU Region » AWS Region in Northern California
» International Support for AWS
Import/Export
» Amazon RDS
» New SimpleDB Features » High-Memory Instances
» FPS General Availability » AWS Security Center » Lower EC2 Pricing

» Amazon EC2 with Windows » Amazon Elastic MapReduce » Amazon CloudFront

» Amazon EC2 in EU Region in Europe Private Content
» AWS Toolkit for Eclipse » SAS70 Type II Audit
» Amazon EC2 Reserved » AWS SDK for .NET
Instances
» AWS Import/Export » Amazon EC2 Reserved Instances
» EBS Shared Snapshots
» New CloudFront Feature with Windows, Extra Large High
» Lower pricing tiers for » SimpleDB in EU Region
» Monitoring, Auto Scaling & Memory Instances
Amazon CloudFront » Monitoring, Auto Scaling &
Elastic Load Balancing » Amazon S3 Versioning Feature
» AWS Management Console Elastic Load Balancing in EU
» Consolidated Billing for AWS
» Lower pricing for Outbound Data
Transfer
 Scalability
Build Scalable Architecture on AWS

A scalable architecture is critical to take advantage of a scalable

infrastructure

Characteristics of Truly Scalable Service

Increasing resources results in a proportional increase in

performance
A scalable service is capable of handling heterogeneity
A scalable service is operationally efficient
A scalable service is resilient
A scalable service becomes more cost effective when it
grows
 Cloud Architecture Lessons
using Amazon Web Services

1. Design for failure and nothing fails

2. Loose coupling sets you free
3. Implement “Elasticity”
4. Build Security in every layer
5. Don't fear constraints
6. Think Parallel
7. Leverage different storage options
 1. Design for Failure
and nothing will really fail

"Everything fails, all the time"

Werner Vogels, CTO Amazon.com

Avoid single points of failure

Assume everything fails, and design backwards
Goal: Applications should continue to function even if the
underlying physical hardware fails or is removed or replaced.
 Design for Failure with AWS
Tools to make your life easier

Use Elastic IP addresses for consistent and re -mappable routes

Use multiple Amazon EC2 Availability Zones (AZs)
Create multiple database slaves across AZs
Use real-time monitoring (Amazon CloudWatch)
Use Amazon Elastic Block Store (EBS) for persistent file systems
 YourWebTwoDotZeroName.com

EC2 Instance A EC2 Instance B

 YourWebTwoDotZeroName.com

Availability Zone 2
EC2 Instance A EC2 Instance B
Availability Zone 1

DATA LOG LOG DATA

Volume Volume Volume Volume

Amazon S3
 2. Build Loosely Coupled Systems
The looser they're coupled, the bigger they scale

Independent components
Design everything as a Black Box
De-coupling for Hybrid models
Load-balance clusters

Use Amazon SQS as Buffers

Tight Coupling Controller A Controller B Controller C

Q Q Q
Loose Coupling
using Queues Controller A Controller B Controller C
 MyWebSite.com
Exterior Firewall Hardware
or Software Solution to open
standard Ports (80, 443)
Web Load Balancer
LB
Hardware or Software solution
to distribute traffic over web
servers
Web Tier
Fleet of machines handling Web Server Web Server
HTTP requests.

Backend Firewall Limits

access to application tier from
web tier
App Load Balancer LB
Hardware or Software solution to
spread traffic over app servers
App Server Tier
Fleet of machines handling
Application specific workloads
App Server App Server App server Backups on
Caching server machines can
be implemented at this layer Tapes Periodic
backups stored on
Tapes usually
managed by 3rd
Data Tier party at their site
Database Server machines with
MySQL MySQL
master and local running
separately, Network storage for Master (Slave)
Static objects
Tapes
 MyWebSite.com
DNS
Elastic Load Balancer
ELB to spread traffic to Web
Server Auto-scaling groups ELB: Web Tier LB

Exterior Firewall no longer

needed because EC2 instances
are controlled with Security Auto-scaling group : Web Tier Auto-scaling group : Web Tier
Groups
Auto-scaling Web Tier
Group of EC2 instances
Web Server Web Server Web Server Web Server
handling HTTP requests.
Backend Firewall no longer Edge Caching
needed High Volume
App Server Load Balancer SLB SLB Static
Software LB (e.g. HAProxy) on Content is edge
EC2 instance to spread traffic cached using
over app server cluster CloudFront
Auto-scaling App Tier
Group of EC2 instances running App Server App Server App Server App Server Cloud
Tomcat Tomcat
the actual app. Instances Front
belong to Auto-scaling group.
Caching servers instances can Auto-scaling group : App Tier Auto-scaling group : App Tier
be implemented at this layer

DB Tier
MySQL RDS DB Instances RDS RDS RDS Amazon
(master, local slave, x-AZ slave Master Slave Slave S3
for failover) , Automated
backups to S3 all managed by
Backups
AWS Availability Zone #1 Availability Zone 2 Amazon S3 used
Availability Zone #n for storing Static
Objects and
Backups
 3. Implement Elasticity
Elasticity is fundamental property of the Cloud

Don’t assume health or fixed location of components

Use designs that are resilient to reboot and re -launch
Bootstrap your instances: Instances on boot will ask a
question “Who am I & what is my role?”
Enable dynamic configuration

Use Auto-scaling (Free)

Use Elastic Load Balancing on multiple layers
Use configurations in SimpleDB to bootstrap instance
 Managed Development
3. Implement Elasticity
3 Usecases
Environment

Dev/Test Apps SaaS Paid Web 2.0 Product

Prod AMI

Managed Automated Cloud-powered

Development Deployment Software Lifecycle
Environment Environment management

AWS Cloud AWS Cloud AWS Cloud

Enterprise IT ISV Startup

 3. Implement Elasticity
Standardized
StandardizedTechnology
Application Stacks Stacks

Apache
WebIIS
Server

ASP.NET
Mongrel
Tomcat
App Server

ASP.NET
RailsMVC
Struts
MVC

Your Code

Log4Net
logger
Log4J
Libraries

Spring.NET
RubyGems
Spring
Packages

memcached
nHibernate
Hibernate
DB Caching

Ruby Runtime
.NET
JEE
Framework

Windows
Centos
Linux
OS

Java Stack .NET Stack RoR stack

 3. Implement Elasticity
3 Approaches to design
3 approaches to designing MDE
your AMIs

Easier to Setup
Inventory of fully baked AMIs
(Frozen/Ready made)

“Golden AMIs” with fetch on boot

(Take N’ Bake)

AMIs with JeOS and “Chef” Agent

(Made to Order)
More Control
Easier to maintain
 3. Implement Elasticity
3 Approaches to design
1. Frozen Pizza Model MDE
IIS
IIS
ASP.NET
IIS
ASP.NET MVC
ASP.NET MVC

Your Code Your Code

IIS

IIS
IIS
IIS

IIS

ASP.NET MVC ASP.NET MVC

IIS
IIS

Your Code ASP.NET MVC

Your Code

Log4Net IIS

Log4Net Log4Net

Spring.NET
Your Code
ASP.NET MVC

Log4Net
Your Code
Log4Net

Spring.NET

nHibernate nHibernate
Spring.NET
Log4Net

Spring.NET .NET
nHibernate
Spring.NET
.NET

Spring.NET
Windows Windows
.NET
nHibernate

Windows
.NET

nHibernate Windows

nHibernate .NET

Amazon EC2
.NET Windows

Windows
.NET AMI
.NET Stack
 3. Implement Elasticity
3 Approaches
“Golden
toPizza
design
Model MDE
AMIs” with fetch on
2. Papa Murphy
boot

Source Control
IIS Your Code Fetch on boot time

IIS
ASP.NET MVC
Log4Net
ASP.NET MVC nHibernate

Spring.NET
Your Code IIS

Amazon S3 IIS IIS

IIS
IIS

IIS IIS

Log4Net .NET

Windo .NET
IIS
.NET
ws
Windo .NET Windo
ws ws
Windo
IIS
Spring.NET ws

IIS
nHibernate
.NET
Amazon EC2
.NET
Windows

Windows
.NET Stack .NET AMI
 3. Implement Elasticity
3 Approaches toPizza
3. Made to Order design
Model MDE

Source Control
Apache
Your Code Cookbooks
Mongrel Recipes
ASP.NET MVC
Rails Log4Net
.NET IIS
nHibernate Chef Server
IIS

Your Code Spring.NET

Amazon S3
logger
CHEF
Agent

RubyGems Windows

memcached
CHEF Agent
Ruby Runtime
Windows
Amazon EC2
Centos
RoR Stack AMI (JeOS)
 3. Implement Elasticity
3 Approaches to design
3 approaches to designing MDE
your AMIs

Easier to Setup
Inventory of fully baked AMIs
(Frozen/Ready made)

“Golden AMIs” with fetch on boot

(Take N’ Bake)

AMIs with JeOS and “Chef” Agent

(Made to Order)
More Control
Easier to maintain
 4. Build Security in every layer
Design with Security in mind

With cloud, you lose a

little bit of physical
control but not your
ownership
Create distinct Security Groups for each Amazon EC2 cluster
Use group-based rules for controlling access between layers
Restrict external access to specific IP ranges
Encrypt data “at-rest” in Amazon S3
Encrypt data “in-transit” (SSL)
Consider encrypted file systems in EC2 for sensitive data
Rotate your AWS Credentials, Pass in as arguments encrypted
Use MultiFactor Authentication
 5. Don't fear constraints
Re-think architectural constraints

More RAM? Distribute load across machines

Shared distributed cache

Better IOPS on my database?

Multiple read-only / sharding / DB
clustering

Hardware Config
Your hardware failed or messed up config? does not match?
simply throw it away and switch to new Implement Elasticity
hardware with no additional cost

Performance
Caching at different levels (Page, Render, DB)
 6. Think Parallel
Serial and Sequential is now history

Experiment different architectures in parallel

Multi-treading and Concurrent requests to cloud services
Run parallel MapReduce Jobs
Decompose a Job into its simplest form
 6. Leverage many storage options
One size DOES NOT fit all

Amazon S3: large static objects

Amazon Cloudfront: content distribution
Amazon SimpleDB: simple data indexing/querying
Amazon EC2 local disc drive : transient data
Amazon EBS: persistent storage for any RDBMS + Snapshots on S3
Amazon RDS: RDBMS service - Automated and Managed MySQL
 6. Leverage many storage options
Which storage option to use when?

Amazon S3 + Amazon EC2 Amazon EBS Amazon Amazon RDS

CF Ephemeral SimpleDB
Store
Ideal for Storing Large Storing non- Off-instance Querying light- Storing and
write-once, persistent persistent weight attribute querying
read-many transient storage for any data structured
types of updates kind of data, Relational and
objects, Static referential
Content Data
Distribution
Ideal examples Media files, Config Data, Clusters, boot Querying, Complex
audio, video, scratch files, data, Log or Mapping, transactional
images, TempDB data of tagging, click- systems,
Backups, commercial stream logs, inventory
archives, RDBMS like metadata, management
versioning Oracle, DB2 shared-state and order
management, fulfillment
indexing systems
Not Querying, Storing Relational (joins)
recommended Searching Database logs query
for or backups,
customer data
Not Database, File Sensitive data Content OLTP, DW cube Simple
recommended Systems Distribution rollups lookups
examples
 Cloud Architecture Lessons
Best Practices

1. Design for failure and nothing fails

2. Loose coupling sets you free
3. Design for dynamism
4. Build Security in every layer
5. Don't fear constraints
6. Think Parallel
7. Leverage many storage options
 AWS community and Ecosystem
Find help, guidance, assistance when you need it

AWS Ecosystem
AWS Community
 Migrating
a Web Application
to AWS

P h o t o : L a Pe d r e ra - C a s a M i l à , B a rc e l o n a - A n t o n i o G a u d i
 Migrating your Web Application
Step by Step towards AWS

A typical Web App needs:

Compute Power
Storage capacity
Content Distribution
Database storage
Messaging
Load balancing
Monitoring
Migrating your Web Application - 1/8
Typical Web App Architecture

Database

Application Server /
Business Logic
Web Server /
Presentation Layer

Client Browser
Migrating your Web Application - 2/8
Amazon S3 for Storage

Store persistent files in Amazon S3 for

lower costs, higher reliability
Client Browser
Migrating your Web Application - 3/8
UseAmazon
Amazon
CloudFront CloudFront
for distribution

Amazon CloudFront is a content delivery network

that caches data stored in Amazon S3 across a
network of 14 edge locations around the world

Client Browser
Migrating your Web Application - 4/8
Amazon EC2 for your choice of web servers

Configure Amazon EC2 running your

choice of web server to handle all
incoming web requests.
Client Browser
Migrating your Web Application - 4/8
Scale out App servers on Amazon EC2

Configure multiple Amazon EC2

instances running your choice of
application server to process requests.

Use Availability Zones and Elastic IPs

for greater reliability and resiliency.
Client Browser Utilize Auto-scaling and Elastic LB
service
 Migrating your Web Application - 5/8
UseEBSAmazon EBSandfor
for Persistent Storage S3 forDatabase
Snapshots

Configure an Amazon EBS device to host

your existing relational database.
Snapshots can be automatically backed up
Client Browser
to Amazon S3.
Migrating your Web Application - 6/8
Use
Amazon Amazon SQS
SQS for queuing requests

SQS

Amazon SQS makes it easy to coordinate

between the web server and application
Client Browser servers.
Migrating your Web Application - 7/8
Use Amazon
Amazon SimpleDB
SimpleDB for log files, metadata

SimpleDB
SQS

Amazon SimpleDB can be used to store

metadata, logfiles, and other information
Client Browser for your site.
Migrating your Web Application - 8/8
Use Amazon SimpleDB
Monitor your Amazon EC2 instances using CloudWatch

SimpleDB
SQS

Amazon CloudWatch to monitoring your

Amazon EC2 instances
Client Browser
 Migrating your Web Application
Step by Step towards AWS

A typical Web App needs: With AWS:

Compute Power Amazon EC2

Storage capacity Amazon S3
Content Distribution Amazon CloudFront
Database storage Amazon EBS
Messaging Amazon SQS
Load balancing Amazon EC2
Monitoring Amazon CloudWatch
 Conclusions

Most Important Lesson From Our Customers:

Start small with a well-defined proof of concept
Build support and awareness in your organization
Once one application is launched others will follow…

Photo: Grand Canyon Hopi Point SunSet

 The day is not too far when applications
The day is not too far….
will cease to be aware of physical
hardware. Much like plugging in a
microwave in order to power it doesn’t
require any knowledge of electricity, one
should be able to plug in an application to
the cloud in order to receive the power it
Scalability, Security,
needsHigh availability,
to run, Fault-tolerance,
just like a utility. As an Testability and
Elasticity will be configurable properties
architect, you will of the application
manage abstract
architecture and compute,
will be an storage and network
automated andresources
intrinsic part of the
instead of physical servers. Applications
platform on which willthey are tobuilt.
continue function even if the
underlying physical hardware fails or is
removed or replaced. Applications will
adapt themselves to fluctuating demand
patterns by deploying resources
instantaneously and automatically, thereby
achieving highest utilization levels at all
times. Scalability, Security, High availability,
Fault-tolerance, Testability and Elasticity
will be configurable properties of the
application architecture and will be an
automated and intrinsic part of the platform
on which they are built.
 Thank you!

jvaria@amazon.com Twitter:@jinman
Presentation idea and template from @simon
http://aws.amazon.com