5 ms·
Tools like this can be very useful in supporting operational use cases in addition to documentation. The tricky part with cloud is how to effectively visualize
by jcims 6y ago
Tools like this can be very useful in supporting operational use cases in addition to documentation. The tricky part with cloud is how to effectively visualize infrastructure that is composed of a variety of services and attributes. If you have a VPC in each of two regions with dynamodb, s3, ecs, alb, third party providers with access via cross account roles, etc etc it gets tricky to sensibly lay out and demonstrate relationships between the indivdiual components.
Hopefully this will get traction and they will start to build in some of this intelligence and perspectives into the application (presumably as a plugin).
- taftster 6y agoRight. When a tool like this can actually "compose" a dataflow using cloud native components (lamdbas, messaging, storage) in real time, this has potential to be super powerful. Think of, for example, Apache NiFi [1] but instead of the components being constrained to a single JVM execution, the components are realized as AWS or Azure services. That "operational view" of your architecture would be super neat, especially when statistics about each component can be visualized in real time. [1] https://nifi.apache.org https://nifi.apache.org
- Veuxdo 6y agoIt is impossible to express all of the relevant information about an architecture in a single view. That's why a diagramming tool that natively supports multiple views/perspectives is a must-have. Anything less is just a toy, frankly.
- Supermancho 6y ago> It is impossible to express all of the relevant information about an architecture in a single view. Yet lots of people have been doing it, successfully, for decades with pen and paper (equivalent). I think you need to constrain your use case from "all architectures" to whatever it is you are trying to describe.
- jcims 6y agoWhile I totally agree, I think we rely on people just making sense of the diagram based on context. Say you're diagraming the architecture of the aforementioned app and you have your VPCs and your ELBs and compute and subnets and IGW and tidy little boxes containing them all to indicate this is everything in prod AWS account, us-west-1. Then you need to add an S3 bucket and dynamo db table. Most people would just drop a bucket icon outside of the VPC and label it...maybe dynamodb sits inside the region box and s3 kind of straddles it. Good enough conceptually to talk through the design. Now imagine you want to automate the process of generating that view (or the associated resource graph) automatically. That's where it gets tricky. Tons of service-specific rules start to come into play. Kind of a mess.
- Veuxdo 6y agoFurthermore, you have your security groups, roles, permissions, and policies. Plus you have build-time concerns (CF templates, CodeBuild builds, images, etc.). You simply cannot fit that into one view and have it make any kind of sense. And those are just static relations. For interactions and data flows, you need sequence diagrams. I wrote about this last month: https://blog.ilograph.com/posts/fixing-aws-architecure-diagrams-distributed-load-testing/ https://blog.ilograph.com/posts/fixing-aws-architecure-diagr...