| Product Architecture | Apache Kafka is architected as a simple broker with a sophisticated API. That means the broker provides limited functionality from a messaging feature point of view – it just replays logs as they were received, leaving the complexity of messaging handling up to API libraries and applications themselves. The simplicity of the Kafka broker also necessitates the use of components such as Zookeeper and MirrorMaker, which adds to deployment and engineering complexity. | PubSub+ is a sophisticated message broker that provides comprehensive messaging and routing features while ensuring application simplicity. PubSub+ implements open wireline protocols and integrated resiliency, robustness, security and management features all without any other external components. |
| Application Integration | Apache Kafka supports custom Java and GO APIs so custom integration is necessary. APIs in other languages are maintained by individuals (not Apache) and are not generally kept up to date. MQTT, AMQP are not supported and the Kafka architecture requires external proxies to provide wireline interfaces such as REST. | PubSub+ supports open (JMS, JCA, OpenMAMA) and custom software APIs in many languages, open wireline protocols (MQTT, REST), web/mobile APIs for Javascript/HTML5 and iOS applications, and has proven integration with many 3rd party products including Apache Kafka without any coding because of our standard APIs. |
| Message routing, filtering, ordering | Kafka topics are coarse, stateful constructs and only exact topic match subscriptions are supported. Kafka does not support wildcard topic matching, filtering of messages within a topic or queue-based addressing. These typical applications provide examples of the need for fine grained message routing. | PubSub+ supports fine-grained hierarchical topics with wildcard subscriptions as well as filtering within a topic. Messages can be richly annotated so consumers can filter and receive only what they want according to varying criteria and all messages are delivered in publish order regardless of topic. PubSub+ also supports queue-based addressing. |
| Messaging Features | Kafka’s simple datapath is optimized for high performance sequential log storage and playback in a basic publish/subscribe manner. It does not support messaging features like request/reply, queues, non-persistent messaging or many others expected by most distributed systems. Lack of selective acks means distributed multi-threaded applications will likely see duplicate events on restart and might see gaps in the event stream. | PubSub+ supports rich messaging features for enterprise applications, price distribution, trading and gaming platforms, micro services, EDAs and many others. From standard features like request/reply, non-persistent messaging, load balanced delivery, XA and session based transactions and message TTL to sophisticated rate limiting and congestion control features built and proven over many years. |
| Datapath Architecture | The Kafka broker uses the sendfile() system call to maximize performance of message delivery to consumers, but this only works for cases where the published message can be delivered completely unchanged to the consumer – otherwise, Kafka’s performance degrades significantly. For example, sendfile() cannot be used with TLS so the maximum message rate for TLS consumers decreases by 90%. The Kafka broker does not manage consumer state – this increases the complexity of client APIs, prevents implementation of certain messaging features and results in several operational shortcomings. | PubSub+ routes and enqueues messages to consumers, tracking message delivery state for each consumer, delivering these messages with the transport the consumer requested (Solace wireline, MQTT, REST, WebSocket). Congestion can be managed, messages can be rate controlled, queue depths can be monitored, and threshold alerts can be emitted. |
| Security | Kafka’s connection model relies on bridges and connectors, pushing client credentials/security to the bridge layer. Apache Kafka also requires separate security configuration for clients and for brokers in Zookeeper. ACLs are based on simple read/write and IP address privileges. Authorization requires integration with external authorization services via custom pluggable services. | PubSub+ supports consistent multi-protocol client authentication and authorization security across the enterprise, with deep integration into enterprise authentication services in a minimal set of components. |
| Operations, Management, Monitoring & Upgrades | Kafka was built as a point solution to solve log injection into big data solutions. As such there was no requirement to provide a comprehensive set of monitoring and management tools as a lot of this functionality would fall under the control of the big-data management platform (e.g. Ambari, Cloudera Manager, etc.). This is generally a good idea as redundant functionality is not required. But, as you move to more use cases the message broker needs to be able to provide enough detailed monitoring functionality to be able to do basic troubleshooting on system wide problems. | Both PubSub+ and Kafka provide a standard programmatic interface to monitor their systems, Solace provides a deeper view into the behavior of the overall messaging system. PubSub+ upgrades entail minimal service disruption whereas Kafka often requires application recode as their heavy APIs evolved. PubSub+ provides the ability to create a complex LAN/MAN/WAN topology with multiple open protocols with fewer devices. This simplifies overall manageability and operational complexity |
