Terraform was made for exactly the reason you stated ("single language for all kinds of cloud infrastructures")
It was also made for non-developers to be able to deploy what someone else built "anywhere"
It was also made for non-developers to be able to deploy what someone else built "anywhere"
Also, as stated in a sibling comment, all the commands, expressions and capabilities of Terraform differ based on your $CLOUD, so in the end it's not that universal.
In fact, it's not different from bash - bash is always the same, you just type `az` instead of `aws-cli`.
>In fact, it's not different from bash - bash is always the same, you just type `az` instead of `aws-cli`.
Terraform works on many platforms (https://developer.hashicorp.com/terraform/downloads)
Not all have (or default to) bash
Whereas Terraform is "the same" everywhere
I am using Terraform because using AWS directly was too cumbersome, and I'm happy with it.
The utility of Infrastructure as Code (IAC) is not “you don’t have to understand the target cloud platform”, which is why cloud providers often have their own IAC solutions (e.g., AWS CloudFormation, and the additional abstractions–Serverless Application Model, Cloud Development Kit–built on top of CloudFormation); Terraform adds multiple cloud support on top, which is useful for people with workloads in different clouds or when working with a vendor whose in-house solution is inferior, but that’s not the whole point.
The utility of IAC is that you don’t have to write custom code based on the current and desired state for each state transition change. You write a description of the target state, and the engine handles determining the current state, what transition code is needed, and executing the transition code.