Cloud Native

Beyond Dashboards: Danielle Cook on What Teams Should Actually Observe | Akamai

0

Guest: Danielle Cook (LinkedIn)
Company: Akamai
Show Name: An Eye on AI
Topic: Observability

Every booth at KubeCon has observability on it. The market is saturated with tools promising to monitor everything. But what should teams actually observe? That is the question Danielle Cook, Senior Product Marketing Manager at Akamai and CNCF Ambassador, posed when organizing her panel at KubeCon CloudNativeCon Atlanta. The answer reveals why most teams are drowning in observability noise instead of gaining actionable insights.

The Observability Noise Problem

Walk the expo hall at any KubeCon event and you will see observability everywhere. Vendors promise comprehensive monitoring, endless dashboards, and AI-powered insights. Yet teams are struggling more than ever to separate signal from noise. Cook identified this as the central challenge facing platform engineers and SREs today. How do you know what the noise levels are, and how can you turn them up or turn them down based on what will deliver actual metrics?

This is not a tooling problem. It is a strategy problem. Organizations have adopted observability tools without first defining what success looks like. They monitor everything because they can, not because they should. The result is alert fatigue, dashboard sprawl, and teams that spend more time managing their observability stack than actually improving their systems.

Cook assembled a panel of women leaders in observability from companies like Intuit and Eon to address this exact issue. The goal was to provide clarity to attendees on what they should actually look for in their observability practice. These are end users who have lived through the pain of implementing observability at scale and learned what works.

The AI Observability Question

The conversation around observability has been complicated further by AI. Cook highlighted a critical distinction that many teams miss. Do you need to use AI to help you observe, or are you using AI as a tool and need to observe it? Differentiating between these two scenarios will be a key theme not just at KubeCon but across the industry.

Using AI to help with observability means applying machine learning to detect anomalies, predict failures, or reduce alert noise. This is where tools use AI to make sense of the massive amounts of telemetry data flowing through modern systems. The promise is that AI can find patterns humans would miss and surface the insights that matter.

On the other hand, AI as a workload that needs to be observed represents an entirely different challenge. As organizations deploy AI models for inference at the edge or run large language models in production, these become systems that require their own observability strategy. Where are the bottlenecks? Is the model performing as expected? What is the cost per inference? These questions demand answers, and traditional observability approaches may not suffice.

Cook emphasized that AI workloads represent another layer where observability is absolutely necessary. But it is super noisy, she noted, pulling the conversation back to the core theme of breaking through that noise to identify what is most important.

Developer Experience and Business Outcomes

The panel Cook organized was designed to look beyond the technical metrics and ask how observability impacts developer experience and business goals. How can you make it easy for a developer to use observability in their day to day jobs that will make an impact on the business? That question gets to the heart of why observability exists in the first place.

Developers should not need to become observability experts to ship reliable software. The tooling should fit naturally into their workflow, surfacing insights when they matter most without requiring constant attention. When observability is done right, it accelerates development velocity rather than slowing it down.

Cook and her panelists planned to discuss metrics around SLOs and how observability meets business goals. Service level objectives provide a framework for defining what good looks like and measuring progress toward reliability targets. But SLOs only work if they are tied to actual business outcomes. Uptime for the sake of uptime is not the goal. The goal is ensuring customers can complete transactions, access content, or run their workloads without friction.

This shift from vanity metrics to business-aligned metrics represents a maturation of the observability practice. Teams are moving beyond collecting data to asking what story that data tells about customer experience and business impact.

Akamai’s Role in the Cloud Native Ecosystem

Akamai has been a household name in content delivery and security for decades, but the company is relatively new to the KubeCon and CNCF ecosystem. Through its acquisition of Linode and subsequent investment in cloud infrastructure, Akamai has positioned itself as a player in the cloud native space. Cook works within the cloud technology group, where engineering teams are developing managed Kubernetes services and open source tools that help organizations build internal developer platforms.

The company recently announced its Akamai Connected Cloud, which combines cloud infrastructure, security tooling, and edge capabilities to enable companies to run inference at the edge. This is where observability becomes critical. As AI workloads move closer to users for lower latency and better performance, the need for distributed observability grows. Understanding what is happening across a globally distributed edge infrastructure requires purpose-built tooling and clear strategies for what to observe.

What This Means for Platform Teams

Platform engineering has emerged as one of the dominant themes at recent KubeCon events. Cook noted that the last three KubeCrash conferences, a virtual event she co-founded, have seen attendees consistently ask for content on platform engineering. That is where the problems are, she explained. People want to talk about platform engineering and AI, and organizers are responding to that demand.

Platform teams sit at the intersection of infrastructure, developer experience, and business outcomes. They are responsible for building the foundations that enable other teams to ship software quickly and reliably. Observability is a core component of that foundation. But if the observability practice itself becomes a source of toil and complexity, it undermines the entire purpose of platform engineering.

The panel Cook organized aimed to help platform teams navigate this challenge by learning from practitioners who have built observability strategies that work at scale. Hearing from end users at companies like Intuit provides a reality check against vendor promises and helps teams avoid common pitfalls.

Closing

The shift from monitoring everything to observing what matters represents a strategic inflection point for cloud native teams. As AI workloads become more prevalent and platform engineering continues to mature, the ability to cut through observability noise will separate high-performing teams from those stuck in firefighting mode.

Why Your SOC Analysts Need AI Prompting Skills Now | Steve Winterfeld, Akamai

Previous article

Why AI Disruption Won’t Be the Doomsday Scenario Enterprises Fear | Rupesh Chokshi, Akamai

Next article