At One Model we’ve been using Opsworks since December 2015 so that we could script, configure, and maintain our infrastructure with Chef. Overall using Opsworks has been frustrating and we probably should have abandoned it a while ago. I should clarify that we are using Opsworks Stacks (the other variations didn’t exist when we started using it).
There are 3 main reasons behind the decision to move away from Opsworks.
- It can be inconsistent.
- It receives little support or investment from AWS.
- Developing and testing recipes is hard.
This is the most frustrating aspect. Instances fail in the setup phase without any reason or error, but then succeed on the next attempt without any changes being made. It happens fairly frequently, almost every second instance created seems to be affected.
It’s frustrating because when it happens it takes 20 or 30 minutes for the setup to timeout before you can stop the instance and try again. It’s more frustrating because there are no errors in the recipes and the next attempt to start the instance will succeed. It’s even more frustrating because there are no errors and nothing obvious that can be fixed to prevent the issue.
This issue also means Opsworks cannot be relied on. What if it occurs when a new instance is being started to ensure service availability?
Lack of internal support
Opsworks Stacks appears to be a forgotten child of AWS and it has been a long time since the last significant update. There still isn’t an option to use an application load balancer (which was released almost a year and a half ago), only classic load balancers are supported. Also, the version of Chef available is a major version behind.
While there have been no updates to Opsworks Stacks, AWS has released other Opsworks products – OpsWorks for Chef Automate and OpsWorks for Puppet Enterprise. We haven’t tried these but they appear to just be managed instances of Chef and Puppet, and I suspect that they are more to get existing users of Chef and Puppet to migrate those services into AWS then providing an alternative to Opsworks Stacks.
Difficult to use
There is no point using a technology to solve a problem if it only complicates things more, and ultimately Opsworks wasn’t making our lives easier. An advantage of Opsworks was that we didn’t have to manage infrastructure for running Chef, but this made it more difficult to test recipes. The easiest way was to use Opsworks, but it is tediously slow (even without setups failing mysteriously).
Additionally using Opsworks required us to learn Chef – a combination of Ruby and scripting languages. Chef is more powerful than what we were using it for, but this made it more complicated for us to learn and understand. It also didn’t help that the version in Opsworks is out of date.
The long term plan is to have our applications run in containers, but while we make the necessary changes we will migrate from Opsworks to building custom AMIs with Packer. We have found Packer easy to learn and quick to get started with. The additional benefit is that using custom AMIs makes starting new instances quicker, as the setup has been done as part of creating the AMI.