• Save
Best Practices for Architecting in the Cloud - Jeff Barr
Upcoming SlideShare
Loading in...5
×
 

Best Practices for Architecting in the Cloud - Jeff Barr

on

  • 7,518 views

 

Statistics

Views

Total Views
7,518
Views on SlideShare
5,011
Embed Views
2,507

Actions

Likes
33
Downloads
1
Comments
1

12 Embeds 2,507

http://getvoip.com 2013
http://www.scoop.it 201
http://www.educacionadistanciaulsac.com 163
http://mblog.myboulton.com 79
http://leoboulton.tumblr.com 16
https://si0.twimg.com 13
https://twimg0-a.akamaihd.net 7
https://twitter.com 5
http://plus.url.google.com 4
http://us-w1.rockmelt.com 4
http://depedmuntinlupa.virtualcampus.ph 1
http://webcache.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Hola
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Explain each service features and details here
  • Explain each service features and details here
  • Explain each service features and details here
  • 3-Tier Auto-scalable Web and Application Tier architecture with HA database (Multi-AZ Setup)
  • 1. Design for failure and nothing fails2. Loose coupling sets you free3. Implement Elasticity4. Build Security in every layer5. Don't fear constraints6. Think Parallel7. Leverage many storage options
  • 1. Design for failure and nothing fails2. Loose coupling sets you free3. Implement Elasticity4. Build Security in every layer5. Don't fear constraints6. Think Parallel7. Leverage many storage options
  • 1. Design for failure and nothing fails2. Loose coupling sets you free3. Implement Elasticity4. Build Security in every layer5. Don't fear constraints6. Think Parallel7. Leverage many storage options
  • 1. Design for failure and nothing fails2. Loose coupling sets you free3. Implement Elasticity4. Build Security in every layer5. Don't fear constraints6. Think Parallel7. Leverage many storage options
  • 1. Design for failure and nothing fails2. Loose coupling sets you free3. Implement Elasticity4. Build Security in every layer5. Don't fear constraints6. Think Parallel7. Leverage many storage options
  • 1. Design for failure and nothing fails2. Loose coupling sets you free3. Implement Elasticity4. Build Security in every layer5. Don't fear constraints6. Think Parallel7. Leverage many storage options
  • The day is not too far when applications 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 needs to run, just like a utility. As an architect, you will manage abstract compute, storage and network resources instead of physical servers. Applications will continue to 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.However, we are not there yet. Today, you can build applications in the cloud with some of these qualities by implementing the best practices highlighted in the paper. Best practices in cloud computing architectures will continue to evolve and as researchers, we should focus not only on enhancing the cloud but also on building tools, technologies and processes that will make it easier for developers and architects to plug in applications to the cloud easily.

Best Practices for Architecting in the Cloud - Jeff Barr Best Practices for Architecting in the Cloud - Jeff Barr Presentation Transcript

  • 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