If you search the Internet for “infrastructure-as-code”, it’s pretty easy to come up with a list of the most popular tools:
- CloudFormation (Which is Close-Source)
What’s not easy is figuring out which one of these you should use. All of these tools can be used to manage infrastructure as code. All of them are open-source, backed by large communities of contributors, and work with many different cloud providers (with the notable exception of CloudFormation, which is closed source and AWS-only). All of them offer enterprise support. All of them are well documented, both in terms of official documentation and community resources such as blog posts and StackOverflow questions.
What is Configuration Management?
Generally, Ansible, Puppet, SaltStack, and Chef are considered to be configuration management (CM) tools and were created to install and manage software on existing server instances (e.g., installation of packages, starting of services, installing scripts or config files on the instance). They do the heavy lifting of making one or many instances perform their roles without the user needing to specify the exact commands. No more manual configuration or ad-hoc scripts are needed.
What is Configuration Orchestration?
Tools like Terraform are considered to be orchestrators. They are designed to provision the server instances themselves, leaving the job of configuring those servers to other tools. Orchestration addresses the requirement to provision environments at a higher level than configuration management. The focus here is on coordinating configuration across complex environments and clusters.
Which is the best?
Configuration management (CM) tools are great at config nodes but less good at coordinating complex tasks. Orchestration tools tend to leave configuration to specialist tools. There is overlap in these roles and capabilities, and most tools can be used in both roles. In practice, some of the tools are going to be a better fit for certain types of tasks. The table following compares the most popular open-source tools.
|Type||Config Management||Config Management||Config Management||Config Management||Orchestration|
|Architecture||Client/Server||Client/Server||Client only||Client only||Client only|
Important concepts description
Language: Procedural vs. Declarative?
Chef and Ansible use a procedural style language where you write code that specifies, step-by-step, how to achieve the desired end state. The onus is on the user to determine the optimal deployment process. Terraform, SaltStack, and Puppet uses a declarative style where you write code that specifies the desired end state. The IaC tool itself then determines how to achieve that state in the most efficient way possible. Procedural languages are more familiar to system admins who have backgrounds in scripting. Declarative tools are more familiar to users with a programming background.
Infrastructure: Mutable vs. Immutable?
Traditional server environments are mutable, in that they are changed after they are installed. Administrators are always making tweaks or adding code. CM tools evolved to manage this complexity and bring order to the configuration and updating of tens to thousands of servers. Immutable infrastructure is one in which servers are never modified after they’re deployed. If something needs to be updated or changed, new servers are built afresh from a common template with the desired changes. This is the world of Terraform, where new servers replace the existing servers. This is also the philosophy of containers. With orchestration, immutability is easily applied to servers as they usually have built-in support for managing the lifecycle of a resource from creation to tearing down.
Orchestration vs. Configuration Management?
My observation is that as cloud environments continue to grow in complexity, the need for orchestration increases. The growing requirement is for coordination of components and the management of the dependencies between the config of one service and another. Immutability avoids certain issues like configuration drift and problematic snowflake servers. Think “cattle” and not “pets.” However, to reap the benefits requires deployment automation, rapid server provisioning, and the handling of stateful data and ephemeral logs. For me, this means one tool focused on infrastructure orchestration and another on applications. This brings together the benefits of a focused orchestration tool such as Terraform along with a wide choice of configuration management tools. This is one of the beauties of Terraform—it can easily work with your config management tool of choice to provide customized application delivery while maintaining the benefits of immutability.
In my opinion, if your role is based on implementing and maintaining Infrastructure, like bare-metal servers, virtual servers, or having a lot of servers on the cloud, it is suitable for you to use an IaC. Terraform can be a good choice for medium or large companies. Also, it is possible to use IaC tools with a CM tool together. For example, You can create and update your infrastructure by Terraform. Then, use Ansible or other CM tools for package installation and service configuration.