Why observability is the next "big thing" in telecoms

I was inspired to write this article by Adaora Okeleke and her team at Analysys Mason who published some research on this topic recently.

Observability is a term that has been rumbling around in the background for a few years in our industry. I believe it is now about to cross-the-chasm and go mainstream in telecoms.

But what is it? Why now? And why should you care?

Why now?

Let's start with this because I think it provides useful context for the first question ("what is it?"). The short answer to "why now?" is the cloud. More specifically, the adoption of cloud native applications, micro-services architectures and the dis-aggregation of networks*.

Multi-cloud is also a factor: the average enterprise has its data and applications spread across 6.8 different cloud environments**. We're perhaps not quite as fragmented as that in telecoms but we're going in that direction.

* if you're averse to jargon you could just say that our world is getting fiendishly complicated and that much of the stuff that used to sit in one location is getting split up and scattered all over the shop

** I'll try to find the exact source for this, but do let me know if you have an opinion on this figure and it's relevance to telecoms.

What is it?

There are a bunch of definitions and resources out there, but personally I found the beginner's guide here relatively easy to understand and relate to. Here is how I made sense of it inside my own head, so apologies in advance for any omissions, inaccuracies or misinterpretations. Observability to me appears to mean quite a few things:

• Having contextualized knowledge about what is going on
• "Joining-the-dots" to have and end-to-end view about what is happening in a distributed multi-cloud environment
• Understanding the dependencies between different applications, functions, micro-services, et cetera
• Being able to quantify the impact of issues on service quality, availability and end user experience (and more importantly knowing how to fix those issues!)
• Adopting a new mindset or philosophy (observability is not just a tool or technology consideration and reminds me of an earlier crossover from the IT world: DevOps)

What is it NOT?

Observability is NOT just a clever new buzzword for monitoring. We can easily monitor a monolithic application, or single domain. Observability goes far beyond that. Bence Szeidl gave a great example earlier today to explain the distinction between monitoring and observability. I don't want to reveal too many details here but it related to Edge computing, and finding the best way to optimize performance for different IoT devices and services. Traditional monitoring approaches were not sufficient because there were too many different variables, and it was impossible to know in advance all of the issues that might be encountered.

Why should you care?

If you've managed to stick with me this far I hope you'll agree that observability is a really important topic for our industry. I can forsee it having a big impact across the whole of a service provider's operations. For example, bringing new insights to guide network planning and optimization, different approaches to service assurance, a better way to manage unpredictable security threats, and potentially many other areas.

I'm also reminded of a speech given by Donald Rumsfeld that attracted some derision at the time, but now looks increasingly astute. Rumsfeld spoke about "Known Knowns". In telecoms we have already entering the realm of "Unknown Unknowns" - and that is precisely why we need observability!

As a final indulgence, and somewhat of a tangent let me re-introduce this old slide that I created B.C. (Before COVID). It was an attempt to build a simple framework to spark discussion on the application of AI/ML. We could simply replace Autonomation (here on the top right) with Observability as the solution to the "Unknown Unknowns" that we face. Sadly, I never found time to commercialize my ideas for the Internet of Dogs :(