Jinesh Varia           Technology Evangelist         jvaria@amazon.com<br />Architectural<br />Design Patterns in Cloud C...
They sent me here to talk<br />But I am here to listen<br />Please Send Feedback<br />jvaria@amazon.com<br />Twitter: @jin...
Cloud Best Practices Whitepaper<br />Prescriptive guidance to Cloud Architects<br />Just Google for “Cloud Best Practices”...
Cloud Computing Attributes<br />What makes the Cloud so attractive<br />Abstract Resources<br />Focus on your needs, not o...
The “Living and Evolving” Cloud<br />The “Living and Evolving” Cloud<br />AWS services and basic terminology<br />Most App...
“At Amazon, Every Day is a Launch Day”<br />The “Living and Evolving” Cloud<br />New Features and Services<br />» Amazon E...
Boot from Amazon EBS</li></ul>» Amazon CloudFront Streaming<br />» Amazon VPC enters Unlimited Beta<br />» AWS Region in N...
Scalability<br />Build Scalable Architecture on AWS<br />A scalable architecture is critical to take advantage of a scalab...
Cloud Architecture Lessons<br />using Amazon Web Services<br />1. Design for failure and nothing fails<br />2. Loose coupl...
1. Design for Failure<br />and nothing will really fail<br />"Everything fails, all the time"<br />Werner Vogels, CTO Amaz...
Design for Failure with AWS<br />Tools to make your life easier<br />Use Elastic IP addresses for consistent and re-mappab...
YourWebsite.com<br />EC2 Instance A<br />EC2 Instance B<br />MASTER<br />SLAVE<br />MASTER<br />Replication<br />LOG <br /...
YourWebTwoDotZeroName.com<br />Availability Zone 2<br />EC2 Instance B<br />EC2 Instance A<br />Availability Zone 1<br />M...
www.YourWebsite.com<br />Staging.YourWebsite.com<br />Elastic IP<br />183.12.43.11<br />Dynamic IP<br />172.0.1.13<br />Pr...
2. Build Loosely Coupled Systems<br />The looser they're coupled, the bigger they scale<br />Independent components<br />D...
MyWebSite.com<br />Exterior Firewall Hardware or Software Solution to open standard Ports (80, 443)<br />Web Load Balancer...
MyWebSite.com<br />DNS<br />Elastic Load Balancer<br />ELB to  spread traffic to Web Server Auto-scaling groups<br />LB<br...
3. Implement Elasticity<br />Elasticity is fundamental property of the Cloud<br />Don’t assume healthor fixed location of ...
3. Implement Elasticity<br />Managed Development Environment<br />Automate everything<br />SaaS<br />Paid<br />AMI<br />We...
3. Implement Elasticity<br />Standardized Technology Stacks<br />Standardized Application Stacks<br />Apache<br />IIS<br /...
3. Implement Elasticity<br />3 Approaches to design MDE<br />3 approaches to designing your AMIs<br />Easier to Setup<br /...
3. Implement Elasticity<br />3 Approaches to design MDE<br />1. Frozen Pizza Model<br />IIS<br />IIS<br />IIS<br />IIS<br ...
3. Implement Elasticity<br />3 Approaches to design MDE<br />“Golden AMIs” with fetch on boot   <br />2. Papa Murphy Pizza...
3. Implement Elasticity<br />3 Approaches to design MDE<br />3. Made to Order Pizza Model <br />Apache<br />Mongrel<br />S...
3. Implement Elasticity<br />3 Approaches to design MDE<br />3 approaches to designing your AMIs<br />Easier to Setup<br /...
4. Build Security in every layer<br />Design with Security in mind<br />With cloud, you lose a little bit of physical cont...
5. Don't fear constraints<br />Re-think architectural constraints<br />More RAM? Distribute load across machines<br />Shar...
6. Think Parallel<br />Serial and Sequential is now history<br />Experiment different architectures in parallel<br />Multi...
6. Leverage many storage options<br />One size DOES NOT fit all<br />Amazon S3: large static objects<br />Amazon Cloudfron...
6. Leverage many storage options<br />Which storage option to use when?<br />
Cloud Architecture Lessons<br />Best Practices<br />1. Design for failure and nothing fails<br />2. Loose coupling sets yo...
AWS community and Ecosystem<br />Find help, guidance, assistance when you need it<br />AWS Ecosystem<br />AWS Community<br />
Migrating<br />a Web Application<br />to AWS<br />Photo: La Pedrera - Casa Milà, Barcelona  -  Antonio Gaudi<br />
Migrating your Web Application<br />Step by Step towards AWS<br />A typical Web App needs:<br />Compute Power<br />Storage...
Migrating your Web Application - 1/8<br />Typical Web App Architecture<br />Database<br />Application Server /Business Log...
Migrating your Web Application - 2/8<br />Amazon S3 for Storage<br />Store persistent files in Amazon S3 for lower costs, ...
Upcoming SlideShare
Loading in...5
×

Architecting for the Cloud: Best Practices

13,303

Published on

AWS Enterprise Event in London

Published in: Education
2 Comments
47 Likes
Statistics
Notes
  • cloud
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • very interesting and nice slides
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
13,303
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
5
Comments
2
Likes
47
Embeds 0
No embeds

No notes for slide
  • Explain each service features and details here
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Architecting for the Cloud: Best Practices

    1. 1. Jinesh Varia Technology Evangelist jvaria@amazon.com<br />Architectural<br />Design Patterns in Cloud Computing<br />
    2. 2. They sent me here to talk<br />But I am here to listen<br />Please Send Feedback<br />jvaria@amazon.com<br />Twitter: @jinman<br />
    3. 3. Cloud Best Practices Whitepaper<br />Prescriptive guidance to Cloud Architects<br />Just Google for “Cloud Best Practices” to find the link<br />http://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf<br />
    4. 4. Cloud Computing Attributes<br />What makes the Cloud so attractive<br />Abstract Resources<br />Focus on your needs, not on hardware specs. As your needs change, so should your resources.<br />On-Demand Provisioning<br />Ask for what you need, exactly when you need it. Get rid of it when you don’t need<br />Scalability in minutes<br />Scale out or in depending on usage needs.<br />Pay per consumption<br />No contracts or long-term commitments.<br />Pay only for what you use.<br />Efficiency of Experts<br />Utilize the skills, knowledge and resources of experts.<br />
    5. 5. The “Living and Evolving” Cloud<br />The “Living and Evolving” Cloud<br />AWS services and basic terminology<br />Most Applications Need:<br />Compute<br />Storage<br />Messaging<br />Payment<br />Distribution<br />Scale<br />Analytics<br />Your Application<br />Amazon RDS<br />Amazon CloudFront<br />Amazon SQS Queues<br />Amazon SimpleDB Domains<br />Payment : Amazon FPS/ DevPay<br />Amazon Elastic MapReduceJobFlows<br />Amazon SNS Topics<br />Amazon S3 Objects and Buckets<br />Auto-Scaling<br />Elastic LB<br />Cloud<br />Watch<br />Amazon EC2 Instances(On-Demand, Reserved, Spot)<br />EBS<br />Volumes<br />Snapshots<br />Amazon <br />Virtual Private Cloud<br />Amazon WorldWidePhysical Infrastructure <br />(Geographical Regions, Availability Zones, Edge Locations)<br />
    6. 6. “At Amazon, Every Day is a Launch Day”<br />The “Living and Evolving” Cloud<br />New Features and Services<br />» Amazon EC2 with Windows Server <br /> 2008, <br /><ul><li>Spot Instances,
    7. 7. Boot from Amazon EBS</li></ul>» Amazon CloudFront Streaming<br />» Amazon VPC enters Unlimited Beta<br />» AWS Region in Northern California<br />» International Support for AWS <br /> Import/Export<br />» AWS Multi-Factor Authentication<br />» Virtual Private Cloud<br />» Lower Reserved Instance Pricing<br />» Reserved Instances in EU Region<br />» Elastic MapReduce<br />» SQS in EU Region<br />» Amazon RDS<br />» High-Memory Instances<br />» Lower EC2 Pricing<br />» New SimpleDB Features<br />» FPS General Availability<br />» Amazon SNS<br />» AWS Security Center<br />2009<br />Jan<br />2010<br />Jan<br />Jul<br />Sep<br />Oct<br />Dec<br />Aug<br />Nov<br />Feb<br />Mar<br />Apr<br />Jun<br />May<br />Feb<br />Mar<br />» Amazon EC2 with Windows<br />» Amazon EC2 in EU Region<br />» AWS Toolkit for Eclipse<br />» Amazon EC2 Reserved<br /> Instances<br />» Amazon CloudFront<br /> Private Content<br />» SAS70 Type II Audit<br />» AWS SDK for .NET<br />» Amazon Elastic MapReduce<br /> in Europe<br />» Amazon EC2 Reserved Instances <br /> with Windows, Extra Large High <br /> Memory Instances<br />» Amazon S3 Versioning Feature<br />» Consolidated Billing for AWS<br />» Lower pricing for Outbound Data <br /> Transfer<br />» AWS Import/Export<br />» New CloudFront Feature<br />» Monitoring, Auto Scaling & Elastic Load Balancing<br />» EBS Shared Snapshots<br />» SimpleDB in EU Region<br />» Monitoring, Auto Scaling &<br /> Elastic Load Balancing in EU <br />» Lower pricing tiers for<br /> Amazon CloudFront<br />» AWS Management Console<br />
    8. 8. Scalability<br />Build Scalable Architecture on AWS<br />A scalable architecture is critical to take advantage of a scalable infrastructure<br />Characteristics of Truly Scalable Service<br />Increasing resources results in a proportional increase in performance<br />A scalable service is capable of handling heterogeneity<br />A scalable service is operationally efficient<br />A scalable service is resilient<br />A scalable service becomes more cost effective when it grows<br />
    9. 9. Cloud Architecture Lessons<br />using Amazon Web Services<br />1. Design for failure and nothing fails<br />2. Loose coupling sets you free<br />3. Implement “Elasticity”<br />4. Build Security in every layer<br />5. Don't fear constraints<br />6. Think Parallel<br />7. Leverage different storage options<br />
    10. 10. 1. Design for Failure<br />and nothing will really fail<br />"Everything fails, all the time"<br />Werner Vogels, CTO Amazon.com<br />Avoid single points of failure<br />Assume everything fails, and design backwards<br />Goal: Applications should continue to function even if the underlying physical hardware fails or is removed or replaced. <br />
    11. 11. Design for Failure with AWS<br />Tools to make your life easier<br />Use Elastic IP addresses for consistent and re-mappable routes<br />Use multiple Amazon EC2 Availability Zones (AZs)<br />Create multiple database slaves across AZs<br />Use real-time monitoring (Amazon CloudWatch)<br />Use Amazon Elastic Block Store (EBS) for persistent file systems<br />
    12. 12. YourWebsite.com<br />EC2 Instance A<br />EC2 Instance B<br />MASTER<br />SLAVE<br />MASTER<br />Replication<br />LOG <br />Volume<br />DATA <br />Volume<br />DATA <br />Volume<br />
    13. 13. YourWebTwoDotZeroName.com<br />Availability Zone 2<br />EC2 Instance B<br />EC2 Instance A<br />Availability Zone 1<br />MASTER<br />SLAVE<br />MASTER<br />Replication<br />DATA <br />Volume<br />DATA <br />Volume<br />LOG <br />Volume<br />LOG <br />Volume<br />Amazon S3<br />
    14. 14. www.YourWebsite.com<br />Staging.YourWebsite.com<br />Elastic IP<br />183.12.43.11<br />Dynamic IP<br />172.0.1.13<br />Production instance<br />App Version 1.1<br />Staging<br />instance<br />App Version 1.2<br />Database<br />
    15. 15. 2. Build Loosely Coupled Systems<br />The looser they're coupled, the bigger they scale<br />Independent components<br />Design everything as a Black Box<br />De-coupling for Hybrid models<br />Load-balance clusters<br />Use Amazon SQS as Buffers<br />Tight Coupling<br />Controller A<br />Controller B<br />Controller C<br />Q<br />Q<br />Q<br />Loose Coupling using Queues<br />Controller A<br />Controller B<br />Controller C<br />
    16. 16. MyWebSite.com<br />Exterior Firewall Hardware or Software Solution to open standard Ports (80, 443)<br />Web Load BalancerHardware or Software solution to distribute traffic over web servers<br />LB<br />Web Tier<br />Fleet of machines handling HTTP requests.<br />Web Server<br />Web Server<br />Backend Firewall Limits access to application tier from web tier<br />LB<br />App Load Balancer<br />Hardware or Software solution to spread traffic over app servers <br />App Server Tier <br />Fleet of machines handling Application specific workloads<br />Caching server machines can be implemented at this layer<br />App Server<br />App Server<br />App server<br />Backups on Tapes Periodic backups stored on Tapes usually managed by 3rd party at their site<br />Data Tier <br />Database Server machines with master and local running separately, Network storage for Static objects <br />MySQL<br />Master<br />MySQL(Slave)<br />Tapes<br />
    17. 17. MyWebSite.com<br />DNS<br />Elastic Load Balancer<br />ELB to spread traffic to Web Server Auto-scaling groups<br />LB<br />ELB: Web Tier<br />Exterior Firewall no longer needed because EC2 instances are controlled with Security Groups<br />Availability Zone #1<br />Availability Zone 2<br />Auto-scaling group : Web Tier<br />Auto-scaling group : Web Tier<br />Availability Zone #n<br />Web Server<br />Web Server<br />Web Server<br />Web Server<br />Auto-scaling Web Tier<br />Group of EC2 instances handling HTTP requests.<br />Edge Caching<br />High Volume Static <br />Content is edge <br />cached using <br />CloudFront<br />Backend Firewall no longer needed<br />SLB<br />App Server Load Balancer<br />Software LB (e.g. HAProxy) on EC2 instance to spread traffic over app server cluster<br />SLB<br />Auto-scaling group : App Tier<br />Auto-scaling group : App Tier<br />Auto-scaling App Tier <br />Group of EC2 instances running the actual app. Instances belong to Auto-scaling group.<br />Caching servers instances can be implemented at this layer<br />App Server<br />App Server<br />App Server<br />App Server<br />Tomcat<br />Tomcat<br />Cloud<br />Front<br />Amazon S3<br />RDS<br />Slave<br />RDS<br />Master<br />RDS<br />Slave<br />DB Tier <br />MySQL RDS DB Instances (master, local slave, x-AZ slave for failover) , Automated backups to S3 all managed by AWS<br />Backups Amazon S3 used for storing Static Objects and Backups<br />
    18. 18. 3. Implement Elasticity<br />Elasticity is fundamental property of the Cloud<br />Don’t assume healthor fixed location of components<br />Use designs that are resilient to reboot and re-launch<br />Bootstrapyour instances: Instances on boot will ask a question “Who am I & what is my role?”<br />Enable dynamic configuration<br />Use Auto-scaling (Free)<br />Use Elastic Load Balancing on multiple layers<br />Use configurations in SimpleDB to bootstrap instance<br />
    19. 19. 3. Implement Elasticity<br />Managed Development Environment<br />Automate everything<br />SaaS<br />Paid<br />AMI<br />Web 2.0 Marketing Campaign<br />Dev/Test<br />Apps<br />Prod<br />Managed Development Environment<br />Automated<br />Deployment Environment<br />Cloud-powered Software Lifecycle management<br />AWS Cloud<br />AWS Cloud<br />AWS Cloud<br />ISV<br /> Department<br />Enterprise IT<br />
    20. 20. 3. Implement Elasticity<br />Standardized Technology Stacks<br />Standardized Application Stacks<br />Apache<br />IIS<br />Apache<br />Tomcat<br />ASP.NET<br />Mongrel<br />Web Server<br />Struts<br />ASP.NET MVC<br />Rails<br />App Server<br />Your Code<br />Your Code<br />Your Code<br />MVC<br />Log4J<br />Log4Net<br />logger<br />Your Code<br />Spring <br />Spring.NET <br />RubyGems<br />Libraries<br />Hibernate<br />nHibernate<br />memcached<br />Packages<br />JEE<br />.NET <br />Ruby Runtime<br />DB Caching<br />Linux<br />Windows<br />Centos<br />Framework<br />OS<br />Java Stack<br />.NET Stack<br />RoR stack<br />
    21. 21. 3. Implement Elasticity<br />3 Approaches to design MDE<br />3 approaches to designing your AMIs<br />Easier to Setup<br />Inventory of fully baked AMIs<br />(Frozen Pizza Model)<br />“Golden AMIs” with fetch on boot<br />(Take N’ Bake Papa Murphy Model) <br />AMIs with JeOS and “Chef” Agent (Made to Order Pizza Model)<br />More Control<br />Easier to maintain<br />
    22. 22. 3. Implement Elasticity<br />3 Approaches to design MDE<br />1. Frozen Pizza Model<br />IIS<br />IIS<br />IIS<br />IIS<br />IIS<br />IIS<br />ASP.NET<br />IIS<br />IIS<br />IIS<br />IIS<br />IIS<br />ASP.NET MVC<br />ASP.NET MVC<br />ASP.NET MVC<br />ASP.NET MVC<br />ASP.NET MVC<br />ASP.NET MVC<br />Your Code<br />Your Code<br />Your Code<br />Your Code<br />Your Code<br />Your Code<br />Log4Net<br />Log4Net<br />Log4Net<br />Log4Net<br />Log4Net<br />Log4Net<br />Spring.NET <br />Spring.NET <br />Spring.NET <br />Spring.NET <br />Spring.NET <br />Spring.NET <br />nHibernate<br />nHibernate<br />nHibernate<br />nHibernate<br />nHibernate<br />nHibernate<br />.NET <br />.NET <br />.NET <br />.NET <br />.NET <br />.NET <br />Amazon EC2<br />Windows<br />Windows<br />Windows<br />Windows<br />Windows<br />Windows<br />.NET AMI<br />.NET Stack<br />
    23. 23. 3. Implement Elasticity<br />3 Approaches to design MDE<br />“Golden AMIs” with fetch on boot <br />2. Papa Murphy Pizza Model<br />IIS<br />IIS<br />Source Control<br />Fetch on boot time<br />Your Code<br />ASP.NET MVC<br />Amazon S3<br />Your Code<br />ASP.NET MVC<br />Log4Net<br />nHibernate<br />Log4Net<br />Spring.NET <br />Spring.NET <br />IIS<br />IIS<br />IIS<br />IIS<br />IIS<br />nHibernate<br />IIS<br />IIS<br />IIS<br />IIS<br />IIS<br />.NET <br />.NET <br />.NET <br />.NET <br />.NET <br />.NET <br />Windows<br />Amazon EC2<br />Windows<br />Windows<br />Windows<br />Windows<br />Windows<br />.NET AMI<br />.NET Stack<br />
    24. 24. 3. Implement Elasticity<br />3 Approaches to design MDE<br />3. Made to Order Pizza Model <br />Apache<br />Mongrel<br />Source Control<br />Rails<br />Your Code<br />Cookbooks <br />Recipes<br />Your Code<br />Amazon S3<br />ASP.NET MVC<br />Log4Net<br />.NET <br />IIS<br />Chef Server<br />nHibernate<br />logger<br />IIS<br />Spring.NET <br />RubyGems<br />memcached<br />Ruby Runtime<br />CHEF Agent<br />CHEF Agent<br />Centos<br />Windows<br />Windows<br />Amazon EC2<br />AMI (JeOS)<br />RoR Stack<br />
    25. 25. 3. Implement Elasticity<br />3 Approaches to design MDE<br />3 approaches to designing your AMIs<br />Easier to Setup<br />Inventory of fully baked AMIs<br />(Frozen/Ready made)<br />“Golden AMIs” with fetch on boot<br />(Take N’ Bake) <br />AMIs with JeOS and “Chef” Agent (Made to Order)<br />More Control<br />Easier to maintain<br />
    26. 26. 4. Build Security in every layer<br />Design with Security in mind<br />With cloud, you lose a little bit of physical control but not your ownership<br />Create distinct Security Groups for each Amazon EC2 cluster<br />Use group-based rules for controlling access between layers<br />Restrict external access to specific IP ranges<br />Encrypt data “at-rest” in Amazon S3<br />Encrypt data “in-transit” (SSL)<br />Consider encrypted file systems in EC2 for sensitive data<br />Rotate your AWS Credentials, Pass in as arguments encrypted <br />Use MultiFactor Authentication<br />
    27. 27. 5. Don't fear constraints<br />Re-think architectural constraints<br />More RAM? Distribute load across machines<br />Shared distributed cache<br />Better IOPS on my database? <br />Multiple read-only / sharding / DB clustering<br />Hardware Config does not match?<br />Implement Elasticity<br />Your hardware failed or messed up config?<br />simply throw it away and switch to new hardware with no additional cost<br />Performance<br />Caching at different levels (Page, Render, DB)<br />
    28. 28. 6. Think Parallel<br />Serial and Sequential is now history<br />Experiment different architectures in parallel<br />Multi-treading and Concurrent requests to cloud services<br />Run parallel MapReduce Jobs<br />Use Elastic Load Balancing to distribute load across multiple servers <br />Decompose a Job into its simplest form<br />
    29. 29. 6. Leverage many storage options<br />One size DOES NOT fit all<br />Amazon S3: large static objects<br />Amazon Cloudfront: content distribution<br />Amazon SimpleDB: simple data indexing/querying<br />Amazon EC2 local disc drive : transient data<br />Amazon EBS: persistent storage for any RDBMS + Snapshots on S3<br />Amazon RDS: RDBMS service - Automated and Managed MySQL<br />
    30. 30. 6. Leverage many storage options<br />Which storage option to use when?<br />
    31. 31. Cloud Architecture Lessons<br />Best Practices<br />1. Design for failure and nothing fails<br />2. Loose coupling sets you free<br />3. Implement Elasticity<br />4. Build Security in every layer<br />5. Don't fear constraints<br />6. Think Parallel<br />7. Leverage many storage options<br />
    32. 32. AWS community and Ecosystem<br />Find help, guidance, assistance when you need it<br />AWS Ecosystem<br />AWS Community<br />
    33. 33. Migrating<br />a Web Application<br />to AWS<br />Photo: La Pedrera - Casa Milà, Barcelona - Antonio Gaudi<br />
    34. 34. Migrating your Web Application<br />Step by Step towards AWS<br />A typical Web App needs:<br />Compute Power<br />Storage capacity<br />Content Distribution<br />Database storage<br />Messaging<br />Load balancing<br />Monitoring<br />
    35. 35. Migrating your Web Application - 1/8<br />Typical Web App Architecture<br />Database<br />Application Server /Business Logic<br />Web Server /<br />Presentation Layer<br />Client Browser<br />
    36. 36. Migrating your Web Application - 2/8<br />Amazon S3 for Storage<br />Store persistent files in Amazon S3 for lower costs, higher reliability<br />Client Browser<br />
    37. 37. Migrating your Web Application - 3/8<br />Use Amazon CloudFront<br />Amazon CloudFront for distribution<br />Amazon CloudFrontis a content delivery network that caches data stored in Amazon S3 across a network of 14 edge locations around the world<br />Client Browser<br />
    38. 38. Migrating your Web Application - 4/8<br />Amazon EC2 for your choice of web servers<br />Configure Amazon EC2 running your choice of web server to handle all incoming web requests.<br />Client Browser<br />
    39. 39. Migrating your Web Application - 4/8<br />Scale out App servers on Amazon EC2<br />Configure multiple Amazon EC2 instances running your choice of application server to process requests.<br />Use Availability Zones and Elastic IPs for greater reliability and resiliency.<br />Utilize Auto-scaling and Elastic LB service<br />Client Browser<br />
    40. 40. Migrating your Web Application - 5/8<br />Use Amazon EBS for Database<br />EBS for Persistent Storage and S3 for Snapshots<br />Configure an Amazon EBS device to host your existing relational database. Snapshots can be automatically backed up to Amazon S3.<br />Client Browser<br />
    41. 41. Migrating your Web Application - 6/8<br />Use Amazon SQS<br />Amazon SQS for queuing requests<br />SQS<br />Amazon SQS makes it easy to coordinate between the web server and application servers.<br />Client Browser<br />
    42. 42. Migrating your Web Application - 7/8<br />Use Amazon SimpleDB<br />Amazon SimpleDB for log files, metadata<br />SimpleDB<br />SQS<br />Amazon SimpleDBcan be used to store metadata, logfiles, and other information for your site.<br />Client Browser<br />
    43. 43. Migrating your Web Application - 8/8<br />Use Amazon SimpleDB<br />Monitor your Amazon EC2 instances using CloudWatch<br />SimpleDB<br />SQS<br />Amazon CloudWatch to monitoring your Amazon EC2 instances<br />Client Browser<br />
    44. 44. Migrating your Web Application<br />Step by Step towards AWS<br />A typical Web App needs:<br />With AWS:<br />Compute Power<br />Storage capacity<br />Content Distribution<br />Database storage<br />Messaging<br />Load balancing<br />Monitoring<br />Amazon EC2<br />Amazon S3<br />Amazon CloudFront<br />Amazon EBS<br />Amazon SQS<br />Amazon EC2<br />Amazon CloudWatch<br />
    45. 45. Amazon Web Services tools<br />Things you need<br />Web : AWS Management Console<br />IDE : AWS Toolkit for Eclipse<br />AWS SDK: .NET SDK, Java SDK<br />Tools : 3rd Party tools eg. CA<br />Firefox Plugins : <br />ElasticFox, S3Fox, SDB Tool<br />Several libraries: <br />
    46. 46. Identify the right candidate<br />Whiteboard Diagram<br />Dashboard<br />Report<br />Web<br />Search<br />DB<br />logs<br />Service<br />LDAP<br />Auth<br />CRM<br />Engine<br />OLAP<br />ERP<br />List all your IT assets<br />Whiteboard your IT Assets <br />Identify upward and downward dependencies<br />
    47. 47. Identify the right candidate<br />Identify the right candidate for the cloud<br />Dashboard<br />Process<br />Search<br />Billing<br />Report<br />Web<br />Search<br />DB<br />logs<br />Service<br />LDAP<br />Auth<br />CRM<br />Engine<br />OLAP<br />ERP<br />
    48. 48. Conclusions<br />Most Important Lesson From Our Customers:<br />Start small with a well-defined proof of concept <br />Experiment with different architectures; Keep one, throw away others<br />Once one application is launched others will follow…<br />Photo: Grand Canyon Hopi Point SunSet<br />
    49. 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.<br />The day is not too far….<br />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.<br />
    50. 50. Thank you!<br />jvaria@amazon.com Twitter:@jinmanPresentation idea and template from @simon<br />
    51. 51. http://aws.amazon.com<br />

    ×