opsworks-pros-and-cons.md

##Reasons to want OpsWorks

1. can finally do machine config without adding things (.ebextensions) to our app
2. config recipes can finally be SHARED! no more duplicate scripts in consumer-domain and cb-mobile
3. scheduled instances

• no more latency/noise at ~8am when we wake up 10 extra boxes

3. 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

4. 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

5. 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

6. nice predefined lifecycle events for you to tack recipes onto
7. UI is beautiful

##Annoying things about it

1. 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

2. 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

3. requires an understanding of chef DSL

• it's ruby, so that's nice at least

4. 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

5. 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

@jusroberts:
A5) About 10 minutes, it was beautiful. They did the update in place without an AMI change. Just changed the ruby the webapp user uses.
B1) Boot time from stopped (already set up, just has to run any new chef recipes + deploy) is about 10 minutes or a little less. Might be able to do some stuff, but a lot of the boot up process is managed for us. I read somewhere that if you write a recipe to delete the opsworks agent logs before you shut down you can shave a lot of time off of boot up.
B2) writing bad scripts. I have yet to see it fail for a non-developer reason.
B3) Agreed, meh. It's easy to hop into, plus since most folks on our team are already rubyists it's kinda a nonissue.
B4) Yep, most likely.
B5) Agreed 100% - just don't suck 🤘 There are things that will validate and lint your recipes, but testing is another beast. I've seen test-kitchen mentioned a lot, haven't ever tried it out though. It's a wrapper around vagrant, so testing takes a while while vagrant fires up your local VMs.

• foodcritic - linting
• chefspec - looks neat and familiar