Deployment makes a prototype available in an environment where other teams can use it. For Kafka, that means more than starting brokers: controllers must manage cluster metadata, and the resulting system must be supportable throughout its lifecycle. section 9.0 section 1.6
Choose where Kafka runs by weighing operational responsibility against the needs of the system:
- On-premises deployment gives a team direct responsibility for servers, broker configuration, authentication, monitoring, and disaster recovery. It suits organizations with engineers who can manage those demands and tune performance and cost. section 9.2.1
- Managed cloud deployment shifts provisioning, updates, and much maintenance to a provider. It reduces operational burden but can cost more at scale and limit control over broker settings and version upgrades. section 9.2.1
- Hybrid deployment is another viable option. Compare it with on-premises and cloud approaches against latency, cost, operability, security, and compliance needs rather than treating any model as the default. section 9.0 section 9.2
From prototype to production
A team planning to put a Kafka prototype on-premises budgets for brokers, then discovers it must also place and configure controllers to manage topics, partitions, configurations, and other metadata. Making the system accessible therefore requires an operational plan, not just running the application. section 9.0
Deployment also applies to services that use Kafka. A trained machine-learning model can be deployed to a model server before a streaming application sends it events for predictions. Model training and model deployment remain separate activities. section 12.4.1
