Hacker News Reader

Hacker News

Comment by subhobroto | Hacker News Reader

Full thread

subhobroto

It seems to be hyperfocused on system architecture diagrams.

There are some other kinds of diagrams would we like to draw that’s not system architecture diagrams, eg:

- algorithms

- decision trees

- UML/ER Diagrams

Mermaid (JS) helps draw quality diagrams quickly - more than system architecture diagrams.

It would have been perfect if the development cycles that went here was used to create Mermaid templates instead.

Unless this also lets us draw more than just system architecture diagrams.

View on HN

This would have been perfect for you maybe. I find the Diagrams package to be just fine as it is. A tool or library doesn't have to support _every_ bit of functionality in order to be useful.

The focus would make sense to me if, say, it exported to initial terraform templates or something like that.

I’d prefer to avoid text blob artifacts if this was being used at work with plenty of text blobs to babysit already

IMO the end days for TF and YAML engineering are close, at least for new work

It’s all HTTP APIs. Build a web UX and store the state in a DB.

SRE/ops people ...at work just use the methods everyone else does

Unless the company still has hardware, cloud ops/SRE is just making their lives harder to be different

> It’s all HTTP APIs. Build a web UX and store the state in a DB.

Please no. Don't make running a stateful service a requirement for tooling people need to use when the world is on fire. Or needs to load 40Mb of JS to rebuild a deployment, and works only on Chrome 46.012.2039465. Ops/SRE/DevOps/SysAdmin/SysOps/etc are different, and have optimised things to reduce the amount of dependancies.

What's the alternative you'd recommend?

The explicit, declarative model, using tools that don't need a ton of other things deployed.

Ideally the same tool can be run locally and in CI (with the same invocation commands) so that an Op can run tests locally, and even see the potential diff, before putting it up for review.

The advantage of this approach is you can see a diff, and use standard tooling like git / pr reviews to approve changes in day to day, and when the world is on fire, someone can break the glass and run it locally.

Never underestimate the value of peer review on a change to the infra - there is a reason things like ITIL exist, and we should learn from them.

> The advantage of this approach is you can see a diff, and use standard tooling like git / pr reviews to approve changes in day to day, and when the world is on fire, someone can break the glass and run it locally.

sounds sweet. imagine applying gerrit to infra

> there is a reason things like ITIL exist, and we should learn from them

spot on.

That said, I am unsure if most people here are ITIL aware/certified.

TBH, the primary reason why I am familiar with ITIL is our clients from Accenture days requires certification to win contracts.

> sounds sweet. imagine applying gerrit to infra

Yeah, it is cool - https://opendev.org/ is done that way, as is some of the wikimedia labs infrastructure

I am not certified either - I have just worked in places with ITIL inspired processes, but I can really see a way they can move forward with tools like terraform / pulumi / ansible and git

There is significant value in text blob workflows.

Requiring the definition of everything that makes up your stack to be stored in a format that is not text adds complexity to the disaster recovery process, not to mention mutation, diffing, reviewing, approving, promoting, etc.

For places where a single environment that is updated in place and requires little/no approval to do so, sure. Personally I really like textual definition of infrastructure and configuration, and disagree that it is end days for them.

I'd love if it generated full terraform files with all the required information from the Python code, the rest from sane defaults.

Would also be great to import things with generic names:

    from diagrams.aws.database import RDS as Database

which you could replace at a later point with:

    from diagrams.gcp.database import SQL as Database

And have a provider neutral description that could eventually be compiled into a provider-specific Terraform description just by changing the imports.

Up-voted. That would really make sense and be extremely useful but I don't see anything related to that.

Nice suggestion. The headline appears misleading to me, I like what I see there, but it's really "Diagram as Config" not source code generally.

> "Diagram as Config" not source code generally

Yup!

As "Diagram as Config" this tool is a great fit but not for "Diagram as Code". There are better alternatives out there.

Reply on news.ycombinator.com