Interview mit Johann-Peter Hartmann – "Wir brauchen erst einmal neue Probleme, um noch besser skalieren zu müssen!"

JavaScript, Skalierung und Microservices – ein unschlagbares Team
Kommentare

JavaScript und die Skalierung – kann das wirklich gut gehen? Oder sind wir vielleicht sogar schon am Ziel angelangt? Und welche Rolle spielen Node und Docker in dieser Geschichte?

Skaliert NodeJS? Ja, natürlich. Aber wie is das mit JavaScript im Allgemeinen? Was passiert, wenn man wirklich skalieren möchte, und das weit über die Grenze eines Servers? Über die eines Clusters? Das sind natürlich spannende und vor allem wichtige Fragen – gerade in einer Zeit, in der vor allem die Applikation vorne mitspielt, die schnell mit der Anzahl der Benutzer mitwachsen kann.

Mit genau diesem Thema beschäftigt sich Johann-Peter Hartmann in seiner Night Session Drone Army – Scaling JavaScript auf den JavaScript Days 2016 in München. Grund genug für uns, um etwas Licht ins Dunkel zu bringen. Es geht dabei um:

Viel Spaß also bei interessanten Ein- und Ausblicken in die Welt der Skalierung mit JavaScript.

JavaScript und Skalierung? Pures Versehen!

entwickler.de: Johann, in der heutigen Zeit dreht sich alles um Skalierung. Eine Applikation, die schnell mit der Zahl der Benutzer mitwachsen kann, kann leicht vorne mitspielen. Wie schlägt sich JavaScript in diesem Umfeld? (Themen)

Johann-Peter Hartmann: Historisch betrachtet spielt JavaScript in diesem Umfeld aus purem Versehen mit. Das ganze Sprachdesign wurde an einer komplett anderen Aufgabenstellung entlang entworfen, bei dem es deutlich mehr um Entwicklungsgeschwindigkeit, einfache Zugänglichkeit von Funktionalität und die Fähigkeit, Dinge als Glue-Code zu verdrahten, ging. Bei wirklich großen Plattformen würde man eigentlich eine typfeste Sprache erwarten, bei der sich die Engine die kontinuierliche Typevaluation und das Casting sparen kann. Eine Sprache wie Java – mit festen Typen, bei der sowohl in der Kompilierung als auch in der JVM deutlich mehr Intelligenz steckt als in allem, was bei JavaScript geplant war – ist eigentlich für solche Aufgaben gemacht.

Mit dem Thema JavaScript und Skalierung beschäftigt sich Johann-Peter Hartmann auf den JavaScript Days 2016 in München. Das Trainingsevent findet vom 21. bis 23. März statt und umfasst zusammen mit den parallel laufenden AngularJS Days und HTML5 Days 30 halbtägige Workshops mit 20 Sprechern.Weitere Programminfos unter: javascript-days.de

AngularJS Days 2016  JavaScript Days 2016  HTML5 Days 2016

Leider – oder glücklicherweise, aus heutiger Sicht – hat sich das bei JavaScript geändert. Mit dem Web 2.0 wanderte die Applikationswelt in weiten Teilen in das Web, und JavaScript wurde die GUI-Sprache Nummer 1, sodass am Ende der Browser War zum JavaScript-Engine-War wurde – und uns mit so hervorragenden JavaScript-Engines wie Google V8, Nitro und Chakra beglückt hat. Und wir sind noch lange nicht am Ende der Fahnenstange angekommen, wie die inzwischen solide Verbreitung von asm.js-Unterstützung in den Browsern zeigt; dort ist man schon bei 50 Prozent der Performance von optimiertem C-Kompilat angekommen.

Für Startups ist das wunderbar: ich habe nicht nur die einfache Zugänglichkeit und die hohe Entwicklungsgeschwindigkeit, sondern auch die Performance. Die Unterstützung von asynchronem Verhalten und Events, ursprünglich für langsame Netze und GUI eingeführt, erleichtern das Schreiben skalierbarer Software ebenso wie die rudimentären funktionalen Fähigkeiten, die zunächst eher eine seltsame Rolle im Sprachdesign spielten.

entwickler.de: Eine besondere Rolle spielt dabei natürlich Node.js – aber auch das hat seine natürlichen Grenzen. Wie weit kann man das Spiel ohne Hilfsmittel treiben? (Themen)

Johann-Peter: Node.js ist der Stürmer, der die Bälle ins Tor bringt, die ihm der JavaScript-Engine-War zugespielt hat. Node, NPM und die inzwischen unglaublich reichhaltige Tool-Welt im Umfeld hat JavaScript auf der Serverseite einfach und zugänglich gemacht. Und der Erfolg von Node zeigt, wie sehr die kleine, flexible Sprache JavaScript im Zusammenspiel mit einer mächtigen Engine und einer offenen Infrastruktur die Probleme von heute trifft.

Der initiale Ansatz von Nodejs – damals eher ein schlichter Wrapper um die V8, der in einer Dauerschleife auf einem Port auf Traffic lauscht – skaliert natürlich gar nicht; es ist schließlich nur ein CPU-Core involviert, und auch 2011 hatte der durchschnittliche Server schon deutlich mehr anzubieten. Der Rest dümpelte in Folge ungenutzt vor sich hin … Das Gemeine war aber der Highlander-Faktor der soliden Basistechnologie von Google: es kann nur einen geben, und der lebt ewig.

Der Engpass liegt nicht im Node, sondern im Storage, Netzwerk oder der Applikationslogik.

Um Himmels Willen, man muss sich nur die Zahlen angucken: ein einfaches NodeScript kann heute bis etwa 20.000 Requests pro Sekunde auf einem Core alleine ausliefern. Bei typischen Interaktionsmustern wären das schon 50.000 konkurrierende Nutzer in Peak-Zeiten. Nimmt man die mit einem normalen Konsumentenverhalten und etwa einem wöchentlichen Besuch an, dann könnte ein einzelner Core im Resultat schon über 10 Millionen aktive Nutzer der Plattform bedienen.

Auch wenn das ein eher theoretisches Szenario ist – der Engpass liegt nicht im Node, sondern eher in Storage, Netzwerk oder der eigenen Applikationslogik. Typischerweise treten dort beim Skalieren die ersten Probleme auf. Nichtsdestotrotz bringt Node selbst mit dem Cluster-Modul schon die Fähigkeit mit, selbst Childprozesse zu starten und die Anfragen auf sie zu verteilen; und damit alle Cores zu nutzen. Der nächste Schritt ist dann die Verteilung auf mehrere Server, typischerweise mittels eines Reverse Proxy. Auch dort gibt es in der Node-Welt eigene Lösungen, trotzdem wird in der Praxis gerne auf NGINX oder HAProxy zurückgegriffen.

Aber ja, man kommt auch schon mit einer reinen Node-Infrastruktur sehr weit. Es wird nur irgendwann sehr mühsam, wenn es etwa um Elastizität oder geographische Verteilung geht.

entwickler.de: Nun gibt es auch Möglichkeiten, diese Grenzen zu durchbrechen – du stellst sie in deiner Night Session „Drone Wars“ vor. Kannst du die Lösung kurz umreißen? (Themen)

Johann-Peter: Die Werkzeuge dazu gibt es schon lange, sie sind ein fester Bestandteil von Cloud-Infrastrukturen und insbesondere beim Vorreiter Amazon seit Jahren verfügbar. Aber: das ist klassischerweise sehr mühsam und aufwendig, es ist viel Spezialwissen, Gehirnschmalz und Geduld nötig, um diese Infrastrukturen zu bedienen.

Mal ehrlich: dieser Komplexität verdankt eine ganze Branche, nämlich den PaaS-Anbietern wie Heroku oder EngineYard, im Kern ihre Existenz. Sie bringen das Know-how über diese Dinge in eine Form, mit der auch wir einfachen Applikationsentwickler umgehen können.

Container gibt es in verschiedenen Varianten seit weit über 10 Jahren!

Erst in den letzten zwei Jahren kommt es langsam zu einer Demokratisierung dieses Bereiches. Und wieder ist es eher einem glücklichen Zufall als einer überragenden Strategie zu verdanken … Container gibt es in verschiedenen Varianten seit weit über 10 Jahren: OpenVZ, Linux-VServer, selbst LXC ist schon acht Jahre alt. Aber wie bei Node war es nötig, dass jemand das passende, einfache Interface zur Technologie und eine leichtgewichtige, offene Infrastruktur drum herum liefert: in diesem Fall Docker.

Auf einmal waren Container einfach (auch für Entwickler) zu erstellen, einfach zu erhalten und gut wiederverwendbar. Die persönliche Plattform konnte der Entwickler jetzt selbst mit einem Legokasten bauen, ohne sich an die Konventionen und Kosten eines PaaS zu binden. Und auch auf der Infrastrukturseite ist die Entität Container gut nutzbar, und eine Vielzahl von ausgewachsenen mächtigen Werkzeugen wie CoreOS, Kubernetes, Deis oder Apache Mesos erlauben fast grenzenlose Skalierbarkeit von Container-Infrastrukturen.

Darum geht es auch in meiner Night-Session – ich möchte zeigen, wie man diese Demokratisierung zum eigenen Vorteil nutzt, und wie einfach der Zugriff inzwischen geworden ist. Und um glaubwürdig zu sein, nutze ich eine einfache Microservice-Struktur, um deutlich zu machen, dass diese Strukturen sehr wohl in der Lage sind, auch komplexere Umgebungen abzubilden.

Node.js, Docker und Microservices to the Rescue!

entwickler.de: Container spielen also auch hier eine wichtige Rolle. Wie schwierig gestaltet sich das Zusammenspiel aus Node.js und z.B. Docker? (Themen)

Johann-Peter: Wenn man mal das benötigte Wissen oder die Zeit zum Einlesen nimmt: in keiner Weise schwierig. Ich habe ja schon angedeutet, dass sich die Grundphilosophien ähneln – eine mächtige Technologie, deren Zeit gekommen ist, kombiniert mit einem einfachen Interface und einer guten Infrastruktur zum Teilen von Lösungen. Dementsprechend liegt die Einarbeitung im Bereich von Minuten bis Stunden.

Und der leichte Zugriff auf viele vorhandene Lösungen erfüllt das Kriterium „Earning while Learning“. Ich kann mir das benötigte Wissen aneignen, während ich die Werkzeuge verwende. Das steht deutlich im Widerspruch zum klassischen Ausskalieren auf der Basis von Amazon Clouds, und befindet sich schon fast gleichauf mit so eleganten Interfaces wie etwa bei Heroku.

Die wichtigsten Microservices-Themen gibt es auf dem Microservices Summit.

entwickler.de: Allgemein haben Microservices in den letzten Jahren einen regelrechten Hype erlebt; dennoch gibt es auch kritische Stimmen. Sind Microservices wirklich der Weisheit letzter Schluss? (Themen)

Johann-Peter: Ich glaube ebenfalls nicht, dass wir uns mit der Entdeckung der Microservices von der Softwarekrise verabschieden können, dafür begleitet sie uns schon zu lange. Natürlich habe ich auch schon Microservice-Happiness gesehen, bei der ein Sechs-Mann-Team eine überschaubar große Applikation allen Ernstes durch Microservices ersetzen will, weil der existierende Monolith unwartbar wurde. Das kann offensichtlich nicht klappen: wer schon an der normalen Komplexität scheitert, kann nicht gewinnen, indem er zusätzlich die Komplexität von Microservices oben drauflegt …

Das soll nicht heißen, dass hier die Entwickler unfähig wären oder Microservices die falsche Lösung darstellen! Meist befindet sich im Hintergrund ein organisatorisches Problem, dass schon bei der ersten Software zur Unwartbarkeit führte. In Folge gibt es gar keine Architektur, die alleine eine Lösung anbieten könnte. Stattdessen muss Architektur und Organisation gemeinsam betrachtet und bewegt werden, um zu einer Lösung zu kommen. Das im Microservice-Umfeld gerne genannte „Inverse Conway Maneuver“ – ich gestalte meine Organisation so, dass die richtige Architektur entsteht – ist ein sehr naiver Ansatz von uns Technikern, aber er geht in die richtige Richtung. Architektur und Organisationsdesign werden in Zukunft verschmelzen; Microservices werden uns aber auf jeden Fall erhalten bleiben.

entwickler.de: Deiner Erfahrung nach – wo liegen die Grenzen der Skalierbarkeit, wenn man alle aktuellen Technologien miteinander vereint?

Johann-Peter: Das mag jetzt überheblich klingen, aber ich glaube, wir Techniker aus dem Web mit Mobile-Umfeld haben da schon einen ganz guten Job gemacht. Facebook bedient an einem Tag 14 Prozent der Menschheit, pro Mensch gibt es vier WhatsApp-Mitteilungen pro Tag. Wir brauchen erst einmal neue Probleme, um noch besser skalieren zu müssen.

Johann-Peter Hartmann

Johann-Peter HartmannJohann-Peter Hartmann ist Gründer und CTO (Chief Tailwind Officer) bei der Mayflower GmbH und eigentlich ein Entwickler mit Hackerherz. Die Weltsicht aus der Hackerperspektive wirkt sich sowohl in der Nähe zu Themen wie Security, DevOps, aber auch Komplexität und Management aus.

 

 

Aufmacherbild: architect drawing a bridge von Shutterstock / Urheberrecht: FERNANDO BLANCO CALZADA

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -