This time I sat down with Karim Traiaia, the Co-founder of Kerno, a company that helps troubleshoot cloud applications. Here are some of the topics we discussed:

* The sparkEvery startup starts with a pain point—how did Karim come up with Kerno, and what problem was he trying to solve at the beginning?

* First customersLanding those early paying users is always tough. Did Kerno rely on free trials, community outreach, or partnerships to get started?

* The eBPF foundationWas eBPF part of the plan from day one, or did the idea for Kerno evolve into it over time? And why eBPF specifically over other tooling?

* What only eBPF can doWhere has eBPF been able to collect critical data that simply wasn’t available from user space or other observability tools?

* Taming the telemetry floodObservability tools generate a LOT of events—from syscalls to protocol traces. How does Kerno decide what data to keep vs. what’s just noise, and how much is actually useful in practice?

* The observer effectWhat about CPU and memory overhead—how does Kerno make sure the eBPF agent itself doesn’t impact the workloads?

* Scaling upWhat’s the largest production environment Kerno has been tested in? What bottlenecks emerged at scale, and how were they solved?

* Measuring impactKerno promises a “64% reduction in customer-facing production incidents” and a “3x increase in successful deployment attempts.” How are those numbers measured and validated?

* Looking aheadWhat would Karim consider a home-run feature or capability for Kerno three years from now?

* From visibility to autonomyWill we see a future where observability shifts from passive runtime visibility to autonomous systems that detect and act on issues—powered by eBPF-fed AI models?

* Startup mindsetIf Karim were a fresh graduate looking at the industry, how would he approach finding and validating an idea that could grow into a startup?

🐝 I’ll leave it there—hope you enjoy the conversation.

This time I sat down with Nikolay Sivko, the Founder and CEO at Coroot, and here are some of the topics we discussed:

* The sparkEvery product begins with a pain point—what was the “aha moment” that made Coroot necessary?

* The landscapeWhen looking at the broad observability market, what’s the biggest advantage Coroot brings compared to existing solutions?

* The profiling edgeMetrics, logs, traces, and continuous profiling all ship out of the box. Where has profiling made the biggest difference in practice?

* Zero-code instrumentationCoroot promises instrumentation without code changes for every language on Kubernetes. Which runtime—Java, Go, Rust, etc.—caused the trickiest edge cases, and how were they solved?

* Taming the firehoseCollecting “everything” is easy—handling it without blowing up the system is the real challenge. How do you decide which telemetry data is important and which not?

* The eBPF observer effectWhat about CPU and memory overhead—how do you guard against the tooling itself impacting the workload?

* 80/20 troubleshootingHow did you arrive at the idea that 80% of issues follow common patterns, and the remaining 20% can be uncovered by linking logs with other system data?

* AI insightsCoroot uses AI to surface actionable insights. How do you avoid false positives and measure the success rate of those explanations?

* From telemetry to root causeHow do you actually map raw telemetry to a possible root cause—is this a huge state machine, pattern matching, or something else under the hood?

* The future of observabilityWill we see a shift from passive runtime visibility to autonomous systems that not only detect but also act on issues, powered by eBPF-fed AI models? The fear, of course, is false positives—how do you see that playing out?

* Community energyYour GitHub repo has passed 6,000 stars in a short time. What have you learned about building—and sustaining—an engaged open-source community?

🐝 I’ll leave it there—hope you enjoy the conversation.

It’s been a while since I first had this idea, but I’ve been thinking hard about how to extend eBPFChirp newsletter and inject more real eBPF energy into the community.

Alongside developing eBPF online coding exercises (still in progress), I want to add interviews that deliver a personal touch and real industry insight—what’s happening inside the minds of exceptional people at companies like Cisco, Cloudflare, and beyond.

Bill Mulligan is definitely one of them and we discussed several interesting topics:

* A day in the lifeWhat does a typical workday look like for you?

* First encounterHow did you first “bump into” eBPF?

* The children’s book twistWhat sparked the idea to write a children’s book about eBPF?

* Common misconceptionsWhat’s the single biggest myth you still hear from newcomers kicking the tires on eBPF?

* Security concernsMany security engineers shy away from eBPF because it traditionally requires root access. Are those risks still real today, and how do you frame the conversation?

* Enterprise signalsYou talk to enterprises every week—what concrete signal tells you eBPF is a fit for them, and how can engineers spot that same signal inside their own orgs?

* Emerging workloadsLooking at the eBPF ecosystem right now—edge AI, 5G cores, serverless—which workload is about to unlock a “must‑have” eBPF pattern that nobody’s talking about yet?

* Scaling Cilium adoptionYou helped Cilium leap from “cool project” to the de‑facto Kubernetes networking standard. What marketing tactic actually moved the needle?

* Inspiring the next generationMany computer‑science students still see networking as “boring” and eBPF as niche. What concrete steps should faculty and staff take to make these topics engaging and mainstream?

* eBPF Documentary Part 2 😉

I’ll leave it at that — hope you enjoy the conversation. 🐝