AWS OpsWorks is a tool for managing an entire application “stack,” including provisioning Amazon infrastructure or services, and providing a configuration management tool to configure any virtual machines (EC2 instances) and deploy application code.

The configuration management piece of OpsWorks is built on the Chef framework, so you could think of it as “Chef-as-a-Service” only customized for the AWS environment.

According to Amazon: “AWS OpsWorks features an integrated management experience for the entire application lifecycle including resource provisioning, configuration management, application deployment, monitoring and access control.” OpsWorks offers more flexibility than a typical PaaS like Heroku, while providing a higher level of control than configuring your servers manually.

Is OpsWorks worth trying in your AWS environment? Here are some of the potential advantages and disadvantages you might experience when using OpsWorks versus Chef:

Advantages of OpsWorks over Chef

  • OpsWorks is tightly integrated with other AWS offerings. If you’re deeply invested in AWS and utilizing a number of AWS services such as Amazon’s Relational Database Service (RDS), this will probably benefit you.
  • OpsWorks is, overall, a bit easier to use than Chef because Amazon has established a framework and eliminated the need for you to make certain architectural or design decisions. Additionally, they have prepared a significant amount of documentation around their framework.

Disadvantages of OpsWorks versus Chef

  • OpsWorks runs an older version of Chef (11.10). The latest stable version of Chef is 12.2.
  • Although it’s possible to trigger manual Chef runs, OpsWorks prefers that you treat your instances like they’re ephemeral. Chef runs are only triggered during certain lifecycle events (instance up, instance down, etc.), rather then running on a scheduled basis like with Chef Server.
  • OpsWorks supports “search”; however it has serious limitations because OpsWorks is not running Chef Server behind the scenes. Certain data, such as Ohai data data from other servers, is not available. In addition, only data for instances within the “stack” is available.
  • OpsWorks supports data bags, but not encrypted data bags. This can be regarded as an advantage or disadvantage. I try to stay away from data bags, but when you’re trying to use community cookbooks this can sometimes be unavoidable.
  • OpsWorks does not support environments. You must create a “stack” per environment.
  • OpsWorks supports Berkshelf, but it has several limitations.
  • OpsWorks does not support some of the Chef tooling that will work with Chef Server.

A final thought: OpsWorks is a framework, and it’s great to have the foundation, conventions, and workflow that it provides. But like any framework OpsWorks “shapes” your design. As a result, you lose significant design freedom.

In the long run, I think many teams will outgrow OpsWorks for that reason. On the other hand, it’s possible to build a “framework” for AWS utilizing Chef and CloudFormation that would not only be more flexible and customization-friendly than OpsWorks, but also would eliminate all the disadvantages mentioned above.

To share some thoughts about your current stack and whether OpsWorks might be a good move for you, contact Bitlancer.