What should I use for configuration management on AWS?

Question

I am trying to find a solution for configuration management using AWS OpsWorks. What I can see is AWS offers three services for OpsWorks

1. Chef Automate
2. Puppet
3. AWS stacks

I have read basics of all three of them but unable to compare between three of them. I am unable to understand when to use which solution.

I want to implemnet a solution for my multiple EC2 instances, using which I can deliver updates to all my instances from a central repository(github). And, rollback changes if needed.

So following are my queries:

1. Which of the three solutions is best for this use case?
2. What should I use if my instances are in different regions?

I am unable to find anything useful on these topics so that I can make my decision. It would be great if I can get links to some useful articles as well.

Thanks in advance.

Answer 1

A good way to find comparison information about things like this is googling for "X vs Y", e.g. "Chef vs AWS stacks", "Chef vs Puppet" or something like that. That does turn out subjective information, and while it is nothing like having hands-on experience, you still get a few nice nuggets here or there.

For example, Chef gives you the full Ruby language while Puppet has a ruby-based DSL. Does that matter for you? Only you can tell.

From my experience with Puppet/Ansible (and I don't know Chef yet) it's all mostly down to taste. For example, I really like the fact that Ansible needs only a working ssh key and nothing else. And I like that there is no central repository. Others may like the fact that Puppet has a repository. Also, I like the dead simple configuration file format. But that is all subjective.

So, to cut to the chase, my advice would be:

• Use AWS Stacks if you are fully committed to AWS, will never change to another provider, and like the higher integration with AWS features. It uses Chef internally anyways, and exposes the Chef files to you.
• Use Chef directly if you like to learn something new and want to stay a bit vendor independent. If you later decide to commit to AWS fully, then you should be able to do so.
• Use Puppet (which AWS starts to support as well, seemingly) if you, well, like Puppet more, or if you can't stand Chef.

Answer 2

One consideration might be lock-in. For example, Amazon's cloud can become expensive very quickly - either because compute ends up being more than you estimated or there is always the possibility that Amazon decides to raise the cost of their compute price. This could cause you to want to change cloud providers to a cheaper one or perhaps you scale to a point at which it makes more financial sense to insource.

Another scenario could be that Amazon's cloud somehow becomes breached. For example, the Spectre and Meltdown exploits are particularly nasty on hypervisors and offer some possibility and prospect of breaking out of a guest into the hypervisor or gaining sensitive information from another tenant on the hypervisor.

These hypothetical and potential scenarios might or might not become realized and may or may not be realistic but nevertheless by choosing something that is easily exported to another cloud allows you to remain agile and easily deploy into another cloud or to insource. This guards against these above scenarios or any others that could arise.

There is nothing more important in this regard than your configuration management system - especially if you are using an [immutable architecture] and/or a cattle-not-pets philosophy as this allows you to simply begin spinning up new compute instances in the new cloud or cluster immediately. You needn't migrate virtual machines. (and hopefully you don't have a large amount of data to export).

So that is to say: Perhaps it would be wise to avoid AWS stacks so you aren't locked into this particular vendor.