Sorry for the delays, I had a little bit of technical difficulties.
My name is Floris van Geel and since 2010 I'm an open source enthusiast and since 2014
I joined my first FOSDEM as a speaker. After that I became an open source, cross open source fanatic.
So I really really love and appreciate when different open source projects come together
and they strengthen each other's power. And for Rocket Chat I'm a community liaison so I
help to engage with community and support and so forth. So let's get to the chase,
while we're here, skating open source real-time and messaging systems for the millions.
It starts off with what is Rocket Chat? Who here knows what is Rocket Chat?
We see a few hands there, like half the room already knows it, so that's great.
Lots of engagement. In general people know about this side of the story, which is like team chat,
like you know from Slack or Teams if you use that stuff. There's different order variants,
also open source. The cool thing about Rocket Chat is that it is not the master of chat,
that it wants to control all the chat. No, it wants to include as much different chat services
as possible. Thus if you look up there is army channel, imagine you have like a company with
support or sales offices and those have clients and clients they don't want to install yet another
thing on their phone. No, what they do, they have email, they have SMS, they have WhatsApp,
they have WeChat, they have whatever telegram you name a few, so I'm not commercializing one of those
and it will connect via an app to the army channel, meaning that the people in the backlog
who have to process that, they can directly route it and solve the issues. On top of that you can
add bots with BotPress or Rasa and that help to automate the task of the people doing those
great chores that make business. Since version five there's the option with the metrics to
federate, not just to another Rocket Chat, but also to other home services. So it's not longer like
we're on an island sitting and please come to us and chat with us. No, actively federating and
working and collaborating together, all of us. And then as an extra source on the cake,
Rocket Chat has a very extended API, not just the normal service calls that you know for
creating users and so forth. No, it also has a real-time API, which means that inside your app
or game you can directly engage with the message flows and with the chat. Then when it comes down
to voice calling, Rocket Chat is agnostic, it's not part of the court, we support mainly the chat,
so for voice calling you can make your choices. You can use Jitsi from out of the box,
you can add Big Blue Bluton or if needed for corporate reasons, teams or Google or a few others.
So that's about Rocket Chat. Now Rocket Chat is built like many other software architectures as a
monolith, meaning that it is one service that's supposed to do everything and that is pretty nice
if you have a medium-sized organization. Except when things start to scale, you get running into issues.
So it's based upon MongoDB, that's important to know. Originally it was built in Meteor because
at the time it was the best and fastest and most efficient route of making a real-time chat service.
So this monolith, you can scale it horizontally by adding more and combining more monoliths,
which obviously has an extent and you cannot reach beyond a certain point of users.
So what Rocket Chat did after version 5 going into 6 is re-architecting this monolith into a
microservices architecture. You still have the same MongoDB cluster, but on top of that there is
different services, like authentication and presence and the actual chats. Those get divided
and they can fail individually and be restarted individually. So you don't have a dependency
that if one little thing breaks that your whole system is down. And on top of that it has the ability
to keep on scaling this way. In order to change this architecture, a new library was chosen.
In this case it's called molecular and there is alternatives on the market, but due to functionality
and exchange of libraries and code, this module was chosen. It's MRT license, extensible,
and its most important part is this part here. We want to use nuts, but it can also work great
with MQTT and other messaging brokers like Kafka. Furthermore, there's many adapters, caching and
extra great features to add upon. So in this re-architecting, this molecular was the primary
choice. Why is that? So there is options which are actually faster. You see here there's one Cote,
like faster, but the difference is between having your remote actions, remote calls,
and your internal call. Oh no. Next cloud is acting up. Sorry for that.
Right. And then go back to this one.
Right. Still solid. The cool thing about molecular is that you can change between these
remote and local actions and you can switch them within a proxy. And due to this flexibility,
that's the reason why this is chosen as the primary driver for the architecture
of microservices. And then nuts is pretty straightforward. I imagine that most people
in the room have heard about nuts as a standard. It's open source Apache tool, very modern, fast.
There's very different ways of implementation examples. And the main downside is that it doesn't
support Qs and that is solved by inside the Mongo Q runner that will take over the division of those
Q tasks. And that has also great advantages due to using these libraries. It is possible to make
interactive extensions for developers. And that's also something that we've been facing with
coming from Meteor to React and TypeScript for the apps is that it's much easier for
modern days developer to adopt the software and thus the community has more impulse for growth.
Put that about that. Perfect. Two minutes left. So in results, if we look down, this one is the
monolith. It's built on 4K concurrent users due to the fact that that was the maximum that it
could hold and could serve. And doing so, it has usage of 12 gigabytes of RAM as well as 15
virtual CPUs on this Amazon instance to test it. And for the new architecture, the microservices,
it could hit over 50K with ease. But for making the tests equally, the test was made with 4K
concurrent users. And then you see that the load on the CPUs and the usage of memory is actively
reduced. It's only using three CPUs and five gigabytes of memory to perform the same amount
of volume of users who are actively chatting. So if you want to learn more about Rocker Chat,
this is our main place where we communicate within the company. It's open.rocker.chat.
And it's open for community. It's open for support. Everything happens in one place.
Sometimes there's a little bit of an earthquake due to some updates or a new version which is
deployed. But within 30 minutes, that's all okay. That means that we take our own pain and
thus not leave the pain at our clients. And the project itself, you can find on GitHub.
And if you get up one little bit up, there is many different implementations and add-ons and
libraries that help you to integrate Rocker Chat within your applications, as well as connect
with these APIs and its services. I still have 30 seconds left for questions.
But my question is, you mentioned I seem to recall that not that long ago, you guys announced
that you're using Matrix as a protocol. What would you say if someone was thinking about
choosing one, like what does Rocker Chat add on top of what Matrix provides?
Yes, I've had this question many times at the booth and it's pretty easy to answer. So what is
the added value of Rocker Chat compared to the Matrix because the Matrix is already really,
really great if I translate it correctly. And that is actually within tech savviness.
All of us here at FOSDEM, we're all so-called nerds or geeks or very technical people that can
take this Matrix and make it work. And specifically if you look at marketing or sales or other roles
that are not so tech-savvy, it's much easier to use Rocker Chat, specifically with the omni
channel and engaging with the customers. UI looks a bit like Slack, however, it's more slick and it's
faster. So it's easier to adapt and that would be the incentive to say, okay, go for the Rocker Chat.
If you have a tech-savvy organization and you want to deep dive and include
WebRTC and have all these components under your own control, go for the Matrix.
Both have on-prem possibilities, data interoperability, security, and to-and encryption.
So that's not the real cause for making this decision. Any other questions?
Okay, then I thank you very much for attending this late at the last slot. And if any question
pop-up, feel free to join Open Rocker Chat, contact me, contact Duda, contact Gabriel,
or anyone that is within there. Thank you.