Category

Inhaltliches

Entscheidungen im richtigen Rahmen treffen

By | Inhaltliches | No Comments

Entscheidungen
„Warum habt ihr das so gemacht?“ – Dies ist so oder abgewandelt die wahrscheinlich häufigste Frage, die rund um Architekturentscheidungen gestellt wird. Natürlich benutze ich sie auch gerne mit als Erstes, wenn ich in ein neues Team komme. Mein Antrieb ist dabei herauszufinden, welche Alternativen betrachtet wurden und welche Rahmenbedingungen und Einflüsse rund um die Entscheidung vorgeherrscht haben. Denn sehr wahrscheinlich sind diese Faktoren auch für zukünftige Entscheidungen wichtig!

In einer idealen Welt dokumentieren Projektteams ihre getroffenen Architekturentscheidungen sorgfältig, so dass jeder bei Bedarf darauf Zugriff hat. Wenn ich als Neuankömmling eine nicht dokumentierte Entscheidung aus der Vergangenheit nachvollziehen möchte, fehlen mir erst einmal wichtige Informationen. Aus dem Code kann ich ablesen, wie die Entscheidung letztendlich ausgefallen ist – vorausgesetzt es gibt eine konsistent durchgehaltene Lösung. Die betrachteten Alternativen finde ich durch Gespräche mit den beteiligten Personen heraus – in den meisten Fällen erfolgreich. Als Letztes stelle ich noch die Frage, warum es genau diese Alternativen waren. Was wurde bewusst ausgeschlossen? Warum wurde Framework XY nicht berücksichtigt? Die Begründung dafür finde ich nur in den Einflussfaktoren für eine Entscheidung:

  • Rahmenbedingungen: Welche Vorgaben müssen eingehalten werden? Z.B.: Steht nur ein kurzer Zeitraum bis zum Zeitpunkt der Entscheidung zur Verfügung? Ist das Budget begrenzt? Welche Technologien dürfen auf keinen Fall eingesetzt werden wegen Vorgaben von außen?
  • Qualitätsziele und -szenarien: Welche Qualitätsziele meiner Software möchte ich mit der Entscheidung erreichen oder unterstützen? Gibt es konkrete Qualitätsszenarien, die ich mit der Entscheidung verknüpfen kann?
  • Risiken: Welchen Risiken möchte ich durch die Entscheidung begegnen?

Diese Fragen helfen mir dabei, die Entscheidungen aus der Vergangenheit richtig zu beurteilen und zu sehen, wo überhaupt Spielräume für Entscheidungen vorhanden waren und was schon von Außen vorgegeben war. Ab und zu stelle ich auch fest, dass eine Entscheidung gar nicht getroffen, sondern tatsächlich vorgegeben wurde.
Ich möchte das anhand der Frage „Welche Programmiersprache wählen wir für unser System ABC?“ verdeutlichen: In einem Projekt auf der „grünen Wiese“ gibt es dafür viele Alternativen: Java, Ruby, C/C++, C#, PHP, JavaScript, etc. Ich bin erst einmal nicht eingeschränkt. Doch die wenigsten Projekte starten auf der grünen Wiese und nach und nach fallen so Alternativen durch äußere Einflüsse weg. Oft sind die Präferenzen und Erfahrungen des Teams für diese Fragestellung entscheidend. Die folgende Abbildung zeigt Einflüsse auf die Entscheidung in Form von Rahmenbedingungen, Qualitätszielen und Risiken.

Einflüsse auf Entscheidungen

Im Extremfall wird meine Entscheidung von außen so stark eingeschränkt, dass sie zur Rahmenbedingung wird. Die Entscheidung wird alternativlos und ist de-facto keine Entscheidung mehr. Wenn ich das in einem Projekt feststelle, begebe ich mich auf die Suche nach weiteren relevanten Fragestellungen. Hier achte ich wieder darauf, dass realistische Alternativen betrachtet werden, die die Qualitäten meines Systems fördern und im durch die Stakeholder vorgegebenen Rahmen liegen.

Zu guter Letzt kümmere ich mich noch um die Dokumentation der nachvollziehbaren Entscheidung, damit der nächste neue Projektmitarbeiter schneller die Antwort findet auf: „Warum habt ihr das so gemacht?“

Interview auf JAXenter: „So machen Sie Microservices… nicht – Fünf Antipatterns“

By | Inhaltliches, Video | No Comments
„So machen Sie Microservices… nicht – Fünf Antipatterns“ (Interview auf JAXenter)

So machen Sie Microservices… nicht – Fünf Antipatterns
Interview mit Stefan Toth (Fragen von Melanie Feldmann)
online bei JAXenter und auf YouTube
erschienen am 28. April 2016

Folien Download zum Vortrag (PDF) auf der JAX 2016: „Microservices-Ansätze scheitern – fünf Antipatterns“

Microservices liegen im Trend. Es wird konzipiert, ausprobiert, neu aufgesetzt und eben auch gescheitert. In dem Interview spricht JAXenter-Redakteurin Melanie Feldmann mit Stefan Toth über die fünf wichtigsten Stolperfallen, auf die Entwickler achten sollten. Gut zu wissen, was es bei der Umsetzung des Architekturstils von vornherein zu vermeiden gilt..



Interview auf dem Software Architecture Summit

By | Inhaltliches, Video | No Comments
„Interview mit Harm Gnoyke und Stefan Zörner – Software Architecture Summit März 2016“
Logo Entwickler Akademie
Mirko Hillert im Gespräch mit Harm Gnoyke und Stefan Zörner
online auf YouTube
veröffentlicht am 22. April 2016

Stefan Zörner und Harm Gnoyke waren mit 2 Sessions auf dem Software Architecture Summit in München dabei:
Bewertungsmethoden unter der Lupe
Softwarearchitektur Speed-Dating

Harm Gnoyke und Stefan Zörner haben im Rahmen des Software Architecture Summit mit Mirko Hillert von der Entwickler Akademie gesprochen. In dem Interview zeigten sie auf, welche Chancen in der Architekturbewertung auch für laufende Projekte liegen und dass eine Bewertung alles andere als schwergewichtig sein kann. Zudem gaben sie Einblicke, welche Skills Softwarearchitekten heute haben sollten, um in der Praxis erfolgreich zu sein…



Abheften mit arc42 für Fortgeschrittene. Konzept oder Entscheidung?

By | Artikel, Inhaltliches, Publikationen | No Comments

arc42 ist als Gliederung für Architekturbeschreibungen von Softwaresystemen weit verbreitet, zumindest in D-A-CH. Entsprechend treffe ich häufig auf Projekte, die arc42 benutzen oder beabsichtigen dies zu tun. Im Praxiseinsatz erlebe ich typische Fragestellungen und die immer gleichen Stolperfallen. In diesem Beitrag beschreibe ich kurz, wie ich in Projekten mit einer besonders häufigen Unsicherheit umgehe.

arc42_TOC

8. oder 9. ?

arc42 ist zuallererst eine Strukturierungshilfe. Es weist Inhalten Ihrer Dokumentation einen Ort zu, wo Sie diese „abheften“. Viele Projekte tun sich schwer, bei einem Lösungsansatz zu entscheiden, ob er besser in Abschnitt 8 („Konzepte“) oder 9 („Entwurfsentscheidungen“) passt. Oder in beide? Die Abbildung rechts zeigt die Struktur von arc42 als Inhaltsverzeichnis.

Schnipsel statt Kapitel

Generell rate ich davon ab, arc42 als Dokument (z.B. in Word) auszufüllen. Sie fahren besser damit, Zutaten Ihrer Dokumentation einzeln anzufertigen und sie später zielgruppengerecht in unterschiedlichen Formen zu rekombinieren. Entsprechend spreche ich im Folgenden nicht davon, wo Sie etwas „eintragen“ oder „reinschreiben“ in arc42, sondern wo so eine Zutat oder auch ein Schnipsel (z.B. eine Architekturentscheidung oder ein Konzept) ihren Platz findet.

Für die Einordnung von Entscheidungen, Konzepten sowie für die meiner Meinung nach eng verknüpfte Lösungsstrategie hilft die folgende Tabelle weiter. Ich führe die Inhalte im Folgenden weiter aus.

path-selection-3 document-with-paper-clip-2 american-football-strategy-4
arc42-Abschnitt 9. Entscheidungen 8. Konzepte 4. Lösungsstrategie
Anzahl pro System mehrere, eine pro wichtiger Fragestellung mehrere, eins pro wichtigem Thema eine verdichtete Übersicht, z.B. als Tabelle
Zielsetzung Nachvollziehbarkeit einer Entscheidung breite Kommunikation eines Lösungsansatzes Brückenschlag von Architekturtreibern zu Lösungsansätzen
Leitfrage Warum haben wir uns so entschieden? Wie gehen wir mit dem Thema um? Wie sieht die Lösung grundsätzlich aus?
Typische Form Prosa, stets gleich strukturiert, knapp, häufig mit Kreuztabelle, Prosa, ergänzt mit Abbildungen und (Quelltext-)Beispielen Tabelle (Spalten: Ziel, Ansätze), ggf. ergänzt mit einem Überblicksbild

Entscheidungen

Eoin Woods versteht Softwarearchitektur recht dramatisch als Summe der Entscheidungen, die — wenn falsch getroffen — Ihr Projekt scheitern lassen können. Diese Architekturentscheidungen ändern Sie im weiteren Verlauf nur schwer (oder es wird zumindest teuer); sie wirken breit.

EntscheidungBei Architekturdokumentation geht es vor allem darum solche  Entscheidungen nachvollziehbar festzuhalten. Im Nachhinein ist das schwieriger als beim Entscheiden. Deshalb nutze ich die gleichen Werkzeuge zum Treffen und zum Festhalten der Entscheidung — die Dokumentation fällt dann quasi ab.

Zum Festhalten einer Entscheidung gehören für mich zumindest eine konkrete Fragestellung (z.B. eine Technologie-Auswahl,  Make-Or-Buy …), betrachtete Alternativen und Bewertungskriterien. Kreuztabellen helfen dabei, Argumente verdichtet darzustellen.

Pro Entscheidung fertigen Sie ein einzelnes schlankes Dokument an oder eine einzelne Wiki-Seite oder ein … (das ist jetzt eine Toolfrage). Jede Entscheidung strukturieren Sie dabei gleich. Meine Empfehlung dazu in Kurzform: Fragestellung, Einflussfaktoren, Annahmen, Alternativen, Entscheidung. Am Ende dieses Beitrags finden Sie weiterführende Links dazu, Beispiele inklusive.

Konzepte

Entscheidungen treffen Sie und Ihr Team, um unter gegebenen Rahmenbedingungen Ziele zu
erreichen. Auch Konzepte verfolgen Ziele und sind Teil Ihrer (Architektur-)Lösung. Dieser Umstand macht die Verwirrung aus, wo man was abheftet in arc42.

Konzept
Meine Auslegung: Während Entscheidungen eine Frage beantworten, diskutiert jedes Konzept ein Thema. arc42 schlägt im betreffenden Abschnitt 8 als Unterkapitel viele solcher Themen vor: Persistenz, Sicherheit, … Der zentrale Unterschied aus meiner Sicht: Während es bei den Entscheidungen vor allem um die Nachvollziehbarkeit geht („Warum haben wir uns so entschieden?“), kommunizieren Konzepte vor allem Dinge, die innerhalb Ihres Softwaresystems übergreifend gelöst sind („Wie gehen wir mit einem bestimmten Thema um?“).

Die Zielgruppe eines Konzeptes sind Team-Mitglieder, die das Konzept in ihren Systemteilen anwenden und/oder umsetzen. Entsprechend haben Konzepte idealerweise Tutorial-Charakter und sind mit Beispielen gespickt. Auch für Konzepte schlage ich gern eine an das 4-Quadranten-Modell angelehnte gleichförmige Struktur vor. Sie ist freier als bei Entscheidungen, und gliedert ein Konzept nur grob vier Teile (Warum? Was? Wie? Wohin noch?), nicht feste Kapitel.

Übrigens löst eine Architekturentscheidung gerne das Anfertigen eines Konzeptes aus. In der Entscheidung beschreiben Sie, warum Sie sich für einen Architekturstil oder eine Technologie entschieden haben (Beispiel: Einsatz von Microservices, Verwendung von AngularJS). In Konzepten beschreiben Sie dann Dinge, die übergreifend für alle Services sind, bzw. wie Sie das UI bauen (die Entscheidung für AngularJS lässt einigen Spielraum …)

Die Lösungsstrategie als Klammer

Ein oft vernachlässigtes Kapitel in arc42 ist Abschnitt 4 („Lösungsstrategie“). Ich nutze es gerne um die Brücke zu schlagen zwischen den architekturrelevanten Anforderungen auf der einen Seite (Abschnitte 1-3 in der arc42-Gliederung) und der Lösung auf der anderen.

Lösungsstrategie
Besonders explizit geht dies in einer Tabelle, in der Sie in einer Spalte die Architekturtreiber (z.B. Ihre Qualitätsziele) auflisten, und diesen in der rechten Spalte Lösungsansätze zuordnen. Diese Lösungsansätze können Architekturprinzipien sein, der zugrunde liegende Stil, verwendete Muster, Technologieentscheidungen, Konzepte … In der Tabelle nennen Sie diese nur, und verweisen auf die betreffenden Schnipsel. Die Lösungsstrategie zeigt auf, mit welchen Ansätzen Sie den Qualitätszielen begegnen, und motiviert die Architektur so bereits auf oberster Ebene.

Übrigens …

Das Problem mit dem Einordnen ist besonders gravierend wenn ein Projekt die Architektur nachdokumentiert, Zutaten also nachträglich anfertigt. Bei einem methodischen Vorgehen fallen die Schnipsel auf dem Weg ab und fügen sich nach und nach zu einer Architekturvision und später zu einem konsistenten Lösungsbild.

Zum Abschluss noch die versprochenen Links für Strukturierunsvorschläge, Beispiele inklusive. In meiner Blog-Serie arc42-Starschnitt finden Sie Beiträge zu allen drei genannten Abschnitten:

Die Leseprobe meines Buches zu Architekturdokumentation behandelt Architekturentscheidungen und die Lösungsstrategie ebenfalls, auch mit Beispielen („Kapitel 3: Entscheidungen treffen und festhalten“ als PDF hier herunter zu laden).

Interview auf JAXenter: „Architekturen bewerten – aber wie?“

By | Inhaltliches, Publikationen | No Comments
„Architekturen bewerten – aber wie?“ (Interview auf JAXenter)

Architekturen bewerten – aber wie?
Interview mit Harm Gnoyke (Fragen von Hartmut Schlosser)
online bei JAXenter
erschienen am 27. Januar 2016

Softwarearchitekturen kann man auf ganz unterschiedliche Art und Weise bewerten. Welche Möglichkeiten es aber gibt, dass Architekturbewertungen tatsächlich objektiv ausfallen und ein Projekt in der Praxis voranbringen, haben wir mit Harm Gnoyke, Architekt bei embarc und Trainer auf dem Software Architecture Summit, besprochen. (mehr …)

zum Interview

Video von der JAX 2015: Architekturüberblicke anfertigen – Tipps und Tricks

By | Inhaltliches, Video | No Comments

JAXenter hat den Vortrag von Stefan Zörner von der JAX 2015 auf Vimeo bereitgestellt.

Logo JAX TV
So sieht’s aus! Architekturüberblicke – Tipps und Tricks
Sprecher: Stefan Zörner
Vortrag auf der JAX 2015 (05. November 2015)

So sieht’s aus! Architekturüberblicke anfertigen:Tipps und Tricks von JAX TV auf Vimeo.
Download Vortragsfolien (PDF)
Folien direkt hier durchschauen (via Speaker Deck)

In dieser Session ging es um das Anfertigen eines Architekturüberblicks aus dem Nichts heraus. Das stumpfe Ausfüllen eines Templates führt dabei oft zu Frust. Stefan Zörner zeigt stattdessen, wie Sie die Aufgabe pragmatisch und zugleich wirkungsvoll angehen. Dabei diskutieren wir auch Formen, Zutaten, Werkzeuge und Vorgehen. Sie lernen die minimale Ausprägung eines Architekturüberblicks kennen und erfahren, in welchen Situationen Sie von diesem Minimalset abweichen können.

JAX TV: Interview mit Stefan Toth zur W-JAX 2015

By | Inhaltliches, Video | No Comments

Mirko Schrempp (Business Technology Magazin) hat Stefan Toth im Rahmen der W-JAX 2015 zu Softwarearchitektur im Allgemeinen und zu embarc im Besonderen befragt.

Jaxenter
JAXenter hat Gespräch als Video (12 Minuten) auf YouTube bereitgestellt.

Zur Sprache kommen auch die Dinge, die wir von den Internet-Größen wie Netflix, Facebook, Spotify lernen können: Architektur-Prinzipien statt fixe Technologienvorgaben, Entscheidungsfreiheit in den Teams, Involvierung jedes Entwicklers in den Architekturprozess – denn, wenn Entwickler schließlich die Macht haben, alles kaputt zu machen, so können – und sollten – sie auch in den Architektur-Prozess einbezogen werden!



Single Page-Anwendungen – Vorteile von Web und Desktop kombiniert

By | Artikel, Inhaltliches | No Comments

Desktop-Anwendungen und klassische Web-Anwendungen haben – jede für sich – große Vorteile. Eine Desktop-Anwendung ist in ihrem Bedienkomfort und auch in ihrer Reaktionsgeschwindigkeit typischerweise der klassischen Web-Anwendung überlegen. Diese muss nämlich für jede Interaktion mit dem Benutzer eine komplett neue Seite auf dem Server rendern und diese wieder zum Browser übertragen. Das ist auch bei modernster Technik zu langsam, um mit einer Desktop-Anwendung zu konkurrieren. Dazu schließt sich ein Offline-Betrieb einer solchen Web-Anwendung schon von selbst aus: ohne Verbindung zum Server kann man auch nichts darstellen. Auf der anderen Seite läuft eine Web-Anwendung auf jeder Plattform, die einen Internet-Browser hat und muss nicht installiert oder aktualisiert werden. Wenn man sich etwas Mühe mit Responsive Layout gibt, funktioniert eine solche Anwendung sogar auf einem mobilen Gerät.

Die klassische Web-Anwendung

Gucken wir uns dazu die folgende Darstellung einer klassischen Web-Anwendung an. Der Anwendungszustand, die Geschäftslogik und der UI-Teil, der die Anwendung in HTML transformiert, ist auf dem Server. Der Browser macht lediglich Anfragen über HTTP und bekommt HTML-Seiten geliefert, die er nur noch darstellen muss. Jede Interaktion erfordert also einen Request zum Server, gefolgt von der Response mit der neuen Darstellung:

Classic Web Application

Klassische Web-Anwendung, Lila: Browser, Blau: Server

Grenzen der klassischen Web-Anwendung

Dieser Ansatz ist erfreulich einfach, kommt aber immer mehr an seine Grenzen, je interaktiver die Anwendung wird. Stellen Sie sich z.B. eine Tabelle vor, bei der sich die Breite jeder einzelnen Spalte durch Ziehen mit der Maus ändert. Oder einen interaktiven Editor für Text, wie diesen. Wenn wir das Modell beibehalten wollten, müssten wir bei jeder Interaktion einen Request/Response-Roundtrip durchführen. Das ist zum Einen technisch ohne den Einsatz von JavaScript-Logik im Browser nicht möglich, zum Anderen hätten wir dann eine große Anzahl von Anfragen (jeder Click und jeder Tastendruck im Extremfall). Eine derartige Anwendung wäre zwar technisch denkbar, würde aber nicht zu einer guten Benutzer-Erfahrung führen. Die Anwendung wäre langsam, würde flackern und wäre generell von der Latenz von Server und Netz abhängig.

Gängige Muster nutzen für derartige Anwendungen daher eher punktuelle JavaScript-Logik, z.B. in Form eines jQuery-Plugins für einen Text-Editor oder eine Tabelle. Dies erfordert allerdings das Halten von Zustand im Browser zusätzlich zu dem Zustand auf dem Server. Soll der Zustand des Browsers über eine Request/Response-Grenze hinweg gehalten werden, so muss dieser als Teil des Requests zum Server übertragen und als Teil des Response zurück übertragen werden. Für einen Text-Editor würde das z.B. auch die Cursor-Position, die Scroll-Position und alle aktuell gewählten Format-Optionen beinhalten. Dies stößt oft an die Grenzen der Plugins und würde auch keinen Best-Practice darstellen. Stattdessen wird für die Lebensdauer einer solchen Komponente häufig auf komplette Server-Roundtrips verzichtet und man hat eher eine Ansammlung von kleinen Browser-Anwendungen innerhalb der klassischen Web-Anwendung. Eine solche Architektur ist möglich, ist aus unser Erfahrung aber ein Grund für den schlechten Ruf von Web-Anwendungen. Die temporäre Verteilung des Zustands auf Browser und Server, die unklare Trennung der Verantwortlichkeiten, die Mischung von Darstellung des HTMLs auf Browser und Server machen eine solche Anwendung häufig aufwändig in der Entwicklung und Wartung.

Single-Page Applications als Lösung

Der Kern des Problems liegt dabei darin, dass Benutzer-Interaktion, Zustand und Programmlogik nicht oder nur zeitweilig nahe beieinander liegen. Der Zustand ist zudem verteilt über Server und Browser, teilweise redundant und zeitweise sogar inkonsistent. Architektonisch ist es reizvoll, dies zu vereinheitlichen und alles nah bei einander zu haben. Da die Benutzer-Interaktion per Definition im Browser liegt, gibt es Ansätze auch Zustand und zumindest den UI-Teil der Programmlogik ebenfalls in den Browser zu verschieben. Das Versprechen ist dabei auch, die Vorteile der Welten Desktop und klassischer Web-Anwendung kombinieren zu können. Den Bedienkomfort, die Reaktionsgeschwindigkeit und die Offline-Fähigkeit der Desktop-Anwendung mit der Verfügbarkeit und der einfachen Installation einer Web-Anwendung? Das geht in der Tat. Und es gibt sogar einen Namen dafür: eine Single-Page Application oder kurz SPA:

SPA Web Client

Single-Page Application, Lila: Browser, Blau: Server

Die Idee dabei ist, die Anwendungs- und UI-Logik näher an den Anwender, also in den Browser, zu bringen und hier auch die komplette Darstellung zu implementieren. Dabei wandert auch der Zustand der Anwendung vom Server komplett in den Browser und damit wäre der Zustand immer synchron, da es schlicht keinen Server-seitigen Zustand mehr gibt. Der Server liefert am Anfang nur eine einzige Webseite aus, die allen Code enthält. Danach dient der Server nur noch dazu, die SPA mit Daten zu versorgen oder Daten zum Speichern entgegenzunehmen. Auf diese Weise kann eine SPA tatsächlich mit einer Desktop-Anwendung konkurrieren. Selbst ein Offline-Betrieb wäre möglich, hierzu müsste zumindest ein Teil der Geschäftslogik im Browser vorhanden sein. Für den Fall einer ungenügenden Internet-Versorgung könnte das nützlich sein, z.B. während Reisen mit der Bahn oder im Flugzeug. Beispiele solcher Anwendungen sind Google Docs und Spreadsheets, Word Online oder auch Facebook.

Herausforderungen bei Single-Page Applications

Es ergeben sich allerdings für SPAs eine Reihe von Herausforderungen. Selten haben Unternehmen ein großes Know-How in der Anwendungsentwicklung mit JavaScript. Entwickler beherrschen vielleicht Java oder C# und stehen JavaScript und seiner Kultur skeptisch gegenüber. In den Grafiken oben stellen wir zudem die Beziehung der Anwendungsschichten zu Anforderungen im Bereich Stabilität und Langlebigkeit dar. Je weiter wir uns in der Pyramide nach unten bewegen, desto höher die Anforderung. In unseren Blog-Posts JavaScript im Großprojekt – TypeScript und andere Typensysteme beschäftigen wir uns mit den Mängeln von JavaScript im Unternehmenskontext und was man dagegen tun kann. Hier empfehlen wir auch für Enterprise-Projekte auf TypeScript zu setzen. In verschiedenen Projekten haben wir direkt miterlebt, wie schnell die Sprache TypeScript unter Java- und C#-Entwicklern zur Gewohnheit wird.

Die Auswahl eines passenden JavaScript Web-Frameworks ist leider auch keine einfache Aufgabe, da der Bereich unübersichtlich und in ständiger Bewegung ist. Unsere Erfahrungen dazu haben wir in den Blogposts über JavaScript-Web-Frameworks und UI-Architektur festgehalten.

Netflix-Architektur Blogserie – Teil 3: Netflix Open Source Services (OSS)

By | Allgemein, Inhaltliches | No Comments

In Teil 1 der umgekehrten Architekturbewertung gab es eine kurze Einführung, Teil 2 kümmerte sich um den Microservice-Ansatz von Netflix. Nun kommen wir zu einem Teil der Netflix-Architektur, der auch von Ihnen potentiell gut nutzbar ist, wenn Sie sich für eine ähnliche Architekturrichtung entscheiden: Die Open Source Services (kurz OSS) von Netflix. Sie bilden einen guten Teil dessen ab, was Netflix neben der eigenen Fachlichkeit an Services baut. Nicht alle Plattform-Services und andere technisch motivierten Services haben es in die Open Source Welt geschafft, aber es werden stetig mehr. Insgesamt erleichtert Netflix damit anderen Firmen den Einstieg in die Welt von Microservices. Doch was hat Netflix selbst davon?

Was leisten die OSSs?

Das folgende Bild zeigt die zentrale Architekturidee hinter den Open Source zur Verfügung gestellten Services. Auf Basis der Infrastruktur der Amazon Cloud wird eine Plattform etabliert, die es einfacher macht individuelle Software bzw. individuelle Services zu schreiben. Netflix selbst sagt: „The Netflix Open Source Platform Components fill gaps in Amazon Web Services. The goal is to make cloud infrastructure more robust, flexible and glitch free.”

Netflix OSS als PaaS (vereinfacht)

Ein schönes Zitat von Dianne Marsh zu den Open Source Services: „Das haben wir nicht für Euch gebaut, das haben wir gebaut, weil wir es brauchten, und es nicht da war. Aber jetzt ist es da.”. Einige Firmen bedienen sich dieser Plattform auch bereits. Yelp, Yahoo, Sincorp oder Hotels.com wären Beispiele, über das Spring Cloud Projekt und die dortigen Netflix-Abstraktionen kommt auch noch einmal ein breiteres Publikum in den Genuss einiger Services.

Wie passen die Komponenten dieser technischen Plattform nun zu den Microservices, die Netflix baut? In Teil 2 dieser Serie habe ich einen Architekturüberblick beschrieben. Im Folgenden ist der gleiche Überblick um die Information ergänzt, wo sich OSS Projekte einfügen (und wo AWS bereits hilft).

OSS und AWS Komponenten in der Netflix Architektur (vereinfacht)

Neben den Projekten die direkt der Struktur und dem laufenden Programm zugeordnet werden können hat Netflix auch OSSs für Deployment, Monitoring oder zum Test der Fehlertoleranz (die berühmte Simian Army). Auf einige dieser Projekte kommen wir in Teil 4 dieser Serie noch zu sprechen. Eine vollständige und aktuelle Liste der Projekte finden Sie unter https://github.com/netflix.

Auswirkungen und Rückschlüsse

Was kann man aus der OSS-Initiative von Netflix für Rückschlüsse auf deren Ziele und Rahmenbedingungen ziehen?

  1. Netflix braucht Entwickler. Die Open Source Services sind gut sichtbar und auf vielen Konferenzen präsent. Damit erscheint Netflix als Vorreiter und attraktiver Arbeitgeber. Mit den Open Source Services sinken die Anforderungen an jeden einzelne Entwickler – sie werden bei der Entwicklung von vielen technischen Details entkoppelt und auch die Infrastruktur ist einfacher einzubinden und anzusprechen. Das ermöglicht wiederum schnelleres Wachstum.
  2. Für Netflix ist schnelle Handlungsfähigeit und Time-to-Market wichtig. Entwickler kennen den Stack vermutlich bevor sie sich bei Netflix bewerben und neue Services sind schnell aufgesetzt. Funktionale Erweiterbarkeit scheint ein wichtiges Qualitätskriterium zu sein.
  3. Innere Qualität der Services ist relevant. Fachliche Services werden mit intern anerkannten technischen Lösungen ergänzt, die sich bewährt haben. Die technischen Services selbst werden durch das Open Source stellen in ihrer Qualität gefördert. Es gibt damit ein Mindestmaß an Dokumentation im Wiki oder Techblog und das Design wird aufgeräumt. Ideen von Anwendern helfen zusätzlich.
  4. Netflix muss Qualitätsanforderungen wie Verfügbarkeit und Skalierbarkeit sicherstellen. Viele OSS-Projekte kümmern sich um diese beiden Themen und man kann so spezialisierte Teams mit Experten auf die Lösungen ansetzen. Gleichzeitig verhindert man damit Wildwuchs in diesen heiklen Gebieten (siehe auch letzter Absatz dieses Posts).

Im abschließenden Teil (5) dieser Blogserie werde ich diese Rückschlüsse noch einmal verdichten und gemeinsam mit den anderen Erkenntnissen dieser Serie aufgreifen.

Ein spannender Aspekt der Open Source Plattform von Netflix ist übrigens, dass technische Konzepte und Ideen damit kommuniziert werden. Durch die Verwendung von Hystrix müssen sich die Service-Eigner weniger Gedanken um Ausfälle und Latenzprobleme machen, gute Architektur-Prinzipien und –Patterns werden automatisch umgesetzt. Ribbon erleichtert die RESTvolle Kommunikation und fördert damit deren Einsatz. Es steht Teams bei Netflix frei was sie machen, aber eine gewisse „Anti-Zähigkeit im Design“ leitet sie mehr oder weniger sanft in eine bestimmte Richtung. Wenn ein Team vom einfachen Weg abweicht hat es bestimmt einen Grund und hat sich das gut überlegt. Ein interessanter Ansatz der Architekturboards, Unternehmensstandards und Assessments etwas alt aussehen lässt. Diese und andere Techniken der Architekturgestaltung werde ich am 22. Oktober auf einer Session beim Architecture Gathering in München vorstellen. Titel: NoBullshit – Architekturarbeit neu gedacht.

JavaScript-Web-Frameworks Update

By | Inhaltliches, Vorträge | 2 Comments

Bei unserem Abendvortrag bei der Buchhandlung Lehmanns in Hamburg haben wir dieses mal die JavaScript Web-Frameworks, Angular 1 und 2, Ember, React und Polymer (Web Components) verglichen.

Für die Ungeduldigen hier gleich der Überblick, basierend auf unseren Erfahrungen mit den unterschiedlichen Frameworks:

User Experience Developer Experience Standards Investitionssicherheit
Angular 1 +
(langsam bei vielen Komponenten)
o
(viel Magie, Komponenten unnötig komplex)

(Angular-way eher Java-Stil)
o
(muss migriert werden)
Polymer +
(nur in Chrome optimal)
o
(bisher nur geringe Toolunterstützung)
+
(basiert auf Standard und 1.0)
o
(1.0, aber wer setzt das ein?)
Ember ++ + (Ember Way)
– (Ember Way)
+ +
(stabile Community)
React ++ Für JS-Dev: ++ (Turnaroundzeiten)

Für Java-Dev: o (viel neues)
+ +
(Einsatz bei Facebook, Rückwärtskompatibilität)
Angular 2 ++ (vermutlich) o
(vieles neu)
+
(bisher kein Release)

Der besondere Blick auf Angular

Wie schon in unserem vorherigen Vergleich in diesem Blog haben wir einen besonderen Blick auf das Framework Angular. Angular 2 ist nach wie vor das bedeutendste JavaScript-Web-Framework:

Web-Frameworks Trend: Angular dominiert das Feld nach wie vor

Web-Frameworks Trend: Angular dominiert das Feld nach wie vor


Während für Angular 2 nach wie vor keine wirkliche Roadmap existiert, gibt es nun zumindest einen Plan für eine sanfte Migration und eine Einsatz beider Frameworks in einer Übergangsphase.

Web Components

Google hat mit den
Web Components Komponenten im Browser als Standard initiiert. Dieser Standard wird momentan nur in Chrome unterstützt, Microsoft arbeitet an der Umsetzung in ihrem Edge-Browser und Firefox unterstützt nur einen Teil der Spec. Safari rührt sich gar nicht.

Das Polymer Framework setzt auf Web Components auf, macht sie in allen Browsern lauffähig, vereinfacht ihre Entwicklung und kommt gleich mit einer ganzen Bibliothek von Standard-Komponenten. Es ist als 1.0-Release verfügbar.

Fazit

Nach wie vor ist das Feld der JavaScript-Web-Frameworks schnelllebig. Welches Framework das richtige ist, hängt hauptsächlich von individuellen strategischen Überlegungen und Anforderungen ab. Ob sich eines der Frameworks gegen die anderen durchsetzen wird und welches Framework das dann wäre ist nicht absehbar. Auch die vermeintliche Sicherheit durch den Standard Web Components können wir so nicht bestätigen. Ohne ein Framework sind Web Components nicht sinnvoll einsetzbar.

Wir empfehlen das Web, HTML, CSS und JavaScript als das zur Zeit sicherste Investment, bei der Auswahl des Frameworks sollten Sie aber auf eine möglichst geringe Bindung an die individuelle Technik des Frameworks achten.