If you check our website, you will find a Tech article about AWS. AWS is a great tool for controlling costs, especially for larger projects in which there is a need for a special person just for infrastructure – AWS allows not to hire such person and continue using distributed computing power that is maintained by highly qualified Amazon staff, that is probably much better than a small startup can ever find and afford to pay for.
If you are a real tech guy that cares about stable work of the business, one of the first questions while deploying to AWS is “How do we duplicate our infrastructure between dev/qa/prod?”.
Especially when your infrastructure consists of hundreds if not thousands of blocks (it is very possible, since every function is a separate Lambda than needs roles, etc).
The approach which allows to keep the whole infrastructure as metadata is called Infrastructure as a Code (IaaC).
If you have your infrastructure in IaaC script format, you can redeploy it a thousand times automatically. If you don’t have such script – you have to deploy thousands of blocks in each environment manually. That’s a no-brainer.
One another great thing with IaaC is that if you modify the script of the infrastructure, it will not recreate the whole existing infrastructure, but only calculate the differences between the current and desired state, and apply just the small needed touches so that you have the final version.
Amazon has thought of it and has their own technology called CloudFormation. It works, but it is slow to support new features.
One of the best 3rd party solutions is terraform. It supports new AWS features even faster than Amazon’s own Cloudformation, but also terraform supports tens of other providers, such as Google Cloud, Github, Azure and many more. All those providers can be handled in the same script! So it really gives you control over the ever-growing complexity of your project.
And we shouldn’t talk only about script, we should talk also about state (the file with which you store the existing infrastructure). With CloudFormation, you will have a separate state file for each provider. With terraform, you have just one. That’s the final deal breaker!
So, that’s why terraform is often preferred to just AWS CloudFormation.
