Elixir: Zaubertrank für Digitalisierung?
Wer Lösungen für digitale Services (Mobility, eHealth u.ä.) und/oder das Internet of Things (IoT) entwickelt, muss sehr genau überlegen, welche Technologie dafür dauerhaft tragfähig genug ist. Das ist keine einfache Wahl, denn neben den spezifischen Anforderungen der Lösung wird sie in der Regel folgende Qualitätsanforderungen erfüllen müssen: skalierbar/elastisch, nebenläufig, verteilt, reaktiv, robust, sicher, integrierbar, konnektierbar. Nur mit der Kombination dieser Eigenschaften lassen sich fürs Internet Lösungen entwickeln, die auch bei steigender Benutzerzahl eine gute UX (Uxer Experience) bieten. All das soll mit hervorragender Wartbarkeit und Produktivität einhergehen, da die „time-to-market“ über die Verteilung dieser Zukunftsmärkte entscheidet. Die Standardtechnologien, die in deutschen Unternehmen für „Enterprise-Anwendungen“ verwendet werden (vor allem .NET, JEE, Spring), sind diesen Herausforderungen nur bedingt gewachsen. Auf diese Stacks zu setzen, nur weil man Personal dafür hat, wäre sehr kurzsichtig. Zumal auch Ihr Personal irgendwann mal auf moderne Umgebungen wechseln will.
Ich möchte Ihnen in diesem Beitrag eine Technologie vorstellen, die m.E. für Digitalisierung und IoT ein Standard werden kann, wie es Java/JEE im Enterprise-Umfeld war: Elixir.
Elixir ist eine Programmierumgebung, die folgende Vorteile auf sich vereint:
- Eine leichtgewichtige, schnell erlernbare, aber denoch sehr mächtige, funktionale Programmiersprache
- Ein sehr gute erweiterbare Entwicklungs- und Build-Umgebung
- Eine sehr aktive Community
- Hervorragende Unterstützung für verschiedenste Zielplattformen vom Web bis Embedded Devices
- Basiert auf der stabilsten Software-Plattform der Welt
Wegen der Kombination dieser Vorteile kann Elixir trotz seiner Jugend (erst 2012 veröffentlicht) eine beeindruckende Entwicklung aufweisen und hat gute Chancen, eine der Standard-SW-Technologien der nächsten Jahrzehnte zu werden.
Die stabilste Plattform der Welt: Erlang/BEAM
Für die Wahl einer Entwicklungstechnologie ist vor allem entscheidend, dass sie das Erreichen der Qualitätsanforderungen überhaupt ermöglicht, besser aber proaktiv unterstützt. Ein Negativbeispiel ist Ruby (on Rails). Diese bei Entwicklern sehr beliebte Technologie ist letztendlich daran gescheitert, dass sie in der betrieblichen Praxis nicht leistungsstark genug war. Übrigens wird sie bei vielen Internetfirmen, die mit Ruby on Rails auf zunehmende Skalierungsprobleme stießen, gerade durch Elixir ersetzt (dessen Sprach- und Tooldesign sich u.a. an der Leichtgewichtigkeit von Ruby orientiert hat).
Elixir ist in Hinblick auf Betriebstauglichkeit hervorragend aufgestellt (und übrigens viel besser als z.B. JVM-basierende Lösungen), weil es quasi auf den Schultern eines kampferprobten Giganten steht: OTP. Auch wenn Sie dieses Kürzel noch nie bewußt wahr genommen haben, besteht zumindest eine sehr hohe Wahrscheinlichkeit, dass Sie sich täglich mehrfach auf seine Stabilität verlassen (können).
OTP steht für Open Telecommunication Platform, ist die Basis für Steuerungssoftware in Vermittlungseinheiten, sogenannten Switches und gilt als die stabilste Software-Plattform der Welt. Sie schultert ein riesiges Daten- und Kommunikationsvolumen, nämlich schätzungsweise 50% des weltweiten Mobilfunk-Verkehrs! Das heißt natürlich, dass es sich um eine massiv verteilte und nebenläufige Plattform handelt. In Informatiker- und Ingenieurskreisen ist OTP aber vor allem für eines legendär: Ihre unfassbare Stabilität bzw. Fehlertoleranz. Als Beleg dafür wird gerne eine gemessene Verfügbarkeit von 99,9999999% kolportiert – umgerechnet bedeutet das eine „Ausfallzeit“ von ca. 3 Sekunden (pro Jahr!). Wohlgemerkt für einzelne Systeme, nicht erst durch Redundanz im Gesamtsystem erzielt. Von keiner anderen SW-Plattfom sind auch nur annähernd so gute Zahlen für Einzelsysteme bekannt. Die werden i.d.R. schon durch zwei Dinge unmöglich gemacht: Abstürze und „Wartungsfenster“.
Möglich ist eine solche Stabilität nur, weil sie von Anfang an das treibende Entwurfsziel war. Als die Vermittlungstechnologie in den 1980ern zunehmend von mechanischer (die guten alten „Hebdrehwähler“) auf digitale Steuerung umgestellt wurde, überlegte der schwedische Telekom-Anbieter Ericsson, wie man die für ein Telefonnetz nötige Stabilität und Verfügbarkeit gewährleisten könnte, während gleichzeitig Software ab einem gewissen Komplexitätsgrad als immanent fehlerhaft galt und auch häufig aktualisiert werden musste. Und das alles sollte auch noch auf Basis der sehr eingeschränkten (Embedded-)Hardware-Möglichkeiten der 1980er Jahre möglich sein.
Aus den Versuchen mit den damaligen Plattformen wurde sehr schnell deutlich, dass eine völlig neue Art von Software-Plattform und Software-Design nötig sein würde. Schließlich führte das zu einem bis heute ungeschlagenem Power-Team: Die aktoren-/message-basierte Programmiersprache Erlang (Ericsson Language) und die dazugehörige virtuelle Maschine BEAM.
„Let it crash!“ – Aktorsysteme und ihre Supervision Trees
Der entscheidende Gedanke beim Entwurf von Erlang war folgender: Da man Software bekanntlich nicht garantiert fehlerfrei erstellen kann, muss man Softwaresysteme fehlertolerant machen, um sie verfügbar zu halten. Das heißt, man muss einzelne Softwareteile so gut wie möglich isolieren, damit Fehler sich nicht ausbreiten können, und überwachen, um auf Abstürze kontrolliert zu reagieren.
Diese Idee hatte Carl Hewitt bereits 1973 in seinem Aktorenmodell vorgestellt: Software wird in kleine eigenständige Einheiten, sog. Aktoren, aufgeteilt. Diese sind vollständig voneinander getrennt und kommunizieren nur über den Austausch von Nachrichten miteinander. Um die Semantik von Systemen abzubilden, werden Aktoren in Supervison Trees angeordnet, die Aktoren miteinander bekannt machen und auf den Tod von Aktoren z. B. durch Exceptions, die üblicherweise nicht abgefangen werden) geordnet reagieren. Aktoren haben auch im Design einen Vorteil: Dadurch dass sie relativ klein und komplett voneinander getrennt sind, ist es viel einfacher, die in ihnen abgebildete Logik konsistent zu beschreiben und zu testen.
Joe Armstrong, der Vater von Erlang adaptierte dieses Modell in seine Sprache und schuf mit BEAM eine virtuelle Maschine, die die Aktoren nativ unterstützt. Denn für Aktoren (in Erlang heißen sie Prozesse) sind folgende Dinge wichtig: Sie müssen extrem leichtgewichtig sein, einen absolut abgeschlossenen Adressraum besitzen und bedingungslosem preemptivem Multitasking unterliegen. Diese Kriterien zusammen ermöglichen auf der BEAM eine massive Nebenläufigkeit in Quasi-Echtzeit. Weil die BEAM nicht als generische Betriebssystem-Virtualisierung (wie die JVM), sondern auf Basis des Aktorenmodells entworfen wurde, gilt sie bis heute als dessen beste Implementierung und ist anderen Aktor-Implementierungen (z.B. AKKA auf der JVM) überlegen, weil diese sich letztendlich immer wieder auf tendenziell ungeeignete Betriebssystem-Mittel wie Threads stützen müssen. Auf der BEAM ist es unproblematisch möglich, Systeme mit Hunderttausenden Aktoren zu betreiben, weil sowohl Startup-Zeit als auch Footprint eines Aktors minimal sind. Korrekt entworfene Aktorsysteme (mit guten Supervision Trees) sind auf dieser Basis – wissenschaftlich ausgedrückt – sauschnell und quasi „unkaputtbar“.
Neben seiner Hausdomäne Telekommunikation ist Erlang/BEAM nicht von ungefähr die technische Basis bekannter sehr leistungsfähiger Systeme wie CouchDB, RabbitMQ, Riak, ejabberd (XMPP Server, den z.B. Facebooks Chat benutzt) und dem Messenger-Service von WhatsApp.
Das Aktormodell war auch die Grundlage für eine andere Entwurfsanforderung an die OTP, Hot Code Replacement. Dadurch dass das System nur aus lauter über Nachrichten kommunizierende Aktoren besteht, deren Ersatz ohnehin im Entwurf vorgesehen ist, ist es natürlich auch möglich, bei einem solchen Ersatz auch eine neue Softwareversion einzuspielen, ohne dass das System dazu heruntergefahren werden müsste. Wie gut das funktioniert, zeigt Elixirs Erweiterung Subprojekt Nerves für die Programmierung von Embedded-Systemen: Nachdem man einmal ein Elixir-Projekt auf die Zielhardware geflasht hat, kann man weitere Softwareversionen über das Netz darauf spielen (und über das Netzt übrigens auch das eingebettet laufende System remote monitoren). Elixir hält so gar jeweils zwei Images vor. Dadurch kann bei Fehlern der neuen Version schnell wieder auf die alte zurückgeschaltet werden.
Einfach, sicher, produktiv: Elixir als funktionale Programmiersprache
In der Zeit des zunehmenden Fachkräftemangels ist es wichtig, Entwicklern eine Technologie an die Hand zu geben, die sie schnell erlernen und beherrschen können, die sicheren und ausdrucksstarken Code fördert und fordert und die durch Syntax und Tooling Spaß, Akzeptanz und Produktivität der Entwickler fördert.
Eine solche Umgebung bringt nicht selten eine um Faktor 5 bis 10 höhere Produktivität ggü. etablierten Technologien hervor, was das Argument des Ausbildungsbedarfs recht schnell ad absurdum führen kann. Ein weiterer Aspekt ist hierbei nicht zu übersehen: Im „war for talents“ hat man größerere Aussicht auf junge Talente, wenn man ihnen die Möglichkeit gibt, in solchen modernen Umgebungen zu abreiten, in denen sie (auch für sich selbst) die Zukunft sehen. Kein guter Berufsanfänger will sich heute noch ernsthaft mit Java u.ä. Sprachen herumschlagen (so wie bei uns in den 80er Jahren das etablierte COBOL nicht die erste Wahl war).
Elixir hat es geschafft, über die stabile Plattform Erlang/BEAM eine moderne, funktionale, dynamische Programmiersprache mit entsprechendem Tooling zu legen. Ich habe schon zig Programmiersprachen in meiner Karriere erlernt, aber ich war selten schon nach kürzester Zeit so nachhaltig von einer überzeugt wie von Elixir.
Wer die Vorteile der funktionalen Programmierung anhand von konkreten Elixir-Codebeispielen kennen lernen möchte, sei auf meine Blogserie hingewiesen: Einfach, sicher, produktiv: Funktionale Programmierung
Welche Zielplattform darf es sein?
Angesichts der Basis Erlang/BEAM, die auf allen gängigen Plattformen läuft, verwundert es nicht, dass es auch für Elixir schon Subprojekte gibt, die diese Plattformvielfalt nutzen.
Standalone: Erlang/Beam ist für die üblichen Server/Desktop-Betriebssysteme verfügbar (ähnlich wie die JVM), eignet sich somit hervorragend für die Entwicklung von Standalone-Anwendungen und Utitilies
Web: Der Standard für moderne Anwendungen / Services ist natürlich das Web. Elixir bietet hier mit dem Server Phoenix eine sehr gut entworfene, und auf der Basis von Pipes&Filters extrem gut erweiterbare Lösung an, die nicht nur für HTTP(s) mit den verschiedenen Mime-Types geeignet ist, sondern auch mit den sogenannten Channels eine sehr leistungsfähige Websocket-Implemetierung bietet. Verblüffend ist vor allem die Geschindigkeit: Wer das erste mal mit Phoenix rum experimentiert, wundert sich nicht selten über Antwortzeiten im Bereich von Mikro-(statt Milli-)sekunden. Und vor kurzem wurde demonstriert, dass Phoenix auf einem einzelnen Server 2 Mio. aktive Websockets parallel bedienen kann – bei voller Nebenläufigkeit und ohne Performance-Einbußen.
Embedded: In Hinblick auf kommende immer komplexere IoT-Szenarien ist es besonders erfreulich, dass man jetzt auf Embedded-Devices endlich eine Alternative hat, die ermöglicht mit dem gleichen nebenläufigen funktionalen Software-Design zu arbeiten. Da Erlang/BEAM ja für diesen Bereich entworfen wurde, ist das auch naheliegend. Mit Nerves gibt es ein Subprojekt, mit dem sich sehr schnell Projekte für gängige Embedded-Zielumgebungen generieren lassen, die oft auch schon gute APIs für Aktuatoren, Sensoren, Displays und ähnliche Peripherie mitbringen
Location-Transparency: Zum Thema Zielplattformen sei ein weiterer Vorteil der Aktorimplementierung von Erlang genannt, die natürlich auch in Elixir verfügbar ist. Ein Aktorsystem kann über viele Nodes / Devices verteilt sein. Solange diese in einem TCP-Netz verbunden sind, können sie untereinander direkt kommunizieren, als wenn sie im selben Adressraum lägen. Das ermöglicht die Art von nebenläufigen, lose gekoppelten Peer-to-Peer-Netzwerken, wie wir sie in der IoT-Zukunft immer stärker werden implementieren müssen
Fazit
Ich habe darzulegen versucht, welche Vorteile Elixir in sich vereint. M.E. ist es damit einer der heißesten Kandidaten, wenn es um die Frage geht, mit welcher Technologie sich Digitalisierung und IoT am ehesten erschließen lassen.
Ich kann sowohl als IT-Stratege/-Architekt als auch als Entwickler, der ich im Herzen immer geblieben bin, sehr gut nachvollziehen, warum Elixir in den letzten Jahren soviel Furore macht, eine Konferenz nach der anderen aus dem Boden schießt und man vor allem wirklich beeindruckende Success Stories hört. Nicht einmal Googles Go kann da mithalten.
JEE, .NET und Spring sind Technologien, die uns im Umfeld der Enterprise-IT vorangebracht haben. Dort waren sie gut und den Anforderungen angemessen. Die Zukunft von Digitalisierung/IoT gehört diesen Technologien nicht, weil Ihr Entwurf den dortigen Anforderungen nicht ausreichend genügt. Wenn Sie sich deshalb aber ohnehin nach einer neuen Technologie für Ihre Digitalisierungsprojekte umsehen müssen, ziehen Sie Elixir ernsthaft in Betracht. Ich sehe weit und breit keine andere Technologie, die gleichzeitig so reif und so modern ist.