Chances are you’ve heard about OpenTelemetry from your engineering team. Perhaps they’ve raved about its built-in support for programming languages and frameworks or the wide array of SDKs. But technical benefits aside, is adopting OpenTelemetry actually a sound business decision?
All signs point to yes. OpenTelemetry is one of those magic moments where engineering desires and business needs perfectly align. Let’s discuss why — and how to make sure your organization can take full advantage of business benefits such as avoiding vendor lock-in, achieving compliance, improving employee retention, and reducing long-term costs.
Why OpenTelemetry is good for business
Our State of Observability 2024: Charting the Course to Success report revealed that OpenTelemetry adoption is a catalyst for achieving better observability outcomes. Respondents from leading organizations — a group that consistently adopts a set of observability best practices — are more likely to adopt OpenTelemetry and reap its benefits.
Avoid vendor lock-in
OpenTelemetry is the key to being in charge of your own data destiny; nearly half (45%) of respondents from leading organizations agree that it prevents vendor lock-in. With OpenTelemetry, organizations only need to instrument observability into applications once and send data to the backend(s) of their choosing. The alternative is to use a vendor’s proprietary agent. While this may seem tempting due to slick marketing or your team saying it’d be ‘easier’ than OpenTelemetry, it has one big catch — what if you want to leave?
By adopting OpenTelemetry, your software isn’t tied to a proprietary agent. Organizations don’t need to fear the consequences of a rip-and-replace, meaning they can choose the vendor that’s truly the best fit. More importantly, if that decision changes later on, the toilsome work of instrumentation does not need to be repeated.
Vendor lock-in rarely benefits anyone except the vendors themselves, leaving organizations vulnerable to aggressive price hikes and paying for extraneous technologies simply because they’re bundled. Perhaps more concerning than the financial repercussions, vendor lock-in prevents organizations from being in charge of their own destinies. Instead, they’re forced to rely on their vendor’s roadmap rather than their own custom needs. If a vendor chooses not to support the hot new language or framework and you aren’t using OpenTelemetry, the organization is stuck, unable to adopt competing and more compelling vendors with better capabilities simply because it’s too difficult or expensive to do a rip and replace.
Achieve data sovereignty and compliance
Nearly every country has a data protection law that requires how its citizens’ data can be transferred and stored, which creates tricky data management scenarios. Not complying with these laws, such as GDPR and CCPA, often results in significant fines and legal implications. GDPR, for example, can cost companies up to 20 million euros or 4% of the company’s worldwide annual revenue — whichever amount is higher.
Staying ahead of data sovereignty requirements often means routing telemetry to different places based on its geographic origin, which can become expensive (or even impossible) with proprietary tooling. Forty-seven percent of all respondents say OpenTelemetry helped their organization meet data residency requirements. That’s likely because the OpenTelemetry Collector’s robust processing capabilities greatly simplify the process and reduce the burden of configuring complex rules around where to send data.
Retain and attract developers
Today’s tightened budgets and skills shortages — 70% say their teams have been short-staffed over the past year — mean that keeping talented developers on staff is more important than ever. Adopting OTel shows developers that your organization is on the vanguard and that it prioritizes innovation and flexibility. It also lets your developers become familiar with cutting-edge technology and build their personal skill sets, increasing retention and satisfaction.
Going beyond adoption, organizations can contribute to the OpenTelemetry project to help build their employer brand and reputation as an organization that gives back to the open-source community — a clear sign that an organization wants to create a positive developer experience. Not only does that attract talent, but it can also help steer the overall direction of the OpenTelemetry project. Ultimately, an open-source project is shaped by its contributors. Organizations that contribute heavily to the project can ensure that its goals fit their needs and use cases.
Lower costs and effort in the long term
Due to its learning curve, getting up to speed with OTel requires a significant upfront effort. However, as with any investment, leaders need to consider the CapEx vs. OpEx tradeoff. Once implemented, OTel can significantly lower costs in the long term, both from a technology and staffing perspective.
From a technology perspective, OTel enables organizations to have better control over their data pipeline — 49% of respondents agree — and filter out data to reduce ingestion costs. On the staffing side, it allows organizations to reduce their efforts in architecting their observability solution. Yes, you must spend effort initially to build OTel support into your environment, but once this is done, you can feel confident that this effort won’t need to be repeated.
In the next decade, rolling your own observability backend could become a thing of the past — much like the once-popular trend of hosting your own email server, which has since faded away. Organizations should enable developers to focus on activities that move the needle rather than configuring their observability solution. With OpenTelemetry, there’s less need to redo instrumentation work over time — which means developers get the toilsome work done once, and can spend their time where it’s most valuable: building software.
How to adopt OpenTelemetry successfully
Win the hearts and minds of people who will do the work. Like with any executive-led change, it’s important to communicate the reasons behind the initiative. Practitioners who are behind the efforts of adopting OTel and instrumenting the code should understand both the business importance and technical benefits.
Identify an internal champion. Find passionate and motivated team members (Hint: they might be the engineers that introduced you to OTel initially). Then, set them loose on OpenTelemetry’s project website and GitHub, where they can find plenty of materials to learn from. Encourage them to join communities like the CNCF Slack group to further develop their passion and network with like-minded individuals.
Don’t underestimate the power of inertia. In an ideal scenario, adopting OTel involves replacing the collection infrastructure and keeping the backend. But even in an ideal scenario, decisions made during the adoption process can have a ripple effect. For a smooth implementation process, consider how you’ll validate that your new OTel tooling has the same capabilities as the previous tooling. Ensure that your team will have access to all the data and resources that you had prior. Thinking through these details before implementing OTel can prevent heartburn down the road and ensure that your organization is positioned to fully reap OTel’s benefits.
Read the full report for more insights and recommendations on OpenTelemetry. The report also focuses on the benefits of platform engineering and the role of AI in observability.
