Als PagerDuty gegründet wurde, war die Entwicklungsgeschwindigkeit von entscheidender Bedeutung. Daher sollte es keine Überraschung sein, dass Rails die einzige Technologie war, die wir anfangs verwendeten. Bald veranlassten uns Einschränkungen dazu, uns umzuschauen, und Scala wurde eingeführt, um uns bei der Skalierung zu helfen.

Es gibt jedoch eine große Lücke zwischen Scala und Ruby, einschließlich des Aussehens der Sprachen und dessen, was die Communities für wichtig halten; kurz gesagt, wie sich alles anfühlt. Die Ruby-Community und insbesondere die Rails-Subcommunity legen großen Wert auf die Entwicklererfahrung gegenüber so ziemlich allem anderen. Scala hingegen hat eher akademische und formalistische Wurzeln und versucht, seine Benutzer davon zu überzeugen, dass Korrektheit so ziemlich alles übertrumpft.

Es nagte an mir und es sah so aus, als hätten wir eine Lücke in unserem Tech-Stack, die schwer zu schließen war. Scala würde wahrscheinlich nicht als Grundlage für unsere Hauptsite dienen und obwohl wir eine bessere Leistung und Skalierbarkeit brauchten, als Ruby und Rails bieten konnten, gab es eine sehr große Lücke und der Wechsel war mühsam. Auch die anfängliche Scala-Codebasis war nicht sehr beliebt, da schnell klar wurde, dass es schwierig war, sauberen und wartungsfreundlichen Scala-Code zu schreiben und einige Technologieentscheidungen die Skalierung schwieriger machten als erwartet.

Als ich 2015 über diese Themen nachdachte, ließ ich mich von einer alten Extreme Programming-Praxis leiten, nämlich der Systemmetapher . Da ich in der Telekommunikationsbranche gearbeitet habe, war es nicht allzu weit hergeholt, PagerDuty als eine Art fortschrittlichen (Telekommunikations-)Switch zu betrachten: Dinge kommen rein, Regeln und Logik leiten sie weiter und ändern sie, und Dinge gehen raus. Wie bei jeder Analogie kann man sie so weit ausdehnen, wie man will (betrachten Sie einen Vorfall als offenen Stromkreis), aber für mich war es genug, ein wenig zu blinzeln und zu erkennen, dass es eine brauchbare Metapher war.

Wenn Sie „Telekommunikation“ und „Programmiersprache“ sagen, sagen Sie „ Erlang .” Ich habe mir Erlang schon einmal angesehen, aber die Sprache hat mich nie angesprochen und in der Vergangenheit hat sie nie wirklich den Sweet Spot für die Systeme getroffen, an denen ich gearbeitet habe. Diesmal schien der „Sweet Spot“-Teil jedoch zu stimmen, aber trotzdem – eine Sprache, die auf Prolog basierte, viele Dinge rückwärts machte (wie das Verwechseln von Groß- und Kleinschreibung), sich wie C mit Header-Dateien anfühlte … das wäre schwer zu verkaufen.

Also legte ich die Idee beiseite, machte mich wieder an die Arbeit und vergaß sie, bis ich ein oder zwei Monate später zufällig auf Elixir stieß. Jetzt Das war interessant! Jemand mit Ruby/Rails-Kenntnissen machte sich auf den Weg und baute eine Sprache auf der Basis von Erlangs virtueller Maschine: Eine, die modern, schnell, sehr hochrangig war, Makros im Lisp/Scheme-Stil hatte, Und gab immer noch vor, nett zu den Benutzern (und nicht zu den Doktoranden) zu sein.

Es ist unnötig zu erwähnen, dass es sofort den ersten Platz auf meiner Liste der „Sprachen, die ich dieses Jahr lernen möchte“ einnahm und ich begann, die Dokumentation, Beispielcode usw. durchzuarbeiten. Was versprochen wurde, hielt, was es versprach – es übertraf die Erwartungen sowohl bei der Ausführung als auch bei der Entwicklungsgeschwindigkeit. Und außerdem war die Entwicklung in Elixir einfach Spaß .

Nachdem ich mich ein wenig mit der Materie beschäftigt hatte und immer mehr davon überzeugt war, dass dies Scala tatsächlich überflüssig machen, Ruby-Benutzern gegenüber freundlicher sein und uns insgesamt schneller und unterhaltsamer machen könnte, begann ich, nach dem gefürchteten Pilotprojekt zu suchen.

Wir stellen vor: Elixir

Die Einführung von Sprachen ist eine heikle Angelegenheit. Die Einführung neuer Programmiersprachen ist mit hohen Kosten verbunden, die jedoch selten berücksichtigt werden. Sie müssen also sicher sein. Und der einzige Weg, dies zu erreichen, ist, paradoxerweise, anzufangen und zu sehen, was passiert. Daher muss ein Pilotprojekt mit vollem Einsatz durchgeführt werden, unternehmenskritisch sein und komplex, aber dennoch begrenzt genug sein, damit Sie den Stecker ziehen und alles in einer Ihrer alten Sprachen neu schreiben können.

Für mein Team ergab sich die Gelegenheit, als wir eine „Rails-native“ Möglichkeit suchten, um transaktional mit Kafka zu kommunizieren. Um den Anlauf für die MySQL-transaktionslastige Rails-App zu erleichtern, wollten wir ein System erstellen, das im Wesentlichen eine Datenbanktabelle nach Kafka-Nachrichten durchsucht und diese an Kafka sendet. Obwohl wir wussten, dass dies nicht wirklich die beste Art der Interaktion mit Kafka war, konnten wir damit einfach Kafka-Nachrichten als Teil der aktuellen ActiveRecord-Transaktion senden. Dadurch war es wirklich einfach, vorhandenen Code mit Kafka-Nebeneffekten zu erweitern und zu überlegen, was bei Rollbacks usw. passieren würde.

Wir haben uns für dieses Projekt als unseren Elixir-Piloten entschieden – es war von hohem Wert und die ersten geplanten Kafka-Nachrichten würden auf unserem kritischen Benachrichtigungspfad liegen, aber es war dennoch sehr in sich geschlossen und hätte bei einem Scheitern des Projekts relativ einfach in Scala wiederholt werden können. Es kommt nicht oft vor, dass man auf den nahezu perfekten Kandidaten für einen neuen Sprachpiloten stößt, aber da war er. Wir stürzten uns ins kalte Wasser und kamen einige Wochen später mit einem neuen Dienst heraus, der viel Feinabstimmung und Gestaltung erforderte, aber Elixir stand uns dabei nie im Weg.

Natürlich hat das nicht das ganze Unternehmen dazu gebracht, zu sagen: „Toll, lasst uns alles stehen und liegen lassen und alles, was wir haben, in Elixir neu schreiben“, aber es war ein wichtiger erster Schritt. Wir begannen zu missionieren, halfen dabei, ein paar weitere Projekte in anderen Teams zu inkubieren und vergrößerten langsam die Präsenz der Sprache. Wir versuchten auch, Leute einzustellen, die Elixir mochten, veranstalteten viele Elixir-Treffen in Toronto, um mit der lokalen Community in Kontakt zu kommen, und – langsam aber sicher – begann ein Team nach dem anderen, die Sprache zu übernehmen. Heute haben wir eine gute Mischung aus Teams, die voll auf Elixir setzen, Teams, die gerade erst anfangen, und Teams, die noch auf das erste Projekt warten, bei dem sie sagen können: „Das machen wir in Elixir.“

Elixir hat sich größtenteils von selbst verkauft: Es funktioniert, es basiert auf einer grundsoliden Plattform, der Code ist sehr verständlich, da die Community eine gesunde Abneigung gegen die Art von „Magie“ hat, die Rails ausmacht, und es ist ziemlich einfach zu verstehen, da es nur eine kleine Oberfläche hat. Mittlerweile ist es ziemlich unwahrscheinlich, dass irgendetwas, das durch PagerDuty fließt, nicht von Elixir-Code berührt wird. Dieses Jahr setzen wir voll darauf, indem wir einige wichtige Funktionsteile aus ihren Legacy-Stacks in Elixir übernehmen, und es besteht keinerlei Zweifel daran, dass Elixir in der Lage sein wird, die Art von Datenverkehr zu bewältigen, mit dem PagerDuty im Jahr 2018 zu kämpfen hat. Von der ersten Ahnung über den Pilotversuch bis hin zur Produktion im großen Maßstab war es eine ziemlich sanfte Fahrt, und einige von uns hoffen insgeheim, dass wir uns eines Tages nur noch mit Elixir-Code befassen müssen.

Ein Artikel über Elixir wäre nicht vollständig, wenn man nicht die Führung der Community loben würde, angefangen beim Elixir-Erfinder José Valim, dem ich die Kultur der Sprache größtenteils zuschreibe. Elixir hat eine der nettesten und hilfsbereitesten Communities überhaupt, und ob auf Slack, im Elixir-Forum oder auf anderen Kanälen wie Stack Overflow und IRC, die Leute sind höflich, hilfsbereit und kooperativ. Es gibt nur wenige Debatten und die Geschwindigkeit des Fortschritts ist erstaunlich. Allein das macht Elixir einen Versuch wert.

Möchten Sie mehr über Elixir erfahren? PagerDuty Techniker finden Sie normalerweise unter San Francisco Und Toronto Meetups. Und wenn Sie daran interessiert sind, bei PagerDuty mitzumachen, sind wir immer auf der Suche nach großartigen Talenten – schauen Sie sich unsere Karriereseite für aktuell offene Stellen.