- PagerDuty /
- Blog /
- Meilleures pratiques et perspectives /
- Élixir chez PagerDuty
Blog
Élixir chez PagerDuty
Lors de la création de PagerDuty , la rapidité de développement était primordiale ; il n'est donc pas surprenant que nous révélions que Rails était la seule technologie initiale utilisée. Rapidement, des limitations ont poussé l'équipe initiale à explorer d'autres options et Scala a été adopté pour nous aider à évoluer.
Cependant, il existe un fossé énorme entre Scala et Ruby, notamment en ce qui concerne l'apparence des langages et les critères d'importance pour les communautés ; en bref, la perception générale. La communauté Ruby, et en particulier la sous-communauté Rails, accorde une importance primordiale à l'expérience du développeur. Scala, quant à lui, a des racines plus académiques et formalistes et tente de convaincre ses utilisateurs que la correction prime sur… presque tout.
Cela m'a agacé et il semblait que nous avions une lacune dans notre infrastructure technologique, une lacune difficile à combler. Scala n'allait probablement pas équiper notre site principal, et même si nous avions besoin de meilleures performances et d'une meilleure évolutivité que celles offertes par Ruby et Rails, l'écart était considérable et la transition était complexe. De plus, la base de code Scala initiale était peu appréciée, car il est rapidement devenu évident qu'écrire du code Scala propre et maintenable était complexe, et certains choix technologiques ont rendu la mise à l'échelle plus complexe 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 du Métaphore du système Ayant travaillé dans le monde des télécommunications, il n'était pas exagéré de considérer PagerDuty comme une sorte de commutateur (télécom) avancé : les données arrivent, les règles et la logique les acheminent et les modifient, et les données sortent. Comme pour toute analogie, on peut l'étendre autant qu'on le souhaite (considérer un incident comme un circuit ouvert), mais pour moi, il suffisait de plisser les yeux et de réaliser que c'était une métaphore exploitable.
Si vous dites « télécommunications » et « langage de programmation », vous dites « Erlang J'avais déjà étudié Erlang, mais ce langage ne m'avait jamais séduit et, par le passé, il n'était jamais vraiment adapté aux types de systèmes sur lesquels je travaillais. Cette fois, cependant, le « sweet spot » semblait tenir, mais malgré tout, un langage basé sur Prolog, avec beaucoup de choses à l'envers (comme mélanger les majuscules et les minuscules), ressemblait à du C avec des fichiers d'en-tête… ce serait difficile à convaincre.
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 solide expérience en Ruby/Rails s'est lancé et a créé un langage basé sur la machine virtuelle d'Erlang : un langage moderne, rapide, de très haut niveau, avec des macros de type Lisp/Scheme. et prétend toujours être gentil avec les utilisateurs (plutôt qu'avec les étudiants en doctorat).
Inutile de préciser qu'il a immédiatement atteint la première place de ma liste des « langages à apprendre cette année » et j'ai commencé à travailler sur la documentation, les exemples de code, etc. Les promesses ont tenu leurs promesses : il a dépassé mes attentes, tant en termes d'exécution que de vitesse de développement. De plus, développer avec Elixir était un pur plaisir. amusant .
Après avoir pris le temps de me familiariser avec le projet et être 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 complexe. Leur coût est important, même si on en tient rarement compte. Il est donc essentiel d'être sûr. Et la seule façon d'en être sûr est, paradoxalement, de se lancer et de voir ce qui se passe. Un projet pilote doit donc être un investissement personnel, être essentiel à la mission et être suffisamment complexe, tout en étant suffisamment limité pour pouvoir tout réécrire dans l'un de vos anciens langages.
Pour mon équipe, l'opportunité s'est présentée lorsque nous avons souhaité disposer d'une solution « native Rails » pour communiquer avec Kafka de manière transactionnelle. Afin de faciliter la mise en place de l'application Rails, riche en transactions MySQL, nous souhaitions créer un système capable d'extraire les messages Kafka d'une table de base de données et de les envoyer à Kafka. Même si nous savions que ce n'était pas la meilleure façon d'interagir avec Kafka, cela nous permettait d'émettre simplement des messages Kafka dans le cadre de la transaction ActiveRecord en cours. Cela facilitait grandement l'amélioration du code existant avec les effets secondaires de Kafka et l'analyse des conséquences des rollbacks, etc.
Nous avons choisi ce projet comme pilote Elixir : il offrait une valeur ajoutée considérable et les premiers messages Kafka prévus se trouveraient sur notre chemin de notification critique. Cependant, il restait très autonome et aurait été relativement facile à refaire en Scala en cas d'échec. Il est rare de tomber sur le candidat idéal pour un nouveau pilote de langage, mais il était là. Nous nous sommes lancés à corps perdu et avons sorti quelques semaines plus tard un nouveau service nécessitant beaucoup de réglages et de mise en forme, mais Elixir ne nous a jamais gênés.
Inutile de préciser que cela n'a pas convaincu toute l'entreprise de « Super, on laisse tout tomber et on réécrit tout ce qu'on a dans Elixir », mais c'était une première étape importante. Nous avons commencé à promouvoir le langage, contribué à l'incubation de quelques projets supplémentaires dans d'autres équipes et progressivement développé sa présence. Nous avons également essayé de recruter des personnes qui appréciaient Elixir, organisé de nombreuses rencontres Elixir à Toronto pour entrer en contact avec la communauté locale et, lentement mais sûrement, les équipes ont commencé à adopter le langage. Aujourd'hui, nous avons un bon mélange d'équipes qui utilisent pleinement Elixir, d'équipes qui montent en puissance et d'équipes qui attendent encore le premier projet qui leur permettra de se dire : « On va faire ça avec Elixir. »
Elixir s'est principalement vendu tout seul : il fonctionne, repose sur une plateforme solide comme le roc, son code est très compréhensible, la communauté ayant une aversion salutaire pour la « magie » qui fait fonctionner Rails, et il est assez simple à prendre en main grâce à sa petite surface d'application. Il est désormais peu probable que tout ce qui transite par PagerDuty ne soit pas affecté par le code d'Elixir. Cette année, nous misons gros sur ce projet en extrayant des fonctionnalités majeures de leurs anciennes piles pour les intégrer à Elixir. Il ne fait aucun doute qu'Elixir sera capable de gérer le type de trafic que PagerDuty doit gérer en 2018. De l'intuition initiale à la production à grande échelle, en passant par le pilote, le parcours a été plutôt tranquille, et certains d'entre nous espèrent secrètement qu'un jour, nous n'aurons plus à gérer que du code d'Elixir.
Un article sur Elixir ne serait pas complet sans un hommage aux leaders de la communauté, à commencer par José Valim, inventeur d'Elixir, à qui j'attribue une grande partie de 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, le forum Elixir ou d'autres canaux comme Stack Overflow et IRC, les gens sont polis, serviables et coopératifs. Les débats sont courts et rares, et la vitesse de progression est impressionnante. Rien que pour cela, Elixir vaut le détour.
Vous souhaitez en savoir plus sur Elixir ? Les ingénieurs de PagerDuty sont généralement disponibles au San Francisco et Toronto Rencontres. Et si vous souhaitez rejoindre PagerDuty, nous sommes toujours à la recherche de talents. Consultez notre page carrières pour les postes ouverts actuellement.