How we managed to save $44,000 annually by replacing Slack with Rocket.Chat

Google Talk, Jabber, Slack, WhatsApp, Telegram, Zulip, Rocket.Chat, Selectel Chat… We are not rating messenger services, rather describing our journey to the ideal corporate tool.

You could also benefit from our experience: we changed our criteria several times and managed to successfully switch to new technological waves.

First there was Jabber

Selectel’s first corporate messengers were Google Talk and Jabber. We had been using the Google ecosystem for handling our emails and documents since the company was founded; GTalk was tightly integrated with the email service and made it possible to exchange messages using the Gmail interface directly. However, GTalk’s major drawback was the lack of group chats and integrations.

That’s why we quickly began using Jabber for group communication. Using Jabber, we also implemented a range of integrations with monitoring systems. *However, they were not particularly efficient, and required a lot of work on implementation and maintenance.

Welcome to Slack

A few years later, we had to think about changing our corporate messenger. From the technical point of view, however, Jabber was a perfect fit. But its mobile clients were out of date. As a result, we started having issues related to setting up and connecting employees that were not working directly in IT. Setting up Jabber without assistance was not a simple task for our accounting specialists, for instance.

At the same time, WhatsApp and then Telegram emerged. They were a lot more convenient to use than their predecessors. We very quickly discovered that virtually all the correspondence between our employees was carried out via Telegram, while the official corporate Jabber had been forgotten. Was this what we wanted?

To prevent potential data leaks and provide a uniform communication environment for all employees, we considered transitioning to Slack. This service seemed attractive because of its ease of use, centralized administration, as well as the option to integrate it with monitoring and incident management systems. The service also offered a stable mobile app.

What changed thanks to Slack

• From then on, all employees were automatically assigned an account with all their colleagues added when they started at the company. This made onboarding much easier, and also allowed for making mass announcements when necessary and collecting feedback.
• Any event, whether from monitoring systems or directly from devices, was immediately sent directly to the messenger of the respective employee or department. Infrastructure incidents were immediately communicated to all employees so that they can take the necessary actions.
• When collaborating on documents in Google Docs, Slack notified about any changes made and drew the recipient’s attention to them.
• Eventually, various bots managed to “sneak” into Slack, including our own HR bot, which made it possible to book meeting rooms, obtain information about salary payment dates, and simply chat with the “artificial intelligence” when you got bored with people.

Looks like we need a new messenger!

• The corporate messenger is an important tool that must be very reliable to ensure continuous operation. We had several issues related to Slack’s availability from Russia, both because of the service’s own failures and Roskomnadzor’s tricks (the Federal Service for Supervision of Communications, Information Technology and Mass Media).
• We expect the messenger to ensure privacy and security. However, when it comes to Slack, as with any SaaS solution, you never know how secure it is in terms of exchanging private data and confidential messages. That’s why we had to search for other communication tools for our most critical business issues.
• The number of company employees is growing gradually, now reaching close to 500 people. The Slack platform rates had also been growing slowly but steadily, costing us approximately $44,000 last year.
• One issue with Slack is related to Russia’s Federal Law No. 152-FZ “On Personal Data”; Slack does not comply with the requirements of this law, and stores all data outside Russia. In general, all western services do the same and only Linkedin has been blocked so far, but it still creates an additional risk

Taking all these factors into account, we opted for a messenger hosted on Russian servers. Developing a new messenger from scratch did not make sense, as there are plenty of Open Source solutions that can be modified and improved by our own developers, if necessary.

The first option we considered was the Zulip platform, which is used as a corporate communication tool by Dropbox. The platform became available under Apache 2.0 permissive free license after Dropbox purchased Zulip in 2014 and published the source code on Github. Written on Python and using the PostgreSQL database, Zulip can be easily integrated with virtually all popular systems. In addition, it supports a wide range of various services and Zulip clients are available for all popular mobile and desktop platforms. However, during testing, we found that the solution was slow and had an unfamiliar and complicated interface: streams are divided into topics, and the topics contain chats. At the same time, we wanted the simplest and most seamless transition from Slack.

Rocket.Chat was the second option we considered. It was released under the MIT license. What we liked most about Rocket.Chat was its functionality and interface, which are very similar to Slack’s and also allow for creating public channels, private groups and discussions, and exchanging files, audio messages and video messages. Rocket.Chat undergoes continuous improvements, which is confirmed by a large number of Github commits.

After analyzing the pros and cons of different platforms, we decided to switch to Rocket.Chat, with Zulip as a fallback option in the event of serious issues.

The migration process

The Rocket.Chat server application is written in JavaScript and uses MongoDB as a database for storing messages. Therefore, we had to ensure the resiliency of our database. MongoDB features an out-of-the-box replication mechanism for failover; we deployed three small virtual machines in different regions and set up the Replica Set mechanism. The application’s architecture makes it possible for us to provide it with information about all replicas in the set, while the application itself distributes the workload between them (which replica to read from and which replicate to write to).

For server deployment, we use the official Docker image of Rocket.Chat published on DockerHub. The application runs on three instances on individual physical hosts and is controlled by means of Kubernetes. The load on the pods (running container sets) is also balanced by Kubernetes, not only to ensure proportional utilization of resources, but also for carrying out updates without shutting down the service. In this case, one of the pods is shut down correctly while processing all active connections, while a new pod with the updated version of the application image is launched instead. In addition to easy updating, this approach makes it possible to scale the system out with a single click when the load increases.

We should also mention one important feature of Rocket.Chat. By default, the application stores all the files sent in chats locally, and not in the database. This is why shared storage is required when you need to operate several application instances. In our case, we used our own S3-compatible cloud storage and set up access to it for all application instances. As a result, all the application instances can store files in the same location, which has not become a potential point of failure, since all the data in the cloud storage is replicated in the N+2 mode.

Selectel Chat

As a result, we had a secure corporate messenger, resilient infrastructure and the option of scaling out. At the end of last year, the entire company migrated to the messenger.

During real-life testing (on our own system), we liked the resulting system so much that we even decided to develop the Selectel Chat service on its basis and make it available to customers. More than 20 companies showed interest during the first quarter. We continue to experiment with the product, recently adding videoconferencing (which means we can also abandon Zoom in the future as well).

Now the company is presenting Selectel Chat to a wider audience. We offer special terms — the price for 1 user is 40 times lower than that offered by Slack.