Les secrets techniques de Slack, cette plateforme qui vaut 28 milliards
Début décembre, Salesforce a annoncé la signature d'un accord en vue d'acquérir Slack pour la somme pharaonique de 27,7 milliards de dollars. Fondée en 2009, la messagerie collaborative revendique 142 000 clients payants. En coulisse, elle s'adosse à une architecture à l'état de l'art qui lui a permis de gérer sans incident le trafic record enregistré lors du premier confinement. Sur mars 2020, Slack revendique une croissance de près de 350% des appels émis ou reçus via sa plateforme d'un mois sur l'autre. Le 25 mars, il a passé pour la première fois le cap symbolique des 12 millions d'utilisateurs connectés simultanément au niveau mondial.
En front end, Slack s'adosse à Electron. Le célèbre framework multiplateforme est le socle de ses applications natives pour Windows, Mac et Linux, mais aussi de son application web délivrée via les navigateurs. Grâce à lui, toutes partagent le même code source. Combinant technologies web (HTML, CSS et JavaScript) et couche logicielle Node.js, Electron est étendu par Slack pour compiler React, l'infrastructure JavaScript orientée graphique initialement sortie des laboratoires de Facebook. Une technologie que Slack a décidé de mettre en œuvre en 2018. Tout comme pour Electron, l'initiative passe par une collaboration avec la communauté gravitant autour du projet open source. Le déploiement de React a été finalisé en 2019.
"React rend d'abord nos applications beaucoup plus rapides et économes en mémoire", explique Cal Henderson, cofondateur et directeur du département technologie de Slack. "Etant orienté objets (et ainsi décomposable en sous-parties, ndlr), il est plus facilement maintenable et nous permet de faire intervenir une équipe de développeurs plus importante." Qu'en est-il des applications mobiles iOS et Android ? Elles font l'objet de développements natifs propres à chacun des deux OS mobiles. La raison invoquée est toujours la même : la performance.
HHVM de Facebook comme socle
Côté back end, l'édifice technique est impressionnant. Certes, Slack articule au départ son architecture autour d'une simple pile Lamp, associant le système d'exploitation Linux, le serveur web Apache, la base de données MySQL et le langage PHP. Le tout hébergé sur le cloud d'AWS. Mais que de chemin parcouru depuis. En 2016, Slack a migré vers HHVM (pour HipHop Virtual Machine). Egalement développé par Facebook, ce fork de PHP intègre un mode de compilation just-in-time (JIT) qui améliore nettement les performances du langage de script. Une technologie qui sera intégrée à PHP à l'occasion de la sortie de sa version 8.
"Avec le télétravail, le nombre d'utilisateurs actifs n'a pas seulement progressé. Chaque utilisateur a aussi recours à la plateforme plus longtemps"
"Depuis, nous avons conservé HHVM car HAcklang, le langage sur lequel il s'appuie, améliore la productivité via un meilleur outillage", argue Cal Henderson. Hacklang reprend "les meilleurs éléments de PHP", tels le workflow d'édition-actualisation et le modèle de mémoire orienté requête. "Il intègre par ailleurs un meilleur système de typage et un contrôleur de type statique. Ce qui facilite l'identification des bugs, et plus globalement le développement du code et sa refactorisation", argue Slack dans un post de blog. Comme avec React, Slack fait depuis partie des contributeurs du projet HHVM. Aux côtés de Hacklang, Slack fait appel aux langages Go et Java.
Pour encaisser l'audience du premier confinement, l'entreprise de Stewart Butterfield, son PDG, a pu bénéficier des services d'AWS, en particulier des instances EC2 et de leur répartiteur de charge (Elastic Load Balancing) aux côtés du système de stockage S3. Sans surprise, Slack manage ses ressources cloud via le très populaire outil d'infrastructure as code Terraform. En 2020, il s'est tourné vers les virtual private cloud (VPC) d'Amazon pour isoler ses environnements d'expérimentation, de développement et test, et de production. Ces trois environnements sont répliqués sur chaque région AWS où Slack est présent. L'architecture permet à Slack de s'étendre à travers le monde tout en sécurisant ses déploiements (lire le blog post).
"Avec la montée en puissance du travail à domicile, le nombre d'utilisateurs actifs n'a pas seulement progressé. Chaque utilisateur a également eu recours à Slack plus longtemps. La plage quotidienne moyenne de connexion a atteint 50% d'une journée en avril", confie Cal Henderson. Conçu pour gérer des canaux de messagerie partagés entre plusieurs organisations, le recours à Slack Connect a explosé. "Ce service, qui implique une gestion particulière de la sécurité et des droits d'accès, rend la gestion de la montée en charge plus complexe", souligne le CTO.
Renvoyant aussi bien à un channel de messagerie qu'à une communication en one-to-one, le canal Slack se place au cœur du système de scalabilité de la plateforme. "Nos clients peuvent opérer de quelques canaux jusqu'à des millions. Certains d'entre eux comptent près d'un million d'utilisateurs et des canaux de communication interne pouvant atteindre des centaines de milliers de participants. D'où l'enjeu de partir du channel pour dimensionner l'architecture", argue Cal Henderson.
Jusqu'à 12 millions d'utilisateurs simultanés
En coulisse, Slack s'est attelé depuis 2017 à faire évoluer ses bases MySQL (qui reposent sur EC2) de clusters en configuration actif-actif vers un système de dimensionnement horizontal basé sur la technologie open source Vitess. Fin 2020, la quasi-totalité de son trafic MySQL avait migré vers la nouvelle architecture. "Lors du pic de 12 millions d'utilisateurs simultanés de mars dernier, nous avons scalé l'un de nos espaces clés le plus utilisé via les workflows de fractionnement de Vitess", détaille-t-on chez Slack, avant de reconnaître : "Sans Vitess, nous n'aurions jamais pu gérer la montée en puissance de nos plus grands clients, ce qui se serait traduit par des interruptions." Conférant à MySQL l'évolutivité d'une base NoSQL, Vitess dimensionne l'infrastructure de données sans nécessiter de modifier le code. De quoi accélérer les déploiements.
Slack fait par ailleurs de Vitess le socle de son service d'hébergement local des données des utilisateurs (International Data Residency). Il se compose de clusters Vitess répartis sur six régions AWS à travers le monde, dont la France.
Pour les nouveaux développements, Slack fait le choix de Kubernetes par défaut. Reposant sur une architecture SOA (service oriented architecture), sa plateforme s'adosse sur 300 à 400 services applicatifs. Pour l'heure, environ 20% d'entre eux ont migré vers l'orchestrateur de containers. C'est notamment le cas de composants sans état (stateless) historiquement mieux adaptés à Kubernetes. Parmi ces services, le CTO de Slack évoque une passerelle entre la couche de base de données et AWS KMS (Key Management Service), permettant aux clients de gérer leur propre clé de cryptage.
Amazon Elastic Kubernetes Service
Pour automatiser son architecture Kubernetes, Slack fait appel à la solution de Kubernetes managé d'Amazon : EKS (Elastic Kubernetes Service). Un autre secret bien gardé qui a évidemment joué un rôle clé pour gérer le pic d'audience de mars.
Suite au rachat de Slack par Salesforce, quel sera le sort de cette plateforme ? A court terme, elle ne devrait pas beaucoup évoluer. "Slack a pour vocation de connecter toutes les applications d'une organisation et pas seulement les applications Salesforce", analyse Bret Taylor, COO de Saleforces. "A l'image de la stratégie que nous avons suivie avec Mulesoft et Tableau, nous avons un équilibre à trouver. L'idée est de s'assurer que Slack reste une marque indépendante et continue de servir ses clients et de s'intégrer à leur système, le tout en faisant en sorte qu'il devienne aussi l'interface utilisateur de Customer 360 (la plateforme de Salesforce taillée pour fédérer l'ensemble des données de clients, ndlr)."