![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Automating all the things
Jun. 10th, 2020 08:46 pmBook Review: Terraform: Up and Running: Writing Infrastructure as Code, by Yevgeniy Brikman
I first encountered Terraform in a previous job, though it was heavily repackaged by an infrastructure team to the extent that I found it exhibited something like the Lasanga code anti-pattern (aka "wool wrapped in cotton"), where additional layers serve no value and inhibit understanding of the tools in use. We've been experimenting with it in my current job, so there's been a good opportunity to get a better handle on the basics of the tool and - perhaps - to avoid some of the mistakes encountered in the past.
It's an imperfect analogy, but I think of Terraform as Puppet/Chef for the cloud, and indeed that's where Brikman begins, discussing "configuration management" software versus "provisioning" software, and pointing out that in fact these things can cross over to a considerable extent; some tools are declarative whereas others are procedural, and so on. The book does a fairly good job of describing HCL (Hashicorp Configuration Language) and the Terraform tool. The examples all use AWS, which is a reasonable choice though obviously not for everyone. One of the strengths of Terraform is the support for a wide variety of ecosystems - Azure and GCP are supported as well, for example, as are other cloud systems.
One area I have to disagree on - or perhaps I misunderstood - is his recommendation to create separate folder structures for different environments. For me, the risk of diverging two or more sets of files negates so much of the benefit of using the tools in the first place, and I've seen that happen. Of course, the back-end state, which is used to keep an inventory of the resources under management, must be kept separate. It's better when you can partition your infrastructure into small pieces of state, too, so that you can lower the risk for any individual change. It's inevitable in a book that you will focus on an end-to-end example, but then assembling all the resource configurations so that you can provision everything with a single command (and a bit of good luck from your cloud provider) feels like it's treating the infrastructure as a monolith, when it would be better to treat it as a set of microservices, each small group following its own release (provisioning) cadence.
The chapter on testing Terraform code turned out to be a bit disappointing - with a tool of this type it's inevitable that mocks and stubs aren't suitable, so everything is to some degree an end-to-end test - but it does at least offer some ideas, and finally observes that testing an entire infrastructure is impractical. It would have been nice to link that to disaster recovery, though: it's not something you want to verify on every build, but a periodic check that you can provision from scratch is powerful. The book concludes with some useful observations about advocating IaC to project stakeholders.
I first encountered Terraform in a previous job, though it was heavily repackaged by an infrastructure team to the extent that I found it exhibited something like the Lasanga code anti-pattern (aka "wool wrapped in cotton"), where additional layers serve no value and inhibit understanding of the tools in use. We've been experimenting with it in my current job, so there's been a good opportunity to get a better handle on the basics of the tool and - perhaps - to avoid some of the mistakes encountered in the past.
It's an imperfect analogy, but I think of Terraform as Puppet/Chef for the cloud, and indeed that's where Brikman begins, discussing "configuration management" software versus "provisioning" software, and pointing out that in fact these things can cross over to a considerable extent; some tools are declarative whereas others are procedural, and so on. The book does a fairly good job of describing HCL (Hashicorp Configuration Language) and the Terraform tool. The examples all use AWS, which is a reasonable choice though obviously not for everyone. One of the strengths of Terraform is the support for a wide variety of ecosystems - Azure and GCP are supported as well, for example, as are other cloud systems.
One area I have to disagree on - or perhaps I misunderstood - is his recommendation to create separate folder structures for different environments. For me, the risk of diverging two or more sets of files negates so much of the benefit of using the tools in the first place, and I've seen that happen. Of course, the back-end state, which is used to keep an inventory of the resources under management, must be kept separate. It's better when you can partition your infrastructure into small pieces of state, too, so that you can lower the risk for any individual change. It's inevitable in a book that you will focus on an end-to-end example, but then assembling all the resource configurations so that you can provision everything with a single command (and a bit of good luck from your cloud provider) feels like it's treating the infrastructure as a monolith, when it would be better to treat it as a set of microservices, each small group following its own release (provisioning) cadence.
The chapter on testing Terraform code turned out to be a bit disappointing - with a tool of this type it's inevitable that mocks and stubs aren't suitable, so everything is to some degree an end-to-end test - but it does at least offer some ideas, and finally observes that testing an entire infrastructure is impractical. It would have been nice to link that to disaster recovery, though: it's not something you want to verify on every build, but a periodic check that you can provision from scratch is powerful. The book concludes with some useful observations about advocating IaC to project stakeholders.