Open Source Creates Vendor Lock-in? Inconceivable!!!!

Open source technology within IT Operations is fairly common now, especially as the "traditional" observability APIs (Prometheus, Jaeger, etc.) become fairly standard. OpenTelemetry (OTel) has further opened that door for broader data sets that help create robust monitoring.

Once upon a time, open source observability was the only recourse for monitoring cloud-native tech stacks, as monitoring vendors (especially APM tools) struggled to support full-stack visibility at a time when containerized, orchestrated microservices became ubiquitous with high performance IT organizations. Today, almost all legacy monitoring tools at least can handle cloud-native stacks (although some better than others) - and yet open source monitoring is not only still prevalent, but in certain cases is gaining traction.

While each specific API provides different advantages, there does tend to be a common reason amongst DevOps / ITOps executives as to why they want to focus on open source observability APIs (even though best-of-breed cloud-native monitoring vendors have appeared) - avoiding the dreaded Vendor Lock-in!!!!!

It sounds evil, right? You can almost hear the heavy breathing of Darth VendorLock, the Sith Lord of rigidity. The horror stories of being dependent on a vendor could easily be told with a flashlight under your chin at a campfire – anything from unavoidable price increases ?to forced service contracts. (yuck!).

The Vendor Lock-In I See Most Often

Which brings me to the crux of my article - the fact that open source APIs have created vastly more monitoring vendor lock-in situations than any other tool(s). Did you ever think of those fantastic open source observability APIs resulting in a vendor lock-in situation? “Inconceivable,” you say? It’s more than merely possible. In fact, I see it more often today than when Prometheus, OpenTracing, etc. were the only options for monitoring microservices. Why does this happen?

Vendor Lock-In Defined

John Edwards at InformationWeek explains that vendor lock-in happens “when a customer willingly submits to a hardware, software, or service provider … making it difficult to switch to a competitor without substantial cost or effort.”

Here’s what vendor lock-in can sound like when evaluating alternative solutions:

• Removing the current tool is so cumbersome, I'll lose value from a new tool.
• We can’t integrate with tool X – we can only use Tool A, which is an inferior product from our Observability vendor.

The Blind Operations Director

Not so long ago, I had a conversation with a DevOps Director. He was grilling me on price increases, specifically worried about what would prevent me (or the company) from raising our prices after the deal was signed. His biggest concern was vendor lock-in, straight up. After we assured him that subscription based products were designed to address such a concern, he brought up a completely different objection:

?“Well, we can’t look at another tool – that would impact about 1,200 people across our organization to go through education, making changes, etc.”

I was taken aback because just making the statement meant two things

1. I had failed to get across to him that we would actually ingest every piece of data the developers made available – not make them throw it away.
2. He was already a victim of his greatest fear in the world – vendor lock-in – it just wasn’t with a licensed vendor

The first issue was easy to fix – as I showed exactly how we integrated (and correlated) any open source data stream with our own data as first class data sources.

The lock-in issue took a longer conversation. He didn’t agree with my assertion that he was actually locked in already – after all, they were using open source. Open source couldn’t possibly lead to that evil result, right?

However, once we switched perspectives from DevOps license and service costs to developer efficiency, it became crystal clear that his 1,100+ developers had been locked into a vendor - the open source API that he had selected.

As You Wish!

The best thing about this story? The happy ending – a customer executing the full vision of Enterprise Observability – combining proprietary and open source data streams together for a much more robust monitoring strategy. Bonus: he not only has 1,000+ people contributing to the solution value, he actually has 1,000+ people using the observability platform every week, increasing software quality, growing customer satisfaction and even improving developer morale!

That’s the power of automation in the monitoring slot of your DevOps processes.