The ROI of Observability – Comparing open source vs. commercial solutions

Consumer expectations for fast, reliable, 24/7 digital access continue to grow higher and higher; today’s businesses must meticulously monitor system health and performance to mitigate the risk of service interruptions and outages. Because of this, spending on observability solutions is projected to reach over $4 billion by 2028, with individual companies spending up to 30% of their overall infrastructure budget on observability.

The drive to maintain high performance and customer satisfaction is one thing driving up costs, but there are technological and organizational factors as well:

• Microservices: The shift towards microservices architecture results in a higher volume of data from numerous, independently-deployed services, along with the need for sophisticated tools to monitor ephemeral instances and trace inter-service communications.
• Ephemeral Servers: The prevalence of reserved instances and cloud serverless/cloud functions in cloud-centric environments, which can be rapidly provisioned and decommissioned, also generates a high volume of data. This leads to higher data ingestion rates and storage needs to maintain visibility and control.
• Chaos Engineering: Chaos Engineering generates unusual observability data as systems responding to induced failures require more extensive monitoring and analysis (and thus drives up costs).
• Hot Storage: The need for indexing and storing vast amounts of data in hot storage for quick retrieval adds considerable expense. This is because of the high resource demands of indexing, and the cost of fast-access, high-performance storage solutions.

All of these factors contribute to the escalating cost of achieving comprehensive observability—it makes sense why data leaders are looking to reduce costs while still maintaining full coverage. What options do they have? In the next section, we’ll delve into the pros and cons of open source vs. commercial observability solutions.

Open Source vs. Commercial: Why the existing stack doesn’t cut it

Observability solutions fall into two main camps (and sometimes a combination of these two camps): open source and commercial vendors. Each comes with its own advantages and disadvantages.

Open Source Observability

Open-source observability tools like Prometheus and Grafana are becoming increasingly prevalent. In fact, according to the Cloud Native Computing Foundation and Gartner, 60% of organizations report using them. It makes sense why: open source tools are free to explore and use, offer benefits like flexibility and a community of other developers you can turn to for support, and have open protocols. Even some commercial observability solutions will offer open-source features and capabilities in an effort to capture more users.

However, the tendency to stitch together multiple open-source observability tools to achieve full coverage has led to tool sprawl, creating consolidation issues and additional data silos that complicate observability further. Moreover, the recent trend of relicensing in the open-source community introduces new challenges, such as restrictions on usage and modifications.

Open-source tools also require significant effort to integrate, especially in complex environments. They require more manual work to ensure compatibility across various components of the observability stack. And, while open-source communities are often very active, the level of support can vary widely. Access to comprehensive, well-organized documentation is limited, and getting timely help for specific, complex issues might rely on community goodwill rather than guaranteed support.

Finally, open-source tools lack the scalability and advanced features of commercial solutions. The development of new features is driven by community interest and contributions, which might not always align with specific enterprise needs. Performance optimization often requires in-depth expertise and tricky configurations.

Commercial Observability Solutions

Then there are the big commercial observability vendors like Datadog, New Relic, and Dynatrace. Commercial vendors offer a wider and more advanced array of features, and provide professional, dedicated support, ensuring that help is available when needed to troubleshoot or optimize usage.

The big con, of course, is cost. Commercial solutions can be expensive, with costs scaling based on usage, features, or the number of users, which might be prohibitive for some organizations. Plus, while they may be more user friendly than open source options, these tools offer less flexibility, which could be a limitation for organizations with unique needs.

Furthermore, commercial solutions can lead to vendor lock-in, making it challenging to switch providers or integrate with other tools due to proprietary technologies and data formats. Plus, users often have limited visibility into the internal workings or algorithms, making it difficult to understand precisely how data is processed or insights are generated. This “black-box” nature can complicate troubleshooting and customization.

But there is one big con that both commercial and open-source solutions share: significant limitations when it comes to providing comprehensive coverage and facilitating effective root cause analysis. These tools tend to compartmentalize data into silos, without offering a unified view that spans across the different layers of an application or infrastructure, and across the different telemetry types—logs, metrics, traces, events and profiling. This fragmentation means engineers must manually sift through multiple dashboards to correlate information, a process that can break down and cause significant stress and delays during urgent incidents.

Today’s observability tools lack the capability to fully understand the multi-dimensional runtime topology and the dynamic interplay between various components and layers, making it challenging to accurately pinpoint causation. Because dependency mappings are typically confined to basic configurations, DNS resolutions, peer to peer communications or just application dependencies, this may not accurately reflect the actual, dynamically changing infrastructure. Distributed tracing helps with application dependencies, but at the cost of instrumentation for the various software components, and the cost of sending and storing the generated telemetry.

Additionally, both open source and commercial vendors are often limited to rudimentary anomaly detection algorithms, which tend to generate extra, unnecessary alerts, drowning out actual issues that need attention. 

Ultimately, these platforms excel at highlighting symptoms rather than drilling down to the underlying root causes, rendering manual debugging a resource-intensive and time-consuming endeavor, particularly for issues that span across multiple system layers.