On the choice of cloud services, I'm happy enough using cloud databases (they can do fast I/O and high-availability at a reasonable price). I'm much less happy with their packaged stuff. Tried out cloud composer this week. Turns out that it can't be easily scripted in Pulumi and wants bigger infrastructure than our main application so not the painless composition of services of the marketing brochure.
My experience is that Terraform does encourage vendor lock-in because every cloud have slightly different resource topologies. Picking which resources to manage yourself in a cluster, and which to manage by Terraform seems like a place to strike a balance.
This statement is strange. The author could not possibly have written a line of Ansible, apart from blindly chaining external commands. It is possible to use it like a bash script but that's not the intention. Serializing state is its primary use case, and also makes it different from "running commands over ssh".
- Terraform knows what changes it made, and knows how to revert them. Thanks to the fact it maintains its own state.
- Ansible is able to revert it but only after you explicitly tell it to revert it.
I'm always scared of removing things in Ansible (or any other automation tools) because I've to handle explicitly a case for removing of the things. That's where the statement "running commands over ssh" comes from.
Like if you have a resource in terraform, and remove that resource from the file - terraform will tell you that happend
If you have a task in ansible and remove it - good luck finding out what you need to clean up. You've to know it and know how to handle that case (using state: present or absent where possible).
So at the end - doing terraform destroy I feel pretty confident to have a clean state (and if APIs are not causing huge side effects, it's same state as before applying changes)
Removing resources with Ansible is additional effort and requires maintenance.
Like I said in the other comment - this title might not suite what I intended to say.
Ansible can read the running state which is more robust. External modifications of state happens, if nothing else than as a result of failure modes not under your control. Setting and reading state explicitly is a feature. Code should be committed to git at all times.
Also not related to the content explained, it compares terraform and ansible for most of the content.
My point was that terraform/pulumi are too tightly coupled with cloud providers to the point that it becomes easier to do functionality using it than to maintain set of servers doing the same functionality.
I've often met with the case that when considering a solution to the problem - I was first looking into what my cloud provider offers so that I can put it in a single terraform project, and only then considered any other solutions. The fact I could keep everything in a single place / source felt so powerful addicting and maintainable.
On the other hand if I would like to create the same setup in cloud agnostic way - I can't utilize Terraform at all (for purpose other than setting up the EC2 instance in AWS case).
Hence the title came - because I felt like the hype for "infra as a code" is mostly driven by the fact that if your cloud provider allows scenario you're looking, then I always felt to lean on the side "Yeah, If I can do it in Terraform, it will be easier to maintain in the future" vs "running ephemeral EC2 instance providing same functionality but never sure if its up to date with ansible script and/or contains misconfigurations"
So in hindsight - this might have become too much clickbait.
And even if it did, a tool like Terraform is just the latest iteration of what we've been doing for years already for things like shell scripts. The difference is that Terraform is a declarative language, and therefore it is easier for those who did not write it to review it, audit it, fork it, etc.
