AWS Summit 2011: Migrating Existing Applications to AWS


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

AWS Summit 2011: Migrating Existing Applications to AWS

  1. 1. Migrating Existing Applications to AWS Matt Tavis | Principal Solutions Architect
  2. 2. Planning on moving apps to the cloud? You have a lot to decide…
  3. 3. A Path to the Cloud • Select apps Deploy • Embrace AWS • Test platform • Migrate data services • Plan migration • Migrate components • Re-factor architecture • Cutover Plan Optimize
  4. 4. …knowing is half the battle. Architecture Center Security Center Whitepapers Resources Case Studies Solution Providers
  5. 5. Migrating Data onto AWS GBs TBs One-time upload w/ UDP Transfer SoftwareData Velocity Required constant delta updates (e.g., Aspera, Tsunami, …) Hours Days Transfer to S3 AWS Import / Export Over Internet Data Size* * relative to internet bandwidth and latency
  6. 6. Cutting Over Your Master Data Store Bulk Export TransferTransfer Snapshot to AWS Delta Freeze Cutover Export Transfer to Data and Updates Deltas AWS Source Unfreeze
  7. 7. Finding your first stop… Express Local Optimize for AWS  Re-design for AWS  Fully embrace cloud architectureForklift Embrace AWS Virtualize app  Optimize resources Retain operational  Scale on-demand approach
  8. 8. The Migration Continuum Forklift Embrace Optimize Effort Scalability Operational Burden Forklift Embrace AWS Optimize for AWS• May be only option for • Minor modifications to • Re-design with AWS some apps improve cloud usage in mind (high effort)• Run AWS like a virtual • Automating servers • Embrace scalable co-lo (low effort) can lower operational services (reduce• Does not optimize for burden admin) on-demand (over- • Leveraging more • Closer to fully utilized provisioned) scalable storage resources at all times
  9. 9. Mapping the Application to AWS - Forklift Matching resources  Examine existing footprint with an eye to resource requirements for that app – don’t obsess on HW specs! Building your AMIs  Create AMIs to match server roles Converting appliances  Create/discover virtual variants for physical appliances  Consult our Solution Providers site Deploying supporting components  NASes, SANs, DNS, Domain Controllers, …
  10. 10. Mapping the Application to AWS - Forklift Secure the application  VPC and/or Public EC2 with Security Groups  Data protection in-transit and at-rest Integrate monitoring and management tools  Use existing tools and/or new cloud management platforms
  11. 11. Mapping the Application to AWS – Embrace Everything on the last slide(s) plus… Rethink storage  Leverage new storage models offered by AWS Embrace elasticity  Bootstrapping your AMI  Dynamic build out, configuration and discovery Scale out and in on-demand  Leverage auto-scaling in both directions
  12. 12. Mapping the Application to AWS – Optimize Everything on the last two slides plus… Re-re-think storage  Further optimize storage through the use of non- traditional storage models (e.g., SimpleDB, NoSQL, …) Parallelize processing  Use more smaller resources to improve granularity of resources Use Spot where possible  Build for total transient nature to reduce costs Embrace scalable on-demand services  Replace software components with scalable AWS services (e.g., SQS, SNS, SES, …)
  13. 13. ELB Forklift steps:A Phased Migration to AWS - Forklift Match resources and build AMIs • Thinks about application needs not server specs • Build out custom AMI for application roles Convert appliances: • Map appliances to AWS AMI-1 @ AMI-1 @ services or virtual appliance C1.Medium C1.Medium AMIs Deploy supporting components: • SAN replacements • DNS AMI-2 @ AMI-2 @ • Domain controllers M2.XLarge M2.XLarge Secure the application components: AMI-6 @ M2.XLarge AMI-3 @ AMI-5 @ M2.2XLarge AMI-4 @ • Use layered security groups to C1.Medium M1.Large replicate firewalls
  14. 14. Steps to Embrace AWS:A Phased Migration to AWS - Embrace ELB Rethink storage: • Leverage S3 for scalable Auto-scaling Group WebWeb WebWeb storage Server Server Server Server • Edge cache with CloudFront • Consider RDS for HA RDBMS Web Tier Parallelize processing: • Bootstrap AMIs for auto- Auto-scaling Group App Server App Server App Server App Server discovery • Pass in bootstrapping parameters App Tier • Leverage configuration management tools for Master Config automated build out Database Management Server Scale out and in on-demand: • Use CloudWatch and Auto- scaling to auto-provision the Network Network DNS Domain fleet Filesystem Filesystem Controller
  15. 15. Steps to Optimize for AWS:A Phased Migration to AWS - Optimize Re-Rethink storage: • Break up datasets across Auto-scaling Group WebWeb WebWeb storage solutions based on Server Server Server Server best fit and scalability Web Tier Parallelize processing: • Spread load across multiple Auto-scaling Group App Server App Server App Server resources SQS • Decouple components for parallel processing App Tier App App Server Server EMR Use Spot where possible to reduce costs Embrace scalable on-demand services Config Network DNS Domain • Scale out systems with Route Management Filesystem Controller minimal effort Server 53 • Route53 • SES, SQS, SNS • …
  16. 16. Mitigating Factors Software Architecture Limitations  Lack of control over design of software components Licensing  Software licensing costs need to be factored into the scale out and in plans as not all software vendors have cloud-ready pricing plans Security, Compliance and Regulations  Where, how and the manner in which data can be processed based on industry regulations can influence AWS architectural options. Skillset / Training  Finding the right personnel to handle AWS migrations can be pivotal in the success of any migrations.
  17. 17. Additional resources:  Architecture Center:  Security Center:  Whitepapers:  Resources:  Case Studies: studies  Solution Providers: providers/Thank you!