DROP DATABASE ooops
Cloud Infrastructure as SQL
41–50 of 113 posts
Re: Cloud Infrastructure as SQL
#42I 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…
Infrastructure is made up of many parts. A single S3 bucket may have multiple resources (a key, a policy, a notification queue). How is having several “insert into” statements for each of these any different from “resource” blocks in terraform?
If anything it would be much worse, because you either write some ungodly huge sql statement to create multiple resources or you loose the ability to know what resources depend on each other and form a graph of dependencies.
This results in much slower plans, as you don’t have a dag and you need to potentially refresh state much more often, or something that looks like terraform but with way way more boilerplate and irrelevant syntax.
Re: Cloud Infrastructure as SQL
#43I can see SELECTs being useful here, but yeesh INSERT/UPDATE/DELETEs would scare the heck out of me. Also not clear on how/why this would be a SaaS product - this seems like it's a library you would download, throw some keys at, and thanks.
> yeesh INSERT/UPDATE/DELETEs would scare the heck out of me
Out of curiosity, why would they?
Re: Cloud Infrastructure as SQL
#44I 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…
Infrastructure is made up of many parts. A single S3 bucket may have multiple resources (a key, a policy, a notification queue). How is having several “insert into” statements for each of these any different from “resource” blocks in terraform? If anything it would be much worse, because you either write some ungodly huge sql statement to create multiple resources or you loose the ability to know what resources depen…
We need to be creative and make types relevant to the resources being modeled. If the infrastructure database is just a bunch of string identifier fields then it isn't very helpful. You have to find good abstractions and model the resources in types that bring meaning to the data.
Re: Cloud Infrastructure as SQL
#45I 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…
It kind of already exists... Libvirt is basically a database under the covers. If anything I'm surprised the implementation isn't "AWS backend for libvirt" > "sql frontend for libvirt" In a past life I was managing virtual machines in elixir and not too long after writing a libvirt adapter I realized that what I should be doing is frontending libvirt with ecto (elixirs database tool)
That's interesting! I never thought of libvirt that way.
Re: Cloud Infrastructure as SQL
#46Being able to check in a SQL file to our repo to manage all of our infra sounds like a dream. Added myself to the early access.
Re: Cloud Infrastructure as SQL
#47I can see SELECTs being useful here, but yeesh INSERT/UPDATE/DELETEs would scare the heck out of me. Also not clear on how/why this would be a SaaS product - this seems like it's a library you would download, throw some keys at, and thanks.
> yeesh INSERT/UPDATE/DELETEs would scare the heck out of me Out of curiosity, why would they?
I guess mass administration -> one mistake can destroy everything.
Re: Cloud Infrastructure as SQL
#48Earlier quoted context omitted.
Infrastructure is made up of many parts. A single S3 bucket may have multiple resources (a key, a policy, a notification queue). How is having several “insert into” statements for each of these any different from “resource” blocks in terraform? If anything it would be much worse, because you either write some ungodly huge sql statement to create multiple resources or you loose the ability to know what resources depen…
We need to be creative and make types relevant to the resources being modeled. If the infrastructure database is just a bunch of string identifier fields then it isn't very helpful. You have to find good abstractions and model the resources in types that bring meaning to the data.
Sure, but that’s got nothing to do with SQL and could be modelled in terraform. Or better yet, indirectly using terraform via IAC providers in languages like Typescript.
Show me a proper example of creating an actual s3 bucket that you’d use in production. KMS key, inventory configuration, resource policy, lifecycle policy, logging enabled. Created via SQL.
Now show me how you’d take this and make it a reusable module so we can have a standard template for buckets that everyone can use.
Re: Cloud Infrastructure as SQL
#49Earlier quoted context omitted.
As someone who has to do lots of compliance activities, this is a fantastic tool, thanks!
Great to hear :-) Please check out our open source mods (e.g. AWS Compliance, GitHub Sherlock, DigitalOcean Thrifty) - we'd love your feedback & help! https://hub.steampipe.io/mods
Will do! Thanks again
Re: Cloud Infrastructure as SQL
#50Earlier quoted context omitted.
We need to be creative and make types relevant to the resources being modeled. If the infrastructure database is just a bunch of string identifier fields then it isn't very helpful. You have to find good abstractions and model the resources in types that bring meaning to the data.
Sure, but that’s got nothing to do with SQL and could be modelled in terraform. Or better yet, indirectly using terraform via IAC providers in languages like Typescript. Show me a proper example of creating an actual s3 bucket that you’d use in production. KMS key, inventory configuration, resource policy, lifecycle policy, logging enabled. Created via SQL. Now show me how you’d take this and make it a reusable modul…
You’re focusing too much on the initial creation rather than on going maintenance and evolution. SQL and relations are much better suited to handle evolution by enforcing constraints than a graph of stitched together pseudo JSON.