OpsWorks is a very nice service, we use and enjoy it a lot, along with
Elastic Beanstalk. OpsWorks is easier to figure out than Elastic Beanstalk,
especially if you already have an understanding of Chef. OpsWorks does have
downsides, though, such as:
- While it’s essentially a Chef Server in the cloud, not all features of a
true Chef server are exposed.
- You can’t use Knife, at all, ever.
- There are no regular roles, but you can use role cookbooks to achieve
- There are no environments, but you can pass a custom JSON blob to an
OpsWorks stack, to achieve similar results, minus an attribute hierarchy or
cookbook version requirements.
- No data bags.
- The evolution of the OpsWorks API is slower than that of Chef – while
Chef is up to version 12.4, OpsWorks is still using Chef 11.10 and it’s
unclear when they’ll start supporting Chef 12 (they kind of do now, but
only for Windows stacks).
- If you want to build your OpsWorks instance directly from cookbooks
stored in GitHub, you must set up your repo in a specific manner and keep a
bunch of cookbooks in a single repo.,
- If you wish to use a certain cookbook (let’s use the apache2 cookbook
https://github.com/svanzoest-cookbooks/apache2 as an example) and it
already exists in https://github.com/aws/opsworks-cookbooks, you must use
the OpsWorks version. Trying to use the official/community release will
result in an error.
At the same time, we also use Chef’s Hosted Chef service, to get the whole
package when needed, but OpsWorks is usually sufficient. Lastly, you always
have the option of running your own Chef Server in-house (or in EC2).
On a different note, you mentioned that you use Chef for online nodes and
Ansible for local dev/experiments. I might suggest that you switch entirely
to one or the other for both online nodes and local development, so you
don’t have to do the same work twice. If you’re going to use OpsWorks, you
might as well standardize on Chef. Chef is very local development-friendly,
with tools such as Chef Zero, Test Kitchen and VirtualBox.
I hope this helps!
On Tue, Jul 7, 2015 at 12:11 PM, Joseph Djomeda firstname.lastname@example.org wrote:
I wanted to pick your mind about some strategic usage of opsworks vs chef
or opsworks with chef. More and more my company is comfortable in running
our servers on the cloud, our own and boxes we manage for few clients.
We have aws and azure account and very soon google cloud. We use more aws
anyways and are very much ok with it.
DevOps department is pretty young and we are at getting it pick up . I got
approval for using chef but I have been reading about aws Opswork and their
Codedeploy which can add a lot to our bottom line. Considering Opswork is
based on chef has been a major factor in adopting chef for our online nodes
and ansible for our local and experiments etc.
Trying opswork didn’t feel like I have an overall control over the farm
event thought it’s been advertised as very flexible.
I am trying not get a wrong opinion so I would like to ask if you have a
similar case and what did you finally decided on and why
Joseph Kodjo-Kuma Djomeda
check out my pains at : www.mycodingpains.com
We become what we think about ourselves…