Provisioning infrastructure on public or private cloud providers is one of the main practices of a DevOps Engineer. However, should you do that manually? Actually no, not recommended as it has many disadvantages:
- Manual provisioning of a large infrastructure architecture takes a long time 🕑.
- Manual provisioning is not a practical solution when you try to duplicate that infrastructure to another environment or region with the same specs or small changes.
- Manual provisioning has a high probability of making mistakes as the infrastructure gets bigger.
- Manual provisioning is not the best thing when it comes to updating the infrastructure as it might takes time depending on the changes and you cannot rollback easily to a previous version because you don’t have versioning in your infrastructure.
Infrastructure as a Code or IaC for short solves the above problems and more, and there are many classifications to the current IaC tools in the market (these are personal classifications not standard ones):
- Cloud-Agnostic vs Provider Specific Services.
- Declarative Configuration vs Programming Approach.
Cloud-Agnostic vs Provider Specific Services
Some of the tools are cloud-agnostic such as Terraform and Pulumi, they are suitable for hybrid and multi-cloud infrastructure when you want to connect different cloud providers as a single infrastructure architecture.
Other tools are provider specific services such as CloudFormation and Cloud Development Kit (CDK) for AWS. The benefit of using a provider specific services is the dashboard provided with the service such as CloudFormation and does not cost extra money.
Declarative Configuration vs Programming Approach
Some of the tools are declarative in nature, using a domain specific language (DSL) such as Hachicorp Configuration Language (HCL) in Terraform which has a learning curve (considered a disadvantage), or something like Cloudformation which uses a data format such as JSON or YAML to write the configuration files with extended functionalities to support referencing services and other features.
Some of the tools use programming or scripting languages such as Pulumi and Cloud Development Kit (CDK) for AWS which actually uses the provider APIs to manage services on your behalf and using your favourite language such as JavaScript. Because you are using programming or scripting languages you can statically analyze the code using linters and develop automation testing code like any other code.
Notes
Some of the tools are hybrid in nature, which can be used as a configuration management tool for example and provisioning tool such as Ansible, but I did not mention them and I recommend using each tool for what it was built for.
All of the IaC tools have to save the state of the infrastructure, so if you want to make a change within the infrastructure it won’t delete and create new ones, instead it will make that change only. The way the IaC tools manage the state differs from a tool to another.
