##Reasons to want OpsWorks
- can finally do machine config without adding things (.ebextensions) to our app
- config recipes can finally be SHARED! no more duplicate scripts in consumer-domain and cb-mobile
- scheduled instances
- no more latency/noise at ~8am when we wake up 10 extra boxes
- chef support is pretty sweet
- chef 11.10 - nice and recent, and gets updates!
- berkshelf built in - it's like Bundler for chef cookbooks
- so many good public cookbooks to take advantage of!
- now that it works we could save some time with this
- upgrading ruby versions is stupid easy
- went from 2.0 to 2.1.1 on running instances, no headaches
- they don't do it through RVM/rbenv, that's cool
- ability to manange LBs - built in HAProxy layer
- using ELB right now for ease
- future: serve all staging envs from single HAProxy instance to cut down on clutter and dollaz
- nice predefined lifecycle events for you to tack recipes onto
- UI is beautiful
##Annoying things about it
- machines take longer to spin up
- different model from Elastic Beanstalk, desires pre-provisioned and sleeping instances.
- initial boot + setup is the part that takes a long time.
- ~25m from machine requisition to booted, chef'd, online
- chef failures are hard to debug (not unique to opsworks)
- gotta be able to SSH in and pick apart the pieces
- often undoing the destruction manually is best
- sucks waiting ~25m for a new box
- requires an understanding of chef DSL
- it's ruby, so that's nice at least
- needs a logging solution
- can't 'snapshot logs' from UI
- solution: setting up a streaming sumo collector won't be hard
- once that's done, we can run the same recipe over all sorts of instances to make them use the sumo collector
- sometimes you just have to destroy and remake
- when a recipe goes awry, sometimes cleansing with fire is best
- luckily they don't just 'go awry', you have to fail hard in your script to bring the pain like that