devopsy.kinsta.cloud

Author: Mike Vizard

  • OpenTelemetry Graduation Sets Stage for AI Observability

    OpenTelemetry Graduation Sets Stage for AI Observability

    OpenTelemetry just hit graduated status at the CNCF, and the timing matters more than the milestone itself. After years of consolidating what used to be OpenTracing and OpenCensus, the project has quietly become the default way modern applications emit traces, metrics and logs — right as the industry is staring down a new wave of workloads that will generate more telemetry than anything that came before.

    Mike Vizard sits down with Chris Aniszczyk of the CNCF to dig into why graduation is less of a finish line and more of a starting point. Aniszczyk’s argument is that OTel’s real value isn’t in any single feature — it’s in being the vendor-neutral plumbing that finally lets organizations modernize legacy monitoring stacks without locking themselves into the next generation of proprietary agents.

    They get into the practical mechanics of running OTel at scale: managing the firehose of telemetry data, the trade-offs around sampling and cost control, and how teams are using the spec’s extensibility to instrument environments that were never designed to be observable in the first place. The discussion also touches on how OTel’s collector model gives platform teams a single chokepoint to enforce schema standards, reduce duplicate tooling and route signals to wherever they’re most useful.

    The bigger thread is what observability looks like once AI agents become first-class citizens in production. Tracing an autonomous workflow means following decisions across model calls, tool invocations and downstream services — with token usage, prompt context and intermediate reasoning all worth capturing. Aniszczyk makes the case that open standards are the only realistic foundation for that kind of traceability, and that the work happening inside OTel right now is what will determine whether agentic workloads stay debuggable as they scale.

  • Software Weaponization Raises DevSecOps Stakes

    Software Weaponization Raises DevSecOps Stakes

    The threat model that DevSecOps teams have been working from for the last decade was built around accidental vulnerabilities — mistakes that needed to be found and fixed before someone exploited them. That assumption is breaking. Vulnerabilities are increasingly being treated as strategic assets, stockpiled by nation-states and threat actors and held back from disclosure until they’re useful as weapons. That shift changes what “good enough” security looks like across the software delivery lifecycle.

    Mike Vizard sits down with Kate Scarcella and Tracy Ragan to dig into what software weaponization actually means in practice for engineering and security teams. Their argument is that the industry has spent years investing in pre-deployment scanning and not nearly enough in knowing what’s actually running in production. The result is sprawling estates of deployed software where teams can’t answer the basic question of which versions, in which configurations, are exposed to a newly disclosed, or quietly hoarded, vulnerability.

    They also get into the mechanics of closing that gap. Stronger SBOM practices are the foundation, but only if SBOMs are continuously updated, queryable and tied to the running environment, not parked in a build artifact. From there the conversation moves into automation: using AI-assisted tooling to identify exposed assets fast, prioritize remediation against real exploitability, and push fixes downstream without manual triage at every step.

    The other thread is organizational. AI is now both a tool defenders rely on and a source of new risk — data poisoning, model misuse, autonomous agents acting on stale context. Scarcella and Ragan make the case that this is the moment to break down the wall between developers, security teams and data scientists, with shared visibility, shared accountability and a runtime view of the entire software estate as the connective tissue.