Bursting und Throtteling in OpenStack

Wir haben die vergangenen Monate genutzt, um eine neue Cloud mit OpenStack aufzubauen. Im Zuge dessen, mussten wir eine Möglichkeit finden, die IOPS sowie die Bandbreite, die VMs zur Verfügung haben, zu limitieren.
Das Limitieren der Bandbreite sowie der IOPS erfolgt in OpenStack in sogenannten Flavors. In einem deutschsprachigen Interface von OpenStack werden diese “Varianten” genannt. Flavors werden hier als VM-Templates genutzt, mit denen sich VMs starten lassen. Es werden hier Ressourcen geregelt wie RAM, CPU und Firewallregeln aber eben auch die Limitierungen. Gesetzte Werte können nicht in laufenden VMs überschrieben werden. Möchte man diese ändern, muss die VM gelöscht und neu gebaut werden, nachdem die neuen Werte im Flavor angepasst wurden. Ein Rebuild reicht hier nicht aus.
Hier gibt es jedoch eine Ausnahme. Durch den Einsatz von beispielsweise libvirtd, können jene Beschränkungen mittels “virsh” angepasst werden.

Was sind IOPS und Bandbreite?

Bandbreite und IOPS geben an, wieviel Datendurchsatz sowie Lese und Schreiboperationen einer VM zugeteilt sind. Per Default sind diese unlimitiert, was unter gewissen Umständen zu Problemen führen kann.

Wieso sind Limitierungen sinnvoll?

In einer Cloud mit mehreren Virt-Systemen laufen mehrere VMs. Sind keine Limitierungen gesetzt, kann jede VM soviel Traffic und IOPS erzeugen, wie sie gerade braucht. Das ist natürlich für die Performance entsprechend gut, jedoch verhält es sich dadurch so, dass andere VMs auf dem gleichen Virt entsprechend unperformanter werden. Limitierungen werden daher dazu genutzt ein gleiches Niveau für alle VMs zu schaffen.

Bandbreite

Average

  1. quota:vif_inbound_average
  2. quota:vif_outbound_average

Wie der Name schon sagt, beschränkt man hier inbound (eingehenden) sowie outbound (ausgehenden) Traffic durch einen durchschnittlichen Wert, den diese beiden nicht überschreiten dürfen.

Peak

  1. quota:vif_inbound_peak
  2. quota:vif_outbound_peak

Die Bandbreite kann man auch mit Peak sowie Burst begrenzen. Peak gibt hierbei an, bis zu welchem Limit die Bandbreite genutzt werden darf, als absolutes Maximum. Dieser Wert funktioniert aber nur in Zusammenarbeit mit “Burst”.

Burst

  1. quota:vif_inbound_burst
  2. quota:vif_outbound_burst

Burst gibt nämlich an, wie lange die Bandbreite im Wert “Average” überschritten werden darf. Gemessen wird hier in KB. Setzt man also den Burst auf 1.048.576 KB, darf der Peak Wert solange genutzt werden, bis 1GB (1.048.576 KB) an Daten übertragen wurden. Zu Beachten ist aber, dass dieser Wert für jeden Zugriff neu gilt. Führt man also 3 Kommandos hintereinander aus (3x wget mit && verknüpft) greift der Burst für alle 3 gleichermaßen. Führt man die gleichen Kommandos ebenfalls hintereinander aus, aber verknüpft diese mit einem Sleep, greift der Burst für jedes Kommando neu.

 

IOPS

Throttle

  1. quota:disk_read_iops_sec
  2. quota:disk_total_iops_sec
  3. quota:disk_write_iops_sec

Die lesenden und schreibenden Prozesse der VMs können natürlich auch begrenzt werden. Hier gibt es zwei Möglichkeiten:

  • Limitierung von lesenden sowie schreibenden Prozessen separat
  • Limitierung auf absoluten Wert

Beides in Kombination geht nicht. Es nicht möglich zu konfigurieren, dass es 300 lesende, 300 schreibende und 700 insgesamte IOPS geben soll, würde aber auch keinen Sinn machen. Zu beachten ist, wenn alle 3 Werte gesetzt werden, können diese in einen Konflikt geraten und gegebenenfalls gar nicht greifen.

Burst

  1. quota:disk_write_iops_sec_max
  2. quota:disk_write_iops_sec_max_length

Durch das Bursting auf den Festplatten direkt, kann angegeben werden, mit welcher maximalen Anzahl an IOPS (quota:disk_write_iops_sec_max)eine VM die oben gesetzten Werte, für wie lange (quota:disk_write_iops_sec_max_length) überschreiten darf. Sinnvoll wäre dies, wenn bekannt ist, dass gewisse Prozesse kurzzeitig mehr IOPS benötigen, als freigegeben ist.

Beispiele

Um Limitierungen zu setzen, wird zunächst ein Flavor benötigt. Im Anschluss können die Werte gesetzt werden. Die Dokumentation zum Anlegen von Flavors gibts hier

openstack flavor set {$flavor} --property quota:{$param}={$value}
quota:disk_read_iops_sec='200'
(quota:disk_total_iops_sec='1000')
quota:disk_write_iops_sec='200'
quota:vif_inbound_average='10240'
quota:vif_inbound_burst='20480'
quota:vif_inbound_peak='15360'
quota:vif_outbound_average='10240'
quota:vif_outbound_burst='20480'
quota:vif_outbound_peak='15360'
quota:disk_write_iops_sec_max_length='10'
quota:disk_write_iops_sec_max='1000'

In diesem Beispiel würde man zum Beispiel die lesenden Prozesse auf 200 (quota:disk_read_iops_sec='200') beschränken, ebenso die schreibenden, bei einer eingehenden Brandbreite von 10MB(quota:vif_inbound_average='10240'). Peak liegt bei 20MB und darf für 15MB erreicht werden. Das ist natürlich ein sehr unrealistisch minimalistisches Begrenzungsbeispiel, jedoch sollte die Art und Weise wie es funktioniert verdeutlich worden sein.

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Gitlab | self-hosted vs. Gitlab as a Service

Egal ob GitLab-CE oder GitLab-EE, es stellt sich die Frage, ob self-hosted oder vielleicht sogar als GitLab as a Service (im Folgenden GaaS genannt). Unterschiede gibt es bei diesen beiden Varianten genug. Doch wo sind die gravierendsten Unterschiede in diesen beiden Varianten, was ist das richtige für wen? Diese Fragen möchte in dem folgenden Blogpost beantworten.

 

 

Zeitaufwand

Fangen wir mit dem zeitlichen Aufwand an. Eine GitLab Instanz zu installieren, kann schon einmal etwas Zeit in Anspruch nehmen. Installation, Konfiguration, Wartung, etc, aber auch das Bereitstellen eines Systems (Hardware Server oder VM und eventuell sogar Storage), kann hier mehrere Stunden dauern. Im direkten Vergleich hierzu steht GaaS gehostet in unserem NWS Portal. Nach bestellen einer Gitlab-CE oder GitLab-EE App, dauert es ca 10 Minuten bis alle Funktionen installiert und konfiguriert sind und GitLab einsatzbereit ist.

Umfang

Bei der self-hosted Variante hat man natürlich alle Freiheiten, die ein Administrator der Anwendung haben sollte. Die Instanz kann mit allen gewünschten Features erweitert und somit sehr stark individualisiert werden. Man hat die Auswahl ob man gerne AutoDevOps mit Kubernetes oder GitLab Runner für das Ausführen von Build Jobs haben möchte.

In der GaaS Lösung ist es so, dass hier direkt ein GitLab Runner mit ausgeliefert wird, sodass ohne Verzögerung erste Jobs laufen können. Eine Umstellung auf AutoDevOps ist jedoch auch möglich. Ebenso bringt diese Variante alle standardmäßigen Features mit, die GitLab so haben sollte. Individuelle Features können leider nicht ohne weiteres hinzugefügt werden, da diese durch das NWS Team geprüft, getestet und für alle Kunden zur Verfügung gestellt werden müssen.

Backups

Wer GitLab nutzt möchte natürlich auch Backups seiner Daten und Arbeiten erstellen. GitLab selbst bietet hier die Möglichkeit Backups aller Daten zu erstellen und diese entsprechend auf dem Server zu speichern. Regelmäßiges Warten dieser Backups ist nötig, da diese Backups je nach Größe der Instanz entsprechend Speicherplatz verbrauchen.

NWS bietet hier etwas mehr Komfort, denn um Backups muss sich hier nicht gekümmert werden. Das System erstellt automatisch jede Nacht Snapshots der Apps und auf Wunsch können auch Tagsüber Snapshots erstellt werden, zum Beispiel wenn Änderungen vorgenommen werden sollen und ein zusätzliches Backup gewünscht ist.

Updates

Regelmäßig werden durch GitLab Updates veröffentlicht. Im normalen Zyklus geschieht dies jeden Monat am 22.ten, jedoch werden zwischendrin auch Security Updates oder Bug Fixes veröffentlicht. Als Administrator vertraut man Updates nicht immer und möchte diese vorher Testen, bevor sie in der Produktionsumgebung eingespielt werden. Hier ist ein Testsystem von Nutzen.

In der GaaS Lösung ist dies automatisch der Fall. Nach Veröffentlichung eines Updates wird in verschiedenen Phasen getestet:

  1. Lokales starten der neuen GitLab Instanz
  2. Starten in der Testing Umgebung
  3. Upgrade einer “veralteten” Instanz in der Testing Umgebung
  4. Starten in der Produktionsumgebung
  5. Upgrade einer “veralteten” Instanz in der Produktions Umgebung

Erst wenn diese 5 Phasen durchlaufen sind, werden Wartungsmails verschickt und die neue Version wird für alle Nutzer live genommen.

TLS

TLS ist aus der heutigen Zeit nicht mehr weg zu denken. Zertifikate sind jedoch unter Umständen etwas teurer. GitLab bietet hier jedoch die Möglichkeit, mittels Letsencrypt TLS Zertifikate für die jeweilige Instanz zu generieren. Sowohl in der Self-Hosted Variante als auch bei GaaS ist dies recht einfach. Der Unterschied besteht lediglich darin, dass in der NWS Plattform lediglich ein Haken gesetzt werden muss, um eben diese Verschlüsselung zu aktivieren.

Self-Hosted

sed -i "/letsencrypt\['enable'\] = true/d" /etc/gitlab/gitlab.rb
sed -i "s#^external_url 'https://.*#external_url 'https://$YOUR_DOMAIN'#g" /etc/gitlab/gitlab.rb
gitlab-ctl reconfigure

GaaS

Monitoring

Monitoring ist ebenso ein essenzieller Bestandteil von Produktionsumgebungen. Bei der selbstständig gehosteten Lösung muss sich hier eigenständig darum gekümmert werden. Welches Tool hierzu verwendet wird, bleibt jedem selbst überlassen, wir empfehlen aber Icinga 2.
Mit der GaaS Lösung kommt ein Monitoring automatisch mit. Zwar ist dies für die Kunden nicht einsehbar, jedoch werden alle Funktionen der Instanz durch unser Support Team überwacht.

Fazit

Welche Variante für einen selbst nun die richtige muss jeder für sich entscheiden. Wenn man GitLab selbst hosted, hat man absolute Kontrolle über die Instanz. Backups, Updates, Ressourcen, es kann selbständig über die Dimensionen entschieden werden und man ist etwas flexibler als in der GaaS Lösung. Jedoch ist in eben dieser der Vorteil, dass Backups, Updates, sowie Konfiguration und Support von den Mitarbeitern von NWS übernommen werden. GitLab kann in NWS 30 Tage kostenlos getestet werden, probiert es also einfach mal aus – testen

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Monthly Snap July – Sommermeeting & Grillfeier | Icinga Releases | Neuerungen, Updates, #lifeatnetways

Während der Monat Juli zu Ende geht, klettern die Temperaturen auf ihren diesjährigen Höchststand: Dienstag, 31. Juli | 36 Grad! Jeder geht mit der Hitze ja anders um. In einem solchen Monat lernt man seine Kollegen nochmal ganz anders kennen – und schätzen! Mit Nicole und Markus etwa werden Stieleis-Kindheitsträume wahr 😉

Sommer, Sonne, Sommermeeting

Highlight des Monats ist der 20. Juli: Sommermeeting und Grillfeier! Vormittags versammelt sich die gesamte NETWAYS Familie im Kesselhaus, wo die Teamleads das Abteilungsgeschehen präsentieren und CEO Bernd eine motivierende Rede hält, wie sie nur Bernd halten kann und einen Ausblick auf große Veränderungen gibt: Wir werden umziehen – physisch in neue Räumlichkeiten, virtuell auf eine neue Webseite. Das muss natürlich gefeiert werden: Am späten Nachmittag ziehen immer mehr Kollegen auf die Dachterrasse zu BBQ, DJ Alexander und Gin&Tonic-Bar.

Gefeiert hat die NETWAYS Familie im Juli so einiges  – auch den #SysadminDay, zu dem es ein großes Frühstücksbuffet gab.

Neuerungen und Updates

Aber wir waren auch abseits der Tanzfläche fleißig! Eine ganze Reihe NWS | Neuerungen und Updates stellt Marius in seinem Blogpost vor. Alexander hat SSL geknackt! Naja, fast. Markus sieht sich ReaR mal anders an und Georg erklärt, wie man einen verschlüsselten File-Container mittels cryptsetup und LUKS erstellen kann. Consultant Markus verrät, wie wir dienstlich Reisen. Marius hat einen anderen Ansatz gefunden: Let’s Encrypt HTTP Proxy: Another approach und Webinar-Meister Christian präsentiert die NETWAYS Webinare: Icinga 2 Serie.

Überhaupt Icinga! Hier hagelts Releases

Mitte Juli präsentieren die Icinga Entwickler ihr Icinga 2.9.0 Release! 2.9.0 bringt Neuerungen wie Elasticsearch 6-Unterstützung, eine einfachere Client-Installation und Bugfixes in punkto Windows-Reload, Speicherprobleme, geplante Downtimes und Benachrichtigungsreihenfolge. Kurz darauf folgt das Release von Icinga Web 2 2.6.0 mit zusätzlichen Dashboard-Widgets, einer neuen Hostgruppen-Übersicht und erweitertem Audit-Logging. Dank aufmerksamer Community Mitglieder, die einen weiteren Bug melden, kann die Icinga Crew letzte Woche gleich noch eins drauf setzen: Icinga 2.9.1.

Auch unsere Buchautoren Lennart und Thomas setzen eins drauf: Icinga 2 Buch, 2nd Edition. Dank Gunnar gibt es in unserem Blog einen Überblick über den Icinga Config Compiler. (Und dank @noledge eine lustige Icinga-Integration. ;))

Let it grow!

Am 1. August wird der erste von 7 (!) neuen Azubis in diesem Jahr kommen. Ja, auch deswegen werden wir umziehen: Wir wachsen! Unsere derzeitigen Auszubildenden kennt ihr ja schon. Afeef hat sich im Juli aber noch einmal genauer vorgestellt (Serie: NETWAYS stellt sich vor). Und worüber zerbrechen sich die anderen so den Kopf? Philipp beschäftigt sich mit der i-doit API, Killian mit AI – Artificial Intelligence (Was ist das? Ist das Gefährlich?) und Nicole gibt einen Einblick in ihre Projektwoche in der Berufsschule.

Und sonst so?

Nach dem einen Event, ist vor dem anderen: Von der OSDC gibt es Fotos, Slides und Videos im Archiv, für die OSBConf steht das Programm. Check it out! Niemals zuvor hatten wir so vielen Anfragen von Menschen, die unser Kesselhaus mieten wollen. Nie zuvor so früh im Jahr so viele Anmeldungen für die OSMC und so viele neue Speaker. Freut euch auf den Herbst! Dann gibt’s auch wieder viele interessante und lehrreiche Schulungen. Guckt doch mal in unseren Kalender: Die Zeit ist reif!

In diesem Sinne: Schönen Sommer!

Julia Hornung

Autor: Julia Hornung

Julia ist seit Juni 2018 Mitglied der NETWAYS-Crew. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und Produktionsassistentin in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

NWS | Neuerungen und Updates

Die letzten Wochen hat sich auf unserer NWS Plattform sehr viel getan. Wir möchten uns an dieser Stelle auch bei unseren Nutzern bedanken, die Verbesserungsvorschläge der Apps an uns reported haben. Aufgrund dieser Aussagen ist es uns möglich, uns und NWS selbst stetig zu verbessern und so schließlich auch das Erlebnis der User zu verbessern! Im Folgenden möchte ich etwas darauf eingehen, welche Neuerungen die letzten Wochen vorgenommen wurden.

Migration der NWS Plattform auf OpenStack

Ein sehr großer Teil, wenn nicht sogar der größte Teil, war die Migration unserer Server auf das neue OpenStack Setup an unserem neuem RZ-Standort. Neue Server, neue Technologie und ein neues Rechenzentrum. All das ermöglicht uns eine Performance-Steigerung der Produkte sowie unserer Anwendung selbst. Es wurde hier eine komplett neue Umgebung aufgebaut, auf der nun auch NWS läuft. Die alte Umgebung wurde komplett abgeschaltet.

Gitlab-CE / Gitlab-EE

Natürlich haben wir auch Updates eingespielt. Gitlab-CE sowie Gitlab-EE wurde auf die Version 11.0.4 angehoben. Diese Version bringt AutoDevOps mit sich und diverse andere Neuerungen.

Icinga2 Satellite

Unsere Satelliten wurden auf die aktuelle Icinga2 Version angehoben, welche aktuell die 2.9.0-1 ist.

Icinga2 Master

Die Master App wurde ebenso auf die 2.9.0-1 angehoben. Wir haben hier auch das eingesetzte Grafana aktualisiert auf die Version 5, welches ein komplett neues Interface mit sich bringt. Ein Update für das neue icinga2-Web steht noch aus!

SuiteCRM

Die Version von SuiteCRM selbst, welche bisher bei NWS im Einsatz war, hatte leider einige wenige Bugs. Diese konnten wir mit der neuen Version 7.10.7 beheben und so die Produktivität der App verbessern. Wir haben hier auch kleinere Änderungen am Aufbau und Konfiguration der Container vorgenommen, welche die Start-Zeit enorm verkürzt haben. Hierzu beigetragen haben auch die Ressourcen, wovon wir den Containern mehr zuteilen.

Rocket.Chat

Rocket.Chat wurde mit der Version 0.66.3 auf die aktuellste verfügbare Version erhöht. Wir haben hier auch den Begrüßungstext, der in der Instanz angezeigt wird durch ein kleines “HowTo” ersetzt, um einen leichteren Einstieg in diese App zu ermöglichen.

WordPress

Auch WordPress wurde mit einem Update versehen. Wir haben hier die Version 4.9.7 aktiviert. Diese Version ist ebenso wie 4.9.6 DSGVO konform.

Nextcloud Verbesserungen

Wir haben einige Reports bekommen, dass die Performance unserer Nextcloud App noch verbesserungsfähig ist. Wir haben aufgrund dieser, gewisse Verhalten nachstellen können und konnten so die dafür verantwortlichen Fehler finden und beheben. Unsere Arbeiten resultierten in einer wesentlichen Performance-Steigerung der App, vor allem im Bereich der Dokumente, der Foto Galerie, sowie des Logins.

Diverse Fehlerbehebungen / Verbesserungen

Wie oben bereits erwähnt, haben wir unter anderem durch die Reports unserer Nutzer Fehlerstellen gefunden und konnte diese beheben. Daraus resultierend hat sich die Start-Zeit der Apps verkürzt, was wir auch bei den Restarts und bei den Updates beobachten konnten. Dies erleichtert uns natürlich die Wartungsarbeiten aber auch die Downtimes für unsere Nutzer, sofern ein Restart einmal nötig sein sollte. Wir haben ebenso falsche/hängende Flows gefunden, welche bisher dafür gesorgt haben, dass Container innerhalb eines Setups gelegentlich die Connection zueinander verlieren konnten. Dieser Fehler wurde behoben und tritt derzeit nicht mehr auf. Wir sind stets dabei weitere Verbesserungen vorzunehmen und Neuerungen zu testen. Um hier Up-to-date zu bleiben, kann ich unseren Twitter Account empfehlen. Hier werden alle Updates regelmäßig veröffentlicht!

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz

Microsoft and GitHub – merge conflict?

For some time it has become clear that Microsoft is going to take over GitHub. As far as official sources can be trusted, GitHub will stay independent although a new CEO (Nat Friedman) will be introduced after the Microsoft takeover.

This question over GitHub’s future independence has raised a lot of skepticism within the developer community and many are considering moving their projects away from GitHub to a different location.

One alternative in this case could be GitLab. GitLab does not only have an online platform but it can as well be installed on your own hardware. Furthermore, it is an extremely solid piece of Open Source software you can fully rely on. This is also shown by the makers of GitLab themselves as they release updates each month – rolling out bug fixes, security updates and many recommendations regarding the use and configuration of your instance.

For those who would like to have their own GitLab instance, NETWAYS offers two options:

First one is available on our NETWAYS Web Services platform where we offer user-managed, hosted GitLab instances as Community or Enterprise Edition. The user does not need to take care of anything regarding installation or maintenance of his GitLab, but can directly go into production in no time with only a few steps needed. You as a customer are also free to decide for how long you would like to run your instances as any app is monthly callable. Furthermore, we regularly update these container based apps and monitor their health  for you. As a customer, you can register on NWS and try all the apps we offer 30 days for free.

The second product we offer is done by NETWAYS Managed Services which is exactly what it is called: With managed hosting you can get a virtual machine in our cloud or rented hardware running a full GitLab, either as Community or Enterprise Edition. You can choose the underlying ressources and we will do the rest for you, like installation with individual parameters and health monitoring. With managed hosting, our customers also have the choice to go full 24/7 support with “emergency” calls.

Nicole Lang

Autor: Nicole Lang

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest Bücher und zockt auch mal gerne.

Rocket.Chat vs Slack

Team oriented Instant-Messaging has become quite popular in recent years with Slack. Its success is undeniable: more than 6 million people use Slack every day.
The name Slack is an acronym for “Searchable Log of All Conversation and Knowledge” and might be an understatement to its todays capabilities.
But nevertheless searching through all conversations, files, and users is where it still shines.
Next to that, the main functionality is the team/group orientated messaging and the ability to integrate it with variety of other online services like Dropbox, Google Drive, GitHub etc. Some other cool features are (group) video calls and screen-sharing.

But Slack also comes with some limitations. You can use it for free, but you will be limited to access only the last 10000 messages.
Also the number of apps and integrations is limited and you can video chat only with one other user at a time.
To unlock those limitations you will have to choose one of the payment plans. And that’s where it can get expensive if you want to provide your growing company or a team with full featured accounts. For a team of 50 users you’ll have to spend at least 312 Euro per month.

One competitor of Slack is Rocket.Chat which is a open-source project that has been in very active development over the past years.
In this post I will briefly highlight the differences and the benefits of this chat solution in comparison to Slack.

Open Source
The first difference that I already mentioned is that Rocket.Chat is open source while Slack is not. Therefore you can access all its features for free and everyone can contribute to the development and implement new features. I have been watching the project on GitHub over the past year and there have been some great UI changes in the last couple of releases that gave it a more modern look and feel than before.

Self-Hosted
The fact that it is open-source makes it possible that you can download the software for free and install and run it on your own server. You are completely in control of where your chat data is stored. This can be an advantage if you know how to properly secure your server but it also can be of danger if you don’t. When it comes to security even Slack had some issues in the past with their service. In 2015 Slack was hacked – the hackers were able to access the main database for four days, giving them the chance to steal all user-profiles.

Customization
In Rocket.Chat you can personalize the whole design. You can even replace the Rocket.Chat icons with your own logos or add your own CSS styles, fonts and scripts.
Slack also provides some options to customize the look but not in the extend of what is possible with Rocket.Chat.

Roles and Permissions
With Slack you can specify which user-role a user should have in the Slack-Workspaces. Those are predefinded role-sets from Slack with different permissions.
Rocket.Chat takes it a step further. You have more presets and you even have the option to create you own role-presets.

Workspaces, Channels and OTR
In comparison to Slack, Rocket.Chat does not have anything similar like the Workspaces in Slack. But it has channels, private channels, direct messaging and even OTR (Off-the-Record) chats.
The last one is something that is currently not available in Slack. If you start a Off-the-Record session in Rocket.Chat with another user, all messages will be end-to-end encrypted and will be deleted after the session. This is perfect if you want to exchange some sensitive information with someone else.

Integrations, Bots and Apps
Slack features hundreds of apps that you can simply add with a few clicks. Some of them act as bots for other external services like for example Jira and Bitbucket.
This is something that Rocket.chat currently has not built in. But the Roadmap concerning Rocket.Chat bots looks very promising.
What you can do is install a Hubot on your server, hook it up to your Rocket.Chat and feed it with some scripts to achieve similar functionality.
There are already many hubot scripts on GitHub but it is just not as convenient to set up as installing an app in Slack.
Something else that both Slack and Rocket.Chat can do is Zapier integrations with other web services.
Rocket.Chat still has to catch up when it comes to the number of available Zapier integrations (10 for Rocket.Chat vs 100 for Slack) but there are already some useful integrations like Twitter, Github and Gmail. Another feature that Rocket.Chat has built in is a helpdesk chat called Livechat. This is a great feature if you have a WebShop or something similar where you would like to provide some additional support for your customers. You just have to enable it in Rocket.Chat and copy the Livechat script to your website. To learn more about it you should read Georgs blog post about that.

Summary
The benefits of Rocket.Chat are:
– the fact that it is open source and therefore free
– you can host it on your own server or on a server of the hosting provider you trust
– you have some additional freedom and control when it comes to visual customization and configuring user-roles

The downsides are:
– you will have to set it up on your own and manage stuff like backups, security and getting it fixed in case of a failure
– you don’t get the variety of apps and integration services as with Slack

If you are looking for a great managed Rocket.Chat solution you should have a look at our Netways Web Services and try Rocket.Chat 30 days for free.
And in case you didn’t know:
If you start both Rocket.chat and Icinga 2 Master a NWS integration job will kick in and configure both your apps so that your Icinga 2 Master will send monitoring alerts to a channel of your Rocket.Chat.
We also support Slack-Notifications in our Icinga 2 Master apps to send monitoring alerts directly to a provided Slack channel.

Gabriel Hartmann

Autor: Gabriel Hartmann

Gabriel freut sich nun in seiner Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS endlich sein im Informatikstudium gesammeltes Wissen artgerecht anwenden zu können. Wenn er nicht gerade an Servern, PC’s und sonstigem bastelt, vertreibt sich der gebürtige Oberfranke seine Freizeit mit Radfahren, Fotografie und Snowboarden. Vor allem reizen ihn interessante Projekte und das Arbeiten an Open Source basierten Linux-Systemen.