Earlier quoted context omitted.
There are two decoupled parts to IAC - describing the state you want and reconciling that with the actual state of the world. Reconciling can be advanced as you want: you could take into account SLAs, perform progressive updates, or just ignore that and remove/create resources at will. So even if you used SQL and inserted it into a database, it's just a representation of state that needs to be reconciled in a separat…
> You're not even _using_ a database to store your state, you're just using SQL to produce some graph of things you need to reconcile. Well, that's one way of doing it. The better way, imho, is to actually have a database to store the state. That also solves: > You would create all these resources, then modify them, then delete them, then create some new resources as a linear history of operations. Not good, very bri…
It doesn’t matter how the state is stored, you still need to reconcile it. So yeah you can write your target state into a database if you wish, but you need something else to compare that with the state of the actual world and progress that towards the state you requested.
> When you have an actual database backing your SQL queries, the migrations would all run in this DB, produce a final state of the DB, then this final state would get applied to bring up your system in one shot.
Yes, what you are describing is how Terraform works. Without SQL.
Except it’s never “one shot” because it’s a DAG of requirements where each resource creation can fail.
> Sure, and that's fairly easy to derive, because we already have a unique identifier, the bucket name
In this specific case, sure. But for a KMS key or in the general case, no you wouldn’t. You’d also be hard-coding provider specific information into your system - “a bucket ARN can be derived from the name attribute”. This is not always the case - consider any REST api that accepts a POST request to create something, but returns only an incrementing integer primary key to uniquely identify it.