The future of code for infrastructure: Terraform or Pulumi, Past or Future…

Marcelo Barbosa
5 min readOct 6, 2020

The code is the key to determine if your company will be another level of Infrastructure management and automation. This has never so been clear as the last in recent years.
The number of opportunities for professionals like DevOps, SRE, or an Infrastructure Engineer in some markets exceeds the demand for Software Engineers.
Sounds that the tools that have been used successfully for a while seem to no longer serve teams and companies.
Nowadays, with the high demand for hybrid cloud, and even for companies that choose a unique cloud provider are failing. The tools didn’t provide support for containers, passing through virtual machines, and covering other services that want adopting best practices.
Faced with this scenario, many looked at Terraform as a tool that has achieved considerable success in provisioning infrastructure in different cloud providers as the final solution for all issues.
However, innovation is hardly made up of sudden jumps as many would like to tell.
Terraform has already had its importance, but given the points, I want to share in this article, it is proving to be a tool that will have to fight to continue receiving all these highlights.

“Terraform has already had its importance…”

The key: HCL

Hashicorp Configuration Language was created to be used in Terraform a descriptive way as a more flexible alternative than the YAML market standard. If we look at so many other projects like Kubernetes, Helm, Ansible, that uses YAML as their descriptive language, we realize that the decision to create this language started to be questioned as soon as it proved to be not as flexible as was thought, and soon the second version arrived: HCL2, leaving many negative comments and affecting projects that sought consolidation, even if partial.
This reminded me of Edsger W. Dijkstra who in 1968 wrote an article “Go To Statement Considered Harmful” demonstrating the harmful effects of its use.

“the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all” higher level “programming languages” - Edsger W. Dijkstra

--

--