Kevin Montalbo

Welcome to episode 66 of the Coding Over Cocktails podcast. My name is Kevin Montalbo and joining us from Sydney Australia is Toro cloud CEO and founder David Brown. Good day, David. 

David Brown

Hi there, Kevin.

Kevin Montalbo

All right. On this edition of the Coding Over Cocktails podcast. We're going to have a tech Smackdown putting forth two technologies or architectural styles in a friendly sparring match. Today, we're debating between two messaging services. JMS versus Kafka, which message broker should you choose on the JMS corner is a Java champion, senior, principal software engineer and reactive architect at redhead. He has contributed to several projects and products touching many domains and technologies such as OSGI mobile continuous delivery and DEV ops. More recently, he focused on reactive systems, cloud native applications and Kubernetes. He is an active contributor to many open source projects such as Apache, Felix Eclipse, Vert X Small Ry Mutiny and Corks and he recently authored the Active Systems with Java book. Joining us today to represent the JMS side is Clement Escoffier. Hi, Clement Welcome to the show.

Clement Escoffier

Hello, thank you for having me.

Kevin Montalbo

All right, thank you for joining us and joining us today to represent the JMS side. Um I'm sorry, on the Kafka corner, let me do that again. We're going to cut that. Sorry. This is the first time. All right on the Kafka corner. We have the field CDO and global technology advisor at Confluent. He works with customers across the globe and with internal teams such as engineering and marketing teams within organizations. His main area of expertise lies within the fields of data streaming, analytics, hybrid cloud architectures, internet of things and Blockchain. He's also a regular speaker at international conferences such as Devo Apache Con and Kafka Summit and writes articles for professional journals, sharing his experiences with new technologies on his blog, representing the Kafka side is Kai Wehner. Hi Kai. Welcome to the show, everyone.

Kai Waehner

Thanks for being here. Great topic to discuss today.

David Brown

Thank you. Thanks. It's a pleasure to have you both on the program. We actually came up with this topic because it is one of the more popular blogs on our website. There's still obviously a lot of interest from our readers on this topic of JMS versus Kafka. It has a lot of search volume as well, so it's still obviously pretty relevant today. So before we jump into the relative advantages and disadvantages, maybe we can just give a brief outline I'll get each of you to give a brief outline of the problems that each platform is trying to solve. So maybe Clement, you can start us off by describing you know, Jamie has been around for a while. What is, what is the solution that it, it, it and, and what problems does it try to solve?

Clement Escoffier

So, yes. So JMS is around for a long time, probably 20 years or something like this. Um It's actually age relatively well. If we look at all the technologies that come from the from more than 20 years ago. Um So, so the problems I tried to address was really to, to, to other way to implement a synchronous communication between different applications or different part of one system. Um very quickly become popular for this integration pattern and the EAP so, enterprise integration patterns because, well, it was the beginning of the rise of what we called ESB and, and things like that. So we, we needed a way we needed a bus to exchange those messages between various applications or part of your, of your systems. Um So JMS is Java centric as AJ is for Java. However, implementations generally rely on different protocol um if we take Artemis or um active and Q they have their own core protocol implementing JMS on top of that. Um And generally, when you use a JMS broker, you actually have a set of protocols that are offered. It's not necessarily one a specific one. Typically, I'm, I'm mostly recommending using IMQP 1.0. because it's the a of IMQP means advanced and believe me, that don't lie about the advanced part. It's a, it's a complicated protocol but it's very, very well done for for cloud and, and things like that. So, so, so one of the program, one of the advantage of JMS is that it's, it's very Java centric. So OK, you have to use Java, but you have these other protocols that you can use. but it's like a clear semantic when you are in Java, you know exactly how it's going to work. You have two type of delivery, um cues and topics and be careful because the topics of JMS is different from the topics from C FCA. So we, we will always have to mention what kind of topics we are we are referring to. So JMS, it's one, it's a queue of message, you have messages inside your queue, you have a set of consumers and they share the load, it's unbounded so you can have as many consumers you want. Um So it's a big advantage on the cloud because you can scale up and scale down according to the depths of the queue. Um It has delivery guarantees and things like that. So it just passes down to ability and so on. Um topics is a pub sub implementation in the sense that all the messages will be broadcasted to all the consumers. So I I won't go into the details of how it's implemented, but basically it means having a queue per, per, per consumer. So it's just a copy of the messages. Um So based on these two relatively simple, well understood delivery mechanism, JMS has successfully handle a lot of problems for the last year, 20 years. Um And we find it in banking systems in smaller application where synchronous is important like yeah um ordering system or logistics or even IOTs these days, it works relatively well on the cloud, on things like cities or in containers because it doesn't have any consumer limits when you, when you have fuels. Um However, it has what should downside typically ordering. Well, you can't, you, you don't know, although it, it can be quite different, which is one of, the scene where Kafka is is very good.

David Brown

You're not arguing for Kafka.

Clement Escoffier

Yeah, it is

David Brown

very nice.

Clement Escoffier

I speak about both. So that's why um

David Brown

you're being too honest there, you gotta, ok.

Clement Escoffier

So it, it has if, if you're looking for hybrid cloud kind of thing. So hybrid cloud is a system where you have um multiple data centers, multiple cloud providers So your application is either replicated or collaborate across clouds. In that case, um The filtering and transferring capabilities between one data center to another one of JMS and of the underlying protocols are very, very advanced with fine grain tuning and things like that. So you can only copy the messages which will be actually consumed on the other side and things like that. So you, you have lots of flexibility. Um Yeah. So tomorrow I said well, it's been popular for, yeah, for almost 20 years, it's still heavily used. We have lots of demands around JMS um um as a as a member of the caucus team. Yeah, it's it's, it's quite popular. Um It's um we, we have a connector for JMS connector for Kafka. Of course, these days we have more demand around Kafka because, well, it's hype and people want to, to use it. It's, it's very cool technologies. But when people do migration, when people have a more legacy kind of systems, JMS is, is still sinks.

David Brown

I did mention a couple of the legacy applications like that like ESB type architecture from the legacy applications. But, but as you said, they're still relevant today for pub subtype architectures and, and Q type applications as well. So Kai maybe you can start on Yeah. What if, if, if JMS was doing all this so well, it has been around for 20 years. What brought about the need for caf

Kai Waehner

Yeah, yeah, that, that's a great point. And so first of all, I really want to make clear that in the end, we are comparing apples and oranges here, right? And even more crazy than that, I would even say that not both are fruits because on the one side, if you talk about JMS and, and that's why I really want to emphasize this. Um this is a standard protocol, right? So this is a standard specification and you need to implement it and then um Reddit has our TS and then IBM is IBM and Q and everyone has a different implementation. So this is the first big difference and therefore a move about just using one broker and then migrating to another vendor. That's not true and we can discuss this later today. So that's the one point. So we're not really comparing apple stang just because CAF has a call implementation. If you use Kafka, it doesn't matter if you use conference Kafka or if you use um um IBM Kafka or redheads CF, it's KFC and it works right? You can just use it. So that's the first big difference and the second big difference. And this is also now where we see that both are relevant today because as we now just heard um the J broke which ever you use is a messaging group. You use it for sending data from A to B and it's very simple and understood and works well for that. On the other side, Kafka is a very different technology. It's what we call an event streaming or data streaming platform. And with that, on a high level, I always explain it as four things. And therefore, I in the intro, it's really funny because we heard that um we are comparing to messaging brokers, but that's not true because Kafka is four things. In the end, it's a messaging broker. So that's the part you can compare to um the JMS broker. And in combination with that, it's a storage system, that's where the JMS broker is partly like that, but um much less so a little bit. And in addition to that with Kafka and I'm really just talking about open source Kafka, right? Not about any vendor like confluent or anything else. It's also a data integration platform with Kafka connect and it's also a stream processing platform with Kafka streams. That's all part of the single Apache C download you have and with that, you'll see that with CF card, you can do many things and it's much more than just a messaging broker if you want your data integration and red, for example, use a patchy camera, which is a fantastic framework. So I work for talent 10 years ago and I love that framework, but you need more components for that. And um I also worked for Tipco before. So I know the messaging part well and the screen processing part and this is really on a high level at two points for CCA it's implementation, it's not a standard where you have different vendors, it's an implementation. And on top of that, it's much more than messaging. And this is the difference and why now in the future, we will still see both because it's very different use cases for pub messaging from A to B at least if it, if, if scale is not extreme, then JMS and brokers are great for that. For anything else, people use CCA more and more. And the key point here is you can use it for transactional workloads and analytics workload. So that's also a common misunderstanding. People think it's only for big data. That's what it was built for over 10 years ago at linkedin. But today over 50% of use cases I see are about transactional workloads. So this is also another move where people say I should always use J MS for transactional workload. So that's that, that's not true. Um You can use it and there are some pros and cons, right? But you need to understand that you can also use Kafka for transactional workloads.

David Brown

So there is a bit of crossover in that regard. Like you said, there's a bunch of stuff that capa does where it's not really any comparable to, to J MS, but there is some crossover in terms of the message broker. And as you said, it's now handling transactional workloads, which has been the traditional domain of J MS. So how would if we were to focus in and zoom in on those areas where there is crossover? Forgetting about the vendor aspect of the different vendors of J MS brokers and just talking about the protocol versus um C A fa um what are the relative advantages and disadvantages? When should you choose one or the other as a, as a message broker clement? What would you say to that?

Clement Escoffier

Um It's an interesting question because, well, when you need pure asynchronous communication from A to B typically, um JMS tends to be simpler, better understood um not going to today, but um Kafka looks simpler and um yeah, you can do a halo world in KF faster than a halo world in JMS definitely just starting the JMS boca will take more time than doing the world thing. However, so it's plenty of of things you need to understand to use and operate K FA very well while JMS has done well, has learned over these 20 years to try to improve that, to make sure that yeah, you don't shoot yourself. Um So for example, when you write, yes, you get a knowledge man based and think that is, is pretty simple. You, you know, you, you know, when it's written and when you consume, when you are done your knowledge, period, that's it done. Well, if you want to do this on the caf a side, it's a little bit more tricky because you need to commit offset not every time because that's, that's a very bad things to do. Um And and K may, may explain why. So you need to have a offset management and, and check and, and when you commit an offset, that means that every record before that has been processed successfully. So as soon as you do as things in the middle, it can be tricky. Um So yeah, this simplicity as sim simple doesn't mean bad. Simple means that it's, it's easy to use for most developers that they don't, that don't necessarily want to have a degree in messaging or streaming technologies. Um They can go there. They know OK, simple. I do a producer, I get my internet when it's written. I even have a blocking API where I know that it's going to block until it's it's written. You have time out something like that. Um On the other side. Yeah, something I, once I get a message, you get message one by one, not by batch as, as ac guys recommending. So you get the message one by one, you process it a period, you can easily filter. So, yeah, I want only the messages with that header or with that content type or coming from that destination and things like that. So the filtering capabilities are, are very interesting too. Um And again, it's, it has already been designed to be relatively easy to understand. Um Again, if you, if you, well, we need to remember that most developers don't necessarily want to spend their nights and weekend trying to understand all the nasty details about what a synchronous flush on the French system is and things like that. So they want to get the work. So it's a job done.

David Brown

So what would you say that that J MS is a simple and mature framework? What would be your response to that?

Kai Waehner

No, I fully agree to that, right? Um So that's totally true in the end, it's very simple because again, the main idea is to send data from A to B and if that's your main goal and the only thing you need to do then J MS broker is the right choice very likely, right? Because with CAA you do much more. Um for most use cases, we see it's not enough to just send data from A to B because you also want to use it and correlate it in real time and integrate with systems. Some are real time, some are not a real time like a data lake. And so use it for a much bigger space. And that's why it's again this, this apple to orange um comparison and I always recommend think about the all use case, not just this broker part. That's my first thing, right? But nevertheless, now we should still talk about this comparison. Um Only of the broker even there, it's important to understand the differences and there are differences which have pros and cons like um um we already mentioned and in the end, it's totally true that J MS has a simple API you just send and consume um on the other side with CF card and you can do much more with that and you have things out of the box like guaranteed ordering and that's things for critical business applications, you get out of the box, so you don't have to worry about that. And therefore it has always pros and cons um the one thing what I would say about me that J MS API is really better if you need some communication paradigms like request reply, right? You can do that easily with Kafka, but it's a pattern around it. You implement it differently with J MS, you have it um out of the API. So that's the thing where it's just messaging, right? Um But um then for the filtering part, so a Kafka broker is dump, you don't do filtering on the Kafka broker that's very different from AJ MS broker. But you do things like filtering in Kafka. Um This was implemented like this intentionally because it's not good for a scale. So in Kafka and that's why we also take a look at the whole ecosystem. You do the filtering and processing in its own application, which is can be for example, a Kafka streams application or A K application. So it's, it's a different kind of architecture and depends on the use case once. And if you just want to send the data from A to B and maybe filter it and do that at a relative small scale, then the chin is broke is the right choice. In other cases, it's typically more like um CAF is the better fit and the last part. And, and this is also a very critical one which people often don't understand. Well, is that um the, the kind of how you consume data is is very different in calf kind and AJ MS broker and AJ MS broker, it's push based, which means the broker pushes the data to the consumer, right? Um which sounds more obvious because people say yes, I want to get data in real time event by event. Well, reality is that um this also um creates pressure on the consumer and especially in a world where you have different consumers in the microservice as well. Um You need things like back, pressure handling and that's built into the C A FA protocol because it's pull based. So each consumer decides by themselves when and how often to consume data. The the drawback of this is and that's what was already explained by clement is that you need to understand how it works. It's not just like the J MS A P you get it, but therefore you have all this power to get it right for your application because your data warehouse is not built for real time. Ge it's built for taking snapshots of data like the last 100 messages and ingest it at once because the indexing layer of the data warehouse doesn't work better. It's not the problem of the messaging layer. And so with that, um you have to build in um back pressure handling so that each consumer can consume it like they need and still um the argument about that getting message one by one. Well, in the end, the consumer wants to get data and guaranteed ordering and reality is um that the latency is so low with Kafka, it doesn't matter if you consume 10 or 100 messages at once, right? Um You can do one by one, but it's not recommended because the performance is worse then obviously, but we are here talking about a few milliseconds and, and this is another point maybe where I would say that both J MS brokers and Kafka are not the right choice if you need low latency, things like real trading in microseconds. That's not either of that, that's completely different application. And as soon as we talk about real time for 99 to 9% it doesn't matter if you get the data in 10 milliseconds or in 20 milliseconds at any scale. And so this push versus pull based is super important to understand. And um the pull base is not as worse as some people think. Um because again, you have to back pressure handling built in there. And the big other difference between um the how J MS brokers typically work and how CCA works. And I say typically because again, J MS is a standard so you can implement it like you want. And um if you use different brokers, they work differently for things like security for things like um network transfer for things like this persistence. So you don't have to say SL A and guarantee. So you need to check with the vendor behind that and the support with Kafka, you have the um storage system behind it, it's implemented in the protocol. And with that, the benefit of it is you store the data in Kafka as long as you want and you can decide that per Kafka topic and in addition to the back pressure handling with that, so sometimes you have not just batch consumers but also consumers that consume the data really late like a week later or maybe a request response from our web app about a data that came in a year ago. So you can easily replay data that is old, completely independent from another consumer that consumes it in real time. And this replayability of data is another huge benefit built into the C FA system out of the box. And while J MS brokers have some kind of persistence, again, everyone has different persistence. So you need to check with the vendor. Um It's not really built for replayability. Yes, it has persistence for high availability that's critical. And that's what typically J MS people means. Um On the other side, you cannot replay data so that one consumer gets it in real time and another one gets it a year later. So that's um what you typically work with another cache system adding to the broker or so on. So this is very different apples and oranges you can choose. And so really think about your use case and then choose the right problem. And so, and that's the last thing here for this long discussion now. Um that that's why I still think also in the future, we will see both platforms, right? Because they have very different use cases like um as Clement mentioned, like if you integrate with legacy systems like mainframes, they have a very good MQ interface, right? So for that, it's a perfect thing to integrate. So most of our customers, they integrate with mainframes, we are IBMMQ, we are the chain S API and a lot of proprietary protocol things on top. But then they use the C FA connect connectors to combine both systems. So these systems are much more complementary than some people think. And it's really better to learn how to use them. Um I've also seen a customer would try to reim implement the J MS patterns on Kafka that will fail. Things like request reply can be done with Kafka, but it works very differently if you try to do the same way like J MS, you will fail.

David Brown

Hm So much good information there. I saw clement, clement, you were, were shaking and nodding your head at various points. Would you, would you like to contribute anything more to the comments?

Clement Escoffier

Everything that K said is absolutely completely true. Um Typically it requests reply base construct in a JMS based system completely. I will even say anti patterns in a CAF based system. So if you want you, you believe you will get it right and believe me, you won't because you are going to create dynamic topics. It has impact on the broker um or, or using a specific keys but then you need to have your power well done and things like that. Um Because of the batching on both consumer and, and, and, and, and pro producer too. It can be very, very weird. Like if, if you have a linger of time on the producer side, it's, it's a Yeah, it's a, I have seen that a lot people trying to implement N PC based on CCA and I'm always like, mm no, that's not going to fly. maybe on your DEV machine. Yeah. Fine because you have a single booker, single topic, single partitions, everything is fine. That's not your production system. Um The second thing is the control flow or black pressure. Um Yeah. Right. OK. CACA consumers are doing a poor things. So they are pulling and, and lots of people believe that it's the key to do back pressure because you can decide when to pull. Well, that's not, you need to read the, the, the, the small print of the K FA documentation because if you do that and as they said, yeah, I'm pulling, yeah, and I'm pulling in in one hour or something like that. Well, there are some time out and a habit and actually the poor method of Kafka is probably the less of the most misunderstood method of Kafka in the sense that it's not only going to poor, poor, just it's actually the last part of the poor method. It's one, it fetch the records, but he has need to locate the coordinator of your consumer group. You need to be sure that everything is there, you have heard it and things like that. And if you don't call Paul enough or, or frequently enough, the coordinator, which is one of the broker of your system will consider you as dead and lead to what all CA FCA developer. Absolutely love a rebalance protocol, which is also something where we can talk hours about just explaining that protocol Um So you need to be very careful that yes, Paul will let you do some back pressure control, but you need to understand a little bit more to implement it right? You need to continue polling but maybe you don't have the capacity to poll. because if you don't want to poll fast enough, it's because it means that you, you block somewhere else. So that means you need to pause all your partitions and then resume them. So that's all features CCA provide. But they are again, you, it's very flexible. It's a toolbox where you can do almost brilliant of things. But you need to understand because yeah. Um well, in my personal life, I have a huge toolbox with every drills and things that I have no idea how to use them. So that's, that's Ka is a little bit the same really, really powerful things, powerful tools, but you need to understand. And one of the things Kai says is, is actually one way to compare against the comparison. as K says, it's not really writing is that K AFC A brokers are relatively dumb in terms of delivery. Um Be careful. It's still very complicated how it's done application and things like that. Leaders rebalance and things, but well, it doesn't do much, get right to segments and to partitions and allow you to read JMS broker on the other side um tends to be a lot more lot I won't say smarter but have a lot more features like filtering, routing and anything like that. Um It was made in different times for different purposes. Um Are these filtering and routines used today? Yes, they are still used. But I would say less than before. we tend to use to do well to have specific applications that will read and do a specific routing. After that, like, like what Kai mentioned Camel like Camel is doing so you will do that on the consumer side and not necessarily on the broker side, but you have this, this possibility about replayability. I completely agree. JMS has not been designed for replayability at all. Um It was, I would say when JMS was designed, it was just not a requirement. We were not doing so much data in mission like we do today. Um The explosion of the number of data we are collecting every single day even just right now. Um has just completely changed and yes, this data in machine and, and this replayability are key now in some use cases while 20 years ago they were not. And that's why it was not necessarily part of the API um As I said, for request reply, don't do that with, with CAF GUIDES. It's not necessarily made that don't try to implement replayability with JMS. It has not been really designed for that and you're going to have lots of headaches trying to make it work. Yeah. Sure. I can make it work on my looking machine. No problem. That's not a pollution system.

Kai Waehner

And the funny thing is really how much in agreement we are. Right. I'm not surprised about this. Um, the audience might be because simply, you know, that these are very different systems with very different benefits. Um, I, I have a few, few, few comments on also what you said, whereas again, I'm always agree, right? Um So um the most interesting thing was the last thing you said, where now we have more data in motion like you call it, right? And that's also um when I talk to customers and for me, it's often hard because I'm in the early stages with our customers. And I need to explain this paradigm shift. So it's very different in the past. So in the past systems were built like you have a message, you send it somewhere, you store it in a database and then you have a web service calling it again, right? Um So this is the old pattern and this is what J MS was built for and where it works very well. So again, as Clement says, so don't try to rebuild R PC, review more procedure calls with the web service API S and request reply with Kafka. That's not how it works with Kafka. You have the data motion is continuously flowing. Um That's a new thing for many people and that's the hard part about it. But for many of the use cases you built today and it doesn't matter what industry you're in. It's a huge added value if you can act on data in real time. And that's more than just storing in a database and wait until someone picks it up later. It's about continuously correlating the data. And this is the huge strength of Kafka. And again, here, now we're not just talking about the messaging part because that's still just sending data from A to B whatever they produce. And consumer are, the correlation is a huge powerful part. And then with this, with calf cut is huge advantages that you have an end to end platform with a single infrastructure. I've seen customers that try to build similar things with a messaging broker with an integration framework like Camel, right? Then also with a correlation layer or screen processing framework like Flint maybe and still they needed some other persistence to store the data long term for replaying it later for using it for data science, for using it for compliance, regulatory reporting and so on. With Kafka, you get the wall ST end to end in a single platform. And um especially when you're not talking about analytics, but about transactional workloads, the customer will be very happy if it's only one platform and one vendor and one support behind that model. And that, that's I think one of the key differences. But once again, um don't try to rele your R PC and well known design patterns with Kafka, it works differently and this is the paradigm shift which provides the data and motion concepts, but it's very different. And this is not just for Kafka, but it's the same. Like if you use a patchy fling or anything else, it's a very different paradigm about how to use data continuously in real time. You have concepts like sliding windows, always monitor the sensor data of the last 30 seconds continuously. That's something what's built into Kafka because it's an event streaming platform, but that's not what a message brought that does for you and you need an additional tool for that. And um I think, I think that's really the key foundational difference. And then one other thing which, which Clement already mentioned several times um is, is about the operations complexity. And, and here also we are in total agreement, right? So um Kafka is built as a distributed system and while you can use it on your development laptop as a single broker and client, and the same is actually true where we see some edge use cases where you deploy a simple broker like in a drone, right in the hardware. But that's a a niche use case. 99% of use cases. Craft is used as 24 7 highly valuable system and therefore it's a distributed system. It has huge advantages for business continuity guaranteed, no data loss and no downtime, even if systems go down, that's all very coins and so on come into play. But with that, of course, you have complexity of the operations, it's harder to operate than aJMS broker. So for that, um the key point is, and I think that also there are vendors like redhead and conference agree because we both have an operator for coons, right? So that you can take over much of the effort of this complexity that's added to the brokers because Kafka is more complex. But again, the framework is built by the experts to operate it for you so that you do things like rolling upgrades automatically instead of doing that um by yourself. And the last part of the on the complexity. And that's also something that people underestimate this comparison. So if you're in the cloud, you shouldn't care about that at all because in the cloud, you get service offerings which take over this complexity. So at confluent, we are running thousands of Kafka clusters, we know how to do it well. And we also do it for you completely. So it's a service offering and with that, you don't have to care if it's a distributed system, how you do rolling upgrades, how do you do the rebalancing on the broker side? That's complex things. If you need to do it by yourself, it's hard, we can also support you. But in the cloud, you don't have to worry about that. You have a model with consumption based pricing and mission critical slas and you just use it and focus on the business problems. And this is also the reason why now we see this big shift to data streaming much more in the cloud because here for customers, it's much easier on premise, they can easily operate the brokers. And Kafka is more complex, even with Cubans and operators in the cloud, you just use it and start small and when it works, you scale it up in a cus way. And this is also the the difference is why we see this huge adoption of Kafka, especially in the cloud because it's much easier to adopt because you don't have to worry about um these things that much. And that's by the way, not just for the Kafka core messaging part, but for the whole ecosystem, if you need to do data integration with your existing systems like a message queue, but on the other side, your cloud data warehouse, then you do the integration out of the box of the same system because Kafka connect is also fully managed then and the same for the data correlation with the stream processing part. This is fully managed, you just write your SQL query deployed there and you run it there under the hood server list. And this is also this kind of of different I think um where we see it going these days, people want to build business applications and not worry about the infrastructure. This is true in general, not just for CF core messaging,

David Brown

lots of great points, both sides of the conversation there. A lot of agreement as well. I was expecting a little bit more debate, but actually there was a lot of agreement there on the common topics, but that's a good thing as well. There seems to be some common use cases for, for both platforms and a lot of life. I think we both agree it left in J MS. So I think, I think a part of the reason this topic comes up and there's still interest in the topic is they're seeing J MS U in the enterprise. But of course, caf is the cool new kid on the block even though it's been around for several years now. But um wondering if they should still be using J MS. It's great to hear from two experts that there is some very clear use cases for J MS. And it's got a lot, a lot of life left in it yet. Um I wanna thank you both for joining us today for our first technology Smackdown. It was super interesting, super passionate. You both obviously love this space. It's been a pleasure to have you both on the program. Thank you.

Clement Escoffier

Thank you.

Kevin Montalbo

All right. That was it. So guys, thank you so much.

David Brown

Thank you. We try and keep it to like less than 40 minutes. So I was reaching the limit of the time

Clement Escoffier

I had one of the big difference that we don't talk. Well, we don't mention is a message from it. like based for mostly schema based for, for Kafka.

David Brown

Let's, let's cover it and insert it now. So go ahead, hit me with a point and we'll edit it in afterwards.

Clement Escoffier

So, one of the key difference is that we are seeing these days in both usage of, of JMS and, and, and CACA is, is a representation of the data you are sending or consuming um Kafka on one side. Um Is I want, I don't know if it's recommending, but a lot of people are using schema based approach using a which is the most popular in the, in the Kafka worlds can use pro above to just on schema start to, to be a little bit more popular than it used to be. Um You can still use few unstructured objects and there is no problem with that, but we, we start seeing this. I want to have a schema to manage my, my, my, see, my version and so on JMS on the other side. Um Well, because it was, it still, it still is a Java centric um as used. Um Well, Java standardization um So basically, you were writing your Java objects. you want sterilizing them into byte arrays using the Java Ster from, from, from from, from J A. So, and on the other side, it was building the objects. So basically, you have your class and you can rebuild exactly the same class on the other side. So you don't necessarily have to think too much about the IZATION and decent organization. Um It's less and less true These days in the sense that well, Java Ster as not being the most successfully applied things over the years. Um And it didn't really well. So we start seeing more mapping to Jason or, or things like that. but not really schema based, but basically, you don't need to think about anything. You just, yeah, it's going to sterilize, send it, you will build on the object while with confluence and the KMA F approach. Well, you need to think about the A. So is it a bad thing or a good thing in general? I would say it's a good thing to think about your schema. It's always a good thing to have a to think about., you are going to switch your data and evolve your data. But again, it's for the developer that just want is work done, it can be something li an extra things t

Kai Waehner

think about. I mean, maybe also from my side, first of all, um it's important to understand that in Kafka, as I said, the broker is dump, so you can send anything, it can be any proprietary byte code or whatever. It's just a byte area on the C fa broker that why it scales so well by the way, and then much better than the MS broker typically. Um but typically it's true. So most of our customers actually schema registry um and this also however, shows the different patterns where people use it, right? So with JM, as you typically send it and someone else consumes it and that's it, right? And the cuff cover, um I won't say that um 95% of microservice I just today use cuff under the hood, not just for the true decoupling and the back pressure ending and so on, but also because of the schema based approach, you can just send data there and you can be sure that everybody can consume it because reality is while any customers start with one first pipeline, get data out of your mainframe and put it into a cloud data warehouse. In most cases, more and more different applications and business domains consume the same data. So you have very different people and and teams and developers consuming it. And with that also very different technologies. So the first team might use um Java, the second to team directly says, no, I just integrated for data bar, I just use KCA connect, I don't code it all by myself, I just configure it. And the third team is the data science team. They use the Python client and consume the data in batch from the last 30 days to train analytic models. And therefore, um Kafka is definitely built so that everybody can use it, including commercial tools and so on. So um all commercial tools today like other middleware also have Kafka connectors because it's used everywhere. And with this, I think to make this discussion short, it's again the same case, like we discussed um J MS S send data in and someone else consumes it with CACA, it's a much more broad ecosystem and spectrum about how to use it. And um I think that's the big difference and that's true why we see most people are using the schema industry because then it's a huge benefit because you have um still the guarantees that um you cannot send malicious messages because it's enforced on client and on server side that the schema is used the right way because otherwise in a microservice architecture, all the different client applications would crash, right? And therefore this is definitely tradeoffs again. Um But for most Kafka use cases, it's a big pro

David Brown

brilliant. All right, we're going to insert that just before I signed off. I'll, I'll get the guys to edit that.

Clement Escoffier

I think it's an important part that should have been mentioned. I don't know. I

David Brown

appreciate it. Yeah, it's great. Thank you. For adding that. Now. We'll have slopped that straight in before that, before I signed up. Great guys. Thanks so much again. Um You've got the half of the day in front of you. I'm guessing you're both, you're both in Europe, I suppose. Yeah. end of the day for me, I'm done. So, thanks guys catch you again. Ok, bye.

Clement Escoffier

Thank you.

Kai Waehner

Good bye.