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