“Under certain engineering assumptions … the failure rate for a complex system is simply the sum of the individual failure rates of its components, as long as the units are consistent, e.g. failures per million hours. This permits testing of individual components or subsystems, whose failure rates are then added to obtain the total system failure rate”
When writing a recent blog about Data Centre Infrastructure Management (DCIM), it struck me that the additional hierarchy described in its dot points are effectively adding extra complexity and extra layers of things that could go wrong.
Without doing any calculations to back this up, it seems logical that the MTBF (Mean Time Between Failures) of any multi-layer solution (virtualised networks in this case) would be greater than a solution that has far fewer layers (physical networks).
But tied to this, a virtual solution that has more layers also means more complexity for the OSS to manage. In my opinion, one of the main reasons a high percentage of OSS projects fail to deliver on time, budget and/or functionality is complexity, so our objective should be to significantly reduce complexity rather than increase it. Similarly, we should seek to improve solution reliability by reducing complexity.
Whilst SDN and NFV solutions may seem to offer efficiency improvements, I still can’t help but thinking that the increased complexity in their overarching OSS and management suites (not to mention related process complexities) will retard some of the efficiencies gained in virtualised networking.
Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email