What does observability mean for your business?

Observability is a broad topic. It can go in quite a few different directions. That’s why Tyk got together with industry experts Navish Bahl (Grafana), Abby Bangser (Syntasso), Andreas Grabner (Dynatrace) and Ruchir Jha (Cardinal). We asked them which areas of observability were currently in their respective spotlights and why. 

We also gathered some important insights into precisely how observability can benefit your business…

In this blog, we’re covering:

• The crucial role of observability in diagnosing issues, preventing application slowdowns and improving end-user experiences.
• How observability supports business objectives. 
• Why strong data governance is key to effective observability. 
• The importance of adaptability in your observability strategy. 

Watch the full webinar recording below, or read on for our top takeaways.

 

 

Observability, performance testing and insights 

For Dynatrace’s Andreas Grabner, observability proved the key to unlocking performance testing results. Metrics and logs could only go so far; when something went wrong during testing, it was observability that delivered insights into what went wrong and why. Observability supported everything from internal performance testing to support for some of the world’s largest businesses, from development to production. 

Now, with 20 years of observability patterns from which to learn, there are tell-tale signs that businesses can look out for when application systems – especially distributed systems – start to fail under load, slow down and make end users unhappy. Using observability earlier on provides the chance to avoid those patterns and deliver happier end user experiences. 

One pattern to look out for, for example, is the N+1 query problem, where too much data is fetched and then filtered on the client side. It’s something to be wary of when using an API gateway. Are all those round trips really needed? If not, they’ll be slowing things down unnecessarily. 

Grafana’s Navish Bahl also first grasped the power of observability in the testing space. For him, the power of observability lies in its black box potential. Companies can use it to glean the insights they need when their systems start going awry. Observability means they can start gaining insights from where it matters most, which is generally higher up in the stack – because that’s where users start feeling the pain. 

Not that every business has the might, the due diligence and the team resources to start instrumenting their applications and start gaining insights from the get-go. Often, it’s a slow journey to get there – but a hugely important one. The earlier you can start collecting data, the better, because you can get the insights you need a lot faster, particularly when you’re building layers on top of layers. 

Building observability into business outcomes

Ruchir Jha was first involved with observability when working at Netflix. Years ago, building an in-house observability stack was akin to creating a glorified data platform. As it evolved, people developed their own opinions on how they wanted to observe specific systems, which in turn evolved into a means of monitoring the health of those systems – and subsequently the business use cases that those systems supported. 

Now CEO of Cardinal, Jha is focused on the power of observability in relation to governance and return on investment (ROI). While a new request may not bring additional revenue, it can translate into n more logs, n more events, n more metrics and so on. The question then becomes how you effectively bring a governance layer on top of that data, as well as giving the user a sense of what data is being generated and how it is being used. 

For Syntasso’s Abby Bangser as well, observability is about business outcomes. It’s rooted in the context of platform teams, including site reliability engineers, DevOps teams and platform engineers. Key to this is the fact that you can use observability to get the information you need to do your job, even when you don’t know upfront every question you need to ask. You can think differently about how you shape your data – and that’s a powerful direction in which to move. 

In platform engineering, observability provides the power to provide teams with the information they need not just to build and run their software as they need to, but to do so safely and successfully. 

What is the true value of observability?

From a business perspective, observability can help track whether an organisation is meeting its goals. Let’s say you have a new product to bring to market. First you need to articulate your goals. Then you can use observability to measure them. 

How many people are signing up for your product at the frontend? How many are using your API in the backend? What is your availability? Once you’ve worked out your goals, you can use observability to monitor your progress on the journey to achieving them. But you need to work out what your business, your team and your platform need as the starting point of designing your observability solution, if you are to gain full value from it.

Data governance in the context of observability 

Governance has something of a bad rep. But governance doesn’t have to feel like a restriction. In fact, when it can provide the strong foundations – repeatable, predictable, standardised foundations – that serve as a springboard to innovation. 

In observability terms, it is governance that can stop your data platform from becoming a kitchen sink. It can give you an ongoing strong opinion on what data you gather, how you use it and whether desired business outcomes are actually being delivered. 

Getting started with observability 

It can be hard to know where to start with observability. Should you be focusing on metrics, logs, traces…? 

There’s no easy answer to this, because it depends on what you’re trying to use observability to solve. One size doesn’t fit all. That said, you can choose between these foundational pieces – metrics, logs and traces – based on the greatest amount of grey pain in the problem you’re trying to solve. 

If you have infrastructure-related issues, for example, then metrics would be a good place to start, so that you can understand what’s happening in your environment. However, if your problem is users complaining about apps being slow, you’ll need to start in the application domain. The key point is to be really prescriptive in the problem you want to solve, then focus your observability solution around that. 

Of course, your platform stack won’t stand still. It will evolve, so your observability strategy needs to be agile enough to evolve alongside it. You’ll also need to focus on socio-technical challenges. People have a tendency to ask the questions they know they can answer. Instead, it’s crucial to focus on the questions that are going to bring value (whether to end users, internal teams or the business as a whole). 

Building a culture of asking questions is key to this. So is acknowledging that sometimes you have to put proxy measures in place because it’s not viable to have a better measurement at that moment. With this approach, you can build observability improvements along the way, rather than watering down the questions you ask. 

The other key element to consider is data ownership and data pipeline ownership. There are plenty of third-party providers that you can ship your data off to. However, buying a solution for visualising your data isn’t the same as outsourcing the ability to collect, filter and managed that data into more than one visualisation location. With observability, it’s important to think about the timescales for visualising your data with different third-party tools, as well as the different skillsets for managing and querying that data.  

Observability and API security 

Security isn’t the core use case of observability. However, observability is evolving and expanding its domain. As well as providing insights into what’s happening within applications, environments, databases, infrastructure and so on, it’s also hardening security. 

This intersection of API security and observability means that security teams can benefit alongside other teams. Indeed, different teams can often benefit from the same observability data – such as access logs enabling engineers to troubleshoot applications while also supporting security teams with threat detection. 

Observability versus analytics 

While we’re on the topic of observability, it’s worth noting the different roles of observability and analytics, as the two complement each other well. In short, observability is all about collecting data points and making observations across multiple systems. Analytics is about taking that information and connecting the dots contextually. 

Together, observability and analytics mean you can ask questions that you might not have even known you wanted to ask. 

Ready… set… observe!

If you’ve articulated your goals and the value you need observability to deliver, it’s time to formulate your strategy. As part of that, be sure to define your philosophy regarding how your data should be shaped and connected to each other. Doing so will empower people in disparate parts of the business to collect that data and engage with it. That shared understanding will be an important part of your observability strategy’s success. 

Of course, it’s also important to understand what not to do when it comes to your observability strategy. Check out our Bad API observability pocket guide for all you need to know.