Is observability as code overhyped? (original) (raw)

Is observability as code as transformative as vendors claim or just another IT buzzword? Learn what to keep in mind when evaluating this emerging approach for your organization.

Brian Kirsch

Brian Kirsch,

Published: 22 Mar 2023

In IT, change often comes before an exact need is figured out for it.

First came DevOps to accelerate software delivery followed by infrastructure as code to continue the journey to the cloud and further speed up deployments. Now we have observability as code, whose goal isn't to make things faster but rather to gain insight into what's being done at such rapid speed.

Similar to infrastructure as code, observability as code uses code to promote automation and repeatability within observability workflows, aiming to give developer teams visibility into the entire software stack.

The need for observability stems from the increased scope and complexity of modern applications. In contrast to the traditional monolithic approach, the modern application software stack is a distributed design in the cloud that often runs without a host system.

This limits an IT team's options when it comes to troubleshooting: If you're executing code in a serverless cloud environment, you don't have a traditional platform to troubleshoot on. For DevOps professionals, this troubleshooting gap creates a new need that observability as code aims to fill.

But is observability as code the right fit for your organization? Keep the following considerations in mind when deciding whether to implement the approach.

Implementing observability as code comes with tradeoffs

Vendors of observability-as-code tools promise a lot -- everything from repeatable best practices and improved collaboration to dashboards offering deep insights.

On the surface, this sounds ideal; it checks most of the boxes that management wants. But while an automated approach that provides more visibility into the software stack seems ideal, observability as code has its downsides.

Complexity

First, observability as code involves a tradeoff: A more complex overall software stack in exchange for a deeper level of insight.

Ensuring best practices are repeatable and collaborative throughout the entire software process can help address the overall complexity of the software stack. But third-party tools, such as Splunk and Terraform, still add complexity when it comes to getting the insights you're looking for from dashboards.

Diagram of the three pillars of observability: logs, metrics and traces.

Performance issues

Adopting observability as code might not create performance issues in your application. But if you've ever done verbose logging in an application, you know generating all that data can have an effect. In addition, collecting and storing that data and mining it for information can entail substantial expenses.

Time

Another concern is the time it can take to deploy an observability-as-code framework. Because speed is such a high priority in DevOps, delays are typically frowned upon. Adding anything new risks causing setbacks, especially for larger-scale distributed applications in the cloud.

The counterargument is that adopting observability as code will ultimately save time because it enables DevOps teams to speed up the troubleshooting process. But those time savings might occur primarily -- albeit not exclusively -- after deployment, rather than during creation.

Tracking

Observability-as-code tools also don't track infrastructure or networking issues. Sure, the code can point you in the right direction, but it's not going to fix a firewall issue or virtual LAN problem.

There's also the question of multi-cloud tools and applications. Because no two clouds do everything the same way, you're forced to make adjustments based on which cloud you're in.

Is observability as code necessary?

Ultimately, the real question is whether your organization needs observability as code.

As with many things in IT, there's no straightforward answer. Increasing application sizes, the rise of serverless applications, and the overall complexity and interworking of today's IT environments mean something must be available for issues that come up. But will it be observability as code or a modified version of it?

Most likely, it will be a hybrid, as few IT organizations ever run anything in a pure state. Things never fall into simple, ideal categories and every business is different.

However, the need for strong observability practices will continue to grow as cloud adoption continues and DevOps teams require additional insight into critical applications. That part of observability as code is not overhyped; in fact, it will be a key point going forward for cloud and serverless applications.

The repeatable best practices and ideal collaboration aspects of observability as code are more of a "nice to have," and many vendors are vague on the details of these aspects. It's similar to the single-pane-of-glass approach that has been promised in monitoring for years: Something everyone talks about, but few can show in practice.