Afraid of getting stuck? Vendor lock-in is in the small details 🔐

Tal Borenstein — Tue, 31 Oct 2023 10:31:11 +0000

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.

Keep: open-source alerts management and automation platform

Here is a quick background about us: with Keep, you can connect, automate, & analyze alerts for any part of your observability stack with GitHub Action-like interfaces.

If you liked this article, make sure to:

Try us out 🚨

Star Keep's repository ⭐️

Join our Slack 💬

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.

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:

You start with Datadog because it's appealing and super easy to implement
A few months later, you start getting those invoices and find out your expenses have skyrocketed
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 shit.

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 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

Building a new shift-left approach for alerting

Tal Borenstein — Mon, 10 Apr 2023 15:19:50 +0000

Hi Community!
Looking forward to hearing your thoughts on this!

Keep is an open-source alerting CLI tool that @shaharglazner and I wrote out of a pain we felt throughout our careers as developers and developers managers.
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.

It's not only that we couldn't create better applicative/infrastructure alerts, but it's also that it is tough to maintain them and ensure they work over time.

Organizations today have so many tools they use for alerting that it's becoming an absolute nightmare.

Alerting as a first-class citizen

The best way to describe what we had in mind when we first built Keep is how one of our first users puts it:

Keep is doing to alerting what GitHub actions did to CI/CD

There were three main guidelines when we started coding:

Good alerts are not just over thresholds/logs BUT should be treated as workflows with multiple "tests" (steps/actions).
The tool should be 100% data agnostic - agnostic to where data resides (& not only "traditional" data sources but also a DB, for example). There's no real reason why it shouldn't be abstracted from developers.
Maintained and lives in your code - allowing it to be integrated with all CI/CD processes (imagine a gate that fails your PR when you break alerts).

What's Ahead?

We constantly try to improve with our promised:

Try our first mock alert and get it up and running in <5 minutes

So we're adding plenty more deployment options, providers, and functions. We're working on simplifying the syntax furthermore.

What do you think about the need for this kind of "abstraction"? What do you think about alerts as post-production tests? How do you manage and control your alerting chaos right now?

Would love to hear your thoughts; feel free to comment here / on our Github repo / in our Slack