What is the most used tool for Cloud Infrastructure deployment Ansible vs Puppet vs Terraform?

Question

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.

Answer 1

@jasper 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 (DSL).

• (2) An object model of (multiple) cloud assets and available services.

• (3) Corresponding logic to execute actions on the assets typically: create, read, update, 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 because it's based on some less-visible CloudStack API SDK written in Golang. 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 (also a specific deployment tool after all), where a significant technical base for a competitive product feature suddenly breaks away because all the responsibility in this context had been factually outsourced to the open source community.

Answer 2

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.