Terraform is an excellent tool for infrastructure provisioning, you can find a lot of pros to starting using Terraform, but you also should know about the downside of Terraform.
Providers limitation
Terraform essentially is the way to create resources via providers. Under the hood provider calls some 3d party service API (for example, AWS API or Azure API).
So to use a new version of API, you need to have a new version of the Terraform provider. In reality, Terraform providers might not support the latest features of API. Or even some old features available via API might not be supported by the Terraform provider.
For example, Microsoft Azure DevOps API supports kubernetes resources creation, but it is not supported by terraform provider. The Pull request with this feature has not being approved for a long time.
Some companies develop Terraform providers for their API and maintain it. But some Terraform providers are created by enthusiasts who might abandon their project anytime.
Hashicorp knows about this problem, so they try to support many providers by themself until official providers are provided.
https://registry.terraform.io/search/providers
I recommend to check provider git history and activity before using terraform provider.
HCL limitations
HCL is Terraform language, it is a very limited.
For example, you need to use hacks to emulate "if" statements, like following:
Because of count usage terraform creates list of resources instead of single resource. So the path for created vm is: module.test_vm[0] just because we want to have conditional creation. StackOverflow question about it.
But Hashicorp improves HCL constantly, for example we just got Terraform 1.3 with optional object fields supported, so now we can have defaul values no only for entire variable, but also for object field.
HCL support in IDEs still far from perfect. Autocomplete is not very smart and reminds me early years of JavaScript. Jetbrains did a great job supporting HCL in their IDEA familiy.
Autocomplete doesn't support object definition in maps.
Apply-only errors
Even if Terraform plan is green, Terraform apply might be errored.
Terraform apply does real API calls, which might fail because of validation errors, eg. "resource name is too long" or network connectivity issues. For example, you might ask to create a database before the database server is created. Terraform requires you manually define resource dependencies with the depends_on property of the resource.
It would help if you had a stage environment with the same terraform state to test Terraform apply before doing the same change for production environment.
State is fragile
Terraform can manage resource only if it is tracked by Terraform state. So if a resource was deleted manually, you need manually delete the information about the resource from Terraform state. Terraform state might "drift" for various reasons, and fixing it might be tricky.
For example, I wrote script to get resources ids from REST API, and import it to terraform with terraform import command.
The drift detection is one of features Terraform Cloud, but not terraform itself.
Terraform Cloud
Terraform cloud has numer of cool features you might like to have. But it is also vendor lock and third-party dependency you can't control or diagnose.
The most irritating thing is "You have exceeded the API's rate limit." error in the middle of work you need to do.
Conclusion
Despite on all this issues, I think that Terraform is a great tool for infrastructure manament.
Top comments (0)