47. “Forklift” migration
Traditional Data Center AWS Cloud
Billing Search Billing
Service service Service
Billing Search Billing
DB DB DB
Full application Full application
stack stack
66. Start with AWS
Previous Experience with Colos
Used EC2 and S3 from the start
Manage instances using Fabric
Use Identity Access Management
67. Embrace Elasticity and Ephemerality
Easily handle unexpected successes
“Let’s try a different machine configuration”
“Where’d the database go?”
68. Move Dev Machines to Instances
Dev box and production box look exactly alike
Update packages & configuration silently
Use cheats to replace lack of GUI’s
• bit.ly/exfmgitcheatsheet
Bonus: sharing and collaboration
69. Move to Managed Services
Cloudsearch
• bit.ly/exfmcloudsearch
Avoiding lock-in
Anticipated next steps: Apache Zookeeper, and more
Focus more on your application; less on infrastructure
77. 1. Adoption and migration
Cloud adoption and migration best practices. Full application life cycle.
78. 1. Adoption and migration
Cloud adoption and migration best practices. Full application life cycle.
2. Pro tips for integration
Engage early and often. Educate. Success criteria.
Previous ExperiencesLate night colo runs to restart machinesHave to pay union fee to bring in new hardware through the freight elevator“Where’d that disk go?”Ever had to move colos in the middle of the night?All that being said, didn’t want to deal with any of that again.Use micros, larges, XL’s and 2XL’s. Assets, like avatars, embeddable assets served directly from S3. Can’t wait to get more integration with cloudfront.No one offs. Everything scripted and reproducible. Use the excellent python package Fabric. Handles everything from launching new instances, installing packages to deploys.Also a big user of IAM. Every dev gets their own console login and keys. Easily have “app” users. Isolated set of keys we can rotate out through configuration.
Easily handle unexpected successUh… requests just doubledAdd 2 new app servers and back to normalDon’t autoscale now, but shouldLet’s try a different configuration different instance sizes CPU vs RAM vs Disk Typically, you rack three classes of machines: LB App DB What if things change? Switch from memcache to redis?Where’d the database go?I misconfigured RAID for shared MongoDBFix RAID configuration script, launch new instanceNo cab fare to run to colo
Dev box looks exactly like a production box just smaller. Same stack. Nginx, uwsgi. Each can be independent or share data sources.Micros extremely cost effective.Actually must faster cycle time than running locallyBringing up a new dev instance takes less than 5 minutes. Even adds cnames for itself in route53Update packages & configuration silently Reuse all ops scriptingDownside: No more git GUI’s...Everyone please make your way to the command lineFrontend team more comfortable with Github for Mac or GitX Not an option as the fuse mount is just to slow Simplify git with bash aliases bit.ly/exfmgitcheatsheetJust need to know four commands a, c, f, pMuch easier to share prototypesCollab between stakeholdersGive sneak peaks to users, investors, friends and family
Pay now for scalability instead of having to make longer term investments Over hiring too soon Sinking dev time into solutions that may not pan outCloudsearch. Been running in production for 4 months now. 15 minutes of downtime. Scales itself out of the box. Horizontal / vertical scaling. For free.Not concerned about lock in. There are open source solutions that can all of this. But need bigger more long term investments More self maintained instances More specialized hiresLooking forward to even more managed services in the future. Currently use mongoDB and Redis. DynamoDB extremely attractive. What would really round things out for us and solve yet another set of problems would be a managed apache zookeeper for distributed configuration management and cluster coordination Worry about the app, not Solr or mysql configuration and maintenance. Oops one of the shard instances died.