As companies migrate their applications to the cloud, they can find their architecture diagrams become increasingly complex. These diagrams provide a visual representation of the various components and how they interact with each other. However, they may not accurately reflect the true complexity of the system.
During early access, our team had the opportunity to analyse 2.3 million AWS resources and dependencies to quantify the complexity hidden in architecture diagrams. What we found on average was 3 links for every resource. A ratio not commonly found in even some of the most complex architecture diagrams. Let’s take a look at why that’s a problem.
The problem *with complexity (explained by looking at houses)*
A house plan like the one above is great for giving you a visual representation of the layout and features (number of rooms, amenities.) However, say you wanted to add an extension or even drill a hole in the wall. Would you feel confident that you have everything required to avoid knocking down a structural wall or drilling through a gas line?
Instead, you might consider consulting the building plans or blueprint. They contain the information you need to confidently make your decisions. However while very useful, blueprints can be complex containing lots of measurements and annotations and if you don’t know what you’re looking for may cause more issues.
The same can be said for architecture diagrams…
AWS diagrams like the one above are a great tool for onboarding new engineers or communicating a high-level overview to stakeholders. They give a clear but often concise representation of an application that does not require much prior experience or context to understand. But would you feel confident making a change to your application based on the above Knowing what we’ve already said above about hidden complexity? Even changing something simple like a security group could be problematic. The architecture diagram may show you some connections but there could be other EC2 instances or RDS databases that are also using that security group. If you make a change, it could impact those resources.
More is not always the answer
Does that mean the answer is to generate a diagram mapping out every link and resource that is related to the application that we are making changes to? To show you what that would look like on the same EKS cluster we can run a query in Overmind’s explore feature. We can set the link depth so that will discover all the relationships & links to other resources.
What you can see is that the same application actually has:
Which is much more than what our diagram was telling us. Meaning that now if we wanted to make a change we can see everything that could be impacted, the resources, items links, and meta-data all in one diagram.
But when you’re dealing with this level of detail it becomes a challenge to display and navigate easily in an interactive GUI let alone trying to replicate it in a drawn static architecture diagram.
Which leaves us in a difficult position because in order to confidently make changes we need to know what will be impacted and to know that we need to map out all links to the resource we are changing. But from what we’ve seen when even a simple application has that many related resources and links it can become a challenge to work with.
It is precisely this challenge that has led us to build Overmind. With impact analysis, you don’t need to worry about creating a diagram of your entire application architecture. Tell it what you’re going to change and you will be informed of any resources outside of that scope that have been impacted by that change. Meaning you will have the confidence that the changes you make won’t have any unintended consequences.
We are currently looking for design partners to join our waiting list. Sign up here → waiting list.