4 ms·

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

by conqrr 4y ago

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.

franga2000 4y ago
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.
pombo 4y ago
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.

by conqrr 4y ago

franga2000 4y ago

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.

pombo 4y ago

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.