iasql VS Quick Start

When the VPC endpoints are enabled you can access your S3 buckets using this endpoint. In this post, we will walk you through how to control your buckets from an internal network with the desired security, and without the extra costs of a NAT gateway using a VPC endpoint and IaSQL. IaSQL is an open-source software tool that creates a two-way connection between an unmodified PostgreSQL database and an AWS account so you can manage your infrastructure from a database.

IaSQL is an open-source software tool that creates a two-way connection between an unmodified PostgreSQL database and an AWS account so you can manage your infrastructure from a database. In this post, we're going to discover an IaSQL module that's built to make deploying to ECS, simplified. Most of the details for deploying a container to AWS ECS are the same (load balancers, security groups, IAM roles, etc), and we have created the aws_ecs_simplified module for you so that you can give it any Github repo with a Dockerfile and get your app deployed to ECS in the fastest time possible, with scalability available! All the needed resources are going to be created automatically in your AWS account, and you'll have full access to the details while you're gaining the benefit of a higher-level simple deployment.

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. :)

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. :)

By "cloud infra" you mean AWS cloud infra, right? https://github.com/iasql/iasql/blob/v0.1.1/package.json#L75-...

Your node js is borrowed technology from china: https://github.com/midwayjs/midway