Vor einiger Zeit sind wir auf ein Produktionsproblem gestoßen: Eine unserer Elixir-Anwendungen reagierte plötzlich zeitweise. Nach einer schnellen Analyse der möglichen Ursachen identifizierten wir einen abrupten und übermäßigen RAM-Verbrauch in Verbindung mit einem schwachen CPU-Verbrauch, der dazu führte, dass die Anwendung jeweils für einige Sekunden nicht mehr reagierte.
Über den Vorfall hinaus ist diese Geschichte interessant, da sie ein perfektes Beispiel für die Belastbarkeit einer in Elixir geschriebenen Anwendung ist. Wenn ein Problem auftritt, kann eine Elixir-Anwendung einige ihrer eigenen Funktionen neu starten und innerhalb weniger Sekunden erneut ausführen. Dies ist ein besonders wichtiges Merkmal für Produkte, die viele Benutzer und/oder eifrige Funktionen haben, wie es bei Welcome to the Jungle (WTTJ) der Fall ist.
Bei WTTJ verwenden wir Elixir seit fünf Jahren in der Produktion, und in diesem Artikel werden wir unser Feedback darüber teilen, wie sich die Dinge entwickelt haben.
Die Geschichte von WTTJ begann nicht mit Elixir. Unsere ersten beiden Minimum Viable Products (MVPs) wurden mit dem Ruby on Rails-Framework geschrieben. Damals konnten wir dank des benutzerfreundlichen Designs und der Gerüste des Frameworks schneller arbeiten. In den ersten zwei Jahren hat sich dieser Stack sehr gut entwickelt: Wir hatten zwei funktionsfähige Produkte, die wir schnell weiterentwickeln konnten.
Aber da Ruby on Rails auf Ruby basiert – einer interpretierten Single-Core-Sprache – war unsere App ein Monolith, der sich nur schwer horizontal skalieren ließ. Und mit der jährlich steigenden Anzahl von Benutzern hatten wir immer mehr Probleme mit Antwortzeiten und Verarbeitungsfehlern. Nach mehreren Versuchen, den Code und die Bibliotheken zu optimieren, stießen wir schnell an die Grenzen der Sprache.
Mitte der 2000er Jahre hatten Multi-Core-Prozessoren den Markt erobert, und es war an der Zeit, eine geeignetere Programmiersprache zu finden, die sowohl Multithreading als auch Multiprocessing unterstützen konnte, um unseren Wachstumsherausforderungen zu begegnen.
Wir haben daher mehrere Sprachen auf den Prüfstand gestellt, hauptsächlich kompilierte Sprachen mit Multicore-Unterstützung: Crystal, Go und Elixir. Trotz seiner Versprechungen war Crystal eine neue und instabile Sprache, und wir wollten einfach nicht riskieren, unser Hauptprodukt mit einer Technologie zu verwalten, die selbst noch Arbeit benötigt. Go wurde ebenfalls schnell ausgeschlossen, da unsere Teams keine Fans der Paradigmen der Sprache waren. Darüber hinaus hätte sich die Entwicklungszeit von Features ohne ein Web-Framework, das den Standards von Ruby on Rails entspricht, erheblich verlängert. Wir haben uns daher für Elixir entschieden, das WTTJ seit September 2018 in der Produktion einsetzt.
Lassen Sie uns jetzt direkt mit unserem Feedback zum Ökosystem der Sprache, den Elementen in Bezug auf die Entwicklung selbst und allem, was mit Bereitstellungen zu tun hat, beginnen.
Das Phoenix-Web-Framework, das mit Elixir geliefert wird, ist zweifellos einer der größten Vorzüge des Ökosystems und hat zur Zustimmung der Sprache in unseren Teams geführt. Obwohl Elixir noch neu war, als wir damit anfingen, konnten wir mithilfe des Frameworks problemlos Webanwendungen erstellen, dank seiner Paradigmen, die Ruby on Rails ähneln, und der Möglichkeit, WebSockets, eine beliebte Technologie bei WTTJ, nativ zu verwenden. Es muss beachtet werden, dass wir dieses Framework hauptsächlich für seine API-Fähigkeiten verwenden und unsere Verwendung der Views- und LiveView-Systeme ziemlich selten ist.
Erwähnenswert ist auch, dass Elixir, obwohl dieser Stack elegant und effizient ist, immer noch eine Nischentechnologie ist. Laut der im Frühjahr 2022 veröffentlichten StackOverflow-Studie geben nur 2,46 % der professionellen Entwickler an, dass sie es verwendet haben oder bald verwenden möchten, obwohl es die zweitbeliebteste Sprache ist (was für ein Paradoxon!). Dies führt zu starken Einschränkungen für Unternehmen, die diese Sprache verwenden.
Zunächst einmal führt diese Nischenpositionierung zu Rekrutierungsherausforderungen: Entwickler mit Erfahrung in Elixir zu finden ist kompliziert. Daher ist es oft notwendig, in Betracht zu ziehen, Entwickler einzustellen, die an der Sprache interessiert sind, aber keine nennenswerte Erfahrung haben, und dann Zeit für deren Schulung aufzuwenden. Dies verursacht zusätzliche Kosten für das Unternehmen, da diese Entwickler ihre Ziele offensichtlich für mehrere Monate nicht erreichen können.
Der andere Nachteil ist natürlich, dass die Community klein ist. Dies bedeutet, dass die Sprache selten integriert ist, Dienstanbieter nicht immer SDKs in der Sprache anbieten und weniger Bibliotheken vorhanden sind, sodass für einige Funktionen weniger Wettbewerb besteht.
Das macht die Community von Elixir jedoch nicht weniger einladend – ganz im Gegenteil! Da Beiträge seltener sind, wird das Vorschlagen neuer Projekte oder das Portieren bestehender Funktionen sehr geschätzt und kann von der Community leichter vorgebracht werden. 2022 freuten wir uns über die Einladung der Denkelixier Podcast, um über unser ecto_anon-Projekt zu sprechen, und unsere Artikel erscheinen auch regelmäßig im ElixirStatus-Newsletter.
Der Hauptvorteil von Elixir für die Entwicklung besteht darin, dass die Sprache funktional ist, was bedeutet, dass sie hauptsächlich deklarativ ist und ihre Variablen unveränderlich sind. Darüber hinaus hat der Schöpfer der Sprache, José Valim, ein ehemaliger Kernentwickler des Ruby on Rails-Projekts, Elixir eine „Ruby-ähnliche“ Syntax gegeben. Er hat es möglich gemacht, mehrere bemerkenswerte Funktionen zu implementieren, wie z externe APIs, zum Beispiel.
Der Einfluss von Ruby on Rails hat Elixir auch die Logik von Active Record gegeben, einem objektrelationalen Zuordnungssystem (ORM). Nach unserem Verständnis hat sich Elixir bei der Erstellung des SQL-Wrappers Ecto an Active Record orientiert, der sich auf explizite Abfragen konzentriert, selbst wenn der Code ausführlich ist. Aber während Sie mit Active Record nur Abfragen in objektorientierter Sprache schreiben können, was bedeutet, dass Sie potenzielle SQL-Optimierungen verlieren, erlaubt Ihnen Ecto, SQL so zu schreiben, als wäre es objektorientiert.
Die Elixir-Sprache erleichtert auch die Verwendung von testgetriebener Entwicklung (TDD) aufgrund der Art und Weise, wie der Code kompiliert wird. Wenn es eine frühere Kompilierung in Elixir gibt, kompiliert der Compiler einfach neu, was sich geändert hat, und dieser Vorteil ist proportional zur Größe der Anwendung. Bei einigen anderen Sprachen müssen Sie, wenn Sie eine umfangreiche Anwendung von Grund auf neu kompilieren, mehrere Kompilierungen für jede winzige Codeänderung ausführen. Wenn Ihr Code gut strukturiert ist, können aufeinanderfolgende Testläufe in unglaublicher Geschwindigkeit durchgeführt werden.
Ein weiterer Vorteil des Elixir-Ökosystems ist Plug, das Sie höchstwahrscheinlich verwenden werden, wenn Sie an Webanwendungen arbeiten. Diese großartige Bibliothek ermöglicht Ihnen die einfache Verwendung von Tools oder Bibliotheken in Ihrem Projekt, z. B. die Integration des Cowboy-Webservers in zwei Codezeilen. Es ermöglicht Ihnen aber auch, alle Ihre Adapter zu verknüpfen, wie z. B. Ihren benutzerdefinierten Anwendungsrouter oder das Websitzungsverwaltungssystem.
Elixir bringt jedoch auch einige Herausforderungen mit sich. Eines der Probleme, auf die wir zuerst stießen, betraf die Verwaltung von Konfigurationsvariablen. Viele Dinge werden in der Version zur Kompilierzeit festgelegt, während wir zuvor dynamische On-Demand-Umgebungen bei WTTJ hatten. Wir mussten daher dieselbe Version mit unterschiedlichen Konfigurationsvariablen ausführen. Es sollte jedoch beachtet werden, dass sich die Tools zum Verwalten von Kompilierzeit- und Laufzeitvariablen seitdem weiterentwickelt haben und diese Unterscheidung jetzt einfacher ist.
Das Startverfahren für Rake-Tasks wurde auch durch den Wechsel zu Elixir und Phoenix beeinflusst. Die Sprache bietet die Möglichkeit, Mix-Tasks mit Mix zu starten, allerdings sind diese Tasks nur in der Entwicklungsumgebung verfügbar, da Mix kein für die Produktion vorgesehenes Tool ist. Daher war es notwendig, Ausflüchte einzurichten, um bestimmte Migrationsaufgaben in der Produktion durchführen zu können.
Bei der Erstellung einer Freigabe sind einige Regeln zu beachten. Eine der feststen Regeln ist, dass die Kompilierungs- und Ausführungsumgebungen ad hoc sein müssen: Der Code muss mit derselben Prozessorfamilie, derselben Distribution kompiliert werden (die Verwendung derselben Distributionsfamilie, z. B. Ubuntu und Debian, reicht nicht aus), und die gleiche Version. Dies hat viele Auswirkungen auf den Prozess der Einrichtung des Lieferprozesses. Wenn Sie Ihre Produktionsumgebung aktualisieren, müssen Sie zuerst Ihren Integrationsprozess aktualisieren und natürlich testen. Elixir hat jedoch einen unbestreitbaren Vorteil: Es ermöglicht Ihnen, sein Ökosystem darin einzubetten – es besteht keine Notwendigkeit, Erlang oder Elixir auf dem Zielcomputer zu installieren! Während dieses Sprachfeature umfangreichere Veröffentlichungen von mehreren Megabyte generiert, begrenzt es auch die Reibung im Bereitstellungsprozess entscheidend.
Da Elixir auf der virtuellen Maschine Erlang basiert, einer Sprache, die ursprünglich der Telekommunikation gewidmet war, besteht einer der Vorteile darin, dass in Elixir geschriebene Anwendungen sehr gut in Clustern funktionieren. Es gibt Protokolle, mit denen sie einfach kommunizieren und so die allgemeine Ausfallsicherheit verbessern können.
Dazu stützt sich Elixir auf GenServers (für generische Serverprozesse), bei denen es sich um interne Prozesse der Anwendung handelt, die es ermöglichen, Zustände und Verhaltensweisen zu isolieren. Die Hauptstärke dieser GenServer besteht darin, dass sie einer Anwendung ein hohes Maß an Flexibilität verleihen, insbesondere durch die Verwendung des Überwachungsbaums, der es ermöglicht, fehlertolerant zu sein, indem fehlerhafte Prozesse isoliert werden, ohne die gesamte Anwendung herunterzufahren. Erinnern Sie sich an unsere zu Beginn dieses Artikels erwähnte Anwendung, die einige Sekunden lang nicht mehr reagierte? Dies war auf einen Neustart des GenServers zurückzuführen.
Es gibt auch mehrere verteilte Speichersysteme im Rahmen des OTP (Open Telecom Platform), wie etwa ETS, DETS und Mnesia. Wir haben Mnesia, ein verteiltes Echtzeit-Datenbankmanagementsystem (DBMS), in einigen Projekten bei WTTJ verwendet, um den Zugriff auf schnelle Informationen innerhalb eines Clusters zu beschleunigen und zu erleichtern.
Das System zum Bereitstellen von Elixir-Anwendungen kann jedoch für Anfänger kompliziert zu verwenden sein. Als wir anfingen, die Sprache zu verwenden, hatten wir Schwierigkeiten mit Distillery (das jetzt veraltet ist), was durch den Mangel an verfügbaren Ressourcen zu dieser Zeit noch verschlimmert wurde. Abgesehen von der Komplexität von Compiler- vs. Run-Umgebungen war Distillery damals eine frühe Version eines Release-Systems, das wahrscheinlich nicht an das Web angepasst war. Aber es ist erwähnenswert, dass die Sprache und ihr Ökosystem seitdem erhebliche Fortschritte gemacht haben und wir unsere Anwendungen jetzt mit dem integrierten Mix-Release bereitstellen.
Bedauern wir es also, Elixir als unsere Haupt-Backend-Sprache gewählt zu haben? Absolut nicht! Die Sprache hat sich als sehr stabil erwiesen, obwohl sie relativ neu ist, und insgesamt war die Lernkurve ziemlich ähnlich wie bei jeder anderen funktionalen Sprache. Das Elixir-Universum ist dichter als Sie zunächst erwarten, daher lohnt es sich, sich zu Beginn die Zeit zu nehmen, das Erlang/OTP-Ökosystem vollständig zu verstehen. Aber wie Sie aus unserer Erfahrung wissen, lohnt es sich auf jeden Fall! Haben wir Sie überzeugt? Wenn Sie noch einen Schritt weiter gehen möchten, besuchen Sie die Exercism-Website, die einen kostenlosen, hochwertigen Schulungskurs zum Programmieren mit Elixir anbietet.
Geschrieben von Karl KleinLeiter des SRE @ WTTJ
Danke an Kevin Lacointe und Stéphane Robino für ihre wertvollen Beiträge zu diesem Artikel
Bearbeitet von Anne-Laure Civeyrac
Abbildung von Myriam Waren
Trete unserem Team bei!
