Using chef with ec2 or through aws opswork

Chef Infra (archive)
1

Hello Guys,

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

Best Regards,

Joseph Kodjo-Kuma Djomeda
check out my pains at : www.mycodingpains.com
We become what we think about ourselves…

2

Joseph,
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:

  1. While it's essentially a Chef Server in the cloud, not all features of a
    true Chef server are exposed.
  2. You can't use Knife, at all, ever.
  3. There are no regular roles, but you can use role cookbooks to achieve
    similar results.
  4. 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.
  5. No data bags.
  6. 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).
  7. 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.,
  8. 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 GitHub - aws/opsworks-cookbooks: Chef Cookbooks for the AWS OpsWorks Service, 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 joseph@djomeda.com wrote:

Hello Guys,

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

Best Regards,

Joseph Kodjo-Kuma Djomeda
check out my pains at : www.mycodingpains.com
We become what we think about ourselves........

3

We went through an evaluation period recently of whether to use Opsworks or
regular ec2 nodes with vanilla Chef.

The conclusion we came to is that Opsworks functions really, really well
for anything that can be done by the existing nodes types available in
Opsworks. It was extremely quick to configure and scale and the lifecycle
events make it extremely easy to tag in recipes where you need them to get
clustering working.

The reason we didn't end up going with Opsworks though is that it's less
flexible than writing your own recipes from scratch. For a web stack it
makes perfect sense, but then if you want to add one off servers like a
Splunk server or some sort of utility server then how does that fit in the
stack? In that case you'd put it outside the stack so you're now having to
use normal Chef infrastructure/code anyway. It felt like Opsworks was a
tool for a specific purpose, a really good tool, but it didn't make sense
to try and cover all infrastructure with it.
I think if you just wanted to run your web stack on Opsworks and then have
stand alone nodes using other Chef recipes that could work well.

Another thing to take note on Opworks is that the development is glacial.
Amazon Linux and Ubuntu are the only OSes available, Chef server 11.10 is
the latest version available to Unix hosts and using the default recipes
there's not always up to date version of compilers available (for example
on Amazon Linux the only php version available is 5.3). When we started
developing in the trial for Opsworks we found that we were doing a bunch of
extra work to get the systems to a state that was the same as just using
the latest versions of community cookbooks. The older chef version meant
that the latest versions of community cookbooks wouldn't work on Opsworks
so we had to fill in the blanks ourselves.

On Tue, Jul 7, 2015 at 9:11 AM, Joseph Djomeda joseph@djomeda.com wrote:

Hello Guys,

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

Best Regards,

Joseph Kodjo-Kuma Djomeda
check out my pains at : www.mycodingpains.com
We become what we think about ourselves........

--
Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com