WEBVTT
00:00:06.719 --> 00:00:13.199
Well, good morning, good afternoon, and good evening, just like Jen said, and I want to say thank you so much for your time today, everyone, and for joining us.
00:00:13.439 --> 00:00:14.800
My name is Michael Jo Kay.
00:00:14.880 --> 00:00:18.719
I am the director of demand generation and business development here at MeshIQ.
00:00:19.120 --> 00:00:34.000
We are incredibly excited to dig into what's new with Apache ActiveMQ, Artemis, and Camel, and to better understand how their evolution is accelerating to address the critical needs of modern cloud deployments, high availability, simplified operations, and robust security.
00:00:34.079 --> 00:00:39.840
And I'm also incredibly grateful and excited to introduce my friend and fellow panelists, JB Onefrey.
00:00:40.000 --> 00:00:43.359
JB, would you like to give a brief introduction before we jump into the session here?
00:00:43.840 --> 00:00:45.280
Yeah, uh thanks, Mike.
00:00:45.600 --> 00:00:49.840
So yeah, I'm JB, um director of the Apache Software Foundation.
00:00:50.079 --> 00:00:54.479
I'm a member for the foundation for more than 20 years now.
00:00:54.799 --> 00:01:07.840
Um I'm working on several Apache projects, obviously, like um ActiveMQ, Carmel, uh Cara, Fartemis, but also more on the big data space, like Apache Prioris, Apache Iceberg.
00:01:08.000 --> 00:01:18.959
So yeah, I'm um happy to have a chat uh with you today about what's uh what the community is thinking about the future and a future and roadmap on ActiveMQ, especially in Carmel.
00:01:19.599 --> 00:01:20.079
I love it.
00:01:20.159 --> 00:01:23.599
The community, the foundation, and we are very lucky to have you with us.
00:01:23.760 --> 00:01:26.079
Uh, wanted to give you a big shout out uh and congratulations.
00:01:26.159 --> 00:01:27.920
You recently joined our board of directors.
00:01:28.000 --> 00:01:33.280
Uh so I know that most feel like I do, uh, anyone that has the pleasure of boarding you with you is very lucky.
00:01:33.439 --> 00:01:36.480
So without any further ado, let's jump into some questions today.
00:01:36.640 --> 00:01:42.159
I know we have a lot to cover in 30 minutes, but I think I want to start with architectural evolution and clustering.
00:01:42.239 --> 00:01:48.079
Uh, specifically, you know, Kaha DB, it's a key component for storage in Apache ActiveMQ.
00:01:48.159 --> 00:01:51.680
Do you see uh a potential evolution for Kaha DB?
00:01:52.560 --> 00:01:54.719
Yeah, but uh you're right, Mike.
00:01:54.799 --> 00:02:02.319
I actually Ka DB is a very critical piece in ActiveMQ uh when you are running your broker.
00:02:02.480 --> 00:02:09.120
By default, it's basically storing uh a lot of details and persistent messages inside the storage.
00:02:09.280 --> 00:02:10.560
That's not the only uh option.
00:02:10.639 --> 00:02:17.039
You can also use a JDBC backend, but that's the preferred one uh uh for ActiveMQ.
00:02:17.439 --> 00:02:21.680
I see two potential evolutions on CADB.
00:02:22.159 --> 00:02:42.240
The first evolution is a natural one because in ActiveMQ right now we are working to support the new the latest version of the uh messaging specification, JMS, and and there are new changes and new updates we have to do on the broker, but should be reflected into KDB.
00:02:42.400 --> 00:03:00.000
Because you know, when you're adding, for instance, durable subscribers, which is a new feature from uh Jacarta Messaging 3, then we have to purchase that because if you switch from one broker to another, uh it means that this information has to be available.
00:03:00.159 --> 00:03:06.639
So we need first to update KDB to be able to store this additional information we need.
00:03:06.800 --> 00:03:08.240
So that's the first evolution.
00:03:08.319 --> 00:03:11.520
I think it's a required one, it's a natural one.
00:03:11.680 --> 00:03:17.360
And the second evolution is more it's more from an architectural standpoint.
00:03:17.520 --> 00:03:23.039
Um, today CaraDB is only able to deal with a single broker.
00:03:23.120 --> 00:03:32.479
So basically, when you start a broker, you're gonna start CaraDB and it's gonna be used only by this broker, which is great by default, but it has two limitations.
00:03:32.719 --> 00:03:48.159
The first limitation is basically when you want to create uh high availability uh instances of ActiveMQ, then you need to share the same storage for the two KDB instances.
00:03:48.319 --> 00:04:00.879
So basically, it means that you have to use NFS or any kind of um share storage to implement that, which is not always super easy, especially in a cloud kind of environment.
00:04:01.039 --> 00:04:02.319
That's the first limitation.
00:04:02.479 --> 00:04:13.280
The second limitation is in ActiveMQ, we can uh we can basically spread the load of messages across different set of brokers.
00:04:13.520 --> 00:04:18.240
That's what we name network of brokers, and we do that using a network connector.
00:04:18.319 --> 00:04:35.759
So basically, one broker can dispatch and forward messages to another broker, and there it means that basically if you lose one of the brokers in this cluster, you're gonna lose all the messages on this broker waiting to be restarted.
00:04:35.920 --> 00:04:42.240
And so I think it's where we can think about a new way to implement KDB.
00:04:42.720 --> 00:04:51.040
And the idea that I've been discussing with the community right now is why not having some kind of replicated KDB?
00:04:51.199 --> 00:05:02.399
And by replicated KDB, it means that two KDB instances can talk each other, and then one can be a replica of the main one.
00:05:02.480 --> 00:05:09.040
And so if we have one broker falls down for any reason, then another one can have a replication of the first one.
00:05:09.199 --> 00:05:13.439
So that's it's it's not a trivial thing to do, to be honest.
00:05:13.600 --> 00:05:16.480
Um, but but I think it's more than welcome.
00:05:16.639 --> 00:05:20.160
Um, and that's something we are uh discussing with the community.
00:05:20.240 --> 00:05:28.160
Uh how we we have different experiments ongoing on that, like uh uh should we use uh Apache Bookkeeper?
00:05:28.240 --> 00:05:29.439
Maybe I don't know.
00:05:29.600 --> 00:05:49.759
Uh for me uh that could be a solution, but also Artemis did a huge work on this part, like uh they they introduced the new mirroring feature in in the latest version of Artemis, and also you have the acceptor lock lock system distributed log system.
00:05:50.000 --> 00:05:51.920
Um, that's also pretty interesting.
00:05:52.160 --> 00:06:03.199
So, thanks to the uh the work between all the communities, we can find something which is pretty solid and and very interesting for the infra and the future of KDB.
00:06:03.920 --> 00:06:04.319
Love it.
00:06:04.399 --> 00:06:10.800
It sounds like the goal is really just uh to highlight that reduction of infrastructure complexity overall, right?
00:06:11.360 --> 00:06:11.920
Absolutely.
00:06:12.000 --> 00:06:19.680
I mean, the complexity is on us in inside RTMEs Active MQ, but for the users, it should be uh straightforward.
00:06:19.920 --> 00:06:21.120
Seamless, yes, yeah.
00:06:21.279 --> 00:06:30.319
Uh so but it makes me think thinking long-term uh and active MQ7, do you see potential big changes from an architectural standpoint?
00:06:30.480 --> 00:06:35.839
You know, so what would you say are the main differences between ActiveMQ6 and ActiveMQ7?
00:06:36.959 --> 00:06:54.240
Yeah, um without knowing exactly when ActiveMQ7 is gonna happen for sure, uh, but the big changes that personally I would love to see is uh today ActiveMQ, since the beginning of ActiveMQ, ActiveMQ is a big spring application, basically.
00:06:54.399 --> 00:07:13.439
Uh we have a bunch of uh spring framework bins, and basically, if you take a look on the main configuration file, which is ActiveMQ XML, it's basically just a lot of bins we are defining, which is fine, but I think we can do there are two comments.
00:07:13.600 --> 00:07:17.600
I I don't want to say issues, but two comments about that first.
00:07:18.319 --> 00:07:28.879
Um, Spring framework is not an Apache project, it's an Apache license framework, but we don't know where Spring is going.
00:07:29.040 --> 00:07:40.879
And with the recent announce about the maintenance of you know CD on Spring and all this stuff, I'm a little bit concerned about the future of Spring for open source projects.
00:07:41.199 --> 00:07:50.079
And so regarding that, I would love to consider removing Spring as the core dependency in ActiveMQ.
00:07:50.560 --> 00:08:04.879
Um, and maybe so it means that maybe leveraging another framework, uh like CDI provided, like uh, I don't know, Quarkus or something internal we can do.
00:08:05.040 --> 00:08:14.079
Uh so I would say that the first big change in the architecture internally to the broker is probably removing Spring from the picture.
00:08:14.240 --> 00:08:15.199
That's the first thing.
00:08:15.360 --> 00:08:18.399
And the second thing is that's true.
00:08:18.639 --> 00:08:23.279
Active MQ is today a little like a big monolith.
00:08:23.519 --> 00:08:28.319
Um basically, uh, you have all the transport connectors extra.
00:08:28.800 --> 00:08:38.879
Um it's pretty convenient for a broker, in my opinion, from a user standpoint, because you just get the Docker image of a broker, you have everything you need, and you just run like this.
00:08:39.120 --> 00:08:42.559
But in terms of maintenance, uh there are some challenges.
00:08:42.799 --> 00:08:59.440
So I think that by using a new framework that like CDI port uh open framework, we can have something more modular where we can update part of you know one transport connector without impacting the rest of the broker.
00:08:59.600 --> 00:09:08.159
So that's the kind of you know, uh changing a little the internals to facilitate our life of us as contributors.
00:09:08.399 --> 00:09:22.399
Um, but so that's the two big changes I I expect for Active MQ7 that would be remove the spring dependency and something more light and modular, uh facilitating the maintenance.
00:09:22.799 --> 00:09:25.600
Right, removing those dependencies and moving frameworks.
00:09:25.679 --> 00:09:32.080
That that is uh you know, it sounds like the goal there is to define a major version shift and introducing new core capabilities.
00:09:32.240 --> 00:09:33.759
It's it's very interesting.
00:09:33.919 --> 00:09:38.080
Um, I'd like to move on to security compliance because I have some questions.
00:09:38.159 --> 00:09:44.480
You know, currently ActiveMQ security is is powered by uh JAS and authorization plugins.
00:09:44.879 --> 00:09:48.559
What are the new features coming around security for ActiveMQ?
00:09:49.039 --> 00:09:50.480
Yeah, that's a great question.
00:09:50.559 --> 00:09:55.360
And uh I think there are a lot of expectations on this front.
00:09:55.440 --> 00:10:05.039
Uh the first thing is you're right, I think ActiveMQ is really based on Jazz, the Java authentication and authorization service.
00:10:05.200 --> 00:10:07.679
Um, and we provide a lot of login modules.
00:10:07.759 --> 00:10:14.320
So you can use a user priority file, you can use a HELDAP or Active Directory uh as a backend.
00:10:14.799 --> 00:10:25.759
But we need more additional login modules to be able to integrate into the modern architecture that exists in the organizations.
00:10:26.080 --> 00:10:28.480
I'm thinking, for instance, OHOD2.
00:10:29.039 --> 00:10:36.720
Um, and and we have a PR right now about uh adding a new login module, adding the HOD to support, which is great.
00:10:36.879 --> 00:10:40.320
Um, I did that, but uh but but that's great anyway.
00:10:40.559 --> 00:10:47.600
Uh and also I'm thinking about new integration layer like OPA, open profile agent.
00:10:47.679 --> 00:11:00.159
So instead of storing everything into ActiveMQ by itself, we should be able to use identity providers that exist in the organizations, but also OPA, agent, and all this stuff.
00:11:00.320 --> 00:11:15.440
So um my focus on this front is really facilitate the integration of ActiveMQ in modern um security infrastructure that exists into the organizations.
00:11:17.360 --> 00:11:26.559
Sounds like you're we're trying to emphasize that that modernization of authenticity protocols uh or authenticity authentication protocols.
00:11:26.799 --> 00:11:34.480
Um but for so for organizations in the highly regulated uh industries, finance, healthcare come to mind right away.
00:11:34.639 --> 00:11:44.240
Um, how do these new security features simplify that path uh to meeting, stringent uh audit and government requirements?
00:11:44.879 --> 00:11:50.320
Yeah, but that's I I think it's the extension of what we talked before.
00:11:50.399 --> 00:12:02.879
I mean, by be able to integrate into the existing um security uh resources from the organization, then they can leverage all that exists today in ActiveMQ.
00:12:03.360 --> 00:12:11.679
Uh I also I think that a critical piece in this um in this kind of regulated environment.
00:12:11.759 --> 00:12:15.519
Um I'm in Europe, so I know how regulated it could be.
00:12:16.639 --> 00:12:18.720
It's uh uh all about auditing.
00:12:18.799 --> 00:12:22.000
Like you need to know everything that happened into the broker.
00:12:22.080 --> 00:12:39.440
Uh, because and it has to be you know stored somewhere because maybe by regulation you may be asked, hey, what happened a couple of months ago on this queue in this broker for regulation purposes?
00:12:39.679 --> 00:12:50.080
So I think that integration into the security infra is one thing, it's key, but also considering additional plugins.
00:12:50.240 --> 00:13:00.159
So I don't think we need to have that by default in in ActiveMQ, but at least provide auditing features, uh, extend plugins to provide additional.
00:13:00.480 --> 00:13:06.559
I mean, we have, for instance, we have one plugin which is named the logger broker plugin.
00:13:06.960 --> 00:13:14.879
So basically, you can log a lot of activities that happen into your broker, including advisory topics and stuff like that.
00:13:15.039 --> 00:13:16.159
So that exists.
00:13:16.320 --> 00:13:24.240
I think it's also an effort about documenting and how it matches with what it's expecting from a regulation standpoint.
00:13:24.559 --> 00:13:25.279
Yeah, yeah.
00:13:25.440 --> 00:13:30.480
The goal is to connect technical security updates to business compliance value.
00:13:30.879 --> 00:13:31.279
Yeah.
00:13:31.679 --> 00:13:32.320
Love it, great.
00:13:32.559 --> 00:13:33.200
Love it.
00:13:33.679 --> 00:13:39.200
Uh for operational excellence, though, what's your take uh on ActiveMQ web console?
00:13:39.519 --> 00:13:42.159
Can you see any evolutions there?
00:13:44.080 --> 00:13:48.960
Um I'm gonna be pretty pretty transparent about that.
00:13:49.039 --> 00:13:51.200
I don't like the the web console.
00:13:51.279 --> 00:13:54.320
Um, I don't like the web console for two reasons.
00:13:54.559 --> 00:14:04.720
Uh, first, because if you take a look about the majority of security issues we got recently on ActiveMQ, I would say 90% are coming from the web console.
00:14:05.279 --> 00:14:10.320
Um, so and also is a pretty old web console.
00:14:10.480 --> 00:14:14.240
So it doesn't look super modern, uh, it's pretty limited.
00:14:14.480 --> 00:14:19.120
We'd never recommend to use it in production, uh, to be to be honest.
00:14:19.279 --> 00:14:20.399
So I don't like it.
00:14:20.559 --> 00:14:27.360
Um and but I mean the only huge benefit of the web console, it's only it exists.
00:14:27.440 --> 00:14:28.240
That's it, that's it.
00:14:28.399 --> 00:14:30.559
So it's pretty convenient to use it.
00:14:30.720 --> 00:14:35.440
Um but but um but but I think that we need something something new.
00:14:35.600 --> 00:14:40.320
Um, and I think Artemis on this front, they did a great move.
00:14:40.559 --> 00:14:48.639
On Artemis, they provide uh an Artemis console which is way more modern and providing a lot of interesting features.
00:14:48.799 --> 00:14:51.360
So my take on the web console is pretty clear.
00:14:51.679 --> 00:14:55.200
Personally, I would love to remove a web console from ActiveMQ.
00:14:56.480 --> 00:15:00.320
Uh now the question is what do we provide to our users?
00:15:00.720 --> 00:15:04.080
Um, I think that we already integrate Geolochia.
00:15:04.639 --> 00:15:10.720
Uh so we can use Geolochia as a kind of uh backbone to a new web console.
00:15:10.879 --> 00:15:15.279
So why not uh creating a new web console using React or something like that?
00:15:15.440 --> 00:15:19.440
I started a I started a prototype around that.
00:15:19.519 --> 00:15:21.600
It's pretty it's pretty interesting.
00:15:21.919 --> 00:15:31.600
Does it make sense for our users compared to external web console that exist and are way more powerful than what we can provide?
00:15:31.759 --> 00:15:35.679
I'm thinking obviously about MeshIQ as a platform.
00:15:35.840 --> 00:15:56.000
So I honestly I would say that uh short term, I would love to remove a web console if the community is okay with that, um, and and maybe provide a light alternative to that, and maybe just relay on external web console that exist, like Ot.io or Mesh IQ or others?
00:15:56.559 --> 00:15:57.200
Yeah, yeah.
00:15:57.279 --> 00:16:05.759
It's I mean that that focus on modernization, it's to provide simplified governance and developer experience, self-serve developer experience.
00:16:06.000 --> 00:16:08.000
Um interesting.
00:16:08.399 --> 00:16:08.960
Interesting.
00:16:09.360 --> 00:16:14.559
So for open telemetry though, it's becoming the industry standard for observability.
00:16:14.799 --> 00:16:25.679
Um, how does the deep integration of open telemetry in this roadmap help teams eliminate that visibility vacuum in complex hybrid cloud message flows?
00:16:26.320 --> 00:16:27.919
That's that's a great question.
00:16:28.080 --> 00:16:34.480
Um, and I actually you are spot on on something that we should consider and we should do.
00:16:34.720 --> 00:16:42.399
Um historically, on ActiveMQ, and uh that's also the same for uh Caraf and Camel.
00:16:42.960 --> 00:16:45.759
We we mostly focus on about JMX.
00:16:46.000 --> 00:16:53.200
So basically we say, hey, we expose everything like matrix, I mean attributes, and everything through JMX.
00:16:53.519 --> 00:17:01.840
And it's up to you to uh get and consume the the matrix you want, the attributes you want, you store wherever you want, but it's up to you.
00:17:02.000 --> 00:17:08.240
And and for instance, we have um uh an Apache project to do that like uh uh Caraf decanta.
00:17:08.400 --> 00:17:17.599
So Carif Decanta, the idea is really putting JMX metrics, log files, stuff like that, and store into Elasticsearch, Cassandra, whatever.
00:17:17.759 --> 00:17:28.160
Um, I think it was nice like uh 10 years ago, four or five years ago maximum, but it's not what we are looking for today.
00:17:28.240 --> 00:17:47.920
Um we are we are looking for more modern kind of exporter that can basically have more details, events, and spans inside the broker that we can expose and export to external systems like Prometheus or Zipkin, whatever.
00:17:48.079 --> 00:17:57.039
And then the big advantage of doing that is we have some kind of details as we have on JMX, but we also add all about the tracking.
00:17:57.279 --> 00:18:31.519
We're able to know that we can correlate, hey, this event is coming from ActiveMQ, it goes into this common route uh using break from ID and stuff like that, and it goes to another RTM broker, and we on Prometheus or ZipKin, we will be able to see, hey, this is all the states of this event, and that will give more uh prompt to hand to end, I would say, tracking about what's happening and the time we spend on different uh thread on the microservices application and stuff like that.
00:18:31.680 --> 00:18:45.759
So I think that I don't think we should we should remove JMX, honestly, because JMX is there and it's great and we can still use it, but adding some open telemetry features like spanning that that's pretty uh that's pretty interesting.
00:18:46.000 --> 00:18:50.480
We already have a uh a GitHub issue about that, um, so we know we have to do that.
00:18:50.720 --> 00:19:04.160
The question is, you know, um how to do that in a kind of sim, I mean meaningful way, like like providing the accurate span for users.
00:19:04.480 --> 00:19:09.599
So, but uh totally agree with you, that's a great feature, and we have to to do that for sure.
00:19:09.759 --> 00:19:14.319
But it's all about discussing tracing and monitoring across distributed systems, so right.
00:19:14.720 --> 00:19:15.680
Yeah, exactly.
00:19:16.079 --> 00:19:24.799
So for cloud native strategy, though, um what are your ideas or what are the ideas about active MQ on the cloud?
00:19:25.440 --> 00:19:38.160
Yeah, that's a great question because uh sometimes we have confusion about where we position um Active MQ or Carmel or whatever in in this uh scope.
00:19:38.319 --> 00:19:44.559
Uh the first thing to remember is we have we already have some managed services uh for ActiveMQ.
00:19:44.640 --> 00:19:52.799
So for instance, if you go on AWS, you can find Amazon MQ, and Amazon MQ is a managed service for Active MQ.
00:19:53.359 --> 00:19:58.559
So the question is you basically as a user, I have two choices.
00:19:58.720 --> 00:20:09.359
Uh, my first choice is I can use existing managed services that provide ActiveMQ for me, could be Amazon MQ, or I think Avon also are doing something similar.
00:20:09.839 --> 00:20:22.079
Or I have a Kubernetes cluster on EKS, AKS, whatever, or even maybe on a private cloud, and I would like to deploy ActiveMQ there.
00:20:22.640 --> 00:20:26.960
So today the only thing that we we provide in ActiveMQ is the Docker images.
00:20:27.119 --> 00:20:29.759
That's great, but that's not enough.
00:20:30.160 --> 00:20:44.000
So uh the things we are working on, and the Amazon MQ team is interesting to contribute that, is basically first we can provide M charts to simplify the deployment of Active MQ brokers on new infra.
00:20:44.400 --> 00:21:01.119
And something that I have in mind is also why not having a Kubernetes operator, but can automatically create new uh brokers for you, uh adding in the in the same stateful set as you have already, creating new Kubernetes services, stuff like that.
00:21:01.279 --> 00:21:08.559
So I think that you on our road to the cloud, I would say there are two features we should add.
00:21:08.799 --> 00:21:10.960
Hem chart, that's gonna happen pretty soon.
00:21:11.119 --> 00:21:17.359
I think that the hem chart is gonna be available, uh maybe not in the next Actium Q release, but the next one.
00:21:17.599 --> 00:21:24.799
But I'll I I would also consider the Kubernetes cloud uh operator uh as a welcome feature we should consider.
00:21:26.000 --> 00:21:26.559
Interesting.
00:21:26.640 --> 00:21:31.440
It sounds like there is a big push to identify those cloud native differentiators.
00:21:31.680 --> 00:21:54.480
Um as Apache Camel though continues to evolve alongside ActiveMQ and Artemis, um, how does the roadmap there ensure that these technologies work, you know, in concert to simplify the modernization journey most companies are moving uh towards and away from these legacy monoliths?
00:21:55.359 --> 00:21:56.720
Yeah, great question.
00:21:56.880 --> 00:21:59.839
Um I think you mentioned the user suspension.
00:22:00.240 --> 00:22:08.240
You know, RTMQ, RTMES, CARAF, Camel, that's all the same, uh the same guys, I would say, in the room.
00:22:08.480 --> 00:22:17.119
Um, but the good thing is the majority of the communities around those projects, um, they are across several projects.
00:22:17.279 --> 00:22:21.200
For instance, I'm on Cara on Camel on ActimQ and Artemis.
00:22:21.519 --> 00:22:24.640
A lot of people from Camel are also on ActiveMQ and Artemis.
00:22:24.799 --> 00:22:30.799
So thanks to that, we can you know we can uh discuss all together and say, hey, we planned this new feature.
00:22:30.880 --> 00:22:31.519
What do you think?
00:22:31.599 --> 00:22:33.039
And how we can leverage that.
00:22:33.200 --> 00:22:41.359
So um the the the relationship between the communities are really great uh on this regard.
00:22:41.759 --> 00:22:55.680
Um now where we are going, I think that, and that's also my role uh as an Apache member um and director of a foundation is to fill the gap between the different projects.
00:22:55.839 --> 00:22:57.759
And and for me, you're right.
00:22:58.319 --> 00:23:08.079
It looks like we are coming from the legacy kind of thing, like uh, hey, it's a messaging platform, there are new things that happen.
00:23:08.319 --> 00:23:15.759
And it's where I think that I don't consider it really as a legacy, I think that it's different use cases.
00:23:15.920 --> 00:23:28.880
Um, like people comparing Kafka and Active MQ, I think it's not fair and it's not right because they they're just two great projects just addressing two very different use cases.
00:23:29.039 --> 00:23:37.920
If you want to implement transaction and there you have this rock solid transaction, probably messaging and active MQ is way better than Kafka.
00:23:38.079 --> 00:23:46.559
If you want to have huge throughput, a lot of log records, you you want to consume big data streaming, Kafka is probably better for sure.
00:23:46.720 --> 00:23:58.480
So now the question is okay, I have ActiveMQ, which is my transaction system, I have Kafka, which is mostly my data system, and at the end of the day, I want to do analytics on everything.
00:23:58.720 --> 00:24:04.240
So why not bringing the gap between messaging and streaming and analytics?
00:24:04.400 --> 00:24:26.319
So basically, analytics means layouts, and by layouts, it means that we can get the data from using Kamel from Kafka and or ActiveMQ and store into iceberg using priorities as a catalog, but store into iceberg, and then you can query your data uh using that.
00:24:26.480 --> 00:24:32.960
That's basically some observability observability platforms that are doing that now.
00:24:33.200 --> 00:24:40.000
If you take a look about a company like Datadog, Datadog, they are using iceberg to store everything and they can do the query.
00:24:40.240 --> 00:24:48.799
So I think that by adding new connectors, and we have a bunch of projects at the Apache Foundation like Apache NiFi, Apache Hop.
00:24:49.119 --> 00:25:00.960
I mean, there are a lot of you know framework and projects we can leverage to create a kind of big backbone that fills the gap between transaction streaming and data.
00:25:01.200 --> 00:25:13.119
And that's that's where I'm super excited with because I think we have a lot of opportunity to you know create the kind of assembly between all the different these different Lego boxes, I would say.
00:25:13.920 --> 00:25:14.319
Definitely.
00:25:14.400 --> 00:25:21.039
It's it's it's the goal of the ultimate goal is to address the entire integration ecosystem and that transition to modern stacks.
00:25:21.599 --> 00:25:22.880
Um very interesting.
00:25:23.039 --> 00:25:24.079
Well, I appreciate this.
00:25:24.160 --> 00:25:27.920
Is the beauty of community uh being able to to chat with you, JB, today.
00:25:28.240 --> 00:25:28.400
Sure.
00:25:28.480 --> 00:25:30.400
Thanks so much and great session.
00:00:06.719 --> 00:00:13.199
Well, good morning, good afternoon, and good evening, just like Jen said, and I want to say thank you so much for your time today, everyone, and for joining us.
00:00:13.439 --> 00:00:14.800
My name is Michael Jo Kay.
00:00:14.880 --> 00:00:18.719
I am the director of demand generation and business development here at MeshIQ.
00:00:19.120 --> 00:00:34.000
We are incredibly excited to dig into what's new with Apache ActiveMQ, Artemis, and Camel, and to better understand how their evolution is accelerating to address the critical needs of modern cloud deployments, high availability, simplified operations, and robust security.
00:00:34.079 --> 00:00:39.840
And I'm also incredibly grateful and excited to introduce my friend and fellow panelists, JB Onefrey.
00:00:40.000 --> 00:00:43.359
JB, would you like to give a brief introduction before we jump into the session here?
00:00:43.840 --> 00:00:45.280
Yeah, uh thanks, Mike.
00:00:45.600 --> 00:00:49.840
So yeah, I'm JB, um director of the Apache Software Foundation.
00:00:50.079 --> 00:00:54.479
I'm a member for the foundation for more than 20 years now.
00:00:54.799 --> 00:01:07.840
Um I'm working on several Apache projects, obviously, like um ActiveMQ, Carmel, uh Cara, Fartemis, but also more on the big data space, like Apache Prioris, Apache Iceberg.
00:01:08.000 --> 00:01:18.959
So yeah, I'm um happy to have a chat uh with you today about what's uh what the community is thinking about the future and a future and roadmap on ActiveMQ, especially in Carmel.
00:01:19.599 --> 00:01:20.079
I love it.
00:01:20.159 --> 00:01:23.599
The community, the foundation, and we are very lucky to have you with us.
00:01:23.760 --> 00:01:26.079
Uh, wanted to give you a big shout out uh and congratulations.
00:01:26.159 --> 00:01:27.920
You recently joined our board of directors.
00:01:28.000 --> 00:01:33.280
Uh so I know that most feel like I do, uh, anyone that has the pleasure of boarding you with you is very lucky.
00:01:33.439 --> 00:01:36.480
So without any further ado, let's jump into some questions today.
00:01:36.640 --> 00:01:42.159
I know we have a lot to cover in 30 minutes, but I think I want to start with architectural evolution and clustering.
00:01:42.239 --> 00:01:48.079
Uh, specifically, you know, Kaha DB, it's a key component for storage in Apache ActiveMQ.
00:01:48.159 --> 00:01:51.680
Do you see uh a potential evolution for Kaha DB?
00:01:52.560 --> 00:01:54.719
Yeah, but uh you're right, Mike.
00:01:54.799 --> 00:02:02.319
I actually Ka DB is a very critical piece in ActiveMQ uh when you are running your broker.
00:02:02.480 --> 00:02:09.120
By default, it's basically storing uh a lot of details and persistent messages inside the storage.
00:02:09.280 --> 00:02:10.560
That's not the only uh option.
00:02:10.639 --> 00:02:17.039
You can also use a JDBC backend, but that's the preferred one uh uh for ActiveMQ.
00:02:17.439 --> 00:02:21.680
I see two potential evolutions on CADB.
00:02:22.159 --> 00:02:42.240
The first evolution is a natural one because in ActiveMQ right now we are working to support the new the latest version of the uh messaging specification, JMS, and and there are new changes and new updates we have to do on the broker, but should be reflected into KDB.
00:02:42.400 --> 00:03:00.000
Because you know, when you're adding, for instance, durable subscribers, which is a new feature from uh Jacarta Messaging 3, then we have to purchase that because if you switch from one broker to another, uh it means that this information has to be available.
00:03:00.159 --> 00:03:06.639
So we need first to update KDB to be able to store this additional information we need.
00:03:06.800 --> 00:03:08.240
So that's the first evolution.
00:03:08.319 --> 00:03:11.520
I think it's a required one, it's a natural one.
00:03:11.680 --> 00:03:17.360
And the second evolution is more it's more from an architectural standpoint.
00:03:17.520 --> 00:03:23.039
Um, today CaraDB is only able to deal with a single broker.
00:03:23.120 --> 00:03:32.479
So basically, when you start a broker, you're gonna start CaraDB and it's gonna be used only by this broker, which is great by default, but it has two limitations.
00:03:32.719 --> 00:03:48.159
The first limitation is basically when you want to create uh high availability uh instances of ActiveMQ, then you need to share the same storage for the two KDB instances.
00:03:48.319 --> 00:04:00.879
So basically, it means that you have to use NFS or any kind of um share storage to implement that, which is not always super easy, especially in a cloud kind of environment.
00:04:01.039 --> 00:04:02.319
That's the first limitation.
00:04:02.479 --> 00:04:13.280
The second limitation is in ActiveMQ, we can uh we can basically spread the load of messages across different set of brokers.
00:04:13.520 --> 00:04:18.240
That's what we name network of brokers, and we do that using a network connector.
00:04:18.319 --> 00:04:35.759
So basically, one broker can dispatch and forward messages to another broker, and there it means that basically if you lose one of the brokers in this cluster, you're gonna lose all the messages on this broker waiting to be restarted.
00:04:35.920 --> 00:04:42.240
And so I think it's where we can think about a new way to implement KDB.
00:04:42.720 --> 00:04:51.040
And the idea that I've been discussing with the community right now is why not having some kind of replicated KDB?
00:04:51.199 --> 00:05:02.399
And by replicated KDB, it means that two KDB instances can talk each other, and then one can be a replica of the main one.
00:05:02.480 --> 00:05:09.040
And so if we have one broker falls down for any reason, then another one can have a replication of the first one.
00:05:09.199 --> 00:05:13.439
So that's it's it's not a trivial thing to do, to be honest.
00:05:13.600 --> 00:05:16.480
Um, but but I think it's more than welcome.
00:05:16.639 --> 00:05:20.160
Um, and that's something we are uh discussing with the community.
00:05:20.240 --> 00:05:28.160
Uh how we we have different experiments ongoing on that, like uh uh should we use uh Apache Bookkeeper?
00:05:28.240 --> 00:05:29.439
Maybe I don't know.
00:05:29.600 --> 00:05:49.759
Uh for me uh that could be a solution, but also Artemis did a huge work on this part, like uh they they introduced the new mirroring feature in in the latest version of Artemis, and also you have the acceptor lock lock system distributed log system.
00:05:50.000 --> 00:05:51.920
Um, that's also pretty interesting.
00:05:52.160 --> 00:06:03.199
So, thanks to the uh the work between all the communities, we can find something which is pretty solid and and very interesting for the infra and the future of KDB.
00:06:03.920 --> 00:06:04.319
Love it.
00:06:04.399 --> 00:06:10.800
It sounds like the goal is really just uh to highlight that reduction of infrastructure complexity overall, right?
00:06:11.360 --> 00:06:11.920
Absolutely.
00:06:12.000 --> 00:06:19.680
I mean, the complexity is on us in inside RTMEs Active MQ, but for the users, it should be uh straightforward.
00:06:19.920 --> 00:06:21.120
Seamless, yes, yeah.
00:06:21.279 --> 00:06:30.319
Uh so but it makes me think thinking long-term uh and active MQ7, do you see potential big changes from an architectural standpoint?
00:06:30.480 --> 00:06:35.839
You know, so what would you say are the main differences between ActiveMQ6 and ActiveMQ7?
00:06:36.959 --> 00:06:54.240
Yeah, um without knowing exactly when ActiveMQ7 is gonna happen for sure, uh, but the big changes that personally I would love to see is uh today ActiveMQ, since the beginning of ActiveMQ, ActiveMQ is a big spring application, basically.
00:06:54.399 --> 00:07:13.439
Uh we have a bunch of uh spring framework bins, and basically, if you take a look on the main configuration file, which is ActiveMQ XML, it's basically just a lot of bins we are defining, which is fine, but I think we can do there are two comments.
00:07:13.600 --> 00:07:17.600
I I don't want to say issues, but two comments about that first.
00:07:18.319 --> 00:07:28.879
Um, Spring framework is not an Apache project, it's an Apache license framework, but we don't know where Spring is going.
00:07:29.040 --> 00:07:40.879
And with the recent announce about the maintenance of you know CD on Spring and all this stuff, I'm a little bit concerned about the future of Spring for open source projects.
00:07:41.199 --> 00:07:50.079
And so regarding that, I would love to consider removing Spring as the core dependency in ActiveMQ.
00:07:50.560 --> 00:08:04.879
Um, and maybe so it means that maybe leveraging another framework, uh like CDI provided, like uh, I don't know, Quarkus or something internal we can do.
00:08:05.040 --> 00:08:14.079
Uh so I would say that the first big change in the architecture internally to the broker is probably removing Spring from the picture.
00:08:14.240 --> 00:08:15.199
That's the first thing.
00:08:15.360 --> 00:08:18.399
And the second thing is that's true.
00:08:18.639 --> 00:08:23.279
Active MQ is today a little like a big monolith.
00:08:23.519 --> 00:08:28.319
Um basically, uh, you have all the transport connectors extra.
00:08:28.800 --> 00:08:38.879
Um it's pretty convenient for a broker, in my opinion, from a user standpoint, because you just get the Docker image of a broker, you have everything you need, and you just run like this.
00:08:39.120 --> 00:08:42.559
But in terms of maintenance, uh there are some challenges.
00:08:42.799 --> 00:08:59.440
So I think that by using a new framework that like CDI port uh open framework, we can have something more modular where we can update part of you know one transport connector without impacting the rest of the broker.
00:08:59.600 --> 00:09:08.159
So that's the kind of you know, uh changing a little the internals to facilitate our life of us as contributors.
00:09:08.399 --> 00:09:22.399
Um, but so that's the two big changes I I expect for Active MQ7 that would be remove the spring dependency and something more light and modular, uh facilitating the maintenance.
00:09:22.799 --> 00:09:25.600
Right, removing those dependencies and moving frameworks.
00:09:25.679 --> 00:09:32.080
That that is uh you know, it sounds like the goal there is to define a major version shift and introducing new core capabilities.
00:09:32.240 --> 00:09:33.759
It's it's very interesting.
00:09:33.919 --> 00:09:38.080
Um, I'd like to move on to security compliance because I have some questions.
00:09:38.159 --> 00:09:44.480
You know, currently ActiveMQ security is is powered by uh JAS and authorization plugins.
00:09:44.879 --> 00:09:48.559
What are the new features coming around security for ActiveMQ?
00:09:49.039 --> 00:09:50.480
Yeah, that's a great question.
00:09:50.559 --> 00:09:55.360
And uh I think there are a lot of expectations on this front.
00:09:55.440 --> 00:10:05.039
Uh the first thing is you're right, I think ActiveMQ is really based on Jazz, the Java authentication and authorization service.
00:10:05.200 --> 00:10:07.679
Um, and we provide a lot of login modules.
00:10:07.759 --> 00:10:14.320
So you can use a user priority file, you can use a HELDAP or Active Directory uh as a backend.
00:10:14.799 --> 00:10:25.759
But we need more additional login modules to be able to integrate into the modern architecture that exists in the organizations.
00:10:26.080 --> 00:10:28.480
I'm thinking, for instance, OHOD2.
00:10:29.039 --> 00:10:36.720
Um, and and we have a PR right now about uh adding a new login module, adding the HOD to support, which is great.
00:10:36.879 --> 00:10:40.320
Um, I did that, but uh but but that's great anyway.
00:10:40.559 --> 00:10:47.600
Uh and also I'm thinking about new integration layer like OPA, open profile agent.
00:10:47.679 --> 00:11:00.159
So instead of storing everything into ActiveMQ by itself, we should be able to use identity providers that exist in the organizations, but also OPA, agent, and all this stuff.
00:11:00.320 --> 00:11:15.440
So um my focus on this front is really facilitate the integration of ActiveMQ in modern um security infrastructure that exists into the organizations.
00:11:17.360 --> 00:11:26.559
Sounds like you're we're trying to emphasize that that modernization of authenticity protocols uh or authenticity authentication protocols.
00:11:26.799 --> 00:11:34.480
Um but for so for organizations in the highly regulated uh industries, finance, healthcare come to mind right away.
00:11:34.639 --> 00:11:44.240
Um, how do these new security features simplify that path uh to meeting, stringent uh audit and government requirements?
00:11:44.879 --> 00:11:50.320
Yeah, but that's I I think it's the extension of what we talked before.
00:11:50.399 --> 00:12:02.879
I mean, by be able to integrate into the existing um security uh resources from the organization, then they can leverage all that exists today in ActiveMQ.
00:12:03.360 --> 00:12:11.679
Uh I also I think that a critical piece in this um in this kind of regulated environment.
00:12:11.759 --> 00:12:15.519
Um I'm in Europe, so I know how regulated it could be.
00:12:16.639 --> 00:12:18.720
It's uh uh all about auditing.
00:12:18.799 --> 00:12:22.000
Like you need to know everything that happened into the broker.
00:12:22.080 --> 00:12:39.440
Uh, because and it has to be you know stored somewhere because maybe by regulation you may be asked, hey, what happened a couple of months ago on this queue in this broker for regulation purposes?
00:12:39.679 --> 00:12:50.080
So I think that integration into the security infra is one thing, it's key, but also considering additional plugins.
00:12:50.240 --> 00:13:00.159
So I don't think we need to have that by default in in ActiveMQ, but at least provide auditing features, uh, extend plugins to provide additional.
00:13:00.480 --> 00:13:06.559
I mean, we have, for instance, we have one plugin which is named the logger broker plugin.
00:13:06.960 --> 00:13:14.879
So basically, you can log a lot of activities that happen into your broker, including advisory topics and stuff like that.
00:13:15.039 --> 00:13:16.159
So that exists.
00:13:16.320 --> 00:13:24.240
I think it's also an effort about documenting and how it matches with what it's expecting from a regulation standpoint.
00:13:24.559 --> 00:13:25.279
Yeah, yeah.
00:13:25.440 --> 00:13:30.480
The goal is to connect technical security updates to business compliance value.
00:13:30.879 --> 00:13:31.279
Yeah.
00:13:31.679 --> 00:13:32.320
Love it, great.
00:13:32.559 --> 00:13:33.200
Love it.
00:13:33.679 --> 00:13:39.200
Uh for operational excellence, though, what's your take uh on ActiveMQ web console?
00:13:39.519 --> 00:13:42.159
Can you see any evolutions there?
00:13:44.080 --> 00:13:48.960
Um I'm gonna be pretty pretty transparent about that.
00:13:49.039 --> 00:13:51.200
I don't like the the web console.
00:13:51.279 --> 00:13:54.320
Um, I don't like the web console for two reasons.
00:13:54.559 --> 00:14:04.720
Uh, first, because if you take a look about the majority of security issues we got recently on ActiveMQ, I would say 90% are coming from the web console.
00:14:05.279 --> 00:14:10.320
Um, so and also is a pretty old web console.
00:14:10.480 --> 00:14:14.240
So it doesn't look super modern, uh, it's pretty limited.
00:14:14.480 --> 00:14:19.120
We'd never recommend to use it in production, uh, to be to be honest.
00:14:19.279 --> 00:14:20.399
So I don't like it.
00:14:20.559 --> 00:14:27.360
Um and but I mean the only huge benefit of the web console, it's only it exists.
00:14:27.440 --> 00:14:28.240
That's it, that's it.
00:14:28.399 --> 00:14:30.559
So it's pretty convenient to use it.
00:14:30.720 --> 00:14:35.440
Um but but um but but I think that we need something something new.
00:14:35.600 --> 00:14:40.320
Um, and I think Artemis on this front, they did a great move.
00:14:40.559 --> 00:14:48.639
On Artemis, they provide uh an Artemis console which is way more modern and providing a lot of interesting features.
00:14:48.799 --> 00:14:51.360
So my take on the web console is pretty clear.
00:14:51.679 --> 00:14:55.200
Personally, I would love to remove a web console from ActiveMQ.
00:14:56.480 --> 00:15:00.320
Uh now the question is what do we provide to our users?
00:15:00.720 --> 00:15:04.080
Um, I think that we already integrate Geolochia.
00:15:04.639 --> 00:15:10.720
Uh so we can use Geolochia as a kind of uh backbone to a new web console.
00:15:10.879 --> 00:15:15.279
So why not uh creating a new web console using React or something like that?
00:15:15.440 --> 00:15:19.440
I started a I started a prototype around that.
00:15:19.519 --> 00:15:21.600
It's pretty it's pretty interesting.
00:15:21.919 --> 00:15:31.600
Does it make sense for our users compared to external web console that exist and are way more powerful than what we can provide?
00:15:31.759 --> 00:15:35.679
I'm thinking obviously about MeshIQ as a platform.
00:15:35.840 --> 00:15:56.000
So I honestly I would say that uh short term, I would love to remove a web console if the community is okay with that, um, and and maybe provide a light alternative to that, and maybe just relay on external web console that exist, like Ot.io or Mesh IQ or others?
00:15:56.559 --> 00:15:57.200
Yeah, yeah.
00:15:57.279 --> 00:16:05.759
It's I mean that that focus on modernization, it's to provide simplified governance and developer experience, self-serve developer experience.
00:16:06.000 --> 00:16:08.000
Um interesting.
00:16:08.399 --> 00:16:08.960
Interesting.
00:16:09.360 --> 00:16:14.559
So for open telemetry though, it's becoming the industry standard for observability.
00:16:14.799 --> 00:16:25.679
Um, how does the deep integration of open telemetry in this roadmap help teams eliminate that visibility vacuum in complex hybrid cloud message flows?
00:16:26.320 --> 00:16:27.919
That's that's a great question.
00:16:28.080 --> 00:16:34.480
Um, and I actually you are spot on on something that we should consider and we should do.
00:16:34.720 --> 00:16:42.399
Um historically, on ActiveMQ, and uh that's also the same for uh Caraf and Camel.
00:16:42.960 --> 00:16:45.759
We we mostly focus on about JMX.
00:16:46.000 --> 00:16:53.200
So basically we say, hey, we expose everything like matrix, I mean attributes, and everything through JMX.
00:16:53.519 --> 00:17:01.840
And it's up to you to uh get and consume the the matrix you want, the attributes you want, you store wherever you want, but it's up to you.
00:17:02.000 --> 00:17:08.240
And and for instance, we have um uh an Apache project to do that like uh uh Caraf decanta.
00:17:08.400 --> 00:17:17.599
So Carif Decanta, the idea is really putting JMX metrics, log files, stuff like that, and store into Elasticsearch, Cassandra, whatever.
00:17:17.759 --> 00:17:28.160
Um, I think it was nice like uh 10 years ago, four or five years ago maximum, but it's not what we are looking for today.
00:17:28.240 --> 00:17:47.920
Um we are we are looking for more modern kind of exporter that can basically have more details, events, and spans inside the broker that we can expose and export to external systems like Prometheus or Zipkin, whatever.
00:17:48.079 --> 00:17:57.039
And then the big advantage of doing that is we have some kind of details as we have on JMX, but we also add all about the tracking.
00:17:57.279 --> 00:18:31.519
We're able to know that we can correlate, hey, this event is coming from ActiveMQ, it goes into this common route uh using break from ID and stuff like that, and it goes to another RTM broker, and we on Prometheus or ZipKin, we will be able to see, hey, this is all the states of this event, and that will give more uh prompt to hand to end, I would say, tracking about what's happening and the time we spend on different uh thread on the microservices application and stuff like that.
00:18:31.680 --> 00:18:45.759
So I think that I don't think we should we should remove JMX, honestly, because JMX is there and it's great and we can still use it, but adding some open telemetry features like spanning that that's pretty uh that's pretty interesting.
00:18:46.000 --> 00:18:50.480
We already have a uh a GitHub issue about that, um, so we know we have to do that.
00:18:50.720 --> 00:19:04.160
The question is, you know, um how to do that in a kind of sim, I mean meaningful way, like like providing the accurate span for users.
00:19:04.480 --> 00:19:09.599
So, but uh totally agree with you, that's a great feature, and we have to to do that for sure.
00:19:09.759 --> 00:19:14.319
But it's all about discussing tracing and monitoring across distributed systems, so right.
00:19:14.720 --> 00:19:15.680
Yeah, exactly.
00:19:16.079 --> 00:19:24.799
So for cloud native strategy, though, um what are your ideas or what are the ideas about active MQ on the cloud?
00:19:25.440 --> 00:19:38.160
Yeah, that's a great question because uh sometimes we have confusion about where we position um Active MQ or Carmel or whatever in in this uh scope.
00:19:38.319 --> 00:19:44.559
Uh the first thing to remember is we have we already have some managed services uh for ActiveMQ.
00:19:44.640 --> 00:19:52.799
So for instance, if you go on AWS, you can find Amazon MQ, and Amazon MQ is a managed service for Active MQ.
00:19:53.359 --> 00:19:58.559
So the question is you basically as a user, I have two choices.
00:19:58.720 --> 00:20:09.359
Uh, my first choice is I can use existing managed services that provide ActiveMQ for me, could be Amazon MQ, or I think Avon also are doing something similar.
00:20:09.839 --> 00:20:22.079
Or I have a Kubernetes cluster on EKS, AKS, whatever, or even maybe on a private cloud, and I would like to deploy ActiveMQ there.
00:20:22.640 --> 00:20:26.960
So today the only thing that we we provide in ActiveMQ is the Docker images.
00:20:27.119 --> 00:20:29.759
That's great, but that's not enough.
00:20:30.160 --> 00:20:44.000
So uh the things we are working on, and the Amazon MQ team is interesting to contribute that, is basically first we can provide M charts to simplify the deployment of Active MQ brokers on new infra.
00:20:44.400 --> 00:21:01.119
And something that I have in mind is also why not having a Kubernetes operator, but can automatically create new uh brokers for you, uh adding in the in the same stateful set as you have already, creating new Kubernetes services, stuff like that.
00:21:01.279 --> 00:21:08.559
So I think that you on our road to the cloud, I would say there are two features we should add.
00:21:08.799 --> 00:21:10.960
Hem chart, that's gonna happen pretty soon.
00:21:11.119 --> 00:21:17.359
I think that the hem chart is gonna be available, uh maybe not in the next Actium Q release, but the next one.
00:21:17.599 --> 00:21:24.799
But I'll I I would also consider the Kubernetes cloud uh operator uh as a welcome feature we should consider.
00:21:26.000 --> 00:21:26.559
Interesting.
00:21:26.640 --> 00:21:31.440
It sounds like there is a big push to identify those cloud native differentiators.
00:21:31.680 --> 00:21:54.480
Um as Apache Camel though continues to evolve alongside ActiveMQ and Artemis, um, how does the roadmap there ensure that these technologies work, you know, in concert to simplify the modernization journey most companies are moving uh towards and away from these legacy monoliths?
00:21:55.359 --> 00:21:56.720
Yeah, great question.
00:21:56.880 --> 00:21:59.839
Um I think you mentioned the user suspension.
00:22:00.240 --> 00:22:08.240
You know, RTMQ, RTMES, CARAF, Camel, that's all the same, uh the same guys, I would say, in the room.
00:22:08.480 --> 00:22:17.119
Um, but the good thing is the majority of the communities around those projects, um, they are across several projects.
00:22:17.279 --> 00:22:21.200
For instance, I'm on Cara on Camel on ActimQ and Artemis.
00:22:21.519 --> 00:22:24.640
A lot of people from Camel are also on ActiveMQ and Artemis.
00:22:24.799 --> 00:22:30.799
So thanks to that, we can you know we can uh discuss all together and say, hey, we planned this new feature.
00:22:30.880 --> 00:22:31.519
What do you think?
00:22:31.599 --> 00:22:33.039
And how we can leverage that.
00:22:33.200 --> 00:22:41.359
So um the the the relationship between the communities are really great uh on this regard.
00:22:41.759 --> 00:22:55.680
Um now where we are going, I think that, and that's also my role uh as an Apache member um and director of a foundation is to fill the gap between the different projects.
00:22:55.839 --> 00:22:57.759
And and for me, you're right.
00:22:58.319 --> 00:23:08.079
It looks like we are coming from the legacy kind of thing, like uh, hey, it's a messaging platform, there are new things that happen.
00:23:08.319 --> 00:23:15.759
And it's where I think that I don't consider it really as a legacy, I think that it's different use cases.
00:23:15.920 --> 00:23:28.880
Um, like people comparing Kafka and Active MQ, I think it's not fair and it's not right because they they're just two great projects just addressing two very different use cases.
00:23:29.039 --> 00:23:37.920
If you want to implement transaction and there you have this rock solid transaction, probably messaging and active MQ is way better than Kafka.
00:23:38.079 --> 00:23:46.559
If you want to have huge throughput, a lot of log records, you you want to consume big data streaming, Kafka is probably better for sure.
00:23:46.720 --> 00:23:58.480
So now the question is okay, I have ActiveMQ, which is my transaction system, I have Kafka, which is mostly my data system, and at the end of the day, I want to do analytics on everything.
00:23:58.720 --> 00:24:04.240
So why not bringing the gap between messaging and streaming and analytics?
00:24:04.400 --> 00:24:26.319
So basically, analytics means layouts, and by layouts, it means that we can get the data from using Kamel from Kafka and or ActiveMQ and store into iceberg using priorities as a catalog, but store into iceberg, and then you can query your data uh using that.
00:24:26.480 --> 00:24:32.960
That's basically some observability observability platforms that are doing that now.
00:24:33.200 --> 00:24:40.000
If you take a look about a company like Datadog, Datadog, they are using iceberg to store everything and they can do the query.
00:24:40.240 --> 00:24:48.799
So I think that by adding new connectors, and we have a bunch of projects at the Apache Foundation like Apache NiFi, Apache Hop.
00:24:49.119 --> 00:25:00.960
I mean, there are a lot of you know framework and projects we can leverage to create a kind of big backbone that fills the gap between transaction streaming and data.
00:25:01.200 --> 00:25:13.119
And that's that's where I'm super excited with because I think we have a lot of opportunity to you know create the kind of assembly between all the different these different Lego boxes, I would say.
00:25:13.920 --> 00:25:14.319
Definitely.
00:25:14.400 --> 00:25:21.039
It's it's it's the goal of the ultimate goal is to address the entire integration ecosystem and that transition to modern stacks.
00:25:21.599 --> 00:25:22.880
Um very interesting.
00:25:23.039 --> 00:25:24.079
Well, I appreciate this.
00:25:24.160 --> 00:25:27.920
Is the beauty of community uh being able to to chat with you, JB, today.
00:25:28.240 --> 00:25:28.400
Sure.
00:25:28.480 --> 00:25:30.400
Thanks so much and great session.
