Can anyone remember what PCMCIA stands for? You know, those cards you'd shove into the slot on your laptop to provide something your laptop lacked, like a Wi-Fi card? My favorite definition is People Can't Memorize Computer Industry Acronyms. The real answer is at the bottom.
FSO is one of the latest acronyms. You're probably already aware that it stands for Full Stack Observability. It means the ability to observe the status of each technology stack component distributed in an IT environment in real-time. Some FSO solutions advertise the ability to not only identify an application that is causing a problem, but actually identify the line of code at issue. I'd like to know how they can do that with legacy applications. If you're an FSO solution provider with this capability, I'd love for you to enlighten me as to how this is possible.
What makes more sense to me is that you either modify or develop applications with FSO in mind. This has its own acronym, ODD, or Observability-Driven Development. I predict you'll be reading about ODD more and more these days. It's the most efficient way to achieve true Full Stack Observability, since you need to be able to identify not only network issues, but application issues.
There are already great solutions for Network Observability, such as Cisco ThousandEyes, which is like "traceroute" on steroids. This is made possible by having agents running on network nodes. The agents provide information you can't get with "traceroute".
But I'm not aware of any solution that can analyze a legacy application's performance down to the line of code. I'm not saying it's impossible. One could identify a specific problem, like an application hanging at a certain point. Then you determine the operation that is failing which could lead you to something like a "while <something = false> do" where the test never becomes true. This often happens when your code depends upon a hardware state. Your code waits for a ready response from the hardware but the hardware has failed and never returns a ready condition.
That's all and good, but if you want true application-level observability you'll need to modify or develop your applications with Observability in mind. One way to avoid the possibility of that loop hanging is to code in a timer so that it exits with an error code that tells you the hardware isn't reaching a ready state. That's but one example of Observability-Driven Development. Actually, it's good coding practice even if you're not coding for Observability.
How many other ways can you code for Observability?
Answer:
PCMCIA: Personal Computer Memory Card International Association
