Lorsque PagerDuty a été fondée, la vitesse de développement était essentielle. Il ne faut donc pas s'étonner lorsque nous révélons que Rails était la seule technologie initiale sur laquelle nous utilisions. Bientôt, les limitations ont amené la première équipe à regarder autour de elle et Scala a été adoptée pour nous aider à évoluer.

Cependant, il existe un énorme fossé entre Scala et Ruby, notamment en ce qui concerne l'apparence des langages et ce que les communautés trouvent important ; en bref, la façon dont tout se passe. La communauté Ruby, et en particulier la sous-communauté Rails, accorde une grande importance à l'expérience du développeur par rapport à presque tout le reste. Scala, en revanche, a des racines plus académiques et formalistes et essaie de convaincre ses utilisateurs que la correction l'emporte sur... eh bien, sur presque tout.

Cela m'a dérangé et il semblait que nous avions un manque dans notre pile technologique qui était difficile à combler. Scala n'allait probablement pas alimenter notre site principal, et même si nous avions besoin de meilleures performances et d'une meilleure évolutivité que celles que Ruby et Rails pouvaient offrir, il y avait un très grand manque et le changement était fastidieux. Il y avait aussi peu d'amour pour la base de code Scala initiale, car il est rapidement devenu évident qu'écrire du code Scala propre et maintenable était difficile et que certains choix technologiques rendaient la mise à l'échelle plus difficile que prévu.

En réfléchissant à ces questions en 2015, je me suis laissé guider par une vieille pratique de l'Extreme Programming, celle de la Métaphore du système . Étant donné que j'ai travaillé dans le monde des télécommunications, il n'était pas exagéré de considérer PagerDuty comme une sorte de commutateur (de télécommunication) avancé : les éléments entrent, les règles et la logique les acheminent et les modifient, et les éléments sortent. Comme pour toute analogie, vous pouvez l’étendre aussi loin que vous le souhaitez (considérez un incident comme un circuit ouvert), mais pour moi, il suffisait de plisser un peu les yeux et de réaliser que c’était une métaphore réalisable.

Si vous dites « télécommunication » et « langage de programmation », vous dites « Erlang ” J'avais déjà regardé Erlang mais ce langage ne m'avait jamais séduit et, par le passé, il n'avait jamais vraiment trouvé le juste milieu en termes de types de systèmes sur lesquels je travaillais. Cette fois, cependant, la partie « juste milieu » semblait tenir, mais malgré tout, un langage basé sur Prolog, qui mélangeait beaucoup de choses (comme mélanger les majuscules et les minuscules), ressemblait à du C avec des fichiers d'en-tête... ce serait difficile à vendre.

J'ai donc laissé tomber cette idée, je suis retourné au travail et je l'ai oubliée jusqu'à ce que je tombe sur Elixir un mois ou deux plus tard. ce C'était intéressant ! Quelqu'un avec une certaine expérience de Ruby/Rails s'est lancé et a construit un langage sur la machine virtuelle d'Erlang : un langage moderne, rapide, de très haut niveau, doté de macros de style Lisp/Scheme, et prétend toujours être gentil avec les utilisateurs (plutôt qu'avec les étudiants en doctorat).

Inutile de dire qu'il a immédiatement obtenu la première place sur ma liste des « langages à apprendre cette année » et j'ai commencé à travailler sur la documentation, les exemples de code, etc. Ce qui avait été promis a tenu ses promesses : il a dépassé les attentes, tant en termes d'exécution que de vitesse de développement. De plus, développer dans Elixir était un pur plaisir amusant .

Après avoir pris mes marques et être devenu de plus en plus convaincu que cela pourrait effectivement supprimer le besoin de Scala, être plus agréable pour les utilisateurs de Ruby et, dans l'ensemble, nous faire aller plus vite tout en nous amusant davantage, j'ai commencé à chercher le redoutable projet pilote.

Présentation d'Elixir

L'introduction de nouveaux langages de programmation est une tâche délicate. L'introduction de nouveaux langages de programmation implique un coût important, même si les gens en tiennent rarement compte. Il faut donc être sûr. Et la seule façon de s'en assurer est, paradoxalement, de se lancer et de voir ce qui se passe. En tant que tel, un projet pilote doit avoir un intérêt personnel, être essentiel à la mission et être suffisamment complexe mais limité pour que vous puissiez tout réécrire dans l'un de vos anciens langages.

Pour mon équipe, l'opportunité s'est présentée lorsque nous avons voulu disposer d'un moyen « natif Rails » de communiquer avec Kafka de manière transactionnelle. Afin de faciliter la mise en place de l'application Rails, qui repose sur de nombreuses transactions MySQL, nous voulions créer un système qui extrayait une table de base de données des messages Kafka et l'envoyait à Kafka. Même si nous savions que ce n'était pas vraiment la meilleure façon d'interagir avec Kafka, cela nous permettait d'émettre simplement des messages Kafka dans le cadre de la transaction ActiveRecord actuelle. Cela nous a permis d'améliorer très facilement le code existant avec les effets secondaires de Kafka et de raisonner sur ce qui se passerait lors des restaurations, etc.

Nous avons choisi ce projet comme pilote Elixir : il avait une grande valeur ajoutée et les premiers messages Kafka prévus se trouveraient sur notre chemin de notification critique, mais il était toujours très autonome et aurait été relativement facile à refaire en Scala en cas d'échec du projet. Il n'arrive pas souvent de tomber sur le candidat idéal pour un nouveau pilote de langage, mais il était là. Nous nous sommes lancés dans l'aventure et sommes sortis plusieurs semaines plus tard avec un nouveau service qui nécessitait beaucoup de réglages et de mise en forme, mais Elixir ne s'est jamais mis en travers de notre chemin.

Bien entendu, cela n’a pas convaincu l’ensemble de l’entreprise de « bien, abandonnons tout et réécrivons tout ce que nous avons dans Elixir », mais c’était une première étape importante. Nous avons commencé à faire de la propagande, aidé à incuber quelques projets supplémentaires dans d’autres équipes et progressivement développé l’empreinte du langage. Nous avons également essayé d’embaucher des personnes qui aimaient Elixir, organisé de nombreuses rencontres Elixir à Toronto pour entrer en contact avec la communauté locale et, lentement mais sûrement, équipe après équipe a commencé à adopter le langage. Aujourd’hui, nous avons un bon mélange d’équipes qui sont entièrement sur Elixir, d’équipes qui montent en puissance et d’équipes qui attendent toujours le premier projet qui leur permettra de dire : « Nous allons faire celui-ci avec Elixir. »

Elixir s'est principalement vendu tout seul : il fonctionne, il repose sur une plate-forme solide comme le roc, le code est très compréhensible car la communauté a une saine aversion envers le genre de 'magie' qui fait fonctionner Rails, et il est assez simple à comprendre comme il a une petite superficie. À l'heure actuelle, il est peu probable que tout ce qui passe par PagerDuty ne soit pas touché par le code Elixir. Cette année, nous parions gros là-dessus en retirant certaines fonctionnalités majeures de leurs piles existantes vers Elixir, et il n'y a aucun doute sur la capacité d'Elixir à gérer le type de trafic auquel PagerDuty est confronté en 2018. De l'intuition initiale au projet pilote jusqu'à la production à grande échelle, le parcours a été plutôt doux et certains d'entre nous espèrent secrètement qu'un jour, nous n'aurons qu'à nous occuper du code d'Elixir.

Un article sur Elixir ne serait pas complet sans un hommage aux dirigeants de la communauté, à commencer par l'inventeur d'Elixir, José Valim, à qui je dois en grande partie la culture du langage. Elixir s'appuie sur l'une des communautés les plus sympathiques et les plus serviables qui soient, et que ce soit sur Slack, sur le forum Elixir ou sur d'autres canaux comme Stack Overflow et IRC, les gens sont polis, serviables et coopératifs. Les débats sont courts et peu nombreux, et la vitesse des progrès est étonnante. Rien que cela fait qu'Elixir vaut la peine d'être essayé.

Vous souhaitez en savoir plus sur Elixir ? Les ingénieurs de PagerDuty se trouvent généralement au San Francisco et Toronto rencontres. Et si vous souhaitez rejoindre PagerDuty, nous sommes toujours à la recherche de grands talents : consultez notre page carrières pour les postes ouverts actuellement.