Opsworks and Chef are very similar Configuration Management (CM) tools. Opsworks is actually built on the Chef framework, then customized for Amazon’s giant cloud environment AWS. Hosted Chef is an IaaS solution from Chef parent company Opscode, in which they host the Chef server for you, and it in turn manages and communicates with your nodes, which are most likely also hosted in a cloud infrastructure such as Amazon’s EC2 infrastructure. So both solutions are evolutions of the traditional CM tool, now tweaked for cloud-hosted environments. Let’s peek behind their respective curtains.
What They Are
Chef is a well-known CM tool, one of the big boys in the market together with PuppetLabs’ Puppet. Chef is targeted at developers and devops rather than to sysadmins. It uses a pure-Ruby DSL in the CLI, and it also has a nice-enough GUI, but one that’s still a few leagues below Puppet and even Opsworks. Opscode then went further and now offers clients the option to cloud-host their servers – Hosted Chef. This setup makes sense mainly if the nodes to be managed are also cloud-based, so Hosted Chef includes a comprehensive library of API primitives for most cloud infrastructures – Amazon’s AWS, Windows Azure, Rackspace, etc.
Opsworks is derived from a version of Chef called chef-solo. This is a free, server-less mode in which your nodes can access cookbooks without requiring access to a central server. It is a great idea because it allows access to the numerous Chef cookbooks created by others and available on the web, without the tedium of first having to set up your own server. The downside (there had to be one) is that you lose access to all the useful stuff a server provides – node data storage, authentication and authorization, cookbook scheduling and persistency, and so on. The analogy here is similar to that in a domain-controlled Windows network, versus a peer-to-peer decentralized network.
Opsworks builds on Chef by creating stacks and layers. As per the Opsworks documentation page: “A stack is a container for all the Amazon EC2 instances and other resources that you want to manage together. Within a stack, you define layers that describe how to provision and configure instances. A stack can have multiple layers. Within a layer, you can specify, for example, packages to install, Amazon EC2 security groups to add, and Elastic IP addresses to assign. This structure gives you the flexibility to define different instance configurations. You define an app by specifying what layer it applies to, the code to run, and some basic configuration. You then deploy the app to the instances on the layer.”
One may wonder why Amazon had to create its own CM tool at all. After all, almost all the major CM’s, including Chef, already have API’s and interfaces for managing EC2 instances. And this costs Amazon nothing – the CM vendors are only too happy to create AWS interfaces for their products so they can tap into its huge customer base. Actually, in creating Opsworks Amazon now has a means of tying up users into the AWS ecosystem. They wanted to deliberately make it difficult to unbundle an app or server built on AWS, and an important piece of the puzzle was the server-management module. In Opsworks they now have exactly this. It wouldn’t have been possible with a 3rd-party CM, yet at the same time they didn’t want the headache of creating their own tool from scratch – after all, they are in the IaaS/ PaaS business, not the CM business. So adopting an already widespread tool like Chef, then customizing it for AWS, was a win-win for them, plus their users can get access to a large library of Chef cookbooks on the web. It may look a loss for Opscode, because why would anyone now use Chef to manage AWS instances? But remember, Opsworks only offers Chef-solo and won’t cannibalize paying Hosted-Chef customers from Opscode. And what Opscode may lose there may well be offset by the huge publicity and street cred they will get as AWS’s CM tool of choice. Also, anyone with Opsworks experience and also has non-AWS servers to maintain will already be familiar with Chef through Opsworks, and will likely choose the already-familiar Chef.
Platforms, Pricing & Support
Opsworks is Chef-based, so it is available on the same platforms as Chef – Linux, Unix and Windows.
Standard Hosted Chef costs $300 and covers 50 nodes, and Enterprise Hosted Chef costs $700 and covers 100 nodes and has more features to make it worth more. Opsworks is totally free. You’re already paying for the AWS servers you’re using, so Amazon ‘kindly’ provides you a tool for managing your servers.
Support for both is very good. Chef has a large, active user community, and documentation is also comprehensive. But there have been complaints that the Chef way of doing things is tricky to master for newbies, and most of the documentation doesn’t help because it’s mostly aimed at experienced users. Opsworks is backed by Amazon, so support and documentation is excellent. Since AWS is used not only by IT techie types, but also by laypeople setting up their own servers, Amazon has included a blisteringly simple to understand walkthrough and user guide. In fact, several new Chef users on discussion forums are reportedly turning not to the Opscode-created Chef site, but to the Opsworks user guide!
Summary
So there you have it. If you were mulling over a Hosted-Chef vs. Opsworks dilemma, you now know many of the differences between them and can make a decision. If you have an EC2 setup, this decision is especially relevant for you. Opsworks is completely free, but it only offers the Chef-solo version, so if you need a proper server-based Chef setup, you still need to go for Hosted Chef (or the standard Chef if you don’t need a hosted solution). And of course, Opsworks only works within AWS, but Hosted Chef can be used for almost any hosted-server solution.
Even though Opscode doesn’t lose much in this particular deal, Amazon’s encroachment into a market that it previously exclusively left up to these 3rd-party vendors could be a cause for worry; not only for Opscode, but for all CM vendors. It may (or may not) be an ominous signal that the Amazon goliath is looking at broadening its offerings to its own customers and moving into market spaces it wasn’t hitherto interested in. This reminds us of Microsoft’s own similar adventures in the late 90’s and early 2000’s, when it started to lock out smaller 3rd-party creators of Windows add-ons by creating its own tools and bundling them together with Windows. The textbook example of strategy this was the famous near-total destruction of the commercial Netscape Navigator browser by Microsoft’s free-with-Windows Internet Explorer. Will Amazon similarly pull out the rug from under its partners’ feet? Time will tell. Also take a look at the pros-cons chart below.
