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 often 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 rooms, amenities etc.) However, say you wanted to add a extension or even drill a hole in the wall. Would you feel confident that you everything required to not knock down a structural wall or drill 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 from 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 change, it could impact those resources.

More is not always the answer

Does that mean the answer is to generate a digram mapping out every link and resource that are 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 same application actually has:

• 164 related items
• 39 related resource types

Which is much more that 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 in one diagram.

But when you’re dealing with this level of detail it becomes a challenge to display and navigate easily in a interactive GUI let alone trying to replicate the same by drawing a 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.

The solution

It is precisely this challenge that has led us 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 that you will have the confidence that changes you make won’t have any unintended consequences.

We are currently looking for design partners to join our waiting list. Sign up here → https://overmind.tech