CloudFormation vs OpsWorks
If you're serious about automating your infrastructure on Amazon Web Services (and you should be) you have multiple options to consider. You can deploy on Elastic Beanstalk and let Amazon manage everything for you. However, if you like to have a bit more control or have something that isn't supported by Elastic Beanstalk then you start looking at either CloudFormation or OpsWorks. I found myself choosing between these two and thought I would share some of the key points in the decision making process:
Use of Standard AWS Components
I was surprised to find that when initially released OpsWorks wasn't using some of the standard AWS services for core infrastructure elements. For instance, the load balancer was HAProxy, not Amazon's own Elastic Load Balancer. While HAProxy is a perfectly suitable alternative to ELB, it has learning curve. Amazon has since changed this and you can use ELB within OpsWorks. But it wasn't just ELB, there were other elements that made OpsWorks feel disconnected...almost like a 3rd party offering.
Chef Learning Curve
OpsWorks uses Chef at its core for server management. This means that there is a large community to pull recipes from for common configuration tasks. But what if, like me, you needed to do something custom. That's supported too, you can build you own custom recipe. That might be a simple task if you are already a chef expert, but if you aren't there is a pretty steep learning curve. There are repositories to configure properly and code to get working right. Where it all fell apart for me was debugging the custom recipes. The only real way to test them was to start up an OpsWorks stack, a process that takes 15 minutes, and wait to see if it worked. That's just not workable.
Documentation
One of the things that I like about CloudFormation is that it auto documents your infrastructure. You build declarative JSON documents that defines your infrastructure and application requirements. Anyone familiar with the Amazon services and JSON can pick apart a CloudFormation document and figure out what it is doing.
Troubleshooting
I like my team knowing how the infrastructure is put together. I find that on the really hard days, when things just aren't going right, it helps us to have a deep understanding of how everything is put together...there are less unknowns. I didn't feel like we could get there with OpsWorks, it would have been doing things that we didn't fully understand.
The Bottom Line
After evaluating it fully, we made the decision to invest our time in CloudFormation. I'm about 6 months in and I still feel it was the right decision for our organization. It is worth mentioning that CloudFormation did leave us with one key gap, code deployments. In a future post I will share some of our CloudFormation work flow and how we solved deployments.