A bittern-marsh team already has Kafka producers and needs Event Hubs without rewriting to AMQP on day one. What should the developer configure?
Select an answer to reveal the explanation.
Short Explanation
Keep the Kafka clients and aim them at Event Hubs. Use the namespace Kafka endpoint as bootstrap instead of rewriting every publisher to AMQP on day one.
Full Explanation
Azure Event Hubs exposes a Kafka protocol endpoint on the namespace, so a bittern-marsh team can keep existing Kafka producers and point bootstrap servers at that Event Hubs Kafka endpoint instead of rewriting every publisher to AMQP on day one. Compatibility configuration (bootstrap, security, topic/event hub naming) lets Kafka clients publish and consume against Event Hubs while the platform still provides partitions, retention, and Capture where needed.
Replacing every producer with Notification Hubs before any publish fails because Notification Hubs targets push notifications to devices, not Kafka-compatible high-throughput event ingestion. Forcing AMQP-only clients and rejecting Kafka bootstrap settings fails the migration goal: it mandates an SDK rewrite the team is trying to avoid. Moving producers into Azure VMs solely to unlock Kafka protocol fails conceptually—Kafka support is a protocol endpoint feature of Event Hubs, not something unlocked by VM placement.
Exam caveat: Kafka feature parity is not identical to every Apache Kafka broker capability; validate compression, transactions, and client versions against current Event Hubs Kafka support before assuming full Kafka semantics. Operational check: connect a Kafka console or existing producer using the namespace Kafka bootstrap and credentials, publish a test record to the target event hub/topic name, and confirm it appears for an Event Hubs or Kafka consumer.