Table of Contents
Table of Contents
A procurement document says “Apache Kafka.” The architecture diagram says “managed Kafka.” Both statements can be true, and that is where many evaluations go off course. Apache Kafka may be the software underneath a paid distribution or a hosted service, while the thing you buy includes packaging, operations, private networking, support, and features around the project.
The useful question is not whether a Kafka offering is open source or commercial. It is which part of the stack you can run, inspect, move, and govern yourself. Once you separate the Apache Kafka project, Kafka-compatible distributions, and managed services, the boundary becomes concrete: you can see what you own, what you operate, and what you rent.
1The API name hides three different boundaries
“Kafka” can refer to a protocol contract, a software distribution, or a service. Those are related, but they answer different procurement questions.
Apache Kafka project. This is the upstream open-source software and its community-defined APIs and semantics. Under the Apache License 2.0, an organization can run, modify, and redistribute the software subject to the license terms. The organization still owns the work of building the cluster, choosing the storage, operating the brokers, and protecting the data plane.
Kafka-compatible distribution. This keeps enough of the Kafka client and broker contract for existing producers, consumers, and tools to connect, but the implementation may change the storage layer, packaging, control plane, or operational model. Its license can be Apache 2.0, another source-available license, or a commercial license. “Compatible” describes an interface and behavior claim. It does not tell you who owns the runtime or which features are portable.
Managed Kafka service. A provider runs some or all of the infrastructure and lifecycle work. You rent an operational outcome through an endpoint, account, or contract. The service may run Apache Kafka itself or a compatible implementation. Open-source software underneath does not turn the service into a self-managed deployment.
These categories can overlap. A provider can manage an Apache Kafka distribution. A Kafka-compatible project can offer a self-managed package and a managed service. The model separates the software layer from the operating boundary, because a single “open source versus commercial” label hides both.
2What you own and what you rent
Ownership becomes easier to discuss when it is tied to a concrete object. A team may own its event records while renting the brokers that store and serve them. It may have the right to inspect source code while lacking control over the service’s maintenance schedule. It may run software in its cloud account while buying a provider-managed control plane.
| Model | You usually control | You usually rent or delegate | Boundary to verify |
|---|---|---|---|
| Self-managed Apache Kafka | Software deployment, broker settings, storage, network path, upgrades, and data plane | Support, infrastructure, or specialist help if purchased separately | Your team carries failure recovery, capacity work, and patching |
| Self-managed compatible distribution | Runtime, data plane, and the distribution’s exposed configuration | Vendor support, commercial features, or a support contract | The license and feature set determine how much of the distribution is reusable |
| Managed Kafka service | Client applications, topics, data governance, and service-level configuration exposed to you | Brokers, host maintenance, provider control plane, and part of incident response | The contract and service limits define your control more precisely than the API does |
| Customer-cloud managed service | Data-plane location, cloud account, network boundary, and selected cloud resources | Lifecycle automation, support, upgrades, and provider tooling | Check whether the service can operate during a control-plane incident and what access it needs |
The table is a starting point. A managed service can be the right trade when a platform team would rather buy operational coverage than run broker recovery at night. Self-managed software can be the right trade in an air-gapped environment or where internal teams need direct control over every runtime component. A Bring Your Own Cloud (BYOC) model can fit when the data plane must stay in the customer’s cloud boundary while the Kafka lifecycle is still managed.
That is also why a license review and a deployment review belong in the same decision record, but should not be collapsed into one question. The license tells you what you may do with software. The deployment model tells you where the running system and its data live.
3Compatibility answers one question, not all of them
Kafka compatibility is valuable because it can protect application investments. A producer that uses standard Kafka APIs, a consumer group that relies on offsets, and a connector that follows Kafka’s protocol expectations may move with limited application change. That is a useful baseline for a platform evaluation.
It does not answer every portability question. The compatibility surface should be split into at least four checks:
- Client behavior: Can producers, consumers, and Kafka Connect workers use the APIs and semantics they depend on?
- Operational behavior: Are topic configuration, quotas, access control lists (ACLs), rebalancing, upgrades, and recovery exposed in a way the team can automate?
- Data-plane behavior: Where are records, offsets, metadata, and schemas stored, and can the team access the underlying cloud resources? Include the virtual private cloud (VPC), object storage, and identity boundary.
- Extension behavior: Are stream processing, governance, connectors, observability, private networking, or security features standard Kafka capabilities or platform-specific additions?
A client test may pass while the operating-model test fails. For example, a team can connect to a hosted service with familiar clients but lose the ability to choose broker placement, inspect the storage path, or reproduce the deployment in another account. That is not a contradiction. It is the difference between API portability and platform portability.
If the requirement is Kafka compatibility with a customer-controlled data plane and a storage architecture that does not tie durable records to broker-local disks, AutoMQ is a concrete example to evaluate. Its open-source project keeps the Kafka protocol and semantics while using a Shared Storage architecture built around S3Stream and S3-compatible object storage. In a self-managed deployment, the team runs the brokers and controls the data plane. The architecture changes the storage boundary underneath the Kafka interface, so that compatibility and operational ownership can be evaluated separately.
The important qualification is that “Kafka-compatible” does not mean “identical in every operational detail.” A serious evaluation should test the client versions, configurations, integrations, failure behavior, and export path that the workload actually uses. Compatibility is a gate into testing, not a substitute for testing.
4A license changes software rights, not data location
Licensing questions often become too broad. Apache License 2.0 is permissive software licensing. It gives users broad rights to use, modify, and distribute covered code, subject to conditions such as preserving notices and complying with the license. It does not decide whether a broker runs in your account, whether a provider operates the cluster, or whether records can be exported without a commercial process.
Source-available licenses require closer reading. A Business Source License may allow source access while limiting particular production or service uses during a stated period. The exact grant, change date, and conversion terms matter. The Server Side Public License adds source obligations for organizations offering a program as a service. Neither label is enough to answer a buyer’s question without reading the actual license text and the intended use.
Managed services introduce a separate commercial layer even when the underlying code is Apache-licensed. The provider can charge for hosted capacity, support, service features, private connectivity, storage, data transfer, or a commitment. Those charges do not change the upstream license. They change the cost and responsibility of running a production system.
For a Kafka evaluation, ask these questions in order:
- What does the license permit for our use case? Check internal use, modification, redistribution, embedding, and offering the software as a service.
- Which code and features are covered? A vendor may combine open-source components with proprietary packaging, control-plane services, connectors, or enterprise features.
- Where does the data plane run? Identify the cloud account, virtual private cloud (VPC), object storage, block storage, and provider access path that hold the records and metadata.
- What remains usable if the commercial relationship ends? Inventory clients, topic settings, ACLs, schemas, offsets, connectors, dashboards, and infrastructure definitions.
Procurement teams often postpone the fourth question. It turns a license discussion into an exit discussion. You can have broad rights to a codebase and still face a costly migration if the application depends on proprietary connectors, service-specific schemas, or a data path that is difficult to export. You can also have a managed service that is commercially sound if the data location, API contract, and transition procedure are explicit.
5Managed service or commercial wrapper?
A “commercial wrapper” can sound dismissive, although the layer often pays for real work. Packaging a distribution, testing upgrades, maintaining a support organization, managing incidents, exposing private connectivity, and building a usable control plane all have value. The question is whether that value sits at the boundary your team wants to rent.
There are three common boundaries:
- Software boundary: You receive packages, source, and documentation. Your team owns the running cluster.
- Control-plane boundary: A provider automates provisioning, configuration, scaling, and upgrades, while the data plane may remain in your account or environment.
- Data-plane boundary: The provider also runs the brokers and storage on its infrastructure. You consume the Kafka endpoint and the service contract.
The same vendor can offer more than one boundary. A customer may select a self-managed distribution for a private environment, BYOC for a customer-owned cloud account, or a fully hosted service for a team that wants fewer infrastructure responsibilities. Those choices layer operations over a compatible runtime.
For a BYOC design, inspect the data plane rather than stopping at the marketing label. AutoMQ’s BYOC documentation describes the control plane and data plane as running in the customer’s cloud account, with Kafka data remaining in customer-controlled VPC and object storage resources. That makes it a useful example of a managed operating model paired with customer-side data-plane placement. A self-managed AutoMQ deployment moves more of the lifecycle work back to the customer, while retaining the Kafka-compatible data-plane architecture.
This separation gives the buyer a better negotiation frame. Instead of asking whether a product is open source, ask which rights, resources, and operational duties the contract assigns to each party. Instead of asking whether a service is managed, ask which failures and changes still require your team to act.
6The take-with-you list
Before approving a Kafka distribution or managed service, write down the answers to this checklist. It is short enough for procurement and specific enough for an architecture review.
- License: What license covers the broker, storage layer, connectors, and control plane? Which use restrictions apply to your deployment and service model?
- Client contract: Which Kafka APIs, protocol versions, and configurations are tested for your producers, consumers, and connectors?
- Data plane: Which account and network hold records, offsets, metadata, and schemas? Who can access those resources?
- Operations: Who owns upgrades, broker replacement, capacity planning, recovery, and incident response? What signals can your team inspect?
- Portability: Can you recreate topics, access control lists (ACLs), quotas, schemas, connectors, and monitoring somewhere else? How are offsets preserved or translated?
- Commercial boundary: Which costs come from software, support, hosted capacity, storage, transfer, private networking, and exit work?
The first two checks protect the application contract. The next two protect operational and data-plane control. The last two make the transition cost visible before it becomes urgent. The boundary is the line between code you may use and a production system you can operate, inspect, and move.
If you are evaluating a Kafka-compatible platform, start with one workload and map these six answers to its real topics, connectors, cloud resources, and failure drills. The AutoMQ architecture documentation shows how its Shared Storage model separates broker compute from durable storage. The Kafka compatibility documentation gives the corresponding protocol boundary. If the model fits, start with the AutoMQ open-source project and validate the client, storage, and recovery behavior before making a broader platform decision.
7References
- Apache Kafka source repository and license
- Apache Kafka documentation
- Apache License 2.0
- Business Source License 1.1
- Server Side Public License
- AutoMQ licensing and enterprise features
- AutoMQ BYOC overview
- Operating model design for enterprise platform ownership
- Data ownership trade-offs in multi-cloud Kafka operations
8FAQ
8.1Is Apache Kafka commercial software?
Apache Kafka is an Apache-licensed open-source project. Companies can still sell distributions, support, hosted capacity, connectors, control-plane tooling, and managed operations around it. “Commercial Kafka” usually describes the paid product or service boundary, not a change to the upstream project’s license.
8.2Is a managed Kafka service open source?
It may run open-source Apache Kafka or another Kafka-compatible implementation. Managed describes who operates the infrastructure and which responsibilities the provider takes on. It does not describe the license by itself.
8.3Does Kafka compatibility remove vendor lock-in?
It can reduce application lock-in when the workload uses standard Kafka clients and semantics. It does not automatically make data export, topic governance, connectors, observability, networking, or recovery portable. Test the full dependency set that production uses.
8.4Does the Apache 2.0 license guarantee control of the data plane?
No. Apache 2.0 governs rights to use, modify, and distribute covered software. A hosted service can run Apache-licensed code while keeping the brokers, storage, and operational controls inside the provider’s boundary. Data-plane control comes from the deployment model and contract.
8.5Where does AutoMQ fit in these categories?
AutoMQ is a Kafka-compatible implementation with an open-source project and self-managed deployment path. Its Shared Storage architecture moves durable stream storage into S3-compatible object storage while keeping Kafka client and semantic compatibility. AutoMQ BYOC adds a managed operating model in the customer’s cloud account, so the software rights, deployment boundary, and operations boundary should be reviewed separately.
