Apache ActiveMQ, Artemis & Camel: The Roadmap to Cloud-Native Resilience, Modern Security, and Next-Gen Management

In this episode, JB Onofré and Mike Jauquet discuss the evolving roadmap for Apache ActiveMQ, Apache Artemis, and Apache Camel, and how these projects are adapting to the demands of modern cloud deployments.

The conversation covers developments from ActiveMQ 6.5 through the upcoming 7.0 release, including improvements in high availability, security, and operational visibility, along with updates designed to simplify the management of modern messaging environments.

Listen in to learn more about what’s ahead for ActiveMQ, Artemis, and Camel.

Learn more about meshIQ at https://meshiq.com.

Follow meshIQ on LinkedIn for more insights on messaging, observability, and enterprise integration: https://www.linkedin.com/company/meshiq/.

Transcript

SPEAKER_00 0:06

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. My name is Michael Jo Kay. I am the director of demand generation and business development here at MeshIQ. 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. And I'm also incredibly grateful and excited to introduce my friend and fellow panelists, JB Onefrey. JB, would you like to give a brief introduction before we jump into the session here?

SPEAKER_01 0:43

Yeah, uh thanks, Mike. So yeah, I'm JB, um director of the Apache Software Foundation. I'm a member for the foundation for more than 20 years now. 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. 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.

SPEAKER_00 1:19

I love it. The community, the foundation, and we are very lucky to have you with us. Uh, wanted to give you a big shout out uh and congratulations. You recently joined our board of directors. Uh so I know that most feel like I do, uh, anyone that has the pleasure of boarding you with you is very lucky. So without any further ado, let's jump into some questions today. I know we have a lot to cover in 30 minutes, but I think I want to start with architectural evolution and clustering. Uh, specifically, you know, Kaha DB, it's a key component for storage in Apache ActiveMQ. Do you see uh a potential evolution for Kaha DB?

SPEAKER_01 1:52

Yeah, but uh you're right, Mike. I actually Ka DB is a very critical piece in ActiveMQ uh when you are running your broker. By default, it's basically storing uh a lot of details and persistent messages inside the storage. That's not the only uh option. You can also use a JDBC backend, but that's the preferred one uh uh for ActiveMQ. I see two potential evolutions on CADB. 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. 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. So we need first to update KDB to be able to store this additional information we need. So that's the first evolution. I think it's a required one, it's a natural one. And the second evolution is more it's more from an architectural standpoint. Um, today CaraDB is only able to deal with a single broker. 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. 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. 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. That's the first limitation. The second limitation is in ActiveMQ, we can uh we can basically spread the load of messages across different set of brokers. That's what we name network of brokers, and we do that using a network connector. 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. And so I think it's where we can think about a new way to implement KDB. And the idea that I've been discussing with the community right now is why not having some kind of replicated KDB? 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. And so if we have one broker falls down for any reason, then another one can have a replication of the first one. So that's it's it's not a trivial thing to do, to be honest. Um, but but I think it's more than welcome. Um, and that's something we are uh discussing with the community. Uh how we we have different experiments ongoing on that, like uh uh should we use uh Apache Bookkeeper? Maybe I don't know. 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. Um, that's also pretty interesting. 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.

SPEAKER_00 6:03

Love it. It sounds like the goal is really just uh to highlight that reduction of infrastructure complexity overall, right?

SPEAKER_01 6:11

Absolutely. I mean, the complexity is on us in inside RTMEs Active MQ, but for the users, it should be uh straightforward.

SPEAKER_00 6:19

Seamless, yes, yeah. Uh so but it makes me think thinking long-term uh and active MQ7, do you see potential big changes from an architectural standpoint? You know, so what would you say are the main differences between ActiveMQ6 and ActiveMQ7?

SPEAKER_01 6:36

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. 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. I I don't want to say issues, but two comments about that first. Um, Spring framework is not an Apache project, it's an Apache license framework, but we don't know where Spring is going. 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. And so regarding that, I would love to consider removing Spring as the core dependency in ActiveMQ. 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. Uh so I would say that the first big change in the architecture internally to the broker is probably removing Spring from the picture. That's the first thing. And the second thing is that's true. Active MQ is today a little like a big monolith. Um basically, uh, you have all the transport connectors extra. 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. But in terms of maintenance, uh there are some challenges. 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. So that's the kind of you know, uh changing a little the internals to facilitate our life of us as contributors. 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.

SPEAKER_00 9:22

Right, removing those dependencies and moving frameworks. That that is uh you know, it sounds like the goal there is to define a major version shift and introducing new core capabilities. It's it's very interesting. Um, I'd like to move on to security compliance because I have some questions. You know, currently ActiveMQ security is is powered by uh JAS and authorization plugins. What are the new features coming around security for ActiveMQ?

SPEAKER_01 9:49

Yeah, that's a great question. And uh I think there are a lot of expectations on this front. Uh the first thing is you're right, I think ActiveMQ is really based on Jazz, the Java authentication and authorization service. Um, and we provide a lot of login modules. So you can use a user priority file, you can use a HELDAP or Active Directory uh as a backend. But we need more additional login modules to be able to integrate into the modern architecture that exists in the organizations. I'm thinking, for instance, OHOD2. Um, and and we have a PR right now about uh adding a new login module, adding the HOD to support, which is great. Um, I did that, but uh but but that's great anyway. Uh and also I'm thinking about new integration layer like OPA, open profile agent. 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. So um my focus on this front is really facilitate the integration of ActiveMQ in modern um security infrastructure that exists into the organizations.

SPEAKER_00 11:17

Sounds like you're we're trying to emphasize that that modernization of authenticity protocols uh or authenticity authentication protocols. Um but for so for organizations in the highly regulated uh industries, finance, healthcare come to mind right away. Um, how do these new security features simplify that path uh to meeting, stringent uh audit and government requirements?

SPEAKER_01 11:44

Yeah, but that's I I think it's the extension of what we talked before. 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. Uh I also I think that a critical piece in this um in this kind of regulated environment. Um I'm in Europe, so I know how regulated it could be. It's uh uh all about auditing. Like you need to know everything that happened into the broker. 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? So I think that integration into the security infra is one thing, it's key, but also considering additional plugins. 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. I mean, we have, for instance, we have one plugin which is named the logger broker plugin. So basically, you can log a lot of activities that happen into your broker, including advisory topics and stuff like that. So that exists. I think it's also an effort about documenting and how it matches with what it's expecting from a regulation standpoint.

SPEAKER_00 13:24

Yeah, yeah. The goal is to connect technical security updates to business compliance value. Yeah. Love it, great. Love it. Uh for operational excellence, though, what's your take uh on ActiveMQ web console? Can you see any evolutions there?

SPEAKER_01 13:44

Um I'm gonna be pretty pretty transparent about that. I don't like the the web console. Um, I don't like the web console for two reasons. 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. Um, so and also is a pretty old web console. So it doesn't look super modern, uh, it's pretty limited. We'd never recommend to use it in production, uh, to be to be honest. So I don't like it. Um and but I mean the only huge benefit of the web console, it's only it exists. That's it, that's it. So it's pretty convenient to use it. Um but but um but but I think that we need something something new. Um, and I think Artemis on this front, they did a great move. On Artemis, they provide uh an Artemis console which is way more modern and providing a lot of interesting features. So my take on the web console is pretty clear. Personally, I would love to remove a web console from ActiveMQ. Uh now the question is what do we provide to our users? Um, I think that we already integrate Geolochia. Uh so we can use Geolochia as a kind of uh backbone to a new web console. So why not uh creating a new web console using React or something like that? I started a I started a prototype around that. It's pretty it's pretty interesting. Does it make sense for our users compared to external web console that exist and are way more powerful than what we can provide? I'm thinking obviously about MeshIQ as a platform. 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?

SPEAKER_00 15:56

Yeah, yeah. It's I mean that that focus on modernization, it's to provide simplified governance and developer experience, self-serve developer experience. Um interesting. Interesting. So for open telemetry though, it's becoming the industry standard for observability. Um, how does the deep integration of open telemetry in this roadmap help teams eliminate that visibility vacuum in complex hybrid cloud message flows?

SPEAKER_01 16:26

That's that's a great question. Um, and I actually you are spot on on something that we should consider and we should do. Um historically, on ActiveMQ, and uh that's also the same for uh Caraf and Camel. We we mostly focus on about JMX. So basically we say, hey, we expose everything like matrix, I mean attributes, and everything through JMX. 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. And and for instance, we have um uh an Apache project to do that like uh uh Caraf decanta. So Carif Decanta, the idea is really putting JMX metrics, log files, stuff like that, and store into Elasticsearch, Cassandra, whatever. 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. 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. 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. 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. 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. We already have a uh a GitHub issue about that, um, so we know we have to do that. 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. So, but uh totally agree with you, that's a great feature, and we have to to do that for sure.

SPEAKER_00 19:09

But it's all about discussing tracing and monitoring across distributed systems, so right. Yeah, exactly. So for cloud native strategy, though, um what are your ideas or what are the ideas about active MQ on the cloud?

SPEAKER_01 19:25

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. Uh the first thing to remember is we have we already have some managed services uh for ActiveMQ. So for instance, if you go on AWS, you can find Amazon MQ, and Amazon MQ is a managed service for Active MQ. So the question is you basically as a user, I have two choices. 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. 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. So today the only thing that we we provide in ActiveMQ is the Docker images. That's great, but that's not enough. 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. 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. So I think that you on our road to the cloud, I would say there are two features we should add. Hem chart, that's gonna happen pretty soon. I think that the hem chart is gonna be available, uh maybe not in the next Actium Q release, but the next one. But I'll I I would also consider the Kubernetes cloud uh operator uh as a welcome feature we should consider.

SPEAKER_00 21:26

Interesting. It sounds like there is a big push to identify those cloud native differentiators. 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?

SPEAKER_01 21:55

Yeah, great question. Um I think you mentioned the user suspension. You know, RTMQ, RTMES, CARAF, Camel, that's all the same, uh the same guys, I would say, in the room. Um, but the good thing is the majority of the communities around those projects, um, they are across several projects. For instance, I'm on Cara on Camel on ActimQ and Artemis. A lot of people from Camel are also on ActiveMQ and Artemis. So thanks to that, we can you know we can uh discuss all together and say, hey, we planned this new feature. What do you think? And how we can leverage that. So um the the the relationship between the communities are really great uh on this regard. 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. And and for me, you're right. 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. And it's where I think that I don't consider it really as a legacy, I think that it's different use cases. 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. If you want to implement transaction and there you have this rock solid transaction, probably messaging and active MQ is way better than Kafka. 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. 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. So why not bringing the gap between messaging and streaming and analytics? 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. That's basically some observability observability platforms that are doing that now. If you take a look about a company like Datadog, Datadog, they are using iceberg to store everything and they can do the query. So I think that by adding new connectors, and we have a bunch of projects at the Apache Foundation like Apache NiFi, Apache Hop. 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. 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.

SPEAKER_00 25:13

Definitely. 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. Um very interesting. Well, I appreciate this. Is the beauty of community uh being able to to chat with you, JB, today. Sure. Thanks so much and great session.