Why aren’t developers rushing to use observability?

Are there no observability tools purpose-built for developers?

When meeting with our customers’ dev teams, I’m continually amazed that basically nobody I talk with needs much selling on the reasons why observability is important. Nearly without fail, when espousing the benefits of watching what your application is doing, I’ll hear responses like: “Yep, I can see the need for that,” or “I agree with you,” or “Agreed. We need to start doing something like this, ” etc.  Contrary to other companies I’ve started or worked at, not having to convince the customer that what you’re selling is important is a huge benefit!.

I then started wondering why so few companies have actually adopted observability if everyone is in agreement that observability is such a good idea!?!? Is it because the tools are immature? Is it because the process of “doing observability” is too hard?

An area of “observability fatigue” I’ve heard customers comment about centers around the concept of actionability. The term ‘actionability’ is used to describe the usefulness of the observed bad behaviors of an application, and whether or not a developer can take the information provided and do something useful with it (improve performance, fix a bug, remediate a security issue, etc). Insights and alerts produced by an observability platform need to be concise, high-value, and not voluminous in number. If your observability platform produces too many alerts, you’ll be overwhelmed as a developer. If your observability platform produces alerts that are meaningless to you (for example, listing a stream of system calls made by your Java interpreter without any way to connect that to the higher-level language constructs you use as a developer), you’ll quickly find an excuse to not use such a platform.

I believe this fatigue is due to poor experiences with existing/legacy security tools (into which category observability products are usually grouped). Customers frequently lament the number of false positives and un-actionable insights. I’ve made it a top priority at DeepFactor to make sure every alert has as much detail as possible, but bombarding users with useless detail is, well, useless. That’s why at DeepFactor, we think like developers think. For every alert or insight we provide based on observing your application’s behavior, we ask ourselves “what would the average developer need to make a change here?”

Take, for example, one of the alerts we provide that I like to use as an example when demonstrating our product – use of unsafe/non-bounded string operations. We all know the number of vulnerabilities and exploits caused by memory unsafe operations continue to grow; indeed, both Microsoft and Chrome released studies claiming that 70% of the security issues they discovered were caused by memory unsafe operations. Old-school 1970s-era string manipulation functions really don’t have a place in new software; good replacements have been around for decades. But yet, we still see developers using them.

If you call one of these functions while being observed by DeepFactor, we’re going to flag it. We’re going to flag it whether or not you wrote that line of code yourself or whether you pulled in a library which pulled in another library which did (ad nauseam). But what do you, as a developer, need to know about this insight?

As a developer, I can tell you that *I* would need to know the:

• Program that called the unsafe function
• Module inside that program that contained the call (eg, which library or executable)
• Source filename and line of code that contained the call
• Stack trace leading up to the call, including the stack trace from higher-level languages (more on this shortly)
• OS/distribution package that owns the module that contained the call (so I can check if a quick fix is available by updating)

If the module containing the offending call is third-party (open source, for example), I’d also like to know the source (perhaps a URL linking to that project’s GitHub repository).

I believe the list above to be concise, high-value, and not overwhelming. But yet oftentimes we see observability products showing data that is not useful to a developer (eg, showing CVEs that may or may not even relate to the observed behavior).

Developers should want to participate in DevSecOps because they will:

1. Have confidence they are releasing secure code at speed.
2. Save time and money by catching issues pre-prod versus having to stop what they’re doing in sprint 2 to context switch and fix the issue in sprint 1 and then return to sprint 2, all the while staying on sprint 2’s schedule.

They just need a tool that speaks their language in concise terms that are easily actionable. Remember earlier when I asked if the low adoption rate of observability is “because the tools are immature”? Perhaps the better question is, “are there no tools purpose-built for developers”? With the list I’ve outlined above, a developer could quickly rule in/out if the code was their own or imported from a third party, whether or not an update exists for that component, and have the ability to reach out upstream (if desired) to report the issue to the actual owner.

At DeepFactor, we think like developers because we are developers. The way we approach actionability is different from other tools. I hope you’ll give our continuous observability platform a try!

DeepFactor observes ACTUAL application behavior at RUNTIME to detect anomalies and prioritize alerts. But why emphasize RUNTIME observability? Think of it this way… Looking at a parked car is different from test-driving it. And you certainly don’t want to accidentally buy a lemon! Similarly, static code analysis is different from observing a RUNNING application. Avoid the lemons with observability—find security & compliance risks in your running application. Click here to start using DeepFactor for FREE!