I have to start by saying it out loud – Terraform is pretty nice. It really makes Infrastructure as Code – very very real. For a person like me coming from a Software Engineering/System Engineering background this takes the infrastructure to a level where it can be pulled in (if not into) the software engineering teams, then at least very, very close to. The word here is agility.
AWS and Terraform
My experience with Terraform is pretty young (at the time of writing somewhere between 48 and 72 hours) – which makes me vulnerable to being capable of seeing all the benefits, but haven’t really seen the risks yet. After first spending some hours randomly googling (which was also very productive) I hit the course on Terraform on LinkedIn learning. That is the only background here.
In below screenshot – is the spun-up hosts from my “Ceph on AWS” testing I’m currently trying to do (Another article on the sanity of running Ceph in AWS) – Terraform code on Github
Terraform and Providers.
In Terraform “AWS” is called a provider and searching at the Terraform registry delivers a awful lot of providers. Searching delivers way more than 200 different providers – and a registry very full of modules ready to use.
What is the value?
To agile development teams – this delivers the ability to take the Infrastructure into the sprint cycles.
- Want you application seperated out into a seperate subnet? (Done!)
- What a load-balancer deployed? (Done!)
- Want to push firewall in place around the infrastructure? (Done!)
It is very easy to use, but the underlying understanding of how infrastructure works is still needed to get things correctly configured up.
Remember that in many cases – the alterative is to deliver wish list to the infrastructure team and wait for them to find time and implement – something that in large companies may take weeks or months.