When making your own diagrams, be sure to adhere to the same principles we did: It can now reasonably be used as documentation in its own right. Conclusionīy splitting up the original AWS diagram into multiple perspectives (with distinct goals), explicitly labeling resources and relations, and adding more detail overall, we greatly improved the value of the diagram as a source of information. Furthermore, viewers learn when, how, and why resources are accessed. Individual resources and the relations between them are properly labeled. This perspective, like the previous two, includes much more process detail when compared to the original. Here is our updated version, expressed as a sequence diagram: The first, Ingest, corresponds to this section of the original: The entire ingest-processing-publishing workflow is a long one, so we break them up into three perspectives. A flow diagram is the wrong tool to express this instead, we will show data flow using a more sophisticated tool: sequence diagrams. In reality, data flows back and forth between resources over dozens of steps. Data does not neatly flow from left-to-right in this system in a handful of steps. This is all, to be blunt, hand-wavy and imprecise. Lambda, DynamoDB, CloudWatch, SNS, and SQS are all involved in some way It travels through AWS Step Functions to resources in the AWS Elemental service The second goal of the original diagram (reprinted here) is to show how data flows through the system while it ingests media. Perspective 2: Ingest Flow Goal: Show how video is ingested into the system Rather than try to express this in this perspective, we instead create new perspectives to show them. What this perspective doesn’t show is the dynamic interactions between the resources as data flows through the system. The information contained in this diagram does not have steps the relations defined between the resources are continuously true. This perspective is an example of a static or invariant perspective. Lastly, integrated notes, on the right, help orient the viewer. Giving the dependencies (arrows) themselves names (in the form of labels) also adds precision and clarity. Package, Endpoint, Dynamo DB Table - are not very good, unfortunately). This is most obvious in the Lambda section in the middle, where state machines and Lambda functions are referred to by name (note that some of the resource names in this solution - e.g. Unlike the original, this perspective shows the actual resource names, not merely service names. Perspective 1: Resource Dependency Goal: Show which resources depend on which resources Rather than try to accomplish both goals in a single diagram, we will break the diagram up into multiple perspectives. The second is to show how data flows between them. The first goal is to show the dependencies between the resources. However, based on the information that is in the diagram, plus a careful reading of the solution text, CloudFormation template, and accompanying code, the goal of this diagram can be inferred.Īs it turns out, there are actually two goals for this diagram. We start with the former: First, what is the goal of this diagram?īy goal, I mean the answer to the question “what is this diagram trying to say?” As mentioned previously, it isn’t explicitly stated. We will do so by improving the precision of both the diagram’s goal and its contents. In this article we will improve this diagram to make it valuable for documentation purposes. Given that it is part of technical documentation, however, I believe it needs to be better. Of course, this diagram would be perfectly fine if it were used only as a decorative element in a blog post or a presentation. If this diagram was given to a new hire, they’d probably feel pretty lost. It gives an impression of what is going on in the solution, but lacks specifics engineers would find valuable. Together, these issues make the diagram vague to the point that it is practically useless as a technical document. The arrows are unlabeled, leaving the viewer to guess as to the nature of the relations between resources. The solution’s resources aren’t actually named in the diagram. We can only try to infer its purpose (see below). In the solution docs, it is simply referred to as the “environment” or the “architecture” of the system. The purpose of this diagram is neither clear nor explicitly stated anywhere. While the guide itself is excellent, the architecture diagram is not very useful.Īs a technical resource, this diagram has a number of obvious problems: This article has been updated to include new perspectives.īelow is AWS’s architecture diagram for their Video-On-Demand service featuring AWS Elemental solution. In this series, we focus on the architecture diagrams included in these solutions and attempt to expand and improve on them. Amazon Web Services (AWS) provides a vast library of practical solutions to common business problems.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |