This looks pretty interesting. How does IaSQL's approach to managing cloud infrastructure compare to traditional Infrastructure as Code (IaC) tools like Pulumi and Terraform, and what benefits can developers expect to see when using IaSQL?
IaSQL's approach to managing cloud infrastructure as data provides the following when compared to IaC tools:
- No need to manage or modify JSON state files
- Provides a familiar interface for working with infrastructure resources so you don’t need to learn new syntax if you know SQL
- No need to reconcile or recreate existing resources. IaSQL automatically imports all your existing infrastructure into PostgreSQL as it facilitates a two-way connection between your AWS account and a vanilla PostgreSQL database.
- Treat complex or delicate infrastructure changes as transactions such that your AWS account is not left in a bad state if something goes wrong since there is a rollback functionality when that happens
- Better input validation. Typos are often caught by type safety and fk constraints instead of at `apply` with IaC tools
- Easier to inspect and make sense of large infra deployments. This is an example use case of how users save money on their AWS bill by removing unused ECR images https://iasql.com/blog/ecr-save/
Another co-founder of IaSQL here. There are definitely some similarities with IaC tools in IaSQL; at it's core there's a diffing system between the cloud infrastructure state and the desired state that is used to execute AWS SDK calls to update your infrastructure.
But we also use the same mechanism to take changes in your infrastructure, perhaps made via the AWS console or an IaC tool like Terraform, and pull that into your IaSQL database. We use an audit log tracking who made changes where to determine which way the synchronization process goes, and this gives us a lot of "powers" over normal IaC.
First, you can inspect the tables in IaSQL and be sure that it's actually the state of our cloud (within a few minutes of difference), so you can be more sure that the changes you're writing up are likely to work.
Second, the changes you write are SQL statements to mutate your infrastructure rather than editing a declaration file, which is a different mental model vs IaC. But you gain from the constraints and foreign key relations on tables to catch mistakes in configuration before execution even happens to a greater degree than IaC tools can as this is like a "type safety" on top of dynamic information (other tables you depend on).
Third, you can enter an IaSQL transaction (slightly different from a normal Postgres transaction as you can't hook function calls on `BEGIN` and `COMMIT`) to make these changes and inspect what IaSQL will do like you can with IaC tools, but if there is a failure, the `iasql_commit` will take the information from the audit log and roll back the changes that were applied by applying the prior versions in reverse, so IaSQL should always be in a working state.
Finally, (since this is getting long) the live-infra data model of IaSQL makes dynamic infrastructure much simpler (eg, you deploy isolated instances of your services per customer) -- anything with a SQL client and credentials for the IaSQL database can connect and initiate these changes, which can be Postgres stored procedures you write and added to the database.
We're in beta so our coverage is not as large as existing IaC tools, but we now cover 25 different AWS services with our modules: https://iasql.com/docs/modules/ But please let us know if there's something you use that's missing. :)
yes! we have a SQL editor in our dashboard, but you get a connection string that can be used with any compatible PostgreSQL client since we use an unmodified PostgreSQL database. More info here https://iasql.com/docs/connect/
Among all the ways to represent infrastructure, code, config, SQL etc I always wonder why visualization or no-code isnt preferred. To me infra is complex enough yet has lots of interdepencies that are very well represented visually like a system design diagram. Unlike code, there isn't much conditional logic. There's a lot of edges cases and state manipulation which can also be represented visually. I'm hoping your SQL approach also paves some way as SQL is nothing but tabular visualization in that sense.
I think it's because developers often mistake "parametric" with "programmable". We want to be able to use the DRY principle on our infrastructure, workflows, pipelines, etc. just as we do in code, and have some simple config options to make large changes easily. Code is simply what we're used to.
CAD software is a great example of how this can be achieved without any code. I can construct the whole model visually in its most natural representation, but also define top-level parameters that make broad changes to the end result. And if complex destructive changes are needed, there's always a scripting interface.
I fully agree with this. Our dashboard cues you into which tables have rows in them and you can click on them to visualize the rows much like any SQL editor. I find this to be much better than using the AWS console/UI to understand what is in an AWS account. A few people in the community are interested in making cloud visualizations and we will definitely post about those when they happen. The great part of encoding infrastructure in PostgreSQL is that relations between pieces of infrastructure like an EC2 instance, a security group, and a load balancer are encoded naturally as foreign key relations that you can make sense of in a familiar when compared to the AWS console or `depends` clauses in IaC tools.
11 comments
[ 5.3 ms ] story [ 29.2 ms ] thread- No need to manage or modify JSON state files
- Provides a familiar interface for working with infrastructure resources so you don’t need to learn new syntax if you know SQL
- No need to reconcile or recreate existing resources. IaSQL automatically imports all your existing infrastructure into PostgreSQL as it facilitates a two-way connection between your AWS account and a vanilla PostgreSQL database.
- Treat complex or delicate infrastructure changes as transactions such that your AWS account is not left in a bad state if something goes wrong since there is a rollback functionality when that happens
- Better input validation. Typos are often caught by type safety and fk constraints instead of at `apply` with IaC tools
- Easier to inspect and make sense of large infra deployments. This is an example use case of how users save money on their AWS bill by removing unused ECR images https://iasql.com/blog/ecr-save/
But we also use the same mechanism to take changes in your infrastructure, perhaps made via the AWS console or an IaC tool like Terraform, and pull that into your IaSQL database. We use an audit log tracking who made changes where to determine which way the synchronization process goes, and this gives us a lot of "powers" over normal IaC.
First, you can inspect the tables in IaSQL and be sure that it's actually the state of our cloud (within a few minutes of difference), so you can be more sure that the changes you're writing up are likely to work.
Second, the changes you write are SQL statements to mutate your infrastructure rather than editing a declaration file, which is a different mental model vs IaC. But you gain from the constraints and foreign key relations on tables to catch mistakes in configuration before execution even happens to a greater degree than IaC tools can as this is like a "type safety" on top of dynamic information (other tables you depend on).
Third, you can enter an IaSQL transaction (slightly different from a normal Postgres transaction as you can't hook function calls on `BEGIN` and `COMMIT`) to make these changes and inspect what IaSQL will do like you can with IaC tools, but if there is a failure, the `iasql_commit` will take the information from the audit log and roll back the changes that were applied by applying the prior versions in reverse, so IaSQL should always be in a working state.
Finally, (since this is getting long) the live-infra data model of IaSQL makes dynamic infrastructure much simpler (eg, you deploy isolated instances of your services per customer) -- anything with a SQL client and credentials for the IaSQL database can connect and initiate these changes, which can be Postgres stored procedures you write and added to the database.
We're in beta so our coverage is not as large as existing IaC tools, but we now cover 25 different AWS services with our modules: https://iasql.com/docs/modules/ But please let us know if there's something you use that's missing. :)
CAD software is a great example of how this can be achieved without any code. I can construct the whole model visually in its most natural representation, but also define top-level parameters that make broad changes to the end result. And if complex destructive changes are needed, there's always a scripting interface.