The late 1990s were a crazy time in the technology industry. Apple converted a blueberry into a computer, Google still had a “new search engine” smell, and while Y2K loomed over our heads Napster was showing everyone how bad Metallica’s music sounded.
Meanwhile, in a garage in Tulsa, Oklahoma, brothers Donald and David Yonce launched a network monitoring software company and named it SolarWinds. They settled on the name despite the software having nothing to do with either the sun or the wind, causing unending market confusion.
At the time, command-line tools, which only a Linux administrator could love, dominated the world of network monitoring tools. The Yonce brothers wanted to create software
everyone could use and love no matter if they lived in their parents’ basement or in a high-rise apartment. The Yonce brothers accomplished both by using a simple formula—
focus on building great tools for customers needing solutions to the problems they faced every day.
Since 1999 SolarWinds has continued to follow this same formula. As a result, you might have noticed we aren’t always (or ever, really) first-to-market with products and services for cutting-edge technologies. SolarWinds waits for markets to emerge and then we build products and services to meet the needs of our customers. This has been a source of frustration at times, especially for one person who demanded enhanced Windows
® phone monitoring (I’m looking at you, Steve).
I admit, it’s often frustrating to wait for cutting-edge technology to become mainstream and markets to emerge, but it makes good business sense to do so because most corporations don’t jump from one shiny piece of technology to another like a kid in an Apple store. Overall, corporations tend to wait for the
Plateau of Productivity on the Gartner hype cycle before adopting new tech. Building software before market maturity involves risk.
But change
will happen, albeit slowly, over time. Companies do adopt newer technologies, and our products and services must evolve, as well. Otherwise, companies risk losing customers to competitors. So, you can’t stand still and you can’t jump too far ahead—you must take the right steps to help your customers along their journey.
Here’s an example of the steps SolarWinds has taken over the past few years:
For years SolarWinds has been gathering bits and pieces of a mature, modern, monitoring platform as if they were Infinity Stones. This is what we do. This is who we are. Throughout our history, we have supported our customers by providing products and services to make their day-to-day lives in IT easier, if not at least a little more tolerable.
We’ve come a long way from that garage in Tulsa. And now it’s time for the next step in our journey together.
Visibility
The world of tech was much different when the Yonce brothers built the first versions of SolarWinds software in their garage. The cloud didn’t exist. Companies hosted their own data centers. High availability often consisted of SAN replication across a T1 line and you simply hoped you could failover (and back) when necessary. When the financial crisis hit and banks were labeled as “too big to fail,” those of us in IT joked our systems had grown so large they were “too big to failover.” It wasn’t as much of a joke as a sad reality knowing we had created this problem ourselves.
At the time, we built application systems using an architecture based on the idea of a server as a single-node entity, located in a data center (or closet) where you could give it a swift kick when it misbehaved, and utilized by internal departments connecting along the same network. Today we refer to these systems as “legacy.”
The monitoring tools of the day also reflected this reality. And twenty years later we still see these legacy tools and systems on the market, built in a time before distributed computing, virtualization, or the cloud. The goal for these tools is to provide “visibility” into the systems, helping users know when issues arise using alerts based on thresholds provided by the hardware and software vendors being monitored. To help achieve visibility these tools will focus on groups of objects such as servers, network devices, and applications.
By grouping similar entities, these monitoring systems started providing correlated metrics across many layers of the infrastructure. This evolution was necessary for two reasons. First, as environments grew in complexity, it was important to know the cause and effect between different parts of the enterprise. Second, it allowed users to identify related entities and relationships which may have never been known previously. Together, these items provided visibility into the infrastructure, metrics allowed for faster root cause analysis, and visibility soon became a core piece of functionality for any monitoring tool.
However,
visibility by itself is no longer enough.
Modern Systems
Now we have globally distributed applications with customers worldwide. We need to get the right data to the right person, at the right time, to make the right decision.
Slowly, as new technology has evolved, system architecture has as well, and monitoring tools have kept pace. Today’s modern monitoring tools understand application systems are built to be globally distributed, highly available, and instantly scalable. The result is the transformation of “administrators” into “
site reliability engineers” who often examine the four golden signals (concurrency, errors, latency, throughput) as a first step in troubleshooting issues.
Enter observability.
Observability picks up where visibility leaves off. The word itself comes from control theory—the classical definition for observability is
the ability to infer the internal state of a system based upon the external outputs. A quick search for the phrase will turn up dozens of definitions for observability applied to application systems. If I were to apply observability to the word itself, I would say the internal state of observability is one of “many marketing messages.”
Consider the observability of a trash dumpster. The default external outputs are lacking, to say the least. The most important metric of a trash dumpster is “how full,” something you cannot tell unless you act upon the system (e.g., remove the lid or door). So, maybe we install a sensor to measure the weight of the dumpster to determine fullness. But trash isn’t a constant: cardboard weighs less than wood, for example. So, we need additional sensors to determine fullness. Doing so might make the dumpster
observable for our requirements, but not necessarily the requirements of someone else.
Now, instead of a trash dumpster, think about the dumpster where your application systems and servers reside. Your systems and workloads are unique to your company. You might take steps (adding sensors) to make your systems observable. But you also need similarly extensible monitoring tools (i.e., the ability to communicate with the sensors). And this is where it gets tricky, and why there are so many definitions of observability.
The requirements for one set of systems, or customers, to make a system observable vary to another. Even dumpsters have differences.
And what one person might infer as a healthy system may not meet the same requirements as someone else. A system can be seen as healthy and still not perform well. For example, I’m healthy enough to run a four-minute mile, but there is no chance of that happening.
And yet we can find common ground among the myriad of observability definitions:
- Infer health from external outputs
- Correlated metrics across technology stacks
- Automated alerts and the ability to open incident tickets
- Use of AIOps and machine learning to identify anomalies
- Provide actionable guidance on issue resolution
- Ease of use—from zero to “wow” in less time than it takes to fill a dumpster
- Analytics and reporting
SolarWinds already has all those features spread across our product portfolio. We’ve been helping customers with their observability needs for years—our tools have evolved along with the needs of our customers who have been evolving their legacy systems into modern distributed architectures. In short, when we looked at the external outputs across our Orion
® Platform we inferred the internal state to be, well,
observable. You can read more about
Orion and our evolution to observability in this post by Head Geek
™ Chrystal Taylor.
Therefore, we are launching our
SolarWinds Observability Self-Hosted (formerly known as Hybrid Cloud Observability) solution. It includes the same products you already know together with a full-stack solution to provide visibility into your systems. Our customers have told us they need a cross-section of our tools, along with subscription licensing, and we’ve listened.
Observability and Visibility
Today’s modern monitoring platforms must offer both observability and visibility. You need observability into specific systems
and you need visibility across your entire enterprise stack.
Building software is hard. Building software to meet the needs of every customer is harder.
Luckily, SolarWinds has more than 20 years of experience building great software our customers love.
