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.
AWS Customer Presentation: exfm - How exfm uses AWS and Amazon CloudSearch- AWS Summit 2012 - NYC
The ex.fm story Lucas Hrabovsky, CTO AWS Summit 2012 - NYC
Start with AWS• Previous Experience with Colos• Used EC2 and S3 from the start• Manage instances using Fabric• Use Identity Access Management
Embrace Elasticity and Ephemerality• Easily handle unexpected successes• “Let’s try a different machine configuration”• “Where’d the database go?”
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
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