Zusammenfassung der Erlang Factory Lite 2015 in Berlin

Dieses Jahr bin ich wieder voller Vorfreude nach Berlin aufgebrochen, auch weil es ein günstiges Angebot für die ICE-Tickets und das Hotel gab. Das Ticket für die Konferenz ist für das gebotene Program ebenfalls preislich absolut angemessen. Im Vergleich mit anderen Konferenzen also ein richtiger “Schnapper”!

Am Abend vor der eigentlichen Konferenz wurde noch zu #elixbeer Treffen des Berlin.ex Meetup eingeladen, dem ich natürlich gerne gefolgt bin. Dort konnte man entspannt in einer coolen Berliner Kneipe sich mit anderen Erlangern und Alchemisten unterhalten, dazu ein Bier genießen und dies im Anschluß sogar mit Bitcoin bezahlen 🙂 Danke an dieser Stelle an Hugo Duksis für die Organisation des geselligen Treffen.

Neben mir sind noch andere Reisegruppen aus Hamburg nach Berlin gereist. Wie bereits 2014 auch wieder die Jungs von Xing und Synlay Cloud, darunter auch ein paar alte Studienkollegen. Beide Gruppen hatten übrigens je eine Person Zuwachs im Vergleich zum Vorjahr – eine erfreuliche Entwicklung die hoffentlich anhält.

Location: NH Berlin Alexanderplatz

Die Location lag wie dieses Jahr wieder zentral in Berlin und nur wenige Minuten vom Hauptbahnhof entfernt. Im dem 4-Sterne Hotel gab es einen Vortragsraum der über viel Platz für alle Besucher und hochwertige Präsentationstechnik verfügt hat.
Die Verpflegung war Mittags durch ein vorzügliches Buffet des Hotels gesichert und ansonsten wurden durchgängig Getränke/Kaffee und Snacks/Kuchen gereicht. Danke hier an den Sponsor AOL Platforms für die großartige Verpflegung sowie die Goodies, welche den Besucht abgerundet haben.

Überblick der Vorträge

Da es nur einen grossen Vortragsraum gab, konnte auch nur ein Track abgehalten werden. Das Programm hat erstaunlich viele und unterschiedlicheTalks umfasst und war von größeren und kleineren Pausen getrennt. Die Mischung und Auswahl der Talks war ganz gut gelungen hat ein breites Spektrum von Erlang präsentiert.

Manche der Vorträge werden im Rest dieses Artikels noch genauer behandelt. Zu den Übrigen je ein kurzer Kommentar:

• Dont fear Erlang, fear your Team: Ein schöner Vortrag von Meike Hecker über Ihre Erfahrungen bei SumUp zu dem Einsatz von Erlang. Fazit ist das Erlang nicht schwerer als Java oder andere High-Level Sprachen zu erlernen ist, denn diese sind alle aufwändig zu meistern. Es ist auch wichtig das nötige Domänenwissen der Anwendung an die Entwickler zu vermitteln.
• Cuneiform: A Functional Workflow Language Implementation in Erlang : Eine Vorstellung von Cuneiform, einem System um verteilte DNA Analysen durchzuführen. Mit einem interessanten und universellen Ansatz der Batch-Verarbeitung sicherlich auch für andere Probleme verwendbar.
• RTB and Big Data – where Erlang and Hadoop meet: Ein Vortrag vom Sponsor AOL Platforms, wie diese Ihr Real-Time-Bidding Advertisement mit Erlang umgesetzt haben. Bevor eine Werbeanzeige angezeigt wird, bieten meist dutzende Anbieter innerhalb weniger Millisekunden um den Zuschlag dass ihre Werbung angezeigt wir. Ein sehr guter und technisch tiefer Vortrag über das seit Jahren produktiv laufendes und skaliertes System von AOL.
• Unleashing the Core Value: Ein Vortrag von Torben Hoffmann über den Einsatz von Riak_Core in eigenen Anwendungen.
• Design by Contract in Elixir: „Let it crash“ meets „It shouldn’t crash“: Eine Integration von Pre- und Post-Conditions wie sie in Eiffel nutzbar sind – implementiert als Makros in Elixir.

Erlang things to know

Da den ganzen Tag über Erlang gesprochen wurden, sind auch einige relevante Themen gefallen. Ein paar dieser Themen sind in meinen Notizen gelandet und ich würde es sehr schade finden diese zu unterschlagen, da sie für manch einen großen Mehrwert haben könnten.

Backpressure: In jedem System mit Datenfluss, muss es Verfahren geben nachdem dieser Fluss kontrolliert werden kann da es sonst zu Überlastung kommen wird. Die Idee ist recht einfach: Wenn der Fluss der Daten behindert wird, findet eine Art entgegengesetzte Kommunikation statt um einen “Rückstau” zu erzeugen. Im einfachsten Fall wird dies mit einer Antwort wie `429 Too Many Requests` bei HTTP bewerkstelligt. Ein wirklich guter Artikel zu Queues und Backpressure ist bei Ferd T-H zu finden. Allgemein geht es um “Load Regulation”, welche durch bereits vorhandene Tools wie etwa safetyvalve abgedeckt werden kann. Theoretischen Hintergrund dazu findet sich in dem Paper “Generic load regulation framework for Erlang” von Ulf Wiger.

Verfügbarkeit: Eine Stärke von Erlang, doch ein gerne missverstandenes Thema. Francesco Cesarini hat dazu in seinen Slides zu dem Talk “Concurrency + Distribution = Scalability + Availability, a Journey architecting Erlang Systems” die typischen Vektoren aufgezeigt.
Folie 18 zeigt, dass “Fault Tolerance” bedeutet wie ein System immer Antwortet auch wenn Fehler auftreten.
Folie 19 zeigt, dass “Resilince” die Stabilität von getrennten Abläufen meint. Wenn ein Request fehlschlägt, sollte dies weitere Requests nicht beeinträchtigen.
Folie 20 zeigt, dass für “Reliability” ein System einfach gesagt alles tun wird um die Aufgabe zu erfüllen, auch mit Retrys wenn nötig.

Retry Strategy: In einem System mit mehreren Komponenten, wie etwa Microservices, muss eine Strategie vorhanden sein, die über die Durchführung von Retrys entscheided. Wie hat sich der Nutzer der API bei Fehlern zu verhalten? Welche Komponenten der Anwendung müssen sich gegen partielle Ausführung eines Ablaufs schützen.

56-Bit Integer: Es erscheint komisch, aber es kann sehr sinnvoll sein Integer mit nur 7 Bytes in Erlang zu verwenden. Die Erklärung ist recht einfach: Während für <<Int:56>>Erlang den nativen Integer Datentyp des Betriebsystem nehmen kann, muss bei <<Int:64>> ein BigInteger verwendet werden der signifikant mehr Speicher und auch Rechenzeit benötigt. Allgemein ist hier noch anzumerken, dass Erlang “Arbitrary-sized integers” verwendet, näheres dazu bei Wikipedia.

Fremdsprachen auf der Erlang-VM

Wie es bei der JVM mit Scala und Clojure bereits bekannt ist, lassen sich weitere Programmiersprachen auf der gleichen VM nutzen. Bei Erlang gibt es hier auch ein paar Kandidaten die von Robert Virding in seinem Talk “Multi-lingual Erlang” aufgelistet wurden. Dabei muss jedoch unterschieden werden, ob die Sprache direkt zu .beam kompiliert, oder durch eine eigene Runtime wie einem Interpreter ausgeführt wird.

• LFE: Lisp flavored Erlang – Ein Lisp Dialekt angereichert mit Erlang der direkt zu BEAM kompiliert.
• Joxa: Ein weiterer Lisp Dialekt der zu Erlang kompiliert.
• Luerl: Experimenteller Lua Interpreter.
• Erlog: Ein Prolog Interpreter in Erlang implementiert.
• Elixir: Eine von Ruby beeinflusste und auf Erlang aufbauende Meta-Programmierspache die direkt zu Erlang kompiliert.

Metriken speichern

In dem Talk “Diabolic Database Design” von Heinz Gries wurde das Design der Metrik-Datenbank DalmatinerDB gezeigt und dazu noch allgemein das Verständnis von Metriken besprochen. Folgende Punkte haben es in meine Notizen geschafft:

• Metriken sind keine Events.
• Die Werte von Metriken haben immer den gleichen Typ (Int, String, Bool).
• Metriken treten periodisch auf.
• Metriken lassen sich aggregieren.
• Metriken sind stabil.

Was mir im praktischen Umgang mit Metriken aufgefallen ist, dass die Umsetzung häufig unbedarft gehandhabt wird. So werden Metriken und Events einfach über den Logger als DEBUG Nachrichten versendet und so das Logging ad absurdum geführt. Sinnvoller ist die Umsetzung mit dedizierten Services/Klassen für Logging, Events und Metriken. Eine Protokollierung und Reversibilität von Ergebnissen ist da noch eine ganz andere Baustelle.

Phoenix Webframework

Seit der Erlang Factory 2014 ist auch Elixir ein heisses Thema im Erlang Umfeld. Die Sprache hat durch die Nähe zu Ruby einen großen Zustrom erlebt und daraufhin blüht das Ökosytem und die Community immer mehr auf. Ein Resultat davon ist das Phoenix Webframework, welches beachtliche Performance, Features und Stabilität an den Tag legen kann.

Der Sonny Scroggin ist aus Nashville (TN) angereist um im Talk “Taking off with Phoenix” alle relevanten Funktionen und Prinzipien des Frameworks aufzuzeigen. Als Einstieg sind die Folien schon sehr hilfreich um das Framework zu verstehen, wenn es tiefer gehen soll sind die Guides des Projekts zu empfehlen.

Gegen Ende August 2015 hat das Projekt die Version 1.0 erreicht und beschreibt sich selber als stabil genug für den Produktiven Einsatz. Ein Benchmark der das unterstreicht ist der Versuch 2 Millionen Websockets auf einer Maschine zu halten und diese noch mit einem gleichzeitigen Broadcast zu beschicken. Die ganze Geschichte dazu ist im Blog nachzulesen.

In meinen Augen ist Phoenix vorzüglich als Framework für Webanwendungen, sowie als bidirektionaler Applicationserver für Websockets geeignet. Das was aktuell mit Java, Ruby, PHP oder NodeJS realisiert wird, ließe sich ebenfalls mit Phoenix umsetzten.
Doch auch außerhalb des Webumfelds könnte Phoenix in Zukunft auf trumpfen. Beim Thema Internet-of-Things (IoT) wird es immer mehr Verbindungen zu einzelnen Maschinen geben, die letztendlich in eine Webportal enden. So ließe sich Phoenix mit VerneMQ, einer Erlang Anwendung für MQTT Nachrichtenaustausch, kombinieren und so eine skalierbare Grundlage für IoT Platformen bieten.

QuickCheck für Elixir

Eine besondere Art Tests zu schreiben ist bisher typischerweise nur Funktionalen Programmiersprachen vorbehalten. Bei QuickCheck handelt es sich um ein Tool um “Property-Testing” zu machen. bei Property-Testing werden Funktionen getestet, indem diese mit tausenden von kontrolliert zufälligen erzeugten Argumenten ausgeführt wird, das Ergebnis der Funktion muss dann zu erwarteten Mustern passen. Man kann es auch als eine Art von Brute-Force-Unittesting ansehen, welche aber erstaunlich effektiv ist und selbst unerwartetste Fehler findet.

In dem Vortrag von Thomas Arts wurde eine Integration von QuickCheck für Elixir vorgestellt, die es erlaubt Property-Testing nativ in Elixir zu nutzen.
Da es bisher QuickCheck nur für Haskell und Erlang gab, wird von manchen dieser Schritt als erheben von Elixir auf den Rang einer “anerkannten” Sprache angesehen. Was wohl etwas scherzhaft zu verstehen ist, denn ab und zu ist eine leichte Differenzierung zwischen Erlang- und Elixir-Entwicklern zu merken, die sich aber zunehmenden mit der Erkenntnis legt, dass hier alle am gleichen Strang ziehen und voneinander profitieren können.

Lightning Talks

Am Ende der Veranstaltung gab es noch mehrere Lightning Talks. Darunter auch Themen die ich besonders interessant fand wie:

• XProf: Ein Profiler mit WebGUI um selektiv einzelne Funktionen Profilen zu können.
• sprintpoker.io: Eine Phoenix Webanwendung um das Sprint-Poker bekannt aus Agilen Frameworks wie Scrum schnell und einfach am Computer oder auch in verteilten Teams umsetzen zu können.
• actordb.com: Eine Datenbank die Daten nach dem „User“ selektiert, dahingehend optimiert und so linear skalieren können soll.

Zusammenfassung und Ausblick

Auch wenn es nur ein Tag war, hatte es dieser doch in sich. Wer die Zeit aufbringen kann und sich für die “Erlang-Welt” interessiert, kann sich der Reisegruppe gerne nächstes Jahr mit anschließen.
Es ist auch möglich morgens mit dem ICE nach Berlin und Abends wieder zurück zu fahren, wer nicht in einem Hotel übernachten möchte – Auch wenn die Anreise am Abend vorher weitaus entspannter ist und Hotels in Berlin sehr günstig sind.

Die Talks waren alle in Englisch und in den Pausen ist es leicht zu tollen Gesprächen gekommen. Dazu noch die allgemein entspannte Community-Atmosphäre und ein paar Inside-Jokes gratis oben drauf.

Doch 2016 wird es noch die ElixirConfEU Ende Mai ebenfalls in Berlin geben. Ein Termin den ich nach der ElixirConfEU in Krakow nicht missen möchte! Da Berlin doch etwas einfacher zu erreichen ist als Krakow, gehe ich davon aus dass die Besucherzahlen und Menge der Vorträge merklich steigen werden sowie der Besuch aus anderen Kontinenten zunehmen könnte. Wer Interesse an Elixir oder Phoenix Workshops hat, wird hier die Möglichkeit dazu bekommen.