RabbitMQ Summit 2018 was a one day conference which brought light to RabbitMQ fr om a number of angles. A panel debate with a selection of guests took place, including questions from the audience.
Check this 40 minutes discussion about the future for the most widely deployed open source message broker in the world: RabbitMQ.
What's new and on the horizon of RabbitMQ
Dormain Drewitz: I think we'll start by having each of our panelists briefly introduce themselves. You've met a couple of them already today. I've got about half a dozen questions and we've got 40 minute. Depending on how verbose people want to be in their answers, there will be more or less time for questions from the audience.
Moderator:
- Dormain Drewitz. Senior Director at Pivotal. (Twitter)
Presentation of panel:
- Gavin M. Roy. VP of Architecture at Aweber Communications . (Twitter, GitHub, Website)
- Dan Carwin. Engineering Director for the RabbitMQ core team, Pivotal. (Twitter, GitHub)
- Karl Nilsson. Software Engineer for the RabbitMQ core team, Pivotal. (Twitter, GitHub)
- Carl Hörberg. CEO of CloudAMQP / 84codes. Twitter, GitHub)
Tell us your favorite and your least favorite use case of RabbitMQ
Dormain: The first question, this comes up a lot with folks initially kind of wrapping their heads around RabbitMQ, is understanding the use cases for it. I'd like everyone on the panel to kind of chime in with their favorite which is like, if the house is burning down and you can only take one use case with you - this is maybe not a good reference to make given what's happening back home in California, for me, but if you can only take one use case, what would it be? And then, conversely, what's the one that just makes your nose wrinkle with like a bad smell? So, favorite/good and bad use cases for RabbitMQ.
Gavin: Well, I'm big fan, as I mentioned before, of the Event Stream. I find that that's the most valuable thing from a business perspective and engineering perspective. Least favorite, sending large, opaque, binary things through RabbitMQ like big images, or videos, or that sort of stuff. It really doesn't like that.
Dan: My favorite use case, I think, is integrating systems written across different generations, in different languages, taking advantage of RabbitMQ’s large collection of various language clients and allowing those types of applications to communicate with each other. My least favorite use case of RabbitMQ is using it as a datastore.
Karl: That was my least favorite as well. My least favorite probably is maintaining very, very large queues and maintaining them for a long time. It's a bit of an anti-pattern. If you're never going to enter them, that's going to be a big problem.
RabbitMQ is such a diverse and flexible tool, it’s very hard to choose a specific use case because it's made for so many of them. For me, the best use case is when your uncertainty is high, when you know you need messaging but you don't actually know exactly what kind of messaging or even what kind of protocols that you actually want to use for your messaging solution. When you're uncertain, I think it's a pretty certain choice that you will be able to do it with RabbitMQ.
Carl: Yeah, I can only agree. We like to see it when people are building big microservice architectures and using RabbitMQ as an event bus or event stream. It's one of the benefits at RabbitMQ that it can support so many use cases, like RPC, while other message queue solutions are maybe more specific, targeted to one-use case.
Worst - yeah, long queue. That's the most problematic use case - having very long queues today. I don't think it's inherently bad using it. But, today, RabbitMQ doesn't scale very well with long queues, unfortunately.
Common pitfalls when using RabbitMQ and features that are overlooked
Dormain: Okay. Well, that makes a nice segue to our next question which is around some of the common pitfalls for using RabbitMQ. And then, just to counterbalance that, maybe some of the features that often go missed. We've kind of heard a couple things today. I already mentioned that seem like potentially good but overlooked features. We're going to work back from the other direction just to just to shake it up a little here.
Carl: What we see as a problem, often, is the memory usage of RabbitMQ. It often comes down to two things, either that you have too long queues, or you have too many connections, or very high connection churn. That's two problem areas for our clients today.
Dormain: And if you were to shine a spotlight on a feature that you think more people should take a look at and “incorporate into their practice”, as a yoga teacher might say.
Carl: Maybe the TTL, like dead lettering and TTL. It's a great feature, if you use it. A lot of customers try to do used delayed message exchange which is not great because it stores all the delayed messages in MNESIA. It's on a single node. It's all problematic. And zero introspections, you can't see which messages you are delaying or how many messages you have delayed.
We typically recommend using TTL and dead lettering. You get much better introspection etc. But, if you do it on a huge scale, like some clients, then there's some problem areas with that too. But that's if you're dead lettering tens of millions of messages at the same time.
Karl: Right. Okay, well I was really pleased to see a talk on the consistent hashing exchange. I think it's underused. I think that's a really, really nice plugin and it's with some nice improvements of in the latest version as well. That's good.
I think, for me, casting my mind back when I actually used to use RabbitMQ rather than develop it, over-reliance on RPC-type patterns is something I found a little bit not helpful. Sometimes, you have to do RPC. Sometimes RPC is a very important thing. You need a response and you respond from your web app or whatever.
I saw people building applications using RPC as a default means. Whereas, a more asynchronous pipeline-type of pattern would’ve performed and done a much better job. I guess, that probably is my contribution.
Dan: Let me start with pitfalls because I've watched all the support escalations come in. RabbitMQ has a lot of guarantees - message safety features. One of the largest pitfalls that I see is customers turning them all on and using them all at once. When you read the documentation, you see things like HAL. It's very attractive.
The pitfall is overuse of guarantees without the realization of the cost - performance-wise, and complexity-wise, and stability-wise on these. For example, just mirror those messages which are truly critical. If you're setting up a two-data center implementation, just replicate only those messages that you absolutely need to be in that second data center, if the first one goes down.
I guess, in terms of underused features, I'm a fan of the event exchange which can be used by people to see what has gone on previously. It's valuable in troubleshooting scenarios. I'd like to see people use more of it.
Gavin: Stop using Celery, things that that are problematic. I think relying on frameworks that abstract away what you're doing and understanding the tool that you're using is bad. When you have a hammer and everything looks like a nail, it's really easy to write code against something like Celery and not understand the ramifications of the things that you're doing. So yeah, there is that.
I was actually surprised in reviewing for my talk. The RabbitMQ team this is prolific and has been for some time. Staying on top of what features are there is hard. I don't know why. I wrote a book on RabbitMQ and, for some reason, I missed the fact that there was this automated reply-to mechanism that doesn't create a queue for your RPC publisher. It just directly sends the replies to it. It blew my mind. How did I miss that? I don't even know what version that came in at, so there's that. Hunting through their extensions is something I would recommend doing.
How to scale RabbitMQ
Dormain: All right. My next question is kind of around scaling. There's lots of dimensions to how to scale RabbitMQ. We had an interesting discussion in our prep call on this.
And so, if there is one thing that you could change about the way RabbitMQ scales, what would that be? But then, on the flip side, if there was something about how it scales today that you would absolutely keep, what would that be?
Dan: The one thing that I would change about scaling RabbitMQ today is the fact that the management plug-in, the number crunching for the statistics that you see in the management UI takes place on the same nodes that does the message processing. If I were able to do it again, and we may do it in the future, is to separate the management interface from the actual message processing. So that, what happens today is, if a node slows down for whatever reason, you can't get management information from it which really impedes your ability to work on it. And it also can limit scaling in an absolute sense.
I'm not sure. I'm not really prepared to answer the other half of the question, “What would I absolutely keep?” I'll pass to Karl and let him cover me on that one.
Karl: Thanks, Dan. That's very helpful. I'm going to answer the same question that you managed to answer.
It's kind of related because scaling out the management data would be effectively adding a new kind of type of node into your RabbitMQ cluster. I think, something I'd like to see at some point in the future, and this is completely on the top of my head now, is being able to have nodes of more different types so that you can scale maybe in different ways, depending on your use cases.
Say, for example, you have nodes that only kind of handle connections at the front. You could scale them independently of the nodes that serve the queue data, for example. That might give you more flexibility to scale RabbitMQ in ways that you're not able to do at the same degree now because, if you add more RabbitMQ nodes, you will replicate metadata across all the nodes more and declaring queues will become slower with the more nodes you add and things like that - writing to the database.
What was the other one? The one we’re trying to avoid.
Dormain: What you would keep.
Karl: I think, at the moment-- and this would just be kept by default but Erlang, by default, scales up very well, so getting bigger boxes, getting faster boxes with more pause - more processes is a good way. It's certainly something that would remain as long as what's written in Erlang’s.
Carl: Yeah. That's typically how we scale up our clients, to give them larger and larger boxes. I think we have some that are running on over a hundred cores and a quarter terabytes of RAM etc. And Erlang scales very well, in a single machine. The problem with scaling horizontally, for many of our clients, is queue location - to spread out the queue leader between these nodes. When a node disappears, not moving that leader node etc. that's a bit problematic today.
Gavin: I'd agree on the the problematic side. I'm actually quite excited for the Raft-based queues because I think that that could potentially help in that area.
But rebalancing queues, I see, is a big problem from a scaling perspective. In fact, I had a production issue, about a month ago, primarily focused around two things. One, the management interface not responding and it was because too many of our high-volume queues were sitting on the same node of this particular three-node cluster.
What would I keep? I think, one of the really strong features that RabbitMQ has from a clustering perspective is that my clients can connect anywhere in the cluster and talk to any resources without concern about locality. While locality is important in really high throughput performance clusters that flexibility of being able to enter the cluster from anywhere and do whatever it is I need to do, I think, is very powerful.
Things to look forward to in the RabbitMQ roadmap
Dormain: Okay. Michael went over a lot of the roadmap earlier this morning. We'll start with Karl on this one. What are some of the things that you're looking forward to the most, in terms of the roadmap?
Karl: I'm really looking forward to getting the quorum queues out. It's something I've been heavily involved with. I think it's going to be interesting, seeing how people use them. They’re not, by default, a drop-in replacement of your classic queue, or your other queue, or High Availability queues, or mirror queues but they are there for a very specific use case - when you really need data safety and replication. We've designed them as such. I'm really looking forward to seeing how that pans out.
Carl: I'm really looking forward towards the churn statistics that you're providing in 3.8 because that's something we are monitoring today in a kind of crude way through the Event Exchange. It's a bit annoying to have a separate application that collects the churn statistics because that's a big problem for a lot of our customers.
Dan: I am looking forward to something a little bit further on. I think Michael may have discussed this as I slept through his talk this morning. But it has to do with the loosening of our adherence to the 0.9.1 AMQP protocol in introducing native processing for additional protocols which could speed up MQTT traffic, for example.
Gavin: All of the above. I know that's kind of cheesy but I think the quorum queues are going to be huge, getting those statistics are going to be great. I think moving away from the AMQ model at the core RabbitMQ, from a long-term perspective, is really what's going to ensure RabbitMQ’s longevity. I'm excited about that as well.
Will RabbitMQ grow beyond AMQP?
Dormain: That sets up our next question well which is about kind of following on, on your talk, Gavin, how RabbitMQ’s modeled around the AMQ with its adapters or translators. Looking out into the future, and we've kind of touched on what's on the roadmap there, does it grow beyond AMQP? Do we need to change the identity completely? How might we get there? What are some of the different paths?
Everyone wants to weigh in around that but we'll start with you, Gavin, since I know you have strong opinions on this.
Gavin: Sure. Probably, my most controversial thought around that is I'm not a fan of AMQP 1.0. I think that the committee that made the protocol did a disservice by abandoning 0-10. I think that the AMQP spec should be forked and the broker implementers out there should somewhat come together and figure out “How do we extend what's there?” because, like I said, it is extensible. RabbitMQ is proof in the pudding. I think that there are small things that can be done to make the protocol better in the long run.
Outside of that, I think finding ways to support things like gRPC, or HTTP2, HTTP3, from an interface perspective, gives it a place in what I'll say is current state-of-the-art hipster programming and that's always good.
Dan: When I work with customers, I talk with customers that use various messaging types. They love RabbitMQ. To go back to MQTT, for example, they're not able to effectively use RabbitMQ for their MQTT processing because of the overhead of the plug-in system where we have to translate those messages. I'm very much looking forward to a time where we can remove that layer of translation, give native processing speed, but still make available the routing logic - what we love about 0.9.1, and allow that to be leveraged by messages which are sent into the broker with other protocols.
Karl: Yeah, very similarly on the same point, I think things like exchanges, bindings, queues, vhost - all those things are very much part of the RabbitMQ model, not just part of the AMQP 0.9.1 model. I think, it's pretty safe to say that they're going to be around for a very long time.
But how we transfer messages from one point to another, I think, there's opportunity there to do better than we are doing at the moment. There are protocols that do better and have more flexibility, more flow control at different levels of the message transfer. The first step to get towards that, as we already mentioned several times, is to make all protocols more equal in terms of how they interact with queues and exchanges, inside of RabbitMQ, and not pay that extra cost that the additional protocols are at the moment. Once we've done that, who knows, what's the best protocol to actually be the primary protocol, if there's going to be such a thing.
Carl: Looking at other protocols, to support horizontal scaling better, I think the clients have to be more cluster aware - aware of all the nodes. AMQP doesn't really have support for that today - AMQP 0.9.1. That's one way.
I think some areas in AMQP protocol could use some improvements like the connection establishment processes 8, 9 packages back and forth, huge delay in setting up a connection. Even more, if you have TLS. Essentially, I really like the model of exchanges, and routing keys, and everything. It makes the protocol very extensible. And yeah, it is extensible, adding new features to the protocol without having to redefine the protocol itself is great.
How to mitigate complexity when RabbitMQ starts supporting more protocols
Dormain: Okay. Some of these ideas would potentially introduce a lot of different challenges in terms of maybe adding more complexity in other areas. How might you think about mitigating some of that as you try to move forward with being able to support more protocols natively?
Throwing in a curve ball question that wasn't on the list. It's really for anyone. I won't make everyone answer.
Gavin: That's kind of interesting because when you think about it, whether you're talking about JMS, or STOMP, MQTT, the identity of how those protocols behave are fundamentally different than the AMQ model. As you move away from that strong identity, do you lose functionality that we gain from AMQ with, for example, you have a lot of customers talking about MQTT. You guys maintain and work on Mosquitto. It's like, how do you think about the differences of that? It seems like that would be a difficult bridge to cross.
Well, just in the model differences and the way that we think about topics or the native type of behaviors. It's hard. It almost seems like you have to say, “Yes. RabbitMQ supports MQTT, natively, in the way MQTT works and we provide a bridge so that you can talk to it with other protocols.” Even if those are first-world citizens, you still have to kind of have that terminology or data model difference. No?
Carl: Yeah, like today, the MQTT adapter doesn't support Quality of Service level 2, for instance, and some other limitations. That is hard to implement with the current adapter kind of thing. It's it's not fully protocol implemented.
Dan: We've had to go out on a limb in some cases in the way that we've implemented authentication and authorization on top of MQTT because the protocol doesn't include these areas and customers demand it, so this is where we we hang ourselves out a bit.
Karl: I think, actually, removing the kind of the hard dependency on 0.9.1 would simplify things, if anything. The protocol that you have internally, inside RabbitMQ, from the time that whatever protocol is has been passed in terms of how they interact with the queue would have to be generic enough to support multiple protocols. I think, there's always going to be a potential for some loss of fidelity or some part of the protocols that you can't support but I think we can do a better job without being tied to the 0.9.1 model. I think that is a simplification in itself.
Carl: Another thing is that RabbitMQ tries really, really hard to not write messages to disk. It tries to cache it. Sadly, when it runs out of memory, it has to write it or offload to disk and then you hit the wall, basically, or clients do - they're publishing fine in 20,000 messages a second. And then, suddenly, 200 messages a second.
I think it could be possible to just write the messages to disk and not fsync them but let the OS do the caching, the whole file system caching layer. Maybe that could simplify things. Maybe RabbitMQ was built in a time where the hard drives were much, much slower than they are today. SSD drives are much better today than the disks were back in 2008 when RabbitMQ was developed. That focus on keeping messages in RAM, maybe is a bit unnecessary today.
What do you love about the RabbitMQ community and what would you like to change?
Dormain: Okay, so my last question before I open it up to the audience. We're sort of between y'all and lunch which is very dangerous place to be. Is really kind of around the RabbitMQ community, that's one of the things we've kind of gathered here for today.
Again, to kind of have a balance, what do you love today about how the RabbitMQ community works? We've heard some examples throughout the morning in terms of the extensibility through plugins and new languages that are supported for those. But then if there's, conversely, something you could change about how it's working today, what would that be? A little bit of each.
We'll start with you, Gavin. You look like you're ready to go.
Gavin: I think the mailing list, actually, is an example of where the community shines. I think that whether its users helping users or the RabbitMQ team putting up with the repetition of the same beginner questions, I think that that's really cool.
I think that, as a community, we could do more to better onboard people from that perspective. In that, I know at least from maintaining client libraries or trying to support users, the questions are always the same. The problems are always the same. There's only so many times where you could say, “Hey, can you go back and learn how to search on Google before you ask this question again?”
I think a lot of that goes to how you onboard people. While the RabbitMQ documentation and examples have gotten us this far, I definitely think that there are things that we could, from a community perspective, that makes it even more approachable.
Dormain: I think, if you can solve the “Did you try googling that?” question, you've solved something across many communities and professions around the world.
Gavin: There are other communities that, from an onboarding or documentation perspective, don't have as much of it. It's not such a high percentage.
Dormain: Just to check in here with folks. How many folks here are on the mailing list? So, to kind of attest to what Gavin says about. Okay. So those of you without your hands raised, you might either be suffering from a rotator cuff injury. I know that those are rampant whenever there's a gathering of people but, obviously, something to check out because it seems like good stuff.
All right, Dan.
Dan: Yeah, this this question gives me the opportunity to express thanks to CloudAMQP/84Codes and to Erlang Solutions for putting together this event. This is an example of open source community working. We talk about, sometimes, there are scandals where you have one set of people writing the open source code base, another people “exploiting it.” Well, we have a community here where we have mutual investments. We have companies supporting each other and covering bases.
I'm also constantly impressed by the contributions we get from various members of the community - contributing code, bug fixes and so forth, going through the CLA process. That's the measure by which I can see that we have a healthy community as opposed to other companies who do all the coding themselves, get no contribution. We have a very lively discussion. We have a lot of people contributing.
I'm grateful that my team is so responsive to questions from both beginners and experts alike. We work very hard to be ethical when it comes to debates online and to maintain the high road, to not attack other open source code bases or commercial code bases that we may be overlapping or in competition with. I take a lot of pride there.
I think RabbitMQ came from a very developer-oriented mindset when it was incepted. One of the things that makes RabbitMQ special is all of the ability to configure RabbitMQ is available through the developer API. There wasn't this separation of church and state where you had operators and developers. Developers could configure the system as well as attach to it and send messages and receive messages from it. What that meant and what we've built up as a legacy of developer-oriented documentation and so forth.
What I see, today, in the arena of hosted cloud computing is a greater increase of operators who don't come from a developer background. I'd like to see us, as community, move toward creating documentation, tutorials, education services that serve these operators who are responsible for RabbitMQ but really don't need to or aren't deep into the APIs and the interfaces. They don't know where it may fall over.
From a support perspective, this is the group of people that often steps over into a trouble area and then we have to re-walk them and say, “Well, look, you've turned on all your message guarantees and that's why it's slow.” Things like that.
Dormain: Well, thank you to anyone here in the audience who's one of those community contributors that Dan mentioned. This is great work that you're doing.
Karl: Yeah, that was really good, Dan. I don't know how I can follow up on that but I think RabbitMQ wouldn’t be very much without this community. It's kind of what drives it. It's where we get all the feedback from. The mailing list, obviously, we get a lot of early feedback which is very important. We also get other other feedback channels but they tend to be slightly slower.
I think we could probably do a little bit better in terms of exposing best practices through the APIs at some of the libraries and tools that we provide, I suppose, and kind of help people fall into the right patterns rather than kind of having this very big flexible open model which you have to learn very thoroughly and make mistakes and then correct them.
Carl: One question, is the RabbitMQ.com website, is that like on a public repository that they can contribute to? Okay, good. Because one really big thing about RabbitMQ is their website and the tutorials there. I think that's one of the many big drivers for adoption that it’s so easy to get started.
The other one is the management interface. The management interface have some drawbacks but it it's better than most other management interfaces for most other kind of servers. It gives great inspection and everything.
I guess, for us, we provide our own. We provide guides and everything on our website but we should certainly try to help the RabbitMQ.com too because that's a big portal to all new RabbitMQ users.
The mailing list is great. We tried to provide bugs and things that we find there. We're trying to set up these events. There's probably going to be more events in other parts of the world to bring more people together. We're trying to do our part in this.
Questions from the audience about RabbitMQ
Dormain: All right, I'll open up to the audience to see if anyone else has any questions for our esteemed panel, whether you want to hear the full gamut of answers or just targeted questions.
Running RabbitMQ in Docker and Kubernetes
Felipe: Hi. It's kind of an opinion from you guys. Just to let you know, I'm an instructor. I think I'm the only two left from the Pivotal - only two, but always we've been asked something like, “Hey, we're getting into this kind of a container-based stuff and sometimes it's like, “Ey, don't do too much like a docker” because you're increasing, you’re scaling up - scaling down, and we already know that the MNESIA database is very fragile at some point. So far, most of our clients, they are still doing virtual machines - virtualization only. What are your thoughts about kubernetes and put RabbitMQ inside docker containers? And if at some point - I mean, right now we've been kind of taught that docker or containers are ephemeral at some point and they're going to crash. And so, we try to recover from from a docker instance on RabbitMQ. It could be kind of painful. I don't know your thoughts about kubernetes and actually support RabbitMQ there.
Gavin: I think you can do it. It's not ephemeral. Just because running in a container, that's just isolation. Kubernetes is going to provide orchestration. There are safe ways to do those things. There are safe ways to use auto-scaling groups in Amazon.
Using containerization or auto-scaling groups to scale on demand, up and down, that's not a good idea. But for having golden image deployment of RabbitMQ where you know that you don't have to worry about the configuration management aspect of things as much or you don't have to worry about artifact differences that's great. Those systems are really good for that.
Dan: To go back to the community reference, we're very fortunate that RabbitMQ is popular enough that there are open-source distributions of an official docker image, a Kubernetes image today. Thankfully, we don't have to own or maintain those.
That being said, we are continuing research internally in an R&D sense looking forward. Can we enhance these? Can we make a Pivotal-branded commercial version that includes value-added features? And so, we're doing research in these areas. Possibly, in the future, we will have Pivotal branded version of RabbitMQ, on Kubernetes, with extra features that make it more resilient, easier to deploy templating, etc.
Carl: If you are not a heavy RabbitMQ user or not using your RabbitMQ user heavily, then you can put it in a Docker instance with a lot of other Docker instances on the same machine. But if you're running out of resources or resource contention, a lot of apps doing a lot of I/O, then your RabbitMQ will suffer and it's just harder to diagnose and see like, “What is it that's using up all these resources? I wouldn't put my big database in a Docker instance, for instance. I guess, you can do it but I wouldn't do it. Neither would I with RabbitMQ.
Elixir and RabbitMQ
Dormain: Thank you. Any other questions? We have a couple more minutes.
Participant: You mentioned something about how good is the community. One community that’s been growing a lot recently is the Elixir one. Do you think, in terms of adoption for future of Rabbits, it would make any sense to build some specific modules in Elixir to try to attract new community members?
Karl: How would that help? I guess, is the question. RabbitMQ is an Erlang application. It’s 11 years old. It’s been Erlang for a very long time. The core of RabbitMQ is Erlang. Elixir fits very well in it, as we've seen today. Once you get over the initial hurdle, which is a learning curve thing anyway, it's perfectly possible to write plugins in Elixir and to run code inside the Erlang VM, written in Elixir, but surrounded by Erlang. I mean, it's all the same, really.
Our CLI tools are written in Elixir, so we already have Elixir in the code base. We haven't really seen a massive increase of Elixir developers actually contributing to RabbitMQ. It’s like, to the core, RabbitMQ is quite hard anyway. The difficulty is not necessarily in the language, it’s understanding how RabbitMQ works internally and what's actually the tradeoffs and why it’s done the way it is. From that point of view, I don't know if driving specifically fitting Elixir into the codebase would gain as much, necessarily.
Dan: From one perspective, having the core team write demonstration Elixir plugins might be beneficial. As tutorials, we could consider that.
Another thing that I think we can do is keep our eyes open to good Elixir plugins that the external community develops and make sure we promote those on the web page that lists plug-ins and so forth. It's challenging sometimes when you list something on the website, it's a tacit endorsement of that. And so, you only want to list solid ones - whether it's a partner, a plug-in, or a language client. We have to do some filtering without being too arbitrary. That's certainly something that I'll be more aware of looking forward is, what can we do to encourage Elixir plug-in developers and to take that into account as we go forward.
Participant: Maybe, just adding a bit on top of that. I wrote some plug-ins in Elixir. I strongly advocate trying Elixir for writing plugins but I would really personally be against trying to adopt Elixir within the core platform because one of the most important thing, as a developer, when you're approaching a code base is consistency in the code style as well as the language itself. I would really not like to have to understand a code base which is written in two different languages. My head would really start spinning. Even if I'm familiar with both languages, let's stick the core to something and then use modular design for the rest.
What is the real future of RabbitMQ?
Participant: Looking at RabbitMQ and the AMQP 0.9.1 and then going towards what's happening on specific environments like Microsoft and using AMQP 1.0 and speaking earlier about a more generalized internal usage of a more general protocol rather than 0.9.1, do you see that is where RabbitMQ is moving towards, in the sense that everything in 0.9.1 is built around exchange, binding, and queue? What do you see the real future of RabbitMQ is?
Karl: Are you talking about the future of RabbitMQ in terms of its internal architecture? Okay. Yes, definitely. Having Michael, in his talk, refer to as a protocol agnostic core is definitely somewhere we want to go because it will bring us a lot of benefit and it will simplify things internally as well which, I think, is really important when you really want to kind of, firstly, guarantee performance, stability, and things like that. The simpler things are, the better you can do with that. So yeah, I think we're definitely going towards that.
As I said earlier, I think things like exchanges, I think, is part of the RabbitMQ model. Exchanges, there's so much built on top of them. There’s so much functionality that is enabled by exchanges. With vhosts, that's an important thing for people who want to partition things like permissions and applications. I don't think those are going to go anywhere but, as I said, how we transfer messages, what protocols we support, I think that's possibly where the future development would lay but that's all in the future.
Gavin: Maybe to elaborate on the question side of it, when you look at, for example, the management interface and you look to get a message or publish a message in there, what's happening underneath the covers is there's an AMQP client internal connection that's made. Is the idea that that somewhat goes away and instead we we start talking about, I don't know, the queue as a first-world citizen object that is bypassing the protocol to communicate with it and, instead, something more Erlang-y? What's the thought there?
Karl: I think it needs to be discussed [laughter]. But if it's possible and it's simpler, why not?
Dormain: All right. Perhaps, on that note, we'll thank our panelists, thank the audience for all your questions and participation. As we head out to lunch, just now you know their faces and you can pepper them with questions in the hallway. Thank you.
[Applause]
