Infrastructure is all the necessary underlining technology that supports your running application. Examples include a server, database or private network.
Before the popularity of cloud all this underlining technology was managed locally. Someone would have to be physically responsible for software updates and upgrades. Now the high adoption of cloud infrastructure allows for their creation in a cloud providers console with a few clicks. Initially it may seem easy to manage all the cloud resources you have.
As you scale or work on larger projects it can be hard to manage all your cloud resources and prices can increase quickly. Infrastructure as Code (IaC) allows you to provision and manage any cloud, infrastructure, or service with code. IaC provides visibility into what resources are being used. That makes it easier to keep track of changes that occur. Using code also allows for automation to play a larger role in your workflow. That removes potential human errors. IaC also standardizes cloud resources because now there shouldn't be any differences between individual servers.
Chef - Uses a Ruby Domain Specific Language (DSL).
Otter - A Windows-oriented solution.
Puppet - Uses proprietary declarative Puppet DSL that's Ruby based.
SaltStack - Acquired by VMWare in 2020. 3rd Most GitHub stars.
CFEngine - The oldest of the group. Used by LinkedIn and Samsung.
Terraform - The one I personally use. Newest of the group and has the 2nd most GitHub star.
Ansible - Acquired by Red Hat in 2015 and ships with the Linux Fedora operation system. Most GitHub stars.
AWS CloudFormation - AWS-only resources can be managed.
Each of these has it's own approach. Here are some strengths and weaknesses between some of these offerings.
- Configuration Management vs Provisioning - Is the IaC tooling more suited for managing software on existing servers or creating new servers?
- Mutable vs Immutable infrastructure - When I make a change are existing resources modified or are new resources created?
- procedural vs declarative - Programming style preference.
- Agent vs Agentless - Does the server that is being configured need to install agent software?
- Master vs Masterless - Does the IaC tooling need it's own server to run from?
- Large vs Small community - Will it be easy for me to find support and resources?
It's best to check your requirements and choose a solution that meets your needs.
There isn't one perfect Infrastructure as Code solution out there. For simpler projects they aren't necessary. It can take longer to learn one of these than just provisioning resources yourself. But as you grow that approach does not scale. In an enterprise environment, Infrastructure as Code is vital for reducing costs, and errors, while increasing visibility across an organization, and consistency.
What's your experience with Infrastructure as Code?