Best Practices in Architecting for the Cloud Webinar - Jinesh Varia

  • 4,672 views
Uploaded on

This deck discusses general best practices of architecting applications in the cloud. It was used in May 2011 Architecture Center webinars. For more information, read the whitepaper available at …

This deck discusses general best practices of architecting applications in the cloud. It was used in May 2011 Architecture Center webinars. For more information, read the whitepaper available at http://bit.ly/aws-best-practices

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
4,672
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
224
Comments
1
Likes
18

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Jinesh Varia Technology Evangelist jvaria@amazon.comMatt Tavis Solution Architect mtavis@amazon.com Best Practices inArchitecting for the Cloud
  • 2. Masteringthe Tradeoffs
  • 3. Cloud Best Practices Whitepaper Prescriptive guidance to Cloud Architectshttp://bit.ly/aws-best-practices
  • 4. 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 perconsumption You stop paying for resources when you turn them off Cloud gives you access to scriptable infrastructure.Automation Allows you to automate using APIs.
  • 5. 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
  • 6. 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
  • 7. 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.
  • 8. Design for Failure with AWS Tools to make your life easierUse Fault-tolerant Services as Ingredients of your App
  • 9. www.example.com (dynamic traffic) media.example.com (static load) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Web Server Logs Amazon Machine Buckets Static Data Image App Server Amazon S3 Amazon EC2 Instance Auto Scaling Group Dynamic Data Amazon EC2 Instance EBS SnapshotsAvailability Zone #1
  • 10. www.example.com (dynamic traffic) media.example.com (static load) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Amazon SNS Web Server (notifications) Logs Amazon Machine Buckets Static Data Image App Server Amazon S3 Amazon EC2 Instance Amazon SimpleDB(Catalog and Config data) Auto Scaling Group Dynamic Data Amazon EC2 Amazon CloudWatch Instance (Monitoring) EBS Snapshots Availability Zone #1
  • 11. Design for Failure with AWS Tools to make your life easierUse Fault-tolerant Services as Ingredients of your AppUse Amazon Elastic Block Store (EBS) Snapshots
  • 12. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Web Server Logs Amazon Machine Buckets Static Data Image App Server Amazon S3 Amazon EC2 Instance Auto Scaling Group Amazon EC2 Instance EBS SnapshotsAvailability Zone #1
  • 13. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Web Server Logs Amazon Machine Buckets Static Data Image App Server Amazon S3 Amazon EC2 Instance Auto Scaling GroupAvailability Zone #1
  • 14. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Web Server Logs Amazon Machine Buckets Static Data Image App Server Amazon S3 Amazon EC2 Instance Auto Scaling Group Amazon EC2 Instance EBS SnapshotsAvailability Zone #1
  • 15. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Web Server Logs Amazon Machine Buckets Static Data Image App Server Amazon S3 Amazon EC2 Instance Auto Scaling Group Amazon EC2 Instance EBS SnapshotsAvailability Zone #1
  • 16. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Web Server LogsAmazon Machine Buckets Static Data Image App Server Amazon S3 Amazon EC2 Instance Auto Scaling Group Amazon EC2 Instance EBS Snapshots Availability Zone #1
  • 17. 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-Recovery
  • 18. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Web Server LogsAmazon Machine Buckets Static Data Image App Server Amazon S3 Amazon EC2 Instance Auto Scaling Group Amazon EC2 Instance EBS Snapshots Availability Zone #1
  • 19. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront LogsAmazon Machine Buckets Static Data Image Amazon S3 Auto Scaling Group Amazon EC2 Instance EBS Snapshots Availability Zone #1
  • 20. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Web Server Logs Static Data Buckets App Server Amazon S3 Amazon EC2 Instance Auto Scaling Group Amazon EC2 Instance EBS SnapshotsAvailability Zone #1
  • 21. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Web Server Web Server Logs Static Data Buckets App Server App Server Amazon S3 Amazon EC2 Amazon EC2 Instance Instance Auto Scaling Group Amazon EC2 Instance EBS SnapshotsAvailability Zone #1
  • 22. 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 Recovery
  • 23. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Amazon Distribution CloudFront Web Server Web Server Logs Static Data Buckets App Server App Server Amazon S3 Amazon EC2 Amazon EC2 Instance Instance Auto Scaling Group Amazon EC2 Instance EBS SnapshotsAvailability Zone #1 Amazon EC2 Instance EBS Availability Zone #2
  • 24. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS)Elastic Load LBBalancer Amazon Distribution CloudFront Web Server Web Server Logs Static Data Buckets App Server App Server Amazon S3 Amazon EC2 Amazon EC2 Instance Instance Auto Scaling Group SnapshotsAvailability Zone #1 Amazon EC2 Instance EBS Availability Zone #2
  • 25. 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 AZ
  • 26. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Distribution Amazon CloudFront Logs Buckets Web Server Web Server Static Data App Server App Server Amazon S3 Amazon EC2 Amazon EC2 Instance Instance Auto Scaling Group Amazon EC2 Amazon EC2 Instance Instance Synchronous EBS Replication EBS SnapshotsAvailability Zone #1 Availability Zone #2
  • 27. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Distribution Amazon CloudFront Logs Buckets Static Data Amazon S3 Auto Scaling Group Amazon EC2 Amazon EC2 Instance Instance Synchronous EBS Replication EBS SnapshotsAvailability Zone #1 Availability Zone #2
  • 28. www.example.com (dynamic data) media.example.com (static data) Amazon Route 53 (DNS) Elastic Load LB Balancer Distribution Amazon CloudFront Logs Buckets Web Server Web Server Static Data App Server App Server Amazon S3 Amazon EC2 Amazon EC2 Instance Instance Auto Scaling Group Amazon EC2 Amazon EC2 Instance Instance Synchronous EBS Replication EBS SnapshotsAvailability Zone #1 Availability Zone #2
  • 29. 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
  • 30. www.example.com (dynamic data) Amazon Route 53 media.example.com (DNS) (static data) Elastic Load Balancer LB Auto Scaling group : Web Tier Auto Scaling group : Web Tier WebAuto Scaling group : Server Server Web Web Tier Web Server Web Server Web Server Web Server App Server Distribution AppWeb Server AppWeb Server Server Server App Server AppWeb Server App Server Server App Server App Server App Server Amazon Amazon EC2 CloudFront Amazon EC2 Memcache Memcache Memcache Memcache Tomcat Tomcat Memcache Memcache Tomcat Cache Tier Cache Tier Cache Tier DB Multi-AZ Buckets Amazon RDS Slave Master Read DB Replica Slave MasterAvailability Zone #1 Availability Zone #2 Amazon S3 Availability Zone #3
  • 31. www.example.com (dynamic data) Amazon Route 53 media.example.com (DNS) (static data) Elastic Load Balancer LB Auto Scaling group : Web Tier Auto Scaling group : Web Tier Web Server Web Server App Server App Server Distribution Web Server Web Server App Server App Server Amazon CloudFront Amazon EC2 Memcache Memcache Tomcat Memcache Memcache Tomcat Cache Tier Cache Tier Multi-AZ Buckets Slave DB Slave Master Availability Zone #2 Amazon S3Availability Zone #3
  • 32. www.example.com (dynamic data) Amazon Route 53 media.example.com (DNS) (static data) Elastic Load Balancer LB Auto Scaling group : Web Tier Auto Scaling group : Web Tier Web Server Web Server Web Server Web Server Distribution Web Server Web Server App Server App Server Web Server Web Server App Server App Server App Server App Server App Server App Server Amazon CloudFront Amazon EC2 Memcache Memcache Tomcat Memcache Memcache Tomcat Cache Tier Cache Tier Multi-AZ Buckets Slave DB Slave Master Availability Zone #2 Amazon S3Availability Zone #3
  • 33. 2. Build Loosely Coupled Systems The looser theyre coupled, the bigger they scale Independent components Design everything as a Black Box De-coupling 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
  • 34. 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-scaling (Free)Use Elastic Load Balancing on multiple layersUse configurations in SimpleDB to bootstrap instanceUse Configuration Management tools like Chef, Puppet, Pallet..
  • 35. 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.Stateless:Extract stateful components out and make them statelessPackable into an AMI:Package and deploy your application into an AMI so it can run on an AmazonEC2 instance. Try to run multiple instances of the application on one EC2instance, if needed. Run multiple instances on multiple Amazon EC2instances.Decouple:Isolate the components using Amazon SQS. Decouple code with deploymentand configuration.
  • 36. 3. Implement Elasticity Standardized Technology Stacks Standardized Application Stacks ApacheWeb Server Apache IIS Apache MongrelApp Server Tomcat ASP.NET Mongrel Rails MVC Struts ASP.NET MVC Rails Your Code Your Code Your Code Your Code logger Libraries Log4J Log4Net loggerRubyGems Packages Spring Spring.NET RubyGemsmemcachedDB Caching Hibernate nHibernate memcachedRuby Runtime Framework JEE .NET Ruby Runtime Centos OS Linux Windows Centos Java Stack .NET Stack RoR stack
  • 37. 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
  • 38. 3. Implement Elasticity 3 ApproachesPizza design MDE 1. Frozen to Model Apache Apache Tomcat Tomcat Struts Struts IIS IISYour Code Your Code IIS ASP.NET MVC IIS IIS IIS ASP.NET MVC IIS Your Code ASP.NET MVC Your Code IIS Log4Net Log4Net Your Code ASP.NET MVC Log4J Spring.NET Log4Net Spring.NET Log4J Your Code nHibernate nHibernate Spring.NET Log4Net .NET .NET nHibernate Spring.NET Windows Windows Spring .NET nHibernate Windows .NET Spring Windows HibernateHibernate Amazon EC2 JEE JEE Linux Linux .NET Stack Java AMI
  • 39. “GoldenImplement on boot 3. AMIs” with fetch Elasticity 3 Approaches to design MDE 2. Take N Bake Pizza Model Apache Your Code Fetch on boot time Source Control Tomcat Struts Struts Log4J SpringYour Code IIS Amazon S3 IIS IIS IIS IIS IIS IIS Log4J .NET Windo .NET ws IIS .NET Windo .NET Windo Apache ws ws Windo Spring ws TomcatHibernate Hibernate JEE Amazon EC2 JEE Linux LinuxJava Stack Java AMI
  • 40. 3. Implement Elasticity 3 Approaches toPizza Model MDE 3. Made to Order design Apache Your Code Cookbooks Tomcat Source Control Recipes Struts Apache Chef ServerYour Code Struts Tomcat Log4J Hibernat Log4J e Spring CHEF Agent Spring Amazon S3 WindowsHibernate CHEF Agent JEE Linux Amazon EC2 LinuxJava Stack AMI (JeOS)
  • 41. 3. Implement Elasticity3 Approachesdesigning your AMIs 3 approaches to to design MDE 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
  • 42. 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
  • 43. In the cloud, Security is a Shared Responsibility Encrypt data in transitSAS 70 Type II Audit 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..
  • 44. www.example.com (dynamic data) Amazon Route 53 media.example.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
  • 45. 5. Think Parallel Serial and Sequential is now historyExperiment different architectures in parallelMulti-treading 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
  • 46. 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
  • 47. 6. Leverage many storage options Which storage option to use when? Amazon S3 + Amazon EC2 Amazon EBS Amazon Amazon RDS CF Ephemeral SimpleDB StoreIdeal 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 DistributionIdeal 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
  • 48. 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
  • 49. 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
  • 50. Thank you!jvaria@amazon.com Twitter: @jinman
  • 51. http://aws.amazon.com