91–100 of 113 posts
Just why... why would anyone uses / learn SQL to manage infrastructure. Also fyi people managing infra are usually not the one doing SQL.
I see a lot of criticisms for not wanting to use SQL to do writes and I think that is misguided. The current state of your infrastructure is absolutely state and SQL is a great language for working with state. While Terraform and all these other "declarative" infrastructure tools are better than what came before them, you're ultimately playing Relation Stitcher by needing to connect the various pieces together. There…
SQL is a great* language for querying relational data..
(* Unless you need to pull relational data out in a tree like structure rather than flattened and denormalized set of rows, in which case you need to wrap a bunch of logic around it to get that type of output)
> you're ultimately playing Relation Stitcher by needing to connect the various pieces together.
I don't see how doing this in SQL does away with that.
SQL also runs in to the same problem pointed out about Ansible; You, the "meat bio-processor", have to pre-calculate and declare the load order for dependencies (make VPC, then make firewall rule tied to VPC, then make VM tied to VPC and firewall rule), you can't leave the execution order or the decision of conditional execution up to the engine (VPC with that ID found, just get the ID, don't recreate it), it's on you to make each of these decisions... That's easy enough for a toy use case, but any large production system and it'll fall apart from too much context needed.
Earlier quoted context omitted.
Like 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.
Why specifically is that worse than config files?
it makes it much more easy to reason about things, as state is abstracted away.
In all seriousness, one issue I see in the comments here is that we're still not truly in the mindset of "infrastructure as code" mode.
If the existing infrastructure is so fragile and precious that DROP DATABASE is a non-starter as opposed to Chaos Engineering 101, then SQL paradigms are not the problem.
Earlier quoted context omitted.
> yeesh INSERT/UPDATE/DELETEs would scare the heck out of me Out of curiosity, why would they?
1. Idempotency. Accidentally run an INSERT twice and you get two VMs instead of one. Sure you could be careful and do upsert-queries but is everyone in your org equally careful? 2. Reverts, in terraform it's as easy as removing the resource and re-applying. Or even just run teardown. Even if you've added other things in the meantime. With SQL if you've INSERTED something you need to come up with the corresponding DEL…
Earlier quoted context omitted.
One reason is because TF supports many clouds and people like having skills that are not vendor specific
Half true. The true half is that terraform will work out of the box with basically all clouds and many saas vendors. The untrue half is that terraform does nothing to abstract away the underlying vendor. You cant treat gcp VMs the same as aws EC2 instances. You do get to reuse HCL.
Not sure of any tool that could abstract the details sufficiently to be widely adopted. There is just too much nuance in cloud config.
I'm exploring using CUE (https://cuelang.org) to define TF resources, exporting as JSON for TF. So far it's much nicer
Earlier quoted context omitted.
Infrastructure is quantum state. AWS APIs lie to you. Status pages lie to you. If I had a nickel every time the solution to a failing HTTP call was "just send it again"... Use whatever tool you like: SQL, Rust, carrier-pigeon - but it wont be a panacea to solving cloud infrastructure.
I'll bite. What infrastructure management tool do _you_ prefer then?
So Terraform and Ansible come to mind. Both deeply flawed, but they become the least-worst current option.
People should still strive for better, test new ideas with new tools, but choices for production code should play it safe almost every time.
Earlier quoted context omitted.
I'll bite. What infrastructure management tool do _you_ prefer then?
Every tool is flawed and picking the right one for your problem is about weighting tradeoffs, that said tools with large well-run communities, the right corporate sponsors and contributors, and enough tenure to round out the sharpest edge cases, are generally "better". So Terraform and Ansible come to mind. Both deeply flawed, but they become the least-worst current option. People should still strive for better, test…
Earlier quoted context omitted.
Why specifically is that worse than config files?
config 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.
- 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
?
Earlier quoted context omitted.
If 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!
TF 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
It would be very difficult to mess this up with SQL foreign keys.