I am considering different message-oriented middleware which I may use on our information system. I've been reading lots of papers and framework documentation. I see that Kafka is not the first choice when we want to do SAGA.
As an example, I read MassTransit's riders documentation, and it says that "many of concepts and idioms" that are used on classical transports (e.g. ActiveMQ, RabbitMQ, etc.) do not apply on Kafka.
What is not possible with Kafka that is usually possible with other MQs (e.g. ActiveMQ, RabbitMQ, etc.)?
What, from a transactional point of view, makes it more complicated to use Kafka in a Saga implementation?
Related
I am new in Kafka and want to understand what is the difference between AsyncAPI and Kafka itself?
AsyncAPI is a specification, bringing async semantics to (synchronous) OpenAPI models.
Apache Kafka is a distributed event platform. It has a TCP protocol, but otherwise no external "API specification". All events sent to Kafka are binary, not types like cloudevents.
You can implement the AsyncAPI around Apache Kafka...
As per docs
The AsyncAPI Specification is a project used to describe and document message-driven APIs in a machine-readable format. It’s protocol-agnostic, so you can use it for APIs that work over any protocol (e.g., AMQP, MQTT, WebSockets, Kafka, STOMP, HTTP, Mercure, etc).
More than a question, this is an architectural dilemma that I am facing.
Is it a good idea to have REST wrapper around a Kafka Producer and integrate with it, instead of directly integrating with Kafka Producer in my code? I could use a generic interface for my higher classes, instead of using the KafkaImpl directly to keep it loosely coupled for the future.
If you have the option, I'd probably go for the pure-Kafka approach, since you'd get better throughput (the clients are very intelligent with respect to batching and futures).
I'm not sure you're decoupling your code by adding a rest wrapper; you're just adding another level of abstraction, adding maintenance burden and covering over some of the benefits of Kafka.
If you really need to use REST, you can make use of Kafka-Rest - no need to reinvent the wheel!
As mentioned kafka-rest-proxy will work.
I know plenty of people that wrap Kafka producer/consumers with Spring Kafka, Mirconaut, Akka, Quarkus, Lagom/Play just to name a few. Spring, specifically, has the messaging binders that can provide that "generic interface" feel.
These are all web frameworks, and putting an API / RPC abstraction layer on any code is definitely necessary in 12factor applications
For a Java/Kotlin Spring boot app, if I want to send messages to Kafka or consume messages from Kafka. Would you recommend using Spring Kafka library or just using Kafka Java API.
Not quite sure are there any more benefits Spring provides or just a wrapper? For Spring they provide a lot of annotations which seems more magics when having some runtime error.
Want to hear some opinions.
Full disclosure: I am the project lead for Spring for Apache Kafka.
It's entirely up to you and your colleagues.
It's somewhat comparable to writing assembly code Vs. using a high level language and a compiler.
For an existing Spring shop that is familiar with spring-messaging (JMS, RabbitMQ etc), it's a natural fit, the APIs will be very familiar (POJO listeners, MessageConverters, KafkaTemplate, etc, etc).
When using the simplest APIs, Spring takes care of the low-level stuff like committing offsets, transaction synchronization, error handling, etc, etc.
If you have very basic requirements and/or want to write all that code yourself, then use the native APIs.
I've been looking into Apache Camel and Kafka over the past two days in hopes of learning about messaging frameworks/brokers. Is a possible use case of Camel/Kafka using Kafka as the message broker while implementing the producers and consumers with Camel? I saw a brief example of something similar, but can't seem to find it again. If not, what is the point of the Camel:Kafka component?
Yes Apache Camel makes using Kafka easier as it hides a bunch of the complexities, which is the main point about Camel components. However if you need to do something really advanced or be in control yourself then sometimes a Camel component may lack a functionality for that, or some hooks/apis you need, and if so people ask for that and we improve these components over time, to the communities requirements. And if you cannot wait/do that, then you do NOT have to use a Camel component and can use the Kafka API yourself directly - after all its all just Java.
There is also an Camel example here: https://github.com/apache/camel/tree/master/examples/camel-example-kafka.
And the Camel in Action 2nd edition book covers Camel with Kafka in its cluster chapter.
I am trying to understand the differences between something like Kafka and something like Camel. To my understanding Camel would provide much more abstraction for developers without having to worry about changing protocols/systems to some extent. How would Kafka not be able to handle most of what Camel can do now? I am reading through the documentation and it seems like Kafka has been updated/upgraded enough to slightly break away from being a message broker only. I guess my question would really come down to how does Kafka compare to Camel in regards to future proofing systems and where does Kafka fall short of Camel? I am under the impression that Kafka doesn't scale as well as a system grows.
Edit: This is strictly based around messages.The documentation surrounding Camel makes it very clear that it's based around Enterprise Integration Patterns, but the deeper I dive into Kafka documentation the same patterns can be implemented. Am I missing something?
Apache Kafka : Is a streaming processing platform. It is based on massively scalable publish subscribe message queue architecture. There are many other platforms which are based on JMS publish subscribe model, which could do the same(with some exceptions). Some of the most popular are Apache-Activemq, RabbitMq
Apache Camel : Is a message oriented middleware. It has implemented almost all the Enterprise Integration Patterns.
You can use Apache Camel with Apache Kafka. Or you can use Apache Kafka without Apache Camel also.
They are two totally different things.
Think about Camel as an interface definition tool where you can define endpoints or channels where messages fly in. But they are abstract. Compare Camel with Spring Integration for instance.
Kafka can provide those messages, so it can implement those abstract channels or endpoints. But so can ActiveMQ and others.
Kafka is a message broker. It is comparable with other message brokers like ActiveMQ, RabbitMQ, Azure Service Bus etc. Camel is an integration middleware. It is more comparable to Apache ServiceMix.
Taking a look at the theory of an Event-Driven Architecture https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch02.html we could differentiate two different kinds of Event-driven topologies depending on whether we need an event mediator or not.
Message broker. In this category we find Kafka as it doesn't rely on a message mediator. Of course as written on previous answers, we could use Kafka together with a mediator depending on our needs.
Message mediator. In this category we find products like Camel. You may see it as a message controller.