The Illusive World of Monitoring for Legacy Systems

In the tech industry, we obsess over the latest and greatest. Regarding observability, we’re always looking at the most advanced hardware, the enthusiasts’ favorite systems, and the tech venture capital trends to get an idea of what to build for next. observIQ is no exception. We watched ARM architecture go from enthusiasts’ fringe technology for neat homemade projects to mainstream, and we were the first to natively support log management for ARM-based networks on our cloud platform.

Consumers tend to replace their electronics about every four years, and software has reached a point where updates are constant and automatic. Developers worldwide pour hours and billions of dollars into maximizing the value of every last flop. But what about the systems left behind, the old-school infrastructures too old to use new advancements? There are billions of dollars worth of legacy systems worldwide, and there is no hope of receiving an update soon. For example, the United States Department of Defense still uses a computer system designed in 1958. Retail companies spend 58% of their IT budgets on maintaining legacy systems built before 2000. Have observability solutions left these infrastructures behind as well?

Largely, yes. That’s probably a big mistake.

The biggest concern with legacy systems is security. As hardware, firmware, and software age, hacking techniques overtake them. That’s one reason why keeping systems updated is so important. Regarding defense and other government-related systems, the policy is to handle vulnerability from a physical access perspective. Access points into legacy systems are kept physically guarded, even though authorized users cannot bring personal electronics to access points. That works, for the most part, but armed guards are not a viable option for retail, school districts, utility companies, banks, and dozens of other organizations that depend on legacy systems.

The hard truth is that legacy systems are hacked all the time. In high school, it was a running joke how easy it was to break into the district’s academic database and change whatever we wanted. Of course, doing so would be noticed almost immediately since physical records were also retained, but it didn’t change the fact that the system security was beyond laughable. They’ve since updated their system and gone entirely digital, but many districts nationwide have not and have no plans to do so shortly.

Observability is a roundabout method for increased security. It can’t prevent breaches, but it can track them. That would allow the owners of compromised legacy systems to compensate for violations in several different ways, such as correcting information changed during breaches, collecting more information to track down attackers, retaining data about breaches for insurance, compliance, and other future uses, and so on at the end of the day. It’s data about what’s going on in the system, which can be beneficial in many imaginative ways. So, if there are so many legacy systems out there that could almost all benefit from enhanced observability, why don’t log management companies support legacy systems?

The answer is multifaceted, but one intuitive factor is incentive. Even though billions are spent on legacy systems every year, the companies and infrastructures that depend on them have evolved without log management for so long that they’ve invested heavily in other means of compensating for the extra expense of the old systems. Even though 80% of legacy system users profess that the lack of new tech adoption will hurt their organizations in the long run, no one has the will to pack it up and roll out something new. If they did, they would have done it already. If a log management company built a robust solution for a pre-90 system, there is no guarantee that anyone would want to use it. It’s unlikely. Anyone still using legacy systems with the will to implement a log management system for higher visibility and security would likely have the will to implement an entirely new system anyway. In the case of government agencies, which are held back by bureaucracy more than willing to change, there is no guarantee that your system will pass the bureaucratic approval process. If it could, then the agency in question likely already implemented something.

Another reason is the origin of observability. Observability emerged as an industry in the 90’s. From its inception, it’s been focused on supporting the next big technology, not the last one. Many significant shifts in the 90’s with hardware and operating systems marked a sort of flashpoint in the history of computing. Personal computing took off. Work in the United States started down the inevitable path of digitization. The need for robust observability solutions was clear then and well into the future. No one thought legacy systems would last this long. They disappear gradually, which brings us to the final reason.

No one wants to build a fantastic technology to compensate for obsolete technology's vulnerabilities on their way out the door. There may be some money in it, but there is no prestige. If you can construct solutions for the past, you can also solve problems today and in the future. You’re probably better off focusing on where the money is going, not where it was.

So, as unsatisfying as it is, it looks like legacy systems won’t ever receive the same intense, competitive support that contemporary systems get from the observability industry. That said, there are still workarounds. Many open-source observability solutions are created by individuals, published on platforms like Github, and constructed by large, dedicated open-source teams like OpenTelemetry. It’s not out of the question that an inspired IT pro at an organization that depends on legacy systems could adapt any combination of open-source tools to work on their system. They probably won’t get more than a ceremonial employee of the month, but it’s at least possible.