Do you ever find yourself wondering why things go wrong with your software and systems even though you may not have changed anything within your configurations or software?
All of our customers, from time to time, experience unexpected problems and outages that seem to randomly appear and consume large volumes of effort and resources. One of the things we have noticed is how many of these problems are almost outside of our control, hidden inside someone else's software.
Modern software is complex, almost all of it depending on other software working reliably and operating in the same predictable way all of the time. Behind the scenes of any software application will be numerous dependencies on other sub-systems. Sometimes there are even dependencies on the way the application has been integrated into the local network, and its interaction with services provided by separate machines.
We believe the 6 main sources for dependency problems come from:
- Integration
- Security Impacts
- Bugs
- Compatibility Issues
- Software Support
- Licensing
If a flaw is found in one of the above, can you be sure that you know which of your many applications are affected by such a problem, and how best to mitigate or repair the issue?
This cartoon from XKCD - https://xkcd.com/2347/ - neatly encapsulates some of the concerns about the fragile inter-dependency of modern software:
Classes of Dependency
The wide range of challenges customers have brouight to us, over the last 25 years, has given us a lot of valuable experience and excellent insights into how things may go wrong. Layer3's system specialists will work collaboratively with your staff to remove doubts and install confidence.
Integration
During the process of integrating networks, systems and applications with each other, there are many ways that a dependency problem might arise. Any given component may have several external dependencies. If one of those dependencies fails, you will need to track down which dependency has failed, determine the root cause of the failure, and then find some way to repair or mitigate that issue.
This can lead to uncontrolled costs if there is no simple fix for the problem.
Security Impacts
Some security issues are critical and must be immediately fixed. Other vulnerabilities may exist in some systems but cannot be exploited for various reasons or are less severe in nature, and are therefore less in need of a rapid fix.
Where a vulnerability is found or reported, you will need to determine which of your applications or systems are affected, which are most at risk, and hence which most urgently need repair. Keeping track of the dependencies, and the extent to which any given system or application is affected, or needs to be urgently repaired, will inevitably entail costs in software/system maintenance.
If attention isn't paid to security matters such as these, it may well lead to a lack of trust by your customers, users or stakeholders. This may lead to some parties losing confidence in your products, with the inevitable consequences on your sales and bottom line.
Bugs
Bugs are sadly a fact of life in any software.
Tracking down precisely where a bug exists can be an open-ended, and hence costly task, especially if it exhibits itself intermittently or apparently non-deterministically. Even if a given bug has been identified in a particular software component, trying to understand what dependencies exist for the component, and hence where impacts will occur, may also be difficult, and hence costly.
Without understanding the dependencies and identifying the component at fault, it may be impossible to reach out to the appropriate support group to find a fix and schedule any relevant repairs.
Even if the bug has been identified, the time to source a patch or fix can produce expensive delays during which time the fault may still be causing great pain. Once you have a fix, actually installing the repair can itself lead to further dependency problems and add to the downtime on your systems, further adding to costs.
Because of all of this, it is wise to have good relations with your various software suppliers, and good support contracts in place with them to ensure you have access to all the latest patches and fixes in a timely fashion.
Compatibility Issues
The inter-dependent nature of various software components, and the ever increasing set of features which come with each component, can sometimes mean that a patch to fix one issue will require the update of the component to a new version which fixes the original problem, but adds yet more features.
This may further require that other components which are dependent on the original component also require to be updated or installed so as to accommodate the new features.
In the worst case, updating a single component can lead to an "update tsunami" involving numerous other components, leaving the overall system significantly different from the pre-patch status.
All of the above adds to costs by increasing the need to thoroughly test all the updated components as much as possible on a test platform, before being confident of rolling out the overall fix to production systems.
Software Support
Any given piece of software may only be supported and maintained for a limited period of time. Alternatively, the maintainer of the software may only provide sporadic support for the component, especially if they are not providing that support as part of their "day job". If your application is dependent on such a component, there may be an issue in the future when the maintainer is no longer able to provide support and bugfixes.
If the software has become "End of Life" for whatever reason, then it will become more difficult to bugfix any issues which subsequently arise. You may have to develop your own fixes in-house, or put together an entire migration plan to move to a completely new version of the application. In the worst case, you may need to migrate to a completely different application which provides equivalent overall functionality. All of these scenarios can involve a significant cost in developing and testing changes.
Licensing
If you are developing your own in-house software using free Open Source Software (FOSS) components, it is wise to be aware of the Licenses associated with each component, and the extent to which you are legally permitted to use the component in a commercial environment.
With applications bought from 3rd parties which make use of such FOSS components, the 3rd party themselves should have sorted out these legal issues, but it as well to be aware of the problem.
Under some circumstances, making commercial use of such components will require that you come to an agreement with the original software developer as to how it may be used. This may require your legal department to get involved in sorting out the fine detail.
Ignoring Licencing can lead to further uncontrolled costs in trying to rectify legal complaints from the owner of the software copyright.
Summary or Point
The overall point is that you need to beware of all the potential interactions and dependencies between different software components, and between applications and the systems which house them, and the network over which they run.
There are numerous different ways in which these dependencies can lead to unexpected costs, and even outages, so it wise to ensure suitable support arrangements are in place, and as much as possible is understood about the inter-dependencies between the components.
How Can We Help
You can rely on Layer3 to help you manage your dependencies, liberate you from unexpected costs and minimise outages. Layer3's experience indicates that while there are many ways unexpected problems can arise, there are equally many ways to achieve highly reliable solutions. No matter what challenges you face, we can help you overcome them!
Please contact us for a free initial discussion - you can either contact us on 0203 805 7795 or email [[mailto:This email address is being protected from spambots. You need JavaScript enabled to view it. This email address is being protected from spambots. You need JavaScript enabled to view it.]]