7 ms·

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 diagra

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.

cs02rm0 6y ago
The focus would make sense to me if, say, it exported to initial terraform templates or something like that.
- jekriro7 6y ago
  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
  - mugsie 6y ago
    > 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.
    - snejj5 6y ago
      What's the alternative you'd recommend?
      - mugsie 6y ago
        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.
        subhobroto 6y ago
        > 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.
        mugsie 6y ago
        > sounds sweet. imagine applying gerrit to infra Yeah, it is cool - https://opendev.org/ 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
  - kronin 6y ago
    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.
- rbanffy 6y ago
  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.
- subhobroto 6y ago
  Up-voted. That would really make sense and be extremely useful but I don't see anything related to that.
josegonzalez 6y ago
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.
techbio 6y ago
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.
- subhobroto 6y ago
  > "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.

cs02rm0 6y ago

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

jekriro7 6y ago
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
- mugsie 6y ago
  > 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.
  - snejj5 6y ago
    What's the alternative you'd recommend?
    - mugsie 6y ago
      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.
      - subhobroto 6y ago
        > 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.
        mugsie 6y ago
        > sounds sweet. imagine applying gerrit to infra Yeah, it is cool - https://opendev.org/ 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
- kronin 6y ago
  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.
rbanffy 6y ago
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.
subhobroto 6y ago
Up-voted. That would really make sense and be extremely useful but I don't see anything related to that.

josegonzalez 6y ago

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.

techbio 6y ago

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.

subhobroto 6y ago
> "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.