Bei der Gründung von PagerDuty war Entwicklungsgeschwindigkeit von entscheidender Bedeutung – daher dürfte es nicht überraschen, dass Rails anfangs die einzige von uns verwendete Technologie war. Schon bald stieß das Gründungsteam an Grenzen und sah sich nach Alternativen um. So wurde Scala eingeführt, um die Skalierung zu erleichtern.

Es besteht jedoch eine große Kluft zwischen Scala und Ruby, sowohl was die Erscheinungsbilder der Sprachen als auch die Prioritäten der jeweiligen Communitys betrifft; kurz gesagt, das gesamte Nutzererlebnis. Die Ruby-Community, insbesondere die Rails-Sub-Community, legt größten Wert auf die Entwicklererfahrung und stellt sie über nahezu alles andere. Scala hingegen hat eher akademische und formalistische Wurzeln und versucht, seine Nutzer davon zu überzeugen, dass Korrektheit über so ziemlich allem steht.

Es ließ mir keine Ruhe, und es schien, als gäbe es eine schwer zu überbrückende Lücke in unserem Technologie-Stack. Scala würde unsere Hauptseite wohl kaum antreiben, und obwohl wir eine bessere Performance und Skalierbarkeit benötigten, als Ruby und Rails bieten konnten, war die Diskrepanz enorm, und ein Wechsel wäre umständlich gewesen. Auch die ursprüngliche Scala-Codebasis stieß auf wenig Begeisterung, da sich schnell herausstellte, dass das Schreiben von sauberem und wartbarem Scala-Code schwierig war und einige Technologieentscheidungen die Skalierung komplizierter machten als erwartet.

Als ich 2015 über diese Fragen nachdachte, ließ ich mich von einer alten Praxis des Extreme Programming leiten, nämlich der des Systemmetapher Da ich einige Zeit in der Telekommunikationsbranche gearbeitet habe, lag es nahe, PagerDuty als eine Art hochentwickelte (Telekommunikations-)Vermittlungsstelle zu betrachten: Daten kommen an, Regeln und Logik leiten und verändern sie, und Daten gehen wieder aus. Wie bei jeder Analogie kann man sie beliebig weit treiben (einen Vorfall beispielsweise als Unterbrechung betrachten), aber mir reichte es, die Metapher etwas genauer zu betrachten und zu erkennen, dass sie durchaus brauchbar war.

Wenn man „Telekommunikation“ und „Programmiersprache“ sagt, sagt man: „ Erlang Ich hatte mir Erlang schon mal angesehen, aber die Sprache hatte mich nie wirklich angesprochen, und in der Vergangenheit passte sie einfach nicht zu den Systemen, an denen ich gearbeitet habe. Diesmal schien der „optimale Ansatz“ jedoch zu stimmen, aber trotzdem – eine Sprache, die auf Prolog basiert, vieles falsch macht (zum Beispiel Groß- und Kleinschreibung verwechselt) und sich wie C mit Headerdateien anfühlt … das wäre schwer zu vermitteln.

Also legte ich die Idee beiseite, ging wieder an die Arbeit und vergaß sie, bis ich ein oder zwei Monate später zufällig auf Elixir stieß. Das Das war interessant! Jemand mit Ruby/Rails-Kenntnissen machte sich an die Arbeit und entwickelte eine Sprache auf Basis der Erlang Virtual Machine: Eine moderne, schnelle, sehr hochstufige Sprache mit Makros im Lisp/Scheme-Stil. Und Er gab weiterhin vor, freundlich zu den Nutzern (und nicht zu Doktoranden) zu sein.

Selbstverständlich landete es sofort ganz oben auf meiner Liste der Programmiersprachen, die ich dieses Jahr lernen wollte, und ich begann, mich durch die Dokumentation, Beispielcode usw. zu arbeiten. Was versprochen wurde, hielt – es übertraf meine Erwartungen sowohl in der Ausführung als auch in der Entwicklungsgeschwindigkeit. Und außerdem war die Entwicklung in Elixir einfach nur genial. Spaß Die

Nachdem ich erste Erfahrungen gesammelt hatte und immer mehr davon überzeugt war, dass dies tatsächlich die Notwendigkeit von Scala beseitigen, Ruby-Benutzern entgegenkommender sein und uns insgesamt schneller und gleichzeitig unterhaltsamer machen könnte, begann ich, nach dem gefürchteten Pilotprojekt zu suchen.

Wir stellen Elixir vor

Die Einführung neuer Programmiersprachen ist knifflig. Sie ist mit hohen Kosten verbunden, die jedoch selten berücksichtigt werden. Daher ist absolute Sicherheit unerlässlich. Und paradoxerweise lässt sich diese nur durch einfaches Abwarten und Beobachten der Ergebnisse gewährleisten. Ein Pilotprojekt muss daher ein hohes Risiko bergen, missionskritisch sein und zwar komplex, aber gleichzeitig so begrenzt, dass man jederzeit abbrechen und alles in einer der gewohnten Sprachen neu schreiben kann.

Für mein Team ergab sich die Gelegenheit, als wir eine „Rails-native“ Möglichkeit zur transaktionalen Kommunikation mit Kafka benötigten. Um den Einstieg in unsere MySQL-transaktionsintensive Rails-Anwendung zu erleichtern, wollten wir ein System entwickeln, das im Prinzip eine Datenbanktabelle nach Kafka-Nachrichten durchsucht und diese an Kafka sendet. Obwohl wir wussten, dass dies nicht die optimale Methode zur Interaktion mit Kafka war, ermöglichte sie uns, Kafka-Nachrichten einfach als Teil der aktuellen ActiveRecord-Transaktion auszugeben. Dadurch konnten wir bestehenden Code problemlos um Kafka-Nebeneffekte erweitern und die Auswirkungen von Rollbacks usw. analysieren.

Wir entschieden uns für dieses Projekt als Elixir-Pilotprojekt – es war sehr wertvoll, und die ersten geplanten Kafka-Nachrichten sollten auf unserem kritischen Benachrichtigungspfad liegen. Gleichzeitig war es sehr in sich abgeschlossen und hätte sich im Falle eines Scheiterns relativ einfach in Scala neu implementieren lassen. Es kommt nicht oft vor, dass man auf einen nahezu perfekten Kandidaten für ein Pilotprojekt mit einer neuen Sprache stößt, aber genau das war der Fall. Wir stürzten uns ins kalte Wasser und präsentierten einige Wochen später einen neuen Dienst, der zwar noch einiges an Feinabstimmung und Anpassung erforderte, aber Elixir stand uns dabei nie im Weg.

Natürlich führte das nicht dazu, dass das gesamte Unternehmen sofort auf Elixir umstellte und sagte: „Super, lasst uns alles hinschmeißen und alles in Elixir neu schreiben.“ Aber es war ein wichtiger erster Schritt. Wir begannen, Elixir zu bewerben, unterstützten weitere Projekte in anderen Teams und trugen so langsam zur Verbreitung der Sprache bei. Wir versuchten auch, Mitarbeiter einzustellen, die Elixir mochten, veranstalteten zahlreiche Elixir-Meetups in Toronto, um mit der lokalen Community in Kontakt zu treten, und – langsam aber sicher – begannen immer mehr Teams, die Sprache zu übernehmen. Heute haben wir eine gute Mischung aus Teams, die vollständig auf Elixir setzen, Teams, die gerade dabei sind, ihre Kenntnisse aufzufrischen, und Teams, die noch auf das erste Projekt warten, bei dem sie sagen können: „Das machen wir in Elixir.“

Elixir hat sich im Grunde von selbst verkauft: Es funktioniert, basiert auf einer soliden Plattform, der Code ist sehr verständlich, da die Community eine gesunde Abneigung gegen die Art von „Magie“ hegt, die Rails ausmacht, und es ist dank seiner überschaubaren Oberfläche recht einfach zu erlernen. Mittlerweile ist es äußerst unwahrscheinlich, dass irgendetwas, das über PagerDuty läuft, nicht mit Elixir-Code in Berührung kommt. Dieses Jahr setzen wir stark darauf, indem wir einige wichtige Funktionen aus unseren bestehenden Systemen nach Elixir migrieren. Es besteht kein Zweifel daran, dass Elixir den Datenverkehr, mit dem PagerDuty 2018 konfrontiert ist, problemlos bewältigen kann. Von der ersten Idee über die Pilotphase bis hin zum produktiven Einsatz verlief alles reibungslos, und einige von uns hoffen insgeheim, dass wir eines Tages ausschließlich mit Elixir-Code arbeiten müssen.

Ein Artikel über Elixir wäre unvollständig ohne ein Lob an die Führungsriege der Community, allen voran Elixir-Erfinder José Valim, dem ich die Kultur der Sprache maßgeblich zuschreibe. Elixir verfügt über eine der freundlichsten und hilfsbereitesten Communitys überhaupt. Ob auf Slack, im Elixir-Forum oder in anderen Kanälen wie Stack Overflow und IRC – die Mitglieder sind stets höflich, hilfsbereit und kooperativ. Diskussionen sind kurz und selten, und die Fortschritte sind beeindruckend. Allein das macht Elixir einen Versuch wert.

Möchten Sie sich näher mit Elixir unterhalten? Die PagerDuty Ingenieure sind in der Regel hier anzutreffen: San Francisco Und Toronto Meetups. Und falls du Interesse hast, PagerDuty beizutreten, wir sind immer auf der Suche nach großartigen Talenten – schau dir unsere Website an. Karriereseite für aktuell offene Stellen.