A presentation at Tech Hub Aarhus Day in in Aarhus, Denmark by Kasper Borg Nissen
Tech Hub Aarhus Day Rethinking Observability as a Platform Capability Kasper KasperBorg BorgNissen, Nissen,Principal PrincipalDeveloper DeveloperAdvocate Advocateat Dash0 kaspernissen.xyz /in/kaspernissen kaspernissen
Tech Hub Aarhus Day Rethinking Observability as a Platform Capability Product Kasper KasperBorg BorgNissen, Nissen,Principal PrincipalDeveloper DeveloperAdvocate Advocateat Dash0 kaspernissen.xyz /in/kaspernissen kaspernissen
Who? Principal Developer Advocate at Dash0 (previously Lunar) KubeCon+CloudNativeCon EU/NA 24/25 Co-Chair (former) Author of OpenTelemetry for Dummies CNCF Ambassador Golden Kubestronaut CNCG Aarhus, KCD Denmark Organizer Co-founder & Community Lead Cloud Native Nordics
Let’s talk about Kubernetes
Kubernetes is a platform for building platforms Bryan Liles KubeCon+CloudNativeCon in San Diego 2019
The Rails Moment
Cognitive Load Cognitive load over time 2000 2005 2010 2015 2020 2026 Visualization Inspired by Daniel Bryant’s talk
🤯 Cognitive load over time Cognitive Load Microservices/ k8s 🤔 😊 Monolith/SO A Monolith/ Heroku 🥳 Monolith 2000 🤗 2005 2010 Microservices/ Platform Engineering 2015 2020 2026 Visualization Inspired by Daniel Bryant’s talk
Why Platform Engineering Emerged �� Developer Kubernetes
Why Platform Engineering Emerged Developer ? Kubernetes
Why Platform Engineering Emerged 🤗 Developer Platform Kubernetes
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support arranged as a compelling internal product. Evan Bottcher https://martinfowler.com/articles/talk-about-platforms.html
Team Topologies ◗ Platform Team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams
Platform as a Product ◗ Platform as a Product (PaaP) is an approach where internal platforms are treated as evolving products with defined users (developers, operations teams) and lifecycles.
The missing abstraction 🥳 Developer Product 1 Product 2 Platform Kubernetes Product 3
Observability Today… Same mistakes, different domain
Observability promised a lot Faster root cause analysis Understanding system behavior Lower MTTR Where do I start? Which tool is right? Why is this metric spiking? Reduced guesswork Human correlation Expectation Reality
LOGS METRICS level=DEBUG level=debug LEVEL=DEBUG 100s/1000s of Microservices TRACES RUM PROFILING DISTRIBUTED SYSTEMS Finding the needle in the haystack
The current reality: fragmentation
The current reality: fragmentation Complex Query Languages
The current reality: fragmentation Complex Query Languages Vendor lock-in
The current reality: fragmentation Complex Query Languages Vendor lock-in Metadata Inconsistency
The current reality: fragmentation Complex Query Languages Vendor lock-in No instrumentation due to high complexity Metadata Inconsistency
The current reality: fragmentation Complex Query Languages Vendor lock-in No instrumentation due to high complexity Metadata Inconsistency Lack of unified insights
The cost & complexity paradox More telemetry, more tooling - same time to recovery Cost Relative Impact Complexity MTTR Time
Up to 84% of current observability users struggle with the costs and complexity of their daily monitoring responsibilities. Gartner Hype Cycle Report, 2025 Source: https://www.gartner.com/en/documents/6755734 26
This isn’t necessarily a tooling problem We don’t have a metrics problem, or a tracing problem. We have systems problems. Metrics Logs Traces
Let’s stop talking about the three pillars of observability … Kill The Three Pillars Manifesto Metrics Logs Traces
Same mistake as early Kubernetes Powerful primitives - no default experience All valid tools. No opinionated workflow.
A shift toward correlation Find related information Jump between signals Reconstruct chain of events
A shift toward…
OpenTelemetry OpenTelemetry (OTel) is an open source project designed to provide standardized tools and APIs for generating, collecting, and exporting telemetry data such as traces, metrics, and logs The de-facto standard for distributed tracing, supports metrics, logs, profiling & RUM The main goals of the project are: Unified telemetry Vendor neutrality Cross platform
OpenTelemetry in a nutshell OpenTelemetry is a toolkit and a specification. What it is ◗ ◗ ◗ ◗ ◗ ◗ Data models API specifications Semantic conventions Library implementations in many languages Utilities and much more What it is NOT ◗ ◗ ◗ ◗ ◗ ◗ Proprietary An all-in-one observability tool A data storage or dashboarding solution A query language A Performance Optimizer Feature complete
1/1/20251/1/2026 Commits: 37.959 PRs+Issues: 46.709 Commits: 53.495 PRs+Issues: 40.597 Source: CNCF Velocity Report
49% of respondents using OpenTelemetry in production. 26% of respondents evaluating OpenTelemetry. Source: https://www.cncf.io/wp-content/uploads/2026/01/CNCF_Annual_Survey_Report_final.pdf
Signals METRICS 42 LOGS 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 TRACES PROFILES RUM
Correlation is the superpower METRICS 42 LOGS 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 20/JUN/2025 “GET / HTTP/1.1ˮ 200 TRACES PROFILES RUM
OpenTelemetry: A 1000 miles view Instrumentation OTel API & SDK Telemetry Backends The OpenTelemetry Collector auto-instrumentation Time-series database … Log database Receive Process Analysis Tools Export Trace database Infrastructure … Kubernetes … Generate and Emit transmit Collect, Convert, Process, Route, Export transmit Store & Analyze Inspired by visualizations from LFS148
OpenTelemetry: A 1000 miles view OTel API & SDK Collection of Telemetry is standardized Vendor space The OpenTelemetry Collector auto-instrumentation … Receive Process Export Infrastructure Kubernetes … “The last observability agent you will ever install” Generate and Emit transmit Collect, Convert, Process, Route, Export … and many more. transmit Store & Analyze
Telemetry without context is just data
What are we looking at?
What are we looking at? Awww… Adorable! Cute Cuteness Pretty Normal Unfortunate Creepy Reddit /r/funny, “Cuteness Vs Number of legs” (circa 2010) Gaah! Kill it! Kill it! 0 1 2 3 4 5 Number of Legs 6 7 8
How we talk about system context Organization (By whom) 1 Architecture (What / Why) Which service / system component is this? 2 Compute (How/2) 3 Platform (How) Kubernetes? Which cluster / namespace / deployment / cronjob / job / pod? AWS ECS? Which cluster / service / task? … Which team owns it? “Who you gonna call?” .. 4 Which container? Which process? Pid? Startup args? Which runtime is it? Node.js? JVM? .NET? Which build? Which version? … Infrastructure (Where) 5 Which datacenter / Cloud region / availability zone / account does it run in? …
OpenTelemetry semantic conventions to context layers 1 Organization 😢 Architecture Service (stable) and (experimental) Deployment Environment 2 Compute 3 Platform Kubernetes Cloud (cloud.platform specifically) Cloud-provider specific 4 COM NOT PRE A HE LIST NSIVE ! Telemetry SDK (stable) and (experimental) Compute Unit and Instance Operating System Process & Process Runtimes Device, Browser, Webengine, … … 5 Infrastructure Cloud (general stuff)
The Platform Team’s Role Observe the platform Enable developers cloud, cluster, CI/CD, shared DBs, etc. traces, metrics, logs, profiling
What does “Observability as a Product” mean? The platform absorbs complexity so teams can focus on understanding systems. Observability as tooling ◗ ◗ ◗ ◗ Terminal YAML Dashboards with empty states Many knobs Observability as a Product ◗ ◗ ◗ ◗ Clean UI Pre-populated dashboards Correlated views “It just works”
Paved Paths for Observability Paved Observability Path Logs Metrics Storage Traces Collectors Correlation Engine Instrumentation
Auto-instrumentation changes the game Manual Instrumentation (fully code-based) Automatic Instrumentation (agent, binaries) No-touch Instrumentation (or zero-code)
Operators as the delivery mechanism Instrumentation Instructs how to inject auto-instrumentation Injects instrumentation in to the pod OpenTelemetry Operator
Observability doesn’t stop at instrumentation Vendors How humans and agents understand the system Explorers Dashboards Alerting … and many more. Synthetic Checks Service Maps Agents Your environment (k8s, cloud, etc) OSS How telemetry is produced and collected Where telemetry lives and how it’s accessed Cost Insights
Why AI needs a platform first Garbage In Garbage Out
Why AI needs a platform first Specifications and Semantic Conventions Your Telemetry
The future interaction model
Demo
So why, OpenTelemetry? Instrument once, use everywhere Separate telemetry generation from analysis Make software observable by default Improve how we use telemetry
Why Observability as Platform Product? ◗ ◗ ◗ ◗ Reduce cognitive load Correlation by default Structure, standardized telemetry Foundation for AI-driven workflows Developers can focus on delivering business value, with observability as a built-in safety net.
https://university.platformengineering.org/observability-for-platform-engineering
Book Get a free copy
Tech Hub Aarhus Day Thank you! Kasper KasperBorg BorgNissen, Nissen,Principal PrincipalDeveloper DeveloperAdvocate Advocateat Dash0 kaspernissen.xyz /in/kaspernissen kaspernissen
Tech Hub Aarhus Day Get in touch! kaspernissen.xyz /in/kaspernissen kaspernissen
Kubernetes has become the default platform for modern applications - but observability hasn’t kept pace. Many teams still rely on disconnected tools and partial signals: metrics without context, logs without structure, and traces that are hard to reason about. The result is slower incident response, higher cognitive load, and unnecessary friction for developers.
This talk explores the shift from observability as a collection of tools to observability as a platform capability. We’ll look at why correlation across signals is essential for understanding complex systems, how platform teams can reduce developer toil through paved paths, and what it means to offer observability as a shared service on Kubernetes.
Using real-world platform patterns, we’ll discuss how consistent, structured telemetry enables faster debugging, better decisions, and lays the groundwork for the next evolution of observability - including AI-assisted workflows and more natural ways of interacting with production systems. We’ll close with a live demo showing how Kubernetes-native automation and open standards enable auto-instrumentation and correlated signals out of the box, giving teams immediate visibility without requiring code changes.
