Infra-as-Code is cloud lock-in(flicksfix.com)
flicksfix.com
Infra-as-Code is cloud lock-in
https://flicksfix.com/posts/infra-as-a-code-is-cloud-lock-in/
14 comments
I agree. I recently got responsibility for deploying an app on EKS. After collaboration with DevOps on Terraform, K8s/Helm and the myriad of assistive services, I wanted to replicate some of the infra privately, using another cloud provider.
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.
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 is exactly the experience I wanted to describe, but sadly didn't choose correct words for that.
> it can’t tell a damn thing about current state of the system
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".
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".
I find it to be a huge difference in two systems:
- 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.
- 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.
Indeed. Terraform is a single point of failure because it explicitly needs to keep state. For larger environments this is a headache.
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.
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.
For larger environments infrastructure drift is a much bigger headache then that Terraform has to store a json blob somewhere.
Having a combination of state and reading running state (like Terraform does) is crucial to have a tool that can scale for large environments.
That title is both misleading and untrue. Infrastructure as Code is exactly that, a way to define your infrastructure definitions code. There is nothing cloud specific about that concept. You can easily write Terrform to work with VMware instances on-prem.
clickbait title.
Also not related to the content explained, it compares terraform and ansible for most of the content.
Also not related to the content explained, it compares terraform and ansible for most of the content.
After some more thoughts into it I realized I choose the wrong title to explain the concept I felt.
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.
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.
CNCF's crossplane seems like the answer to me:
https://crossplane.io/
Each vendor creates/supports its own 'provider', it is day2 operations ready as it reacts to changes done manually (not like terraform), it's all around well known k8s api
Title doesn't represent what the blog post is actually about.
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.
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.
NixOS can for the most part replace Ansible and it gives you actual configuration as code for your VMs as the OS is built up from immutable configuration files and packages (think Dockerfile layers but for VMs and actually reproducible)
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.