In the tech industry, we obsess over the latest and greatest. When it comes to 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 as ARM architecture went from an 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 personal electronics about every four years, and software has reached a point where updates are constant and automatic. Developers around the world pour hours and billions of dollars into maximizing the value of every last flop. But what about the systems that were left behind, the old-school infrastructures that are too old to make use of new advancements? There are billions of dollars worth of legacy systems still in use around the world, with no hope of receiving an update any time soon. The United States Department of Defense, for example, still uses a computer system that was designed in 1958. Retail companies collectively 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 obviously security. As hardware, firmware, and software age, hacking techniques overtake them. That’s one reason why keeping systems updated is so important. When it comes to 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 to the extent that authorized users are not allowed to bring personal electronics to access points. That works, for the most part, but when it comes to retail, school districts, utility companies, banks, and dozens of other organizations that depend on legacy systems, armed guards are not a viable option.
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 fully digital, but many districts across the country have not, and have no plans to in the near future.
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 breaches 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, and that can be made beneficial in a myriad of imaginative ways. So if there are so many legacy systems out there, and they 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’s system, there is no guarantee that anyone would actually want to use it. In fact, 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 will to change, there is no guarantee that your system will pass the bureaucratic approval process, and if it could, then the agency in question likely already implemented something.
Another reason is the origin of observability. Observability really emerged as an industry in the 90’s. From its inception on, it’s been focussed on supporting the next big technology, not the last one. There were many big shifts in the 90’s both with hardware and operating systems that mark 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 then and well into the future was clear. No one thought legacy systems would last this long. And little by little, they are disappearing, which brings us to the final reason.
No one wants to build an amazing technology for the mere purpose of compensating for the vulnerabilities of that which is obsolete and on its way out the door. There may be some money in it, but there is no prestige, and if you have the capability to construct solutions for the past, you also have the ability to solve problems today and in the future, and 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 out there, created by individuals and 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 a possibility.