Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
 Jinesh Varia           Technology Evangelist         jvaria@amazon.comArchitecturalDesign Patterns in Cloud Computing
They sent me here to talkBut I am here to listenPlease Send Feedbackjvaria@amazon.comTwitter: @jinman
Cloud Best Practices WhitepaperPrescriptive guidance to Cloud ArchitectsJust Google for “Cloud Best Practices” to find the linkhttp://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf
Cloud Computing AttributesWhat makes the Cloud so attractiveAbstract ResourcesFocus on your needs, not on hardware specs. As your needs change, so should your resources.On-Demand ProvisioningAsk for what you need, exactly when you need it.  Get rid of it when you don’t needScalability in minutesScale out or in depending on usage needs.Pay per consumptionNo contracts or long-term commitments.Pay only for what you use.Efficiency of ExpertsUtilize the skills, knowledge and resources of experts.
The “Living and Evolving” CloudThe “Living and Evolving” CloudAWS services and basic terminologyMost Applications Need:ComputeStorageMessagingPaymentDistributionScaleAnalyticsYour ApplicationAmazon RDSAmazon CloudFrontAmazon SQS QueuesAmazon SimpleDB DomainsPayment : Amazon FPS/ DevPayAmazon Elastic MapReduceJobFlowsAmazon SNS TopicsAmazon S3 Objects and BucketsAuto-ScalingElastic LBCloudWatchAmazon EC2 Instances(On-Demand, Reserved, Spot)EBSVolumesSnapshotsAmazon Virtual Private CloudAmazon WorldWidePhysical Infrastructure (Geographical Regions, Availability Zones, Edge Locations)
“At Amazon, Every Day is a Launch Day”The “Living and Evolving” CloudNew Features and Services» Amazon EC2 with Windows Server     2008, Spot Instances,
Boot from Amazon EBS» Amazon CloudFront Streaming» Amazon VPC enters Unlimited Beta» AWS Region in Northern California» International Support for AWS     Import/Export» AWS Multi-Factor Authentication» Virtual Private Cloud» Lower Reserved Instance Pricing» Reserved Instances in EU Region» Elastic MapReduce» SQS in EU Region» Amazon RDS» High-Memory Instances» Lower EC2 Pricing» New SimpleDB Features» FPS General Availability» Amazon SNS» AWS Security Center2009Jan2010JanJulSepOctDecAugNovFebMarAprJunMayFebMar» Amazon EC2 with Windows» Amazon EC2 in EU Region» AWS Toolkit for Eclipse» Amazon EC2 Reserved    Instances» Amazon CloudFront    Private Content» SAS70 Type II Audit» AWS SDK for .NET» Amazon Elastic MapReduce    in Europe» Amazon EC2 Reserved Instances     with Windows, Extra Large High     Memory Instances» Amazon S3 Versioning Feature» Consolidated Billing for AWS» Lower pricing for Outbound Data     Transfer» AWS Import/Export» New CloudFront Feature» Monitoring, Auto Scaling  & Elastic Load Balancing» EBS Shared Snapshots» SimpleDB in EU Region» Monitoring, Auto Scaling &    Elastic Load Balancing in EU » Lower pricing tiers for    Amazon CloudFront» AWS Management Console
ScalabilityBuild Scalable Architecture on AWSA scalable architecture is critical to take advantage of a scalable infrastructureCharacteristics of Truly Scalable ServiceIncreasing resources results in a proportional increase in performanceA scalable service is capable of handling heterogeneityA scalable service is operationally efficientA scalable service is resilientA scalable service becomes more cost effective when it grows
Cloud Architecture Lessonsusing Amazon Web Services1. Design for failure and nothing fails2. Loose coupling sets you free3. Implement “Elasticity”4. Build Security in every layer5. Don't fear constraints6. Think Parallel7. Leverage different storage options
1. Design for Failureand 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 physical hardware fails or is removed or replaced.
Design for Failure with AWSTools to make your life easierUse Elastic IP addresses for consistent and re-mappable routesUse multiple Amazon EC2 Availability Zones (AZs)Create multiple database slaves across AZsUse real-time monitoring (Amazon CloudWatch)Use Amazon Elastic Block Store (EBS) for persistent file systems
YourWebsite.comEC2 Instance AEC2 Instance BMASTERSLAVEMASTERReplicationLOG VolumeDATA VolumeDATA Volume
YourWebTwoDotZeroName.comAvailability Zone 2EC2 Instance BEC2 Instance AAvailability Zone 1MASTERSLAVEMASTERReplicationDATA VolumeDATA VolumeLOG VolumeLOG VolumeAmazon S3
www.YourWebsite.comStaging.YourWebsite.comElastic IP183.12.43.11Dynamic IP172.0.1.13Production instanceApp Version 1.1StaginginstanceApp Version 1.2Database
2. Build Loosely Coupled SystemsThe looser they're coupled, the bigger they scaleIndependent componentsDesign everything as a Black BoxDe-coupling for Hybrid modelsLoad-balance clustersUse Amazon SQS as BuffersTight CouplingController AController BController CQQQLoose Coupling using QueuesController AController BController C
MyWebSite.comExterior Firewall Hardware or Software Solution to open standard Ports (80, 443)Web Load BalancerHardware or Software solution to distribute traffic over web serversLBWeb TierFleet of machines handling HTTP requests.Web ServerWeb ServerBackend Firewall Limits access to application tier from web tierLBApp Load BalancerHardware or Software solution to spread traffic over app servers App Server Tier Fleet of machines handling Application specific workloadsCaching  server machines can be implemented at this layerApp ServerApp ServerApp serverBackups on Tapes Periodic backups stored on Tapes usually managed by 3rd party at their siteData Tier Database Server machines with master and local running separately, Network storage for Static objects MySQLMasterMySQL(Slave)Tapes
MyWebSite.comDNSElastic Load BalancerELB to  spread traffic to Web Server Auto-scaling groupsLBELB: Web TierExterior Firewall no longer needed because EC2 instances are controlled with Security GroupsAvailability Zone #1Availability Zone 2Auto-scaling group : Web TierAuto-scaling group : Web TierAvailability Zone #nWeb ServerWeb ServerWeb ServerWeb ServerAuto-scaling Web TierGroup of EC2 instances  handling HTTP requests.Edge CachingHigh Volume Static Content is edge cached using CloudFrontBackend Firewall no longer neededSLBApp Server Load BalancerSoftware LB (e.g. HAProxy) on EC2 instance to spread traffic over app server clusterSLBAuto-scaling group : App TierAuto-scaling group : App TierAuto-scaling App Tier Group of EC2 instances  running the actual app.  Instances belong to Auto-scaling group.Caching  servers  instances can be implemented at this layerApp ServerApp ServerApp ServerApp ServerTomcatTomcatCloudFrontAmazon S3RDSSlaveRDSMasterRDSSlaveDB Tier MySQL RDS DB Instances (master, local slave, x-AZ slave for failover) , Automated backups to S3 all managed by AWSBackups Amazon S3 used for storing  Static Objects and Backups
3. Implement ElasticityElasticity is fundamental property of the CloudDon’t assume healthor fixed location of componentsUse designs that are resilient to reboot and re-launchBootstrapyour 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 instance
3. Implement ElasticityManaged Development EnvironmentAutomate everythingSaaSPaidAMIWeb 2.0 Marketing CampaignDev/TestAppsProdManaged Development EnvironmentAutomatedDeployment EnvironmentCloud-powered Software Lifecycle managementAWS CloudAWS CloudAWS CloudISV  DepartmentEnterprise IT
3. Implement ElasticityStandardized Technology StacksStandardized Application StacksApacheIISApacheTomcatASP.NETMongrelWeb ServerStrutsASP.NET MVCRailsApp ServerYour CodeYour CodeYour CodeMVCLog4JLog4NetloggerYour CodeSpring	Spring.NET	RubyGemsLibrariesHibernatenHibernatememcachedPackagesJEE.NET Ruby RuntimeDB CachingLinuxWindowsCentosFrameworkOSJava Stack.NET StackRoR stack
3. Implement Elasticity3 Approaches to design MDE3 approaches to designing your AMIsEasier to SetupInventory 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 ControlEasier to maintain
3. Implement Elasticity3 Approaches to design MDE1. Frozen Pizza ModelIISIISIISIISIISIISASP.NETIISIISIISIISIISASP.NET MVCASP.NET MVCASP.NET MVCASP.NET MVCASP.NET MVCASP.NET MVCYour CodeYour CodeYour CodeYour CodeYour CodeYour CodeLog4NetLog4NetLog4NetLog4NetLog4NetLog4NetSpring.NET	Spring.NET	Spring.NET	Spring.NET	Spring.NET	Spring.NET	nHibernatenHibernatenHibernatenHibernatenHibernatenHibernate.NET .NET .NET .NET .NET .NET Amazon EC2WindowsWindowsWindowsWindowsWindowsWindows.NET AMI.NET Stack
3. Implement Elasticity3 Approaches to design MDE“Golden AMIs” with fetch on boot   2. Papa Murphy Pizza ModelIISIISSource ControlFetch  on boot timeYour CodeASP.NET MVCAmazon S3Your CodeASP.NET MVCLog4NetnHibernateLog4NetSpring.NET	Spring.NET	IISIISIISIISIISnHibernateIISIISIISIISIIS.NET .NET .NET .NET .NET .NET WindowsAmazon EC2WindowsWindowsWindowsWindowsWindows.NET AMI.NET Stack
3. Implement Elasticity3 Approaches to design MDE3. Made to Order Pizza Model ApacheMongrelSource ControlRailsYour CodeCookbooks RecipesYour CodeAmazon S3ASP.NET MVCLog4Net.NET IISChef ServernHibernateloggerIISSpring.NET	RubyGemsmemcachedRuby RuntimeCHEF AgentCHEF AgentCentosWindowsWindowsAmazon EC2AMI (JeOS)RoR Stack
3. Implement Elasticity3 Approaches to design MDE3 approaches to designing your AMIsEasier to SetupInventory 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 ControlEasier to maintain
4. Build Security in every layerDesign with Security in mindWith cloud, you lose a little bit of physical control but not your ownershipCreate distinct Security Groups for each Amazon EC2 clusterUse group-based rules for controlling access between layersRestrict external access to specific IP rangesEncrypt data “at-rest” in Amazon S3Encrypt data “in-transit” (SSL)Consider encrypted file systems in EC2 for sensitive dataRotate your AWS Credentials, Pass in as arguments encrypted Use MultiFactor Authentication
5. Don't fear constraintsRe-think architectural constraintsMore RAM? Distribute load across machinesShared distributed cacheBetter IOPS on my database? Multiple read-only / sharding / DB clusteringHardware Config does not match?Implement ElasticityYour hardware failed or messed up config?simply throw it away and switch to new hardware with no additional costPerformanceCaching at different levels (Page, Render, DB)
6. Think ParallelSerial and Sequential is now historyExperiment different architectures in parallelMulti-treading and Concurrent requests to cloud servicesRun parallel MapReduce JobsUse Elastic Load Balancing to distribute load across multiple servers Decompose a Job into its simplest form
6. Leverage many storage optionsOne size DOES NOT fit allAmazon 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 optionsWhich storage option to use when?
Cloud Architecture LessonsBest Practices1. 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
AWS community and EcosystemFind help, guidance, assistance when you need itAWS EcosystemAWS Community
Migratinga Web Applicationto AWSPhoto: La Pedrera - Casa Milà, Barcelona  -  Antonio Gaudi
Migrating your Web ApplicationStep by Step towards AWSA typical Web App needs:Compute PowerStorage capacityContent DistributionDatabase storageMessagingLoad balancingMonitoring
Migrating your Web Application - 1/8Typical Web App ArchitectureDatabaseApplication Server /Business LogicWeb Server /Presentation LayerClient Browser
Migrating your Web Application - 2/8Amazon S3 for StorageStore persistent files in Amazon S3 for lower costs, higher reliabilityClient Browser

More Related Content

Architecting for the Cloud: Best Practices

  • 1. Jinesh Varia Technology Evangelist jvaria@amazon.comArchitecturalDesign Patterns in Cloud Computing
  • 2. They sent me here to talkBut I am here to listenPlease Send Feedbackjvaria@amazon.comTwitter: @jinman
  • 3. Cloud Best Practices WhitepaperPrescriptive guidance to Cloud ArchitectsJust Google for “Cloud Best Practices” to find the linkhttp://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf
  • 4. Cloud Computing AttributesWhat makes the Cloud so attractiveAbstract ResourcesFocus on your needs, not on hardware specs. As your needs change, so should your resources.On-Demand ProvisioningAsk for what you need, exactly when you need it. Get rid of it when you don’t needScalability in minutesScale out or in depending on usage needs.Pay per consumptionNo contracts or long-term commitments.Pay only for what you use.Efficiency of ExpertsUtilize the skills, knowledge and resources of experts.
  • 5. The “Living and Evolving” CloudThe “Living and Evolving” CloudAWS services and basic terminologyMost Applications Need:ComputeStorageMessagingPaymentDistributionScaleAnalyticsYour ApplicationAmazon RDSAmazon CloudFrontAmazon SQS QueuesAmazon SimpleDB DomainsPayment : Amazon FPS/ DevPayAmazon Elastic MapReduceJobFlowsAmazon SNS TopicsAmazon S3 Objects and BucketsAuto-ScalingElastic LBCloudWatchAmazon EC2 Instances(On-Demand, Reserved, Spot)EBSVolumesSnapshotsAmazon Virtual Private CloudAmazon WorldWidePhysical Infrastructure (Geographical Regions, Availability Zones, Edge Locations)
  • 6. “At Amazon, Every Day is a Launch Day”The “Living and Evolving” CloudNew Features and Services» Amazon EC2 with Windows Server 2008, Spot Instances,
  • 7. Boot from Amazon EBS» Amazon CloudFront Streaming» Amazon VPC enters Unlimited Beta» AWS Region in Northern California» International Support for AWS Import/Export» AWS Multi-Factor Authentication» Virtual Private Cloud» Lower Reserved Instance Pricing» Reserved Instances in EU Region» Elastic MapReduce» SQS in EU Region» Amazon RDS» High-Memory Instances» Lower EC2 Pricing» New SimpleDB Features» FPS General Availability» Amazon SNS» AWS Security Center2009Jan2010JanJulSepOctDecAugNovFebMarAprJunMayFebMar» Amazon EC2 with Windows» Amazon EC2 in EU Region» AWS Toolkit for Eclipse» Amazon EC2 Reserved Instances» Amazon CloudFront Private Content» SAS70 Type II Audit» AWS SDK for .NET» Amazon Elastic MapReduce in Europe» Amazon EC2 Reserved Instances with Windows, Extra Large High Memory Instances» Amazon S3 Versioning Feature» Consolidated Billing for AWS» Lower pricing for Outbound Data Transfer» AWS Import/Export» New CloudFront Feature» Monitoring, Auto Scaling & Elastic Load Balancing» EBS Shared Snapshots» SimpleDB in EU Region» Monitoring, Auto Scaling & Elastic Load Balancing in EU » Lower pricing tiers for Amazon CloudFront» AWS Management Console
  • 8. ScalabilityBuild Scalable Architecture on AWSA scalable architecture is critical to take advantage of a scalable infrastructureCharacteristics of Truly Scalable ServiceIncreasing resources results in a proportional increase in performanceA scalable service is capable of handling heterogeneityA scalable service is operationally efficientA scalable service is resilientA scalable service becomes more cost effective when it grows
  • 9. Cloud Architecture Lessonsusing Amazon Web Services1. Design for failure and nothing fails2. Loose coupling sets you free3. Implement “Elasticity”4. Build Security in every layer5. Don't fear constraints6. Think Parallel7. Leverage different storage options
  • 10. 1. Design for Failureand 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 physical hardware fails or is removed or replaced.
  • 11. Design for Failure with AWSTools to make your life easierUse Elastic IP addresses for consistent and re-mappable routesUse multiple Amazon EC2 Availability Zones (AZs)Create multiple database slaves across AZsUse real-time monitoring (Amazon CloudWatch)Use Amazon Elastic Block Store (EBS) for persistent file systems
  • 12. YourWebsite.comEC2 Instance AEC2 Instance BMASTERSLAVEMASTERReplicationLOG VolumeDATA VolumeDATA Volume
  • 13. YourWebTwoDotZeroName.comAvailability Zone 2EC2 Instance BEC2 Instance AAvailability Zone 1MASTERSLAVEMASTERReplicationDATA VolumeDATA VolumeLOG VolumeLOG VolumeAmazon S3
  • 14. www.YourWebsite.comStaging.YourWebsite.comElastic IP183.12.43.11Dynamic IP172.0.1.13Production instanceApp Version 1.1StaginginstanceApp Version 1.2Database
  • 15. 2. Build Loosely Coupled SystemsThe looser they're coupled, the bigger they scaleIndependent componentsDesign everything as a Black BoxDe-coupling for Hybrid modelsLoad-balance clustersUse Amazon SQS as BuffersTight CouplingController AController BController CQQQLoose Coupling using QueuesController AController BController C
  • 16. MyWebSite.comExterior Firewall Hardware or Software Solution to open standard Ports (80, 443)Web Load BalancerHardware or Software solution to distribute traffic over web serversLBWeb TierFleet of machines handling HTTP requests.Web ServerWeb ServerBackend Firewall Limits access to application tier from web tierLBApp Load BalancerHardware or Software solution to spread traffic over app servers App Server Tier Fleet of machines handling Application specific workloadsCaching server machines can be implemented at this layerApp ServerApp ServerApp serverBackups on Tapes Periodic backups stored on Tapes usually managed by 3rd party at their siteData Tier Database Server machines with master and local running separately, Network storage for Static objects MySQLMasterMySQL(Slave)Tapes
  • 17. MyWebSite.comDNSElastic Load BalancerELB to spread traffic to Web Server Auto-scaling groupsLBELB: Web TierExterior Firewall no longer needed because EC2 instances are controlled with Security GroupsAvailability Zone #1Availability Zone 2Auto-scaling group : Web TierAuto-scaling group : Web TierAvailability Zone #nWeb ServerWeb ServerWeb ServerWeb ServerAuto-scaling Web TierGroup of EC2 instances handling HTTP requests.Edge CachingHigh Volume Static Content is edge cached using CloudFrontBackend Firewall no longer neededSLBApp Server Load BalancerSoftware LB (e.g. HAProxy) on EC2 instance to spread traffic over app server clusterSLBAuto-scaling group : App TierAuto-scaling group : App TierAuto-scaling App Tier Group of EC2 instances running the actual app. Instances belong to Auto-scaling group.Caching servers instances can be implemented at this layerApp ServerApp ServerApp ServerApp ServerTomcatTomcatCloudFrontAmazon S3RDSSlaveRDSMasterRDSSlaveDB Tier MySQL RDS DB Instances (master, local slave, x-AZ slave for failover) , Automated backups to S3 all managed by AWSBackups Amazon S3 used for storing Static Objects and Backups
  • 18. 3. Implement ElasticityElasticity is fundamental property of the CloudDon’t assume healthor fixed location of componentsUse designs that are resilient to reboot and re-launchBootstrapyour 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 instance
  • 19. 3. Implement ElasticityManaged Development EnvironmentAutomate everythingSaaSPaidAMIWeb 2.0 Marketing CampaignDev/TestAppsProdManaged Development EnvironmentAutomatedDeployment EnvironmentCloud-powered Software Lifecycle managementAWS CloudAWS CloudAWS CloudISV DepartmentEnterprise IT
  • 20. 3. Implement ElasticityStandardized Technology StacksStandardized Application StacksApacheIISApacheTomcatASP.NETMongrelWeb ServerStrutsASP.NET MVCRailsApp ServerYour CodeYour CodeYour CodeMVCLog4JLog4NetloggerYour CodeSpring Spring.NET RubyGemsLibrariesHibernatenHibernatememcachedPackagesJEE.NET Ruby RuntimeDB CachingLinuxWindowsCentosFrameworkOSJava Stack.NET StackRoR stack
  • 21. 3. Implement Elasticity3 Approaches to design MDE3 approaches to designing your AMIsEasier to SetupInventory 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 ControlEasier to maintain
  • 22. 3. Implement Elasticity3 Approaches to design MDE1. Frozen Pizza ModelIISIISIISIISIISIISASP.NETIISIISIISIISIISASP.NET MVCASP.NET MVCASP.NET MVCASP.NET MVCASP.NET MVCASP.NET MVCYour CodeYour CodeYour CodeYour CodeYour CodeYour CodeLog4NetLog4NetLog4NetLog4NetLog4NetLog4NetSpring.NET Spring.NET Spring.NET Spring.NET Spring.NET Spring.NET nHibernatenHibernatenHibernatenHibernatenHibernatenHibernate.NET .NET .NET .NET .NET .NET Amazon EC2WindowsWindowsWindowsWindowsWindowsWindows.NET AMI.NET Stack
  • 23. 3. Implement Elasticity3 Approaches to design MDE“Golden AMIs” with fetch on boot 2. Papa Murphy Pizza ModelIISIISSource ControlFetch on boot timeYour CodeASP.NET MVCAmazon S3Your CodeASP.NET MVCLog4NetnHibernateLog4NetSpring.NET Spring.NET IISIISIISIISIISnHibernateIISIISIISIISIIS.NET .NET .NET .NET .NET .NET WindowsAmazon EC2WindowsWindowsWindowsWindowsWindows.NET AMI.NET Stack
  • 24. 3. Implement Elasticity3 Approaches to design MDE3. Made to Order Pizza Model ApacheMongrelSource ControlRailsYour CodeCookbooks RecipesYour CodeAmazon S3ASP.NET MVCLog4Net.NET IISChef ServernHibernateloggerIISSpring.NET RubyGemsmemcachedRuby RuntimeCHEF AgentCHEF AgentCentosWindowsWindowsAmazon EC2AMI (JeOS)RoR Stack
  • 25. 3. Implement Elasticity3 Approaches to design MDE3 approaches to designing your AMIsEasier to SetupInventory 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 ControlEasier to maintain
  • 26. 4. Build Security in every layerDesign with Security in mindWith cloud, you lose a little bit of physical control but not your ownershipCreate distinct Security Groups for each Amazon EC2 clusterUse group-based rules for controlling access between layersRestrict external access to specific IP rangesEncrypt data “at-rest” in Amazon S3Encrypt data “in-transit” (SSL)Consider encrypted file systems in EC2 for sensitive dataRotate your AWS Credentials, Pass in as arguments encrypted Use MultiFactor Authentication
  • 27. 5. Don't fear constraintsRe-think architectural constraintsMore RAM? Distribute load across machinesShared distributed cacheBetter IOPS on my database? Multiple read-only / sharding / DB clusteringHardware Config does not match?Implement ElasticityYour hardware failed or messed up config?simply throw it away and switch to new hardware with no additional costPerformanceCaching at different levels (Page, Render, DB)
  • 28. 6. Think ParallelSerial and Sequential is now historyExperiment different architectures in parallelMulti-treading and Concurrent requests to cloud servicesRun parallel MapReduce JobsUse Elastic Load Balancing to distribute load across multiple servers Decompose a Job into its simplest form
  • 29. 6. Leverage many storage optionsOne size DOES NOT fit allAmazon 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
  • 30. 6. Leverage many storage optionsWhich storage option to use when?
  • 31. Cloud Architecture LessonsBest Practices1. 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
  • 32. AWS community and EcosystemFind help, guidance, assistance when you need itAWS EcosystemAWS Community
  • 33. Migratinga Web Applicationto AWSPhoto: La Pedrera - Casa Milà, Barcelona - Antonio Gaudi
  • 34. Migrating your Web ApplicationStep by Step towards AWSA typical Web App needs:Compute PowerStorage capacityContent DistributionDatabase storageMessagingLoad balancingMonitoring
  • 35. Migrating your Web Application - 1/8Typical Web App ArchitectureDatabaseApplication Server /Business LogicWeb Server /Presentation LayerClient Browser
  • 36. Migrating your Web Application - 2/8Amazon S3 for StorageStore persistent files in Amazon S3 for lower costs, higher reliabilityClient Browser
  • 37. Migrating your Web Application - 3/8Use Amazon CloudFrontAmazon CloudFront for distributionAmazon CloudFrontis a content delivery network that caches data stored in Amazon S3 across a network of 14 edge locations around the worldClient Browser
  • 38. Migrating your Web Application - 4/8Amazon EC2 for your choice of web serversConfigure Amazon EC2 running your choice of web server to handle all incoming web requests.Client Browser
  • 39. Migrating your Web Application - 4/8Scale out App servers on Amazon EC2Configure multiple Amazon EC2 instances running your choice of application server to process requests.Use Availability Zones and Elastic IPs for greater reliability and resiliency.Utilize Auto-scaling and Elastic LB serviceClient Browser
  • 40. Migrating your Web Application - 5/8Use Amazon EBS for DatabaseEBS for Persistent Storage and S3 for SnapshotsConfigure an Amazon EBS device to host your existing relational database. Snapshots can be automatically backed up to Amazon S3.Client Browser
  • 41. Migrating your Web Application - 6/8Use Amazon SQSAmazon SQS for queuing requestsSQSAmazon SQS makes it easy to coordinate between the web server and application servers.Client Browser
  • 42. Migrating your Web Application - 7/8Use Amazon SimpleDBAmazon SimpleDB for log files, metadataSimpleDBSQSAmazon SimpleDBcan be used to store metadata, logfiles, and other information for your site.Client Browser
  • 43. Migrating your Web Application - 8/8Use Amazon SimpleDBMonitor your Amazon EC2 instances using CloudWatchSimpleDBSQSAmazon CloudWatch to monitoring your Amazon EC2 instancesClient Browser
  • 44. Migrating your Web ApplicationStep by Step towards AWSA typical Web App needs:With AWS:Compute PowerStorage capacityContent DistributionDatabase storageMessagingLoad balancingMonitoringAmazon EC2Amazon S3Amazon CloudFrontAmazon EBSAmazon SQSAmazon EC2Amazon CloudWatch
  • 45. Amazon Web Services toolsThings you needWeb : AWS Management ConsoleIDE : AWS Toolkit for EclipseAWS SDK: .NET SDK, Java SDKTools : 3rd Party tools eg. CAFirefox Plugins : ElasticFox, S3Fox, SDB ToolSeveral libraries:
  • 46. Identify the right candidateWhiteboard DiagramDashboardReportWebSearchDBlogsServiceLDAPAuthCRMEngineOLAPERPList all your IT assetsWhiteboard your IT Assets Identify upward and downward dependencies
  • 47. Identify the right candidateIdentify the right candidate for the cloudDashboardProcessSearchBillingReportWebSearchDBlogsServiceLDAPAuthCRMEngineOLAPERP
  • 48. ConclusionsMost Important Lesson From Our Customers:Start small with a well-defined proof of concept Experiment with different architectures; Keep one, throw away othersOnce one application is launched others will follow…Photo: Grand Canyon Hopi Point SunSet
  • 49. 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.The day is not too far….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.

Editor's Notes

  1. Explain each service features and details here
  2. This is your classic three tier architecture. Incoming requests are fielded by a web server. The web server probably also draws files (such as images, PDFs, music, and so forth) from a file server. The web server farms processing out to a number of servers running an application server. This is where the bulk of your application’s business logic probably resides. You probably maintain a relational database on the back-end as well.
  3. Let’s start our migration project by moving many of our static and large files over to Amazon S3. Things like images, music, PDFs, and the like are best suited for Amazon S3. Amazon S3 provides a low-cost, highly reliable and scalable storage environment for your web applications.
  4. Many times you’ll have a number of users hitting your web application from all over the world. It can be time consuming and slow to serve all of those users’ requests from Amazon S3. That’s why we built Amazon CloudFront. Amazon CloudFront is a content delivery network that takes the data you’ve stored in Amazon S3 and caches it across a worldwide network of edge locations. In this way, the large static files used by your web application are stored as close as possible to the users who are requesting them.
  5. Amazon EC2 enables you to choose the operating system and application platform of your choice to host your web application. Whether it’s Microsoft .NET, IBM WebSphere, JBoss, Oracle Fusion Middleware, PHP, Ruby on Rails, or whatever, you can configure your own virtual environment to run the platform you need for your business. This is where you’ll move your web application, altering it to point to the persistent files you’ve moved to Amazon S3.
  6. A typical web application has a front-end web server to field incoming requests, which then farms out work to a bunch of application servers. You can move these applications ervers to Amazon EC2 as well.
  7. You’ll also want to move your database into the cloud. Amazon Elastic Block Store is a feature of Amazon EC2 that provides a block storage device in the cloud. You’d house your database in Amazon EBS. Amazon EBS can also be setup to periodically snapshot backup images into Amazon S3, so you can always roll back to a version of Amazon EBS if you need to, and you can rest assured that your database will exhibit the same resilient and reliable characteristics as the rest of AWS.
  8. Amazon SQS is a queueing service that provides the glue between your web server and your application server. The most common setup will involve configuring two queues. The first queue will accept messages from the web server hosted on Amazon EC2. Application servers, also hosted on Amazon EC2, will pluck those messages off the queue, process data based on the contents of the message, and then place the equivalent of an “I’m done! Here are the results.” message on the second queue. The web server would then pluck the message off the second queue and return results back to the client that made the initial request. In this way, your Amazon EC2 instances can grow or shrink, startup and fail with impunity, while you can rest assured that all of your data processing happens reliably.
  9. Amazon SimpleDB can be added to the equation to store your access logs, application logfiles, and even indices to data you’re storing in Amazon S3.
  10. Amazon SimpleDB can be added to the equation to store your access logs, application logfiles, and even indices to data you’re storing in Amazon S3.
  11. 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.