Michael T. Nygard: Maneuverable Web Architecture

Was kann man mitnehmen aus einem Talk von Michael Nygard? Viel, aber nie das was man erwartet. Zugegeben, ist die Analogie zu den Kampfpiloten recht weit hergeholt und hat in erster Linie wenig mit Architekturen zu tun. Nygard hat aber genauer hingeschaut und anschaulich erklärt, wie sich Kampfpiloten physikalische Kräfte zu nutzen machen um ihre Dogfights in den Lüften zu gewinnen. Das zielgerichtete Freisetzen und Aufnehmen von Impulsen, um sich in dem Raum der physikalischen Gesetze optimal zu bewegen, verbindet Nygard mit dem Schlüsselwort der Manövrierfähigkeit.

Die Architektur eines IT-Systems bewegt sich ebenfalls in einem Raum. Oftmals in einem turbulenten Projektgeschäft mit ständig wechselnden Anforderungen. Nygard forciert hier das Ziel: eine Architektur so zu gestalten, dass sie Impulse steuern kann. Es geht dabei um Kontrolle von Tempo, Anpassung und Wachstum.

Diese Ideen sind nicht völlig neu, wenn auch anschaulich dargestellt. Als Entwickler haben wir in unseren ersten Projekten gelernt, dass wir früh Designentscheidungen treffen müssen. Wir haben auch gelernt, dass wir uns mit diesen nur dann nicht in eine Sackgasse manövrieren, wenn wir Testfälle schreiben. Testfälle, die uns ermöglichen zu refaktorisieren.

Auch wenn sich die Beispiele in Nygards Talk im Wesentlichen auf Web Architekturen beziehen, sind doch die meisten Ideen genereller Natur und lassen sich auf andere Architekturen in der IT übertragen. Dabei standen zwei Punkte für mich im Vordergrund:

Ich habe erlebt wie monolithische Systeme die IT ausgebremst und dadurch die Kunden/Auftraggeber/Nutzer frustriert haben. Lange Durchlaufzeiten, unverhältnismäßig hohe Kosten bei geringen Änderungswünschen, fehlende Integrationsfähigkeit und der Verlust von Releasefähigkeit waren die Folge. Im schlimmsten Fall fehlte sogar die Möglichkeit die Systeme an neue rechtliche Vorgaben und Gesetze anzupassen.

Im Gegensatz dazu konnte ich erleben, wie eine modularisierte feingranulare Architektur, welche über standardisierte Web APIs auf URI Basis realisiert wurde, genau diese Probleme nicht aufwies. Daumen hoch für Nygards Analogie.

(von Frank Hinkel)

Christophe Coenrates: Fast, Stunning, and Cross-Platform Mobile Apps with PhoneGap

Der Talk von Christophe Coenrates über die Smartphone unabhängige Entwicklung von Apps begann mit der interessanten Info, dass keine Folien im klassischen Sinne benutzt würden, sondern der Vortrag mit Hilfe einer iPad-App gehalten wurde – natürlich entwickelt mit PhoneGap. So konnte gleich anschaulich gezeigt werden, wie die Anwendung auf Gesten etc. reagiert und welche Übergänge zwischen den “Folien”, bzw. besser gesagt Webseiten möglich sind. Auch eine kleine Live-Demo mit Änderungen an einer mit PhoneGap erstellten App führte Coenrates vor.

Dadurch, dass PhoneGap komplett auf HTML, CSS und Javascript setzt – die Technologien, die plattformübergreifend auf allen Smartphones verfügbar sind – kann die App auch während der Entwicklung einfach im Browser auf dem Entwicklungscomputer ausgeführt werden. Das erspart unnötige Deploymentzyklen auf ein Device. Genauso präsentierte Christophe Coenrates auch die Beispiele. Im Grunde entstehen so mit PhoneGap, das auf der Open-Source Software Apache Cordova basiert, laut der Vorstellung von Coenrates optimalerweise SinglePage Apps, für die auch die gängigen Bibliotheken wie Knockout.js, Handlebar.js, jQuery oder auch Bootstrap benutzt werden können. Von Frameworks wie jQuery Mobile riet er hingegen ab, da sie durch ihre harten Abhängigkeiten den Entwickler in der Wahl weiterer Bibliotheken oft einschränken.

Wie einfach es mit PhoneGap ist, neue Plattformen, für die eine Anwendung entwickelt wird, hinzuzufügen, zeigte Coenrats mit wenigen Kommandozeilenbefehlen. Ebenso schnell fügte er neue Features hinzu. Auch Spezialisierungen für einzelne Smartphones mit individuellen Funktionen sind möglich. Beispielsweise kann eine iOS-App einfach mit XCode geöffnet werden und für Apple-Devices individualisiert werden. So kann dann beispielsweise auch der Vorschaumodus der jeweiligen IDE genutzt werden.

Neben der lokalen Kompilierung beim Entwickler bietet PhoneGap auch verschiedene Buildserver in der Cloud an, so dass auch die Entwicklung möglich ist, wenn beispielsweise die notwendige Hardwareplattform beim Entwickler sonst nicht zur Verfügung stehen würde.

Insgesamt war es ein interessanter Talk von Christophe Coenrates über die plattformübergreifende Entwicklung, der Hunger auf mehr machte. In meiner Idee, demnächst PhoneGap einmal auszuprobieren, bin ich in jedem Fall bestärkt worden.

(von Jan Nikolai Trzeszkowski)

Phil Calçado: APIs – The Problems with Eating your Own Dog food

Phil Calçado lernte ich bereits vor einiger Zeit auf einem Event in Berlin kennen und hatte daher hohe Erwartungen an seinen Vortrag APIs: The Problems with Eating your Own Dog food. Ich sollte nicht enttäuscht werden. Nachdem die Frage: “Was ist Soundcloud?” und die damit verbundenen Anforderungen an Performanz geklärt waren, wurde dargestellt, wie sich die Soundcloud Architektur über die Zeit entwickelt hat.

Während dieser Evolution wurde zeitweise das Rendern der Webseite auf den Browser verlagert, was zu ungefähr 159 API-Anfragen pro Seitenanfrage führte. Nicht nur dem Publikum machte diese Zahl Angst sondern auch der Soundcloud Crew, jedoch war man zuversichtlich, dass durch zusätzliche Server diese Last zu schaffen sei. Schnell lernte man, dass nach dem Zusammenbruch des HAProxy weitere Komponenten (memcached/Rails/MySQL) der Masse an Anfragen nicht gewachsen waren. Wie bei Twitter wurde hier die Erfahrung gemacht, dass serverseitiges Rendern von Webseiten weiterhin zentral für die zeitnahe Auslieferung von Webinhalten ist.

Interessante Erfahrungen vermittelte der Vortrag über das Design von Micro Services, welche auch in anderen Talks des Modern Web Architecture-Tracks ein dominantes Thema waren. So führte der initiale Schnitt in kleinere Services dazu, dass pro Benutzeranfrage deutlich mehr Zeit in die HTTP-Verarbeitung geflossen ist. Auch wenn damit die Datenbank entlastet werden konnte, war dies keine befriedigende Situation. Als zentrales Problem stellte sich die fehlende Parallelisierbarkeit von Rails heraus, da fachlich mögliche, parallele Anfragen nicht umgesetzt werden konnten. Da Rails, zum Leid Calçados, weiterhin eine zentrale Technologie im Soundcloud System darstellt, wurde das Problem durch die Verwendung von nebenläufigem IO umschifft.

Beispielhaft wurde dies anhand der nebenläufigen Beschaffung von Trackinformationen verdeutlicht. Dies wird in der Ruby Anwendung aufgerufen und über Scala Klassen umgesetzt. Über Scala Futures erfolgt die Kommunikation zwischen beiden Komponenten. So können die Vorteile von Scala im Bezug auf nebenläufige Programmierung genutzt werden, ohne das Rails-Programmiermodell zu sabotieren. Auch dieses Anwendungsbeispiel zeigt wie praktische polyglotte Programmierung funktionieren kann.

Abschließend zeigte Calçado, dass über nebenläufige Anfragen hinaus die Reduktion des Netzwerkverkehrs eine zentrale Rolle spielt. Verbesserungen in dieser Richtung konnten durch spezifische APIs für Anwendungsgruppen wie Mobile, Web oder Partner realisiert werden. Weitere Verbesserungen erhofft man sich durch eine weitere Untergliederung in Experience based APIs.

Alles in Allem zeigt der Vortrag, dass das Design von Services kein Selbstläufer ist, sondern neben den offensichtlichen Vorteilen auch Herausforderungen schafft, in deren Bewältigung auch Rückschläge eingerechnet werden müssen.

(von Tobias Neef)

James Lewis: Microservices – adaptive architectures and organisations

Da wir uns bei innoQ regelmäßig nicht nur in Projekten, sondern auch auf Konferenzen und im Rahmen von Artikeln intensiv mit den Möglichkeiten zum Aufbrechen von Monolithen auseinandersetzen, war der Talk Microservices – adaptive architectures and organisations von James Lewis eine willkommene Gelegenheit, Einblicke in die Erfahrungen anderer zu dem Thema zu erhalten.

Ein anschauliches Beispiel für die Gefahren von Monolithen lieferte James u.a. mit einer war story von einer Fluggesellschaft, die im Anschluss an den Ausbruch des Vulkans Eyjafjallajökull keinerlei Flugstarts mehr abwickeln konnte. Jedoch nicht, weil die Flüge von der über Europa hinwegziehenden Aschewolke betroffen waren, sondern weil die Retail-Website (mit Fluginformationen) der Airline wesentlich stärker frequentiert wurde als üblich. Während der Zeit nach dem Vulkanausbruch wollten sich zahlreiche Passagiere über eventuelle Ausfälle oder Verschiebungen ihres Fluges informieren. Begünstigt durch ungeduldige User und den damit verbundenen Einsatz des Refresh Buttons geriet das System zunehmend unter Last. Da die Retail-Website und die für die Abwicklung von Flugstarts zuständige Departure Control als monolithisches System implementiert waren kam es schließlich zum Totalausfall.

Als Gegenentwurf zu Monolithen sind Microservices von überschaubarer Größe, lose gekoppelt, verwenden REST zur Kommunikation und können unabhängig voneinander skaliert und deployed werden. Die Frage nach der geeigneten Größe von Microservices wurde von James mit “so groß, dass sie in seinen Kopf passen” beantwortet und in einem Blog-Post vertieft.

Zusammengefasst übertragen Microservices die Unix-Philosophie auf den Bau von Systemen in Unternehmen:

Der aus meiner Sicht kritischste Punkt beim Versuch einen auf Microservices basierenden Systementwurf erfolgreich in die Tat umzusetzen, ist Conway’s Law:

…organizations which design systems … are constrained to produce designs which are copies of the communication structure of those organizations

– Melvin Conway, 1968

Die von James in diesem Zusammenhang aufgeworfene Empfehlung ist, Teams interdisziplinär unabhängig von bestehenden Strukturen um das zu entwickelnde Produkt herum zu organisieren. Je nach Unternehmen bedarf es dazu einiger Überzeugungsarbeit und eines gewissen Maßes an Unterstützung aus dem Management.

Abgesehen davon, dass die von James empfohlene Granularität von Microservices für meinen Geschmack etwas zu klein ausfällt, findet der Talk meine uneingeschränkte Zustimmung. Dementsprechend würde ich mich im Zweifel zugunsten von Microservices und gegen einen Monolithen aussprechen.

(von Robert Reimann)

Simon Willnauer: With a hammer in your hand… Elasticsearch

Ich war im Vorfeld sehr gespannt auf den Talk von Simon Willnauer zum Thema “Elasticsearch”. Der Vortragende gehört zum Team des Open-Source-basierten, verteilten Suchservers und hat schon vorher als Lucene-Committer viel Erfahrung im Bereich Volltextsuche gesammelt. Da ich Elasticsearch gerade für ein Projekt evaluiere, hoffte ich aus dem Vortrag vor allem eine bessere Vorstellung über die grundlegenden Konzepte dieses Produktes mitnehmen zu können.

Grundlage seines Vortrages “With a hammer in your hand… Elasticsearch” war – gemäß dem Motto “No slides – no bullshit” – ein Shellscript. Dieses enthielt primär Curl-Aufrufe, da die Kommunikation mit dem Elasticsearch-Cluster über REST-konforme HTTP-Schnittstellen stattfindet. Wer sich einen detaillierteren Eindruck verschaffen möchte, findet das Skript hier.

Um die grundlegenden Funktionen von Elasticsearch zu demonstrieren, streamte er in Echtzeit Tweets aus dem globalen Twitterstream nach Elasticsearch. Auf der Basis dieser indizierten Tweets führte er dann die Suchfunktionalität von Elasticsearch vor. Für das Streaming der Tweets verwendete er das Tool stream2es, welches auch in Verbindung mit anderen Quellen verwendet werden kann.

Er stellte noch ein weiteres Tools vor, das in der täglichen Arbeit mit Elasticsearch sehr nützlich sein kann. Mit Karmi kann man den Zustand des Elasticsearch-Clusters überwachen. Simon Willnauer führte damit das dynamische Hinzufügen und das dynamische Herunterfahren von Nodes vor.

Insgesamt hat mir der Talk sehr gut gefallen, da deutlich wurde, wie einfach man mit Hilfe von Elastisearch die eigene Applikation um Volltextsuche erweitern kann. Die wirkliche Herausforderung bei der Verwendung von Elasticsearch liegt aus meiner Sicht aber in einem tieferen Verständnis der grundlegenden Konzepte der Volltextsuche. Diese sind unbedingt notwendig, um die Query-DSL von Elasticsearch verstehen zu können. Darauf ist der Vortrag leider kaum eingegangen, ansonsten hat er mir aber sehr gut gefallen.

(von Holger Kraus)

Sam Aaron: Sonic Pi – Teaching Computer Science with Music

Am zweiten Tag der Konferenz habe ich mich nachmittags für den Vortrag “Sonic Pi: Teaching Computer Science with Music” im Track “Software Craftmanship / Teaching Software Development” entschieden. Ich kannte Sam Aaron bis dato nicht. Meine Erwartung war, ein paar Tipps zu bekommen wie man mit Hilfe von Raspberry Pi und Musik den Kiddies das Coden näher bringen könnte. Es folgte eine Unterhaltungsshow der Extra-Klasse und für mich das Highlight der diesjährigen GOTO.

Der Vortrag startete mit Live Music Hacking, was das Audiosystem im Konferenzsaal an seine Grenze brachte. Hinter dem transparenten Hintergrund des Code-Editors leuchteten durch die Musik erzeugte visuellen Effekte. Die Musik selbst wurde durch die Ausführung von Clojure-Ausdrücken im Emacs mit Overtone generiert.

Nachdem sich Sam Aaron kurz vorgestellt hatte, ging es anschließend um die Reform des Schulsystems in UK. Im Informatikunterricht sollten wir den Kindern das Programmieren und das Kreieren eigener Software anstatt den Umgang mit MS Office Produkten lehren. Die dafür passende Lösung – Sonic Pi – stellte er direkt vor. Sonic Pi ist eine Open-Source Entwicklungsumgebung mit der man die Grundkonzepte der Programmierung erkunden und lehren kann, indem man Musik kreiert. Gleichzeitig soll das Engagement und Interesse am Unterricht verbessert werden.

Der insgesamt sehr gelungenen Konferenz setzte dieser inspirierende, unterhaltsame und informative Vortrag das Sahnehäubchen auf. Auf Wiedersehen, GOTO!

(von Wadim Kruse)

Jon Moore: Building Hypermedia APIs with HTML

Building Hypermedia APIs with HTML war für mich einer der überzeugendsten Vorträge auf der diesjährigen GOTO in Berlin. Ich ging mit etwas Vorwissen in den Vortrag, da ich selbst momentan in einem Projekt HTML für eine Suchschnittstelle einsetze.

Jon Moore ist es gelungen, nachvollziehbar darzulegen, dass HTML sich – entgegen weitverbreiteter Ansicht – sehr gut als Media Type für APIs eignet und den Alternativen (etwa XML oder JSON) überlegen ist. Dies liegt vor allem daran, dass in HTML die notwendigen Mittel bereits standardisiert sind – insbesondere Links zur Navigation und Formulare zur Interaktion.

Semantische Anreicherungen des Markups sind durch standardisierte Ontologien wie beispielsweise schema.org möglich. Hinzu kommt, dass HTML-Schnittstellen in vielen Web-Projekten meist ohnehin bereits vorhanden sind, da sie im Browser das Human Interface darstellen. Mit einer sauberen Grundlage und evtl. etwas semantischer Anreicherung hat man so schnell die bereits vorhandene Schnittstelle Hypermedia-konform gemacht. Den ebenfalls gerne von der JSON-Front angebrachten Kritikpunkt des größeren Footprints entkräftigte er gekonnt mit dem Argument gzip. Im Demo-Teil seines Vortrags zeigte Moore eine eindrucksvolle, im Projektkontext bei Comcast entstandene Hypermedia-Library für Python.

(von Robert Glaser)

TAGS