When your product depends on Apache Kafka, performance and reliability are non-negotiable. But in working with dozens of customers—each responsible for deploying and managing their own Kafka clusters—I saw a recurring pattern: running Kafka was a major operational burden, even for teams with dedicated Kafka experts.

The challenge wasn’t Kafka itself. It was everything around it.

The Kafka Adoption Challenge

Here are the most common struggles I observed:

  • Out of Sight, Out of Mind
    These Kafka clusters were often deployed for a single product, so they weren’t treated like critical shared infrastructure. They got neglected—until things went wrong.

  • A Different Kind of Operations
    Operating Kafka for a third-party product is very different from managing it for internal applications. Customers often lacked context, expertise, or both.

  • Every Deployment Was a Snowflake
    Different clouds, different scaling approaches, different monitoring—every customer environment was unique. This increased support costs, slowed down adoption, and hurt overall satisfaction.

So how do you support dozens of Kafka clusters, across multiple clouds, in networks you don’t control, when you can’t touch the config?

Enter Strimzi: A Path to Standardization

We turned to the Strimzi Kafka Operator—and it changed everything.

With Strimzi, we could standardize deployments while giving customers the flexibility they needed. Here’s how we made it work:

  • Reference Architecture via Helm
    We built a Helm chart that encapsulated best practices, tested defaults, and smart guardrails. Customers only needed to make decisions relevant to their environment—reducing risk and complexity.

  • Test Bed for Config Validation
    Knowing that customers often skip thorough testing, we created a test environment to validate Kafka configurations before they hit production.

This let us move from reactive firefighting to proactive, scalable support.

Crisis as a Catalyst

Convincing customers to replace or rebuild their Kafka clusters isn’t easy—until a crisis forces the issue.

In one case, a customer handling over 1 PB of compressed messages per day in a single Kafka topic, with a 100ms publish SLA, started seeing producer timeouts. The root cause? The cluster was in a degraded state—more than 200 Kafka brokers, unbalanced and under pressure.

Using our prepackaged Strimzi Helm configuration, I sat down and did the math:

  • What’s the ideal vertical scaling approach using Azure node types?
  • How many brokers are needed?
  • What resource limits make sense per pod?

The customer deployed a new Kubernetes node pool. We adjusted resource requests to fit the node sizes, scheduled a brief outage, and went for it.

With Strimzi:

  • We deployed a fresh cluster in hours
  • Rebalanced partitions using Cruise Control
  • Stabilized performance and reduced cost

Yes, you can do all of that manually with Kafka. But you can’t put yourself in a container and manage clusters across the globe in every time zone at once. With Strimzi, we could.

From 1 PB to 13 PB

That same customer? A month later they were pushing 4 PB/day. The last time I checked? 13 PB/day.

Thanks to Strimzi:

  • They scaled horizontally with confidence
  • Maintained SLAs across explosive growth
  • Avoided major outages and support escalations

Without Strimzi, supporting that kind of scale would have meant training hundreds of engineers on the deep internals of Kafka operations. That’s just not practical—or sustainable.

The Impact

Before Strimzi:

  • Deploying Kafka clusters added up to 90 days to project schedules
  • Human error led to 2–6 days of downtime per cluster, per year

With Strimzi:

  • Kafka deployment time dropped to under 1 hour
  • Support overhead plummeted
  • Downtime due to config or operational error? Gone

Final Thoughts

Strimzi isn’t just a Kubernetes operator. It’s a force multiplier. It enabled our teams—and our customers—to operate mission-critical Kafka infrastructure at scale, with consistency and confidence.

When developers ask me what operators can really do, I point to Strimzi. It’s not just automation—it’s operational excellence in a box.