Observability vendor lock-in is in the small details

Tal Borenstein
October 31, 2023
Observability vendor lock-in is in the small details
Back to all Blog Posts

TL;DR

In the world of observability, vendor lock-in slows progress and spikes costs.

OpenTelemetry broke some chains but didn't free us entirely.

This post shows the bridge between talk and action and how platforms like Keep offer flexibility, interoperability, cost optimization, community-driven support, and an escape from vendor lock-in traps.

If you maintain >1 observability/monitoring system, are concerned with vendor lock-in, and need help keeping track of what's going on and where, this post is for you.

Vendor Lock-in meme

Vendor lock-in in the o11y space

Vendor lock-in is a concern that both companies and customers struggle with in the world of SaaS.

The fear of becoming trapped by a single provider and unable to switch to alternative solutions can choke innovation and inflate costs.

Platforms like Keep, focusing on data portability and vendor neutrality, offer an escape from such vendor lock-in conditions using an application abstraction layer.

Using Keep to migrate Alert between platforms
Using Keep to migrate an Alert between 2 different platforms

We constantly educate our customers that “we are doing everything we can so you won’t be vendor-locked with us.” But to be frank, we all chase the next sticky feature to ensure our customers won't go anywhere.

Here's a legitimate real-world scenario:

1. You start with Datadog because it's appealing and super easy to implement
2. A few months later, you start getting those invoices and find out your expenses have skyrocketed
3. You want to migrate your way out but fail because it's too damn hard.

Charity Majors (@mipsytipsy):
DataDog has been telling users they can use OTel to get data in, but not get data out. The DataDog OTel collector PR was silently killed. https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/5836 The person who wrote it appears to have been pressured into closing it, and nothing has been proposed to replace it.[1]

OpenTelemetry (aka OTel) is a great example and an ambassador of how open standards can break the shackles of vendor lock-in in the observability space.

Before OTel, every vendor had its own SDK implementation, and switching to (or even just trying out) new vendors was sh*t.

While OTel did break some chains, the above quote teaches us that vendors still have a few aces up their sleeves.

This is where platforms like Keep come in to bridge the gap between companies who promise one thing but act the other way around:

Flexibility in Tool Selection


Keep empowers organizations to consolidate all their alerts into a single unified interface.

This approach allows you to gather data and use features from various observability products, including Grafana, Datadog, New Relic, Sentry, and others.

The ability to centralize data from multiple sources means that you're not limited to a single vendor's feature list. This flexibility in tool selection is a critical step towards avoiding vendor lock-in.

Interoperability and Data Portability

One-click alert migration with Keep


One of the core principles of Keep is interoperability.

By using Keep as your central alert management and automation hub, you're no longer constrained by the proprietary data formats and APIs of individual vendors.

Keep acts as an applicative abstraction layer, ensuring that your data can be easily exported and integrated with other tools or platforms.

This not only safeguards against vendor lock-in but also streamlines the process of transitioning between tools when necessary.

Cost Optimization


Vendor lock-in often leads to rising costs as you become dependent on a single provider's pricing structures.

Keep's ability to work with various observability products lets you take advantage of cost-effective solutions for different aspects of your observability needs.

This cost optimization is a significant benefit, as you can choose the most economical tools for your specific use cases and avoid overpaying for unnecessary features.

We come across many companies who prefer to keep their logs in one tool (for example, Axiom or Coralogix) and their metrics in another tool (for example, Datadog) for cost optimization.

Avoiding Lock-In Traps


Many vendors create proprietary hooks and features that can make it challenging to migrate away from their platforms. (sometimes they even do it secretly [2])  

Keep helps you avoid these traps by providing a vendor-agnostic layer that abstracts away these proprietary features.

This allows you to retain control over your data and workflows, preventing vendor lock-in tactics from being effective.

Open-Source Community and Support


Keep is an open-source project, which means it's developed and maintained by a diverse community of contributors.

This community-driven approach ensures that the platform remains vendor-agnostic and evolves based on the needs of the users, not a single vendor's agenda.

Moreover, this support system can reduce your reliance on a single vendor's support services.

Future-Proofing


The technology landscape is constantly evolving, and vendor offerings change.

Keep's adaptable architecture ensures that your organization can pivot and adapt to emerging technologies and new observability products without the fear of being locked into outdated solutions.

---

In conclusion, Keep's open and flexible approach to alert management and automation is a game-changer in the battle against vendor lock-in.

By centralizing and streamlining your observability data while remaining agnostic to the tools you use, Keep provides a foundation for your organization to remain in control, save costs, and embrace innovation without the fear of being tied to a single vendor's ecosystem.

It's a powerful resource in the fight for vendor independence in today's ever-changing tech landscape and the ever-growing observability world.

---

[1] Charity's Tweet
[2] Datadog "asked" me to kill this pull request

AIOps! Finding Incidents in the Haystack of Alerts

Picture this: a flood of alerts pouring in from various monitoring systems, each clamoring for attention. Amidst this deluge, identifying critical incidents is akin to finding a needle in a haystack.

Tal Borenstein
April 11, 2024
AIOps! Finding Incidents in the Haystack of Alerts

Unifying alerts from various sources

Demonstrate the strength of a unified API in consolidating and managing alerts.

Shahar Glazner
November 26, 2023
Unifying alerts from various sources

Extending Grafana with Workflows

We all have that one service that, for some Phantom-de-la-machina reason, gets stuck and requires some manual action, like maybe a reboot or a REST call.

Gil Zellner
September 14, 2023
Extending Grafana with Workflows

Getting started with Keep — Observability Alerting with ease

Creating and maintaining effective alerts, avoiding alert fatigue, and promoting a strong alerting culture can be difficult tasks. Keep addresses these challenges by treating alerts as code, integrating with observability tools, and using LLMs.

Daniel Olabemiwo
May 14, 2023
Getting started with Keep — Observability Alerting with ease

Building a new shift-left approach for alerting

Alerting (aka monitors/alarms) always felt like a second-class citizen within all the different monitoring/observability/infrastructure tools with a very narrow feature set, which in turn results in poor alerts, alert fatigue (yes, your muted Slack channel), unreliable product and a complete alerting-hell.

Tal Borenstein
April 10, 2023
Building a new shift-left approach for alerting

Current problems in the alerting space

In the past month, we have engaged in conversations with over 50 engineers, engineering managers, and SREs to gather feedback on the products we are developing at Keep. Here is a summary of what we have learned.

Shahar Glazner
March 19, 2023
Current problems in the alerting space