In the ever-evolving world of software development, we’re often swept up in the latest trends and innovations. Lately, it seems like every developer is talking about ‘microservices architecture.’ The race is on to create as many microservices as possible, with teams proudly showcasing their expanding collection of small, independent services. It might sound like a competition to see who can have the most microservices, but it’s not that simple. In this blog post, we’ll explore a fascinating challenge that hides beneath the surface of the microservices excitement. It’s a topic often overlooked in the midst of all the buzz. You see, every architectural choice we make in software development is a bit like a double-edged sword – it has its benefits, but it can also introduce complexities that significantly affect our systems. It’s time to dive into the less obvious side of the microservices trend and learn about a metric called ‘Average Component Dependency’ (ACD).
The potential problem
Now, let’s imagine a scenario: you’ve reached a significant milestone in your project, and you’ve amassed an impressive collection of 100 microservices in your software ecosystem. It’s a remarkable achievement. However, a seemingly small request comes in – a request to make a minor change to one of your APIs by adding a new field to a contract. This leaves you with a crucial question: how many of your carefully designed microservices will be impacted by what seems like a minor tweak?
This is where it gets interesting. To solve this puzzle and predict the effects of your change, we’ll take a journey into the world of Average Component Dependency (ACD). Get ready because this metric is like a key that unlocks the secrets of the complex relationships between your microservices.
What is Average Component Dependency (ACD)
To make sense of this maze of microservices and calculate the Average Component Dependency (ACD), we’ll start by exploring metrics that measure how tightly different parts of the software are connected and how they affect its overall structure. These metrics are essential for ensuring your software remains manageable and strong over time, a crucial aspect for any developer aiming to build a robust and long-lasting system.
One of these metrics, called Average Component Dependency (or simply ACD), was introduced by John Lakos in his influential book ‘Large Scale C++ Design’ (Addison-Wesley, 1996). ACD isn’t just another complicated number; think of it as a tool that can tell you, on average, how many other elements a randomly selected component relies on – both directly and indirectly, even including itself.
Excited to learn more? You should be. ACD is like your trusty compass in the vast world of microservices, helping you understand the consequences of your changes and make informed decisions to ensure the long-term health of your software.
How to calculate ACD?
Now, let’s simplify things with an example. Imagine a graph like the one below.
In this context, each node represents a microservice and is assigned a numeric value. To put it another way, we can understand these numbers as follows: by counting the number of nodes that can be reached from a specific node and then adding one to that count. In the world of graph theory, this set of nodes reachable from a particular node is known as its ‘closure.
If you add up all the values in the boxes you come up with a sum called Cumulative Component Dependency (CCD), which in this case is 18.
ACD = CCD/ n, where n – is the total number of nodes/microservices.
The minimum value for ACD is always 1, which would describe a system without any dependencies. The maximum value is equal to the total number of nodes/microservices; in our example, that would be 6.
In the above illustrative example, we can determine that ACD is calculated as 18 divided by 6, resulting in an ACD value of 3.
What does this mean for you as a software developer?
Well, it’s a valuable insight. It suggests that in a scenario akin to the one above, when you make modifications to a service, on average, approximately 3 other services will be impacted by the change. This is precisely what ACD, or Average Component Dependency, reveals. Armed with this metric, you gain a tool to assist in making informed decisions when the time comes to introduce yet another microservice into the mix. It’s a compass for navigating the intricate world of microservices architecture.
Conclusion
The Average Component Dependency (ACD) metric provides us with valuable insights into the level of coupling within systems. It quantifies the average number of microservices that are likely to be impacted when a modification is made to a single microservice. ACD depends also on the size of your system so If your system is small (n < 500), higher ACD values, for example 100, are less concerning.
For midsized systems (500 <= n < 5,000), ACD values over 100 are concerning, while values over 1000 point to serious issues with large cycle groups.
If your system is huge (n >= 5,000), even a value of 500 is already quite concerning.