4 ms·
Everything in the real world is quantum state but that doesn’t stop every SaaS application out there from using an RDBMS as their system of record. This is why
by rubiquity 5y ago
Everything in the real world is quantum state but that doesn’t stop every SaaS application out there from using an RDBMS as their system of record. This is why we have reconciliation processes. Terraform state files are just an ad-hoc storage format without any of the features that SQL and RDBMS have had for decades (I don’t mean to pick on terraform so much, it’s just the one I’m most familiar with).
- stingraycharles 5y agoLike someone else says, SELECTs make sense, INSERT/UPDATE/DELETE to manage infrastructure state, rather than using “proper” infrastructure as code, sounds like a path to hell to me.
- eloff 5y agoWhy specifically is that worse than config files?
- stingraycharles 5y agoconfig files / templates are typically declarative, you tel some orchestrator “this is how I want my infrastructure to look like, please detect changes and make it happen”. it makes it much more easy to reason about things, as state is abstracted away.
- yawaramin 5y agoWhat's the difference in declarativeness between: - Opening a YAML file in a text editor, deleting some lines, then doing a Kubernetes or Terraform or whatever apply operation - Creating a SQL migration to delete some rows from a table, checking the migration into the repo, and then running a database migration ?
- dspillett 5y agoIf properly modelled so the modifying operations are consistent and logical, SQL for modification has the advantage over "proper code to update" has the advantage that in many cases the same query to find something is used with only minor alteration to modify it. Now the real magic, would be to make changes atomic!
- verdverm 5y agoTF has locks so that two people cannot modify infra at the same time. There are also dependencies within the resources to consider, such as network creation before firewall rule before VM
- yawaramin 5y agoYeah, and Terraform providers can be buggy and actually mess up those dependencies. I ran into this very recently where Terraform planned my changes successfully but failed to delete something because it had a dependency on another thing which it was planning to delete later. It would be very difficult to mess this up with SQL foreign keys.
- oneplane 5y agoUnless it can also do state verification, planning and the three-way: desired state, expected state and actual state in one diff, it doesn't hold a candle to Terraform. At the same time this SQL would be useful when used in combination with a classic database migration framework which essentially comes down to a bad version of terraform. Inversely, you could simply use de Terraform CDK and an SQL adapter to write SQL into Terraform definitions. People who want to use SQL can use that, and in the background it's still terraform with all its benefits.