Best Practices for Architecting in the Cloud - Jeff Barr

Jeff Barr Technology Evangelist jbarr@amazon.com Best Practices in Architecting for the Cloud

My BackgroundEducation: BS in Computer Science, The American University, 1985 Grad student in Digital Media University of Washington, 2010-PresentBackground: Microsoft Visual Studio team Consulting to startups and VC’s Amazon employee since 2002: Evangelist Blogger (AWS Blog) Author (Host Your Website in the Cloud) Talk show host (AWS Report)

Cloud Best Practices Whitepaper Prescriptive guidance to Cloud Architectshttp://bit.ly/aws-best-practices

Cloud Computing Attributes Why Architects love the cloud? Abstract No Servers or Hard drives but Instances and Volumes. Resources Cloud resources are fungible.On-Demand Ask for what you need, exactly when you need it. Get ridProvisioning of it when you don’t need.Scalability in Minutes Scale out or in depending on usage needs. Pay OnConsumption You stop paying for resources when you turn them off Cloud gives you access to scriptable infrastructure.Automation Allows you to automate using APIs.

The “Living and Evolving”The “Living and Evolving” Cloud Cloud AWS services and basic terminology Tools to access services Cross Service features Platform building blocks Infrastructure building blocks

AWS BuildingThe “Living and Evolving” Cloud Blocks Inherently Fault-Tolerant Fault-Tolerant Services with the right  Amazon S3  Amazon architecture Route53  Amazon  Amazon EC2 SimpleDB  Elastic Load Balancing  Amazon EBS  Amazon DynamoDB  AWS IAM  Amazon RDS  Amazon  AWS Elastic  Amazon VPC CloudFront Beanstalk  Amazon SWF  Amazon ElastiCache  Amazon SQS  Amazon EMR  Amazon SNS  Amazon  Amazon SES CloudSearch

Scalability Build a Scalable Architecture on AWS A scalable architecture is critical to take advantage of a scalable infrastructureCharacteristics of Truly Scalable Service Increasing resources results in a proportional increase in performance 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 Services1. Design for failure and nothing fails2. Loose coupling sets you free3. Implement “Elasticity”4. Build Security in every layer5. Think Parallel6. Leverage different storage options

1. Design for Failure and nothing will really fail"Everything fails, all the time"Werner Vogels, CTO Amazon.comAvoid single points of failureAssume everything fails, and design backwardsGoal: Applications should continue to function even if the underlying physicalhardware fails or is removed or replaced.

Design for Failure with AWS Tools to make your life easierUse Fault-tolerant Services as Ingredients of your AppUse Amazon Elastic Block Store (EBS) SnapshotsAuto-scaling for Auto-RecoveryMulti-AZ Data Replication and RecoveryOn-demand application provisioning in a different AZMulti-AZ Application Deployment and Data replication

2. Build Loosely Coupled Systems The looser theyre coupled, the bigger they scale Independent components Design everything as a Black Box De-couple for Hybrid models Load-balance clustersUse 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

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 configurationUse Auto ScalingUse Elastic Load Balancing on multiple layersUse configurations in SimpleDB to bootstrap instanceUse Configuration Management tools like Chef & Puppet…

3. Implement Elasticity Towards elastic architecturesResilient to reboot and re-launch:Design the system such that in the event of a failure, it is resilient enough toautomatically re-launch and restart. Forcefully fail and test (Chaos Monkey).Stateless:Extract stateful components and strive to make them stateless.Packable into an AMI:Package and deploy your application into an AMI so it can run on an AmazonEC2 instance. Run multiple instances on multiple Amazon EC2 instances.Decouple:Isolate the components using Amazon SQS. Decouple code with deploymentand configuration.

Use a Chaos MonkeyStandardized Technology Stacks Standardized Application Stacks

3. Implement ElasticityStandardized Technology Stacks Standardized Application StacksWebIIS Apache Server ASP.NET Mongrel TomcatApp ServerASP.NET MVC Struts Rails MVC Your Code Log4Net logger Log4J LibrariesSpring.NETRubyGems Spring PackagesmemcachednHibernate HibernateDB CachingRuby JEE Runtime .NETFramework Windows Centos Linux OS Java Stack .NET Stack RoR stack

3. Implement Elasticity3 Approachesdesigning your AMIs 3 approaches to to design MDE Easier to Setup Inventory of fully baked AMIs (Frozen Pizza Model) “Golden AMIs” with fetch on boot (Take N’ Bake Papa Murphy Model) AMIs with JeOS and “Chef” Agent (Made to Order Pizza Model) More Control Easier to maintain

4. Build Security in every layer Design with Security in mindIn the Cloud, Security is a SharedResponsibility and it has to beimplemented in every layer

In the cloud, Security is a Shared Responsibility Encrypt data in transitSOC 1/SSAE 16/ISAE 3402 Encrypt data at restISO 27001/2 Certification Protect your AWS CredentialsPCI DSS 2.0 Level 1-5 Rotate your keysHIPAA/SOX Compliance Infrastructure Application Secure your application, OS,FISMA A&A Low Security Security Stack and AMIsHow we secure our How can you secure yourinfrastructure application and what is your responsibility? Services Security Enforce IAM policiesWhat security options Use MFA, VPC, Leverage S3and features are available bucket policies, EC2 Securityto you? groups, EFS in EC2 Etc..

www.myphpwebsite.com (dynamic data) Amazon Route 53 media.myphpwebsite.com (DNS) (static data) Elastic Load LB # Permit HTTP(S) access to Web Balancer Layer from the Entire Internet ec2auth Web -p 80,443 -s 0.0.0.0/0 Distribution Amazon Web Server CloudFront Web Server App Server App Server Auto Scaling group : Web Tier # Permit Web Layer access to App Amazon EC2 Layer ec2auth App -p 8000 –o Web Memcache Memcache Tomcat # Permit App Layer access to DB ec2auth DB -p 3209 –o App Cache Tier # Permit admin access SSH to all Amazon S3 RDS Buckets three layers Master # First allow connection from office to Web tier, and from there to the other layers Availability Zone #1ec2auth Web -p 22 -s <for example, network block of your office> RDS ec2auth App -p 22 -o Web Slave Availability Zone #2 ec2auth DB -p 22 -o Web

5. Think Parallel Serial and Sequential is now historyExperiment with different architectures in parallelMulti-threading and Concurrent requests to cloud servicesRun parallel MapReduce Jobs on Amazon Elastic MapReduceUse Elastic Load Balancing to distribute load across multiple serversDecompose a Job into its simplest form

5. Think Parallel This is where AWS really shines.. Amazon Cluster Elastic Spot Expand/ Hadoop Elastic Compute Instances Shrink Super MapReduce HPC computerDistributed On-demand Each VM = Cost savings Expand or Big DataProcessing Infrastructure 2 Xeon due to lower Shrink a powerFramework (Cloud) + “Nehalem” “Spot price” running house Automation Quad-core (Time-insensitive cluster tasks) 10G Ethernet 2 GPGPUs

6. Leverage many storage options Use Scalable IngredientsAmazon S3: large static objectsAmazon Cloudfront: content distributionAmazon SimpleDB: simple data indexing/queryingAmazon EC2 local disc drive : transient dataAmazon EBS: persistent storage for any RDBMS + Snapshots on S3Amazon 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 CloudFront Ephemeral DynamoDB & Store SimpleDBIdeal 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 (SimpleDB) structured types of updates kind of data Relational and objects, Static Highly scalable referential Content applications Data Distribution (DynamoDB)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 systemsNot Querying, Storing Relational (joins)recommended Searching Database logs queryfor or backups, customer dataNot Database, File Sensitive data Content OLTP, DW cube Simplerecommended Systems Distribution rollups lookupsexamples

Cloud Architecture Lessons Best Practices1. Design for failure and nothing fails2. Loose coupling sets you free3. Implement Elasticity4. Build Security in every layer5. Think Parallel6. Leverage many storage options

Additional Info.. AWS Architecture Center - http://aws.amazon.com/architecture AWS Premium Support - http://aws.amazon.com/premiumsupport AWS Blog – http://aws.amazon.com/blogPhoto: Grand Canyon Hopi Point SunSet

Thank you!jbarr@amazon.com Twitter: @jeffbarr

http://aws.amazon.com

http://www.scoop.it	167
http://www.educacionadistanciaulsac.com	158
http://mblog.myboulton.com	78
https://si0.twimg.com	13
https://twimg0-a.akamaihd.net	7
http://us-w1.rockmelt.com	4
http://depedmuntinlupa.virtualcampus.ph	1
http://webcache.googleusercontent.com	1

Best Practices for Architecting in the Cloud - Jeff Barr

by Amazon Web Services on Aug 01, 2012

Accessibility

Categories

Upload Details

Usage Rights

8 Embeds 429

Statistics