The 3 Myths of Observability
We all have our favorite urban legends. From cow tipping to chupacabras, these myths persist despite a lack of definitive proof (and often evidence to the contrary). Technology isn’t immune to this phenomenon. It has its own set of urban legends and myths that emerge alongside new technologies and continue well into mass adoption. As organizations consider the shift from monitoring to Observability, I hear three common misperceptions. It’s time to debunk the myths.
Myth #1: If you implement an observability strategy, you’ll experience fewer incidents
Actually, the opposite may be true — but that’s not a bad thing. Imagine that you measure your temperature and pulse rate every day. Does that make you less or more prone to health problems? Not really. Chances are, simply monitoring these vital signs will have no impact on your long-term health and, in fact, you might actually find previously unknown issues.
In that sense, just implementing an observability strategy does not necessarily impact the number of incidents that occur. But when a problem DOES arise, you have a treasure trove of telemetry data you can use to quickly identify and remediate the problem because you not only know where the problem is, you also know why the problem occurred in the first place. At the end of the day, observability helps you reduce the time it takes to respond to and resolve issues, making your organization perform better — and your customers happier.
Myth #2: Buying an observability tool means you have an observability strategy
Going back to my previous analogy, does having a doctor mean that you’re healthy? Clearly, the answer is no, and the same is true here. Having an observability platform is necessary, but it’s not sufficient on its own. The real questions are: How widely adopted is the tool? How well-versed in the tool are those individuals who use it?
What’s more, observability isn’t limited to a single department. It needs to become part of the company culture. Yes, the DevOps team may comprise the primary stewards of the organization’s observability strategy, but its impact will extend across the company. For example, an observability tool can serve up real-time insights on critical KPIs to business stakeholders and even the executive team. You can also use observability data to illustrate system functionality for new hires or leverage observability techniques to verify new behavior, such as a feature change. When you look at observability as a company-wide investment rather than a team-specific one, its value grows exponentially.
Myth #3: Implementing observability is cheap or even free.
This one may be more of a wish than a myth, but the reality is that the value you derive from observability is directly related to your investment in it. Observability is a critical supporting function to DevOps and cloud adoption.
Modern infrastructure and methodologies are like a jet airplane that allows us to move fast, but pilots cannot fly something as complex as an airplane without a cockpit full of dials and gauges. Similarly, companies cannot be successful in their digital transformation and cloud adoption without high-quality observability. In other words, your investment in observability scales up in complexity and size as your environment grows — and justifiably so. More users, more microservices, more frequent code deploys, more new tools, and more services being adopted–all of these increase the scale and complexity of your environment, and the costs of observability.
One additional point, new technologies emerge every day and companies are eager to leverage them to drive value, which means observability tools need to continuously adapt to integrate with new tech — and the increasing complexity that comes with it. How can you manage your spend in an ever-changing environment? Thinking about your observability budget as a percentage of your overall infrastructure and operations budget is an effective strategy. But remember, the value provided by a good observability program in terms of efficiency, speed, and customer satisfaction will far surpass the dollars you put into it.
Conclusion
A final point that’s often overlooked is the cost of NOT having visibility. The hidden costs of not monitoring and observing the right metrics include loss of revenue and customer trust due to performance issues and outages, keeping your engineering teams tied up resolving issues rather than building new features, and more. These blind spots can cost you more than implementing observability itself!
As in most things, hindsight is 20/20. When (not if) an issue arises, and there’s no telemetry to fall back on, how do you move forward? How will you resolve it? How will you ensure it won’t happen again? In my opinion, you should be as conservative as possible and instrument everything that’s applicable, so you can observe the performance of your software constantly, in real-time, at any scale. By understanding the value observability can bring to your organization, you can turn these urban legends into an observability strategy that makes your team legendary.
Feature image via Pixabay.