<p>These tools serve slightly different purposes: use a <em>configuration management</em> tool like Ansible/Puppet for configuration / customization and orchestration tool like Terraform to provision infrastructure.</p>

<p>Ansible and Puppet are primarily configuration management tools. It is suitable for resource customization and configuration.</p>

<p>Puppet requires Puppet Agent installation on each server. Ansible doesn't require any agents. It uses SSH protocol for performing all operations.<br>
Ansible supports YAML syntax. Ansible is little more popular now than Puppet.</p>

<p>Terraform is an infrastructure orchestration tool that supports many cloud platforms.
With Terraform you simply declare resources and how you want them configured and then Terraform will map out the dependencies and build everything for you.
I prefer to use it to provision VMs and Cloud services like Databases or Storages.</p>

<p>All three tools have excellent community support.</p>

CC BY-SA 4.0
2020-01-08T08:37:03.200Z
Hi Evgeny. Could you support your answer with some references or links?
Bruce Becker
CC BY-SA 4.0
2020-01-08T09:22:57.637Z
Hi Bruce. This is related post - https://www.ibm.com/cloud/blog/chef-ansible-puppet-terraform
Evgeny Anikiev
CC BY-SA 4.0
2020-01-08T08:31:09.383Z
2020-01-08T13:24:53.760Z
2020-01-08T13:24:53.760Z
Evgeny Anikiev
<p>@jasper welcome!</p>

<p>This really might depend on the context. On long term it's worth to take a deeper look for a moment if you are not after quick shots and go beyond experiments for a sustainable (and large) infrastructure.</p>

<p>So we have got many clouds out there. Deployment automation means, they have some API.</p>

<p>So what does make a deployment automation tool delivering <em>infrastructure as code</em> capability?</p>

<ul>
<li><p><strong>(1)</strong> Unified, programmable, configurable abstraction layer, also <em><a href="https://en.wikipedia.org/wiki/Domain-specific_language" rel="nofollow noreferrer">called domain specific language</a></em> (DSL).</p></li>
<li><p><strong>(2)</strong> An <a href="https://en.wikipedia.org/wiki/Object_model" rel="nofollow noreferrer">object model</a> of (multiple) cloud assets and available services.</p></li>
<li><p><strong>(3)</strong> Corresponding logic to execute actions on the assets typically: <em><a href="https://en.wikipedia.org/wiki/Create,_read,_update_and_delete" rel="nofollow noreferrer">create, read, update, delete</a></em> (CRUD) and synonyms.</p></li>
</ul>

<p>Now there are some challenges to address human readability and sustainability varying by programming language ecosystems and communities: </p>

<ul>
<li>Cloud products being themselves computer infrastructure and network engineering (these are different disciplines!) abstractions are not following some official "cloud domain" ISO/IEEE naming standards as far as I know. That is, all the names are pushed by vendors and might be marketing biased. So either you invent your own terminology or decide which terms are most generic, or a mix of that. There is therefore a good reason that you find also cloud vendor specific deployment languages and tools for example like <em>Cloud Formation</em> by AWS.</li>
<li><em>Somebody</em> needs to maintain related components to support new API versions for <em>every cloud platform</em>!</li>
</ul>

<p>Some deployment tools delegate the <em>cloud driver</em> (that's another term for cloud platform specific code bases) to separate projects, which in their term delegate responsibility for API compatibility to one or another boilerplate (=often boring and tedious) API implementations.</p>

<p>Therefore my conclusion is that depending on your purposes the most straight-forward way to write infrastructure as a code is the programming language of your choice using a well-supported SDK which is though vendor-specific!</p>

<p>Still this is the point where you have got greatest flexibility because for a small standard use case you could write your own abstraction layer and your custom logic whatever you want. </p>

<p>Python examples:</p>

<ul>
<li><p><em>boto3</em> for AWS</p></li>
<li><p><em>exoscale/cs</em> for Apache CloudStack</p></li>
<li><p><em>python-openstackclient</em> for Apache CloudStack</p></li>
</ul>

<p>Recent Terraform example: its Apache CloudStack driver has <a href="https://github.com/terraform-providers/terraform-provider-cloudstack/issues/72" rel="nofollow noreferrer">backward compatibility problems</a> because it's based on some less-visible <a href="https://github.com/xanzy/go-cloudstack" rel="nofollow noreferrer">CloudStack API SDK written in Golang</a>. I am sure you can run into problems of this sort with any deployment tool; so if you commit to one, bring enough courage and patience to connect with and contribute to the corresponding community (same is for SDKs but they at least typically have less abstraction).</p>

<p>That is, before deciding for a certain cloud deployment automation tool, consider besides the things you see on the surface like syntactic sugar and community support also the following aspects:</p>

<ul>
<li>If it's open source, is it written in a programming language where you/your team could create an emergency patch if things go really worse?</li>
<li>How well supported are those cloud drivers critical to your business: these typically can't be <em>all</em> of them, if so, you might run into issues like <a href="https://gitlab.com/gitlab-org/gitlab-runner/issues/4338" rel="nofollow noreferrer">GitLab with <em>Docker Machine</em></a> (also a specific deployment tool after all), where a significant technical base for a competitive product feature <a href="https://github.com/docker/machine/issues/4537" rel="nofollow noreferrer">suddenly breaks away</a> because all the responsibility in this context had been factually outsourced to the open source community.</li>
</ul>

CC BY-SA 4.0
2020-01-08T12:30:47.567Z
2020-01-08T13:17:56.323Z
2020-01-08T13:17:56.323Z
Ta Mu
<p>I have some time for research at work right now, and I was thinking on expanding my knowledge on my favorite subject, which is DevOps (love you all). </p>

<p>I have some advanced experience with Ansible, as it has always been my choice when preparing and provisioning hardware in my Cloud tenancies. I started working with Ansible because it was the first software that popped up based on a quick SE search, a couple of months ago. However, I'd like to know <strong>how Ansible compares with <em>Terraform</em> and/or <em>Puppet</em>, in the following aspects:</strong></p>

<ol>
<li>Which is the most commonly used tool between the three in the DevOps community, more specifically when deploying Cloud infrastructure to customers, and why is that?</li>
<li>Which of the three use the simplest syntax (to my knowledge, Terraform is best at this)? I’m looking for a human-readable syntax if possible which makes things easier to remember.</li>
<li>Which is most respectable in the DevOps community, with regard to community standards, and why? Do any of these tools have a feature that makes them stand out from a development POV?</li>
</ol>

<p>Thank you as always for your time.</p>

CC BY-SA 4.0
2020-01-08T08:20:02.713Z
Hi Jasper! This question is going to be very difficult to answer objectively. Perhaps you could give us some context on your criteria (which sector are you working in, what is the skill level or orientation of your colleagues, etc) which will help constrain the answer. As it stands, I think this question is too open to interpretation and thus may be flagged "opinion-based". Thanks!
Bruce Becker
CC BY-SA 4.0
2020-01-08T08:23:11.257Z
Thanks @BruceBecker ! I am a Junior with one year of experience. I work in Consulting, so all sectors apply, but my favorite thing is doing DevOps related work in projects (cloud infrastructure, programming and automation). My colleagues are in charge of other parts of projects so they don’t compare to me in any way, mostly. Thank you for the clarification, I hope it doesn’t get closed!
jasper
CC BY-SA 4.0
2020-01-08T08:28:35.997Z
Thanks for the clarifications :) it may help to update the question if you can. The issue is really with the superlatives ("simplest", "most commonly used", "most respectable"). This phrasing doesn't leave room for nuance and ambiguity. Each of the three things you mentioned are the most used, simplest and most respectable -- in the places where they are the most used, in the simplest way, and most respected. Perhaps you could emphasise what priority you are assigning the problems you're trying to solve?
Bruce Becker
CC BY-SA 4.0
2020-01-08T08:29:29.320Z
@BruceBecker ok!! Right away
jasper
<ansible><terraform><deployment><infrastructure-as-code><puppet>
What is the most used tool for Cloud Infrastructure deployment Ansible vs Puppet vs Terraform?
jasper
# What is the most used tool for Cloud Infrastructure deployment Ansible vs Puppet vs Terraform?

(Asked by: username_0 on 2020-01-07)

I have some time for research at work right now, and I was thinking on expanding my knowledge on my favorite subject, which is DevOps (love you all).

I have some advanced experience with Ansible, as it has always been my choice when preparing and provisioning hardware in my Cloud tenancies. I started working with Ansible because it was the first software that popped up based on a quick SE search, a couple of months ago. However, I'd like to know **how Ansible compares with *Terraform* and/or *Puppet*, in the following aspects:**

1. Which is the most commonly used tool between the three in the DevOps community, more specifically when deploying Cloud infrastructure to customers, and why is that?
2. Which of the three use the simplest syntax (to my knowledge, Terraform is best at this)? I’m looking for a human-readable syntax if possible which makes things easier to remember.
3. Which is most respectable in the DevOps community, with regard to community standards, and why? Do any of these tools have a feature that makes them stand out from a development POV?

Thank you as always for your time.

**Tags:** ansible, terraform, deployment, infrastructure-as-code, puppet

> **Comments:**
> **username_1**: Hi Jasper! This question is going to be very difficult to answer objectively. Perhaps you could give us some context on your criteria (which sector are you working in, what is the skill level or orientation of your colleagues, etc) which will help constrain the answer. As it stands, I think this question is too open to interpretation and thus may be flagged "opinion-based". Thanks!  
> **username_0**: Thanks @BruceBecker ! I am a Junior with one year of experience. I work in Consulting, so all sectors apply, but my favorite thing is doing DevOps related work in projects (cloud infrastructure, programming and automation). My colleagues are in charge of other parts of projects so they don’t compare to me in any way, mostly. Thank you for the clarification, I hope it doesn’t get closed!  
> **username_1**: Thanks for the clarifications :) it may help to update the question if you can. The issue is really with the superlatives ("simplest", "most commonly used", "most respectable"). This phrasing doesn't leave room for nuance and ambiguity. Each of the three things you mentioned are the most used, simplest and most respectable -- in the places where they are the most used, in the simplest way, and most respected. Perhaps you could emphasise what priority you are assigning the problems you're trying to solve?  
> **username_0**: @BruceBecker ok!! Right away  

---

## 2 answers

### Answer by username_3 on 2020-01-08. Score: 2 | Accepted answer

@username_0 welcome!

This really might depend on the context. On long term it's worth to take a deeper look for a moment if you are not after quick shots and go beyond experiments for a sustainable (and large) infrastructure.

So we have got many clouds out there. Deployment automation means, they have some API.

So what does make a deployment automation tool delivering *infrastructure as code* capability?

* **(1)** Unified, programmable, configurable abstraction layer, also *[called domain specific language](https://en.wikipedia.org/wiki/Domain-specific_language)* (DSL).
* **(2)** An [object model](https://en.wikipedia.org/wiki/Object_model) of (multiple) cloud assets and available services.
* **(3)** Corresponding logic to execute actions on the assets typically: *[create, read, update, delete](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete)* (CRUD) and synonyms.

Now there are some challenges to address human readability and sustainability varying by programming language ecosystems and communities:

* Cloud products being themselves computer infrastructure and network engineering (these are different disciplines!) abstractions are not following some official "cloud domain" ISO/IEEE naming standards as far as I know. That is, all the names are pushed by vendors and might be marketing biased. So either you invent your own terminology or decide which terms are most generic, or a mix of that. There is therefore a good reason that you find also cloud vendor specific deployment languages and tools for example like *Cloud Formation* by AWS.
* *Somebody* needs to maintain related components to support new API versions for *every cloud platform*!

Some deployment tools delegate the *cloud driver* (that's another term for cloud platform specific code bases) to separate projects, which in their term delegate responsibility for API compatibility to one or another boilerplate (=often boring and tedious) API implementations.

Therefore my conclusion is that depending on your purposes the most straight-forward way to write infrastructure as a code is the programming language of your choice using a well-supported SDK which is though vendor-specific!

Still this is the point where you have got greatest flexibility because for a small standard use case you could write your own abstraction layer and your custom logic whatever you want.

Python examples:

* *boto3* for AWS
* *exoscale/cs* for Apache CloudStack
* *python-openstackclient* for Apache CloudStack

Recent Terraform example: its Apache CloudStack driver has [backward compatibility problems](https://github.com/terraform-providers/terraform-provider-cloudstack/issues/72) because it's based on some less-visible [CloudStack API SDK written in Golang](https://github.com/xanzy/go-cloudstack). I am sure you can run into problems of this sort with any deployment tool; so if you commit to one, bring enough courage and patience to connect with and contribute to the corresponding community (same is for SDKs but they at least typically have less abstraction).

That is, before deciding for a certain cloud deployment automation tool, consider besides the things you see on the surface like syntactic sugar and community support also the following aspects:

* If it's open source, is it written in a programming language where you/your team could create an emergency patch if things go really worse?
* How well supported are those cloud drivers critical to your business: these typically can't be *all* of them, if so, you might run into issues like [GitLab with *Docker Machine*](https://gitlab.com/gitlab-org/gitlab-runner/issues/4338) (also a specific deployment tool after all), where a significant technical base for a competitive product feature [suddenly breaks away](https://github.com/docker/machine/issues/4537) because all the responsibility in this context had been factually outsourced to the open source community.


---

### Answer by username_2 on 2020-01-08. Score: 1

These tools serve slightly different purposes: use a *configuration management* tool like Ansible/Puppet for configuration / customization and orchestration tool like Terraform to provision infrastructure.

Ansible and Puppet are primarily configuration management tools. It is suitable for resource customization and configuration.

Puppet requires Puppet Agent installation on each server. Ansible doesn't require any agents. It uses SSH protocol for performing all operations.  
Ansible supports YAML syntax. Ansible is little more popular now than Puppet.

Terraform is an infrastructure orchestration tool that supports many cloud platforms.
With Terraform you simply declare resources and how you want them configured and then Terraform will map out the dependencies and build everything for you.
I prefer to use it to provision VMs and Cloud services like Databases or Storages.

All three tools have excellent community support.

> **Comments:**
> **username_1**: Hi Evgeny. Could you support your answer with some references or links?  
> **username_2**: Hi Bruce. This is related post - https://www.ibm.com/cloud/blog/chef-ansible-puppet-terraform  

---

