Self-Contained Systems – Teil 2

Eberhard Wolff: Willkommen zur zweiten Folge über Self-Contained Systems. Mein Name ist Eberhard Wolff, ich sitze hier mit Stefan Tilkov und wir wollen in dieser Folge darüber reden, warum man eigentlich Self-Contained Systems machen wollen würde, was Herausforderungen dort sind und wo das Ganze herkommt, wie man sich selbst damit beschäftigen kann, nachdem wir ja in der ersten Folge vor allem darüber gesprochen haben, was Self-Contained Systems sind. Also Gründe für Self-Contained Systems.

Ich kann mal anfangen, ich glaube, ein wichtiger Grund ist, wir können ganz viele Dinge lokal entscheiden, wenn wir das so aufbauen. Das heißt wir können…für mich ist das eigentlich ein Thema aus der Modularisierung. Wenn wir über Module reden, wollen wir eigentlich entkoppeln. Normalerweise würden wir sagen: das ist etwas, wo wir architektonisch Geschäftslogik voneinander entkoppeln, und hier haben wir andere Dimensionen der Entkopplung. Das heißt, wenn ich in einem Self-Contained System sitze, kann ich selbst Technologie-Entscheidungen treffen, die die anderen Self-Contained Systems nicht beeinflussen. Mein System kann ausfallen, ohne dass es die anderen Self-Contained Systems beeinflusst, weil die Kommunikation asynchron ist und ich dadurch keine Fehlerkaskaden bekomme. Ich kann bestimmte Infrastrukturen benutzen, ohne dass andere Self-Contained Systems das tun können, und so weiter und so weiter. Und ich glaube, dadurch haben wir einfach eine ganze Menge an zusätzlichen Dimensionen von Entkopplung und können, nutzen das halt letztendlich aus, damit Teams und Entwickler unabhängig arbeiten können und wir dadurch insbesondere große, komplexe Systeme einfach entwickeln können.

Stefan Tilkov: Ich glaube, das ist eine ganz, ganz zentrale Motivation. Wir wollen irgendwie diese Lokalität hinbekommen und wir nutzen auch oft den Begriff Isolation. So ein bisschen kann man sich das vielleicht vorstellen wie isolierte Teilbereiche, die einfach nur dann sichtbar werden, wenn es für mich an einer Schnittstelle relevant wird. Diese Idee der Trennung von Schnittstelle und Implementierung ist ja steinalt und nichts Neues, die ist ja seit 50 Jahren in der IT. Aber hier ist sie sehr weitgehend durchgezogen. Also, es ist nicht nur eine lokale Entscheidung darüber, welche Implementierungsstrategie ich hier wähle, also wieviele Methoden ich benutze, und wie ich meine Klassen schneide. Sondern es ist eine ganz zentrale Möglichkeit, ganz, ganz wesentliche Entscheidungen anders zu treffen. Ich kann in meinem Self-Contained-System oder das Team, in dem ich bin, wir können in unserem Self-Contained System sehr, sehr umfassend andere Entscheidungen anders treffen, als das jemand anderes machen kann und es tut niemandem weh. Wenn wir uns entscheiden, jetzt mal, je nach dem Grad von Freiheit, den man so erlaubt – aber nehmen wir mal an, wir erlauben sehr viel Freiheit – dann könnte das Team entscheiden, jetzt einfach mal von Java auf Scala umzustellen oder auf Ruby oder auf Clojure oder Elixir oder was auch immer, die Programmiersprache zu wechseln, eine andere Datenbank einzusetzen, vielleicht irgendetwas zu mischen, vielleicht wilde Experimente zu machen. Ich kann all diese Dinge lokal tun, ich muss dazu kein Meeting einberufen. Ich benutze immer gerne, das habe ich letztes Mal schon, den Begriff Meeting-Vermeidungs-Architektur. Also ich muss nicht erst mit 100 Leuten abstimmen, was wir jetzt für eine neue Basisbibliothek einführen, sondern ich kann das einfach in meiner lokalen Insel anders entscheiden.

Eberhard Wolff: Vielleicht ein Ergänzungspunkt noch, sozusagen ein bisschen auf der Metaebene. Ich habe das Gefühl, dass manchmal die Diskussion sehr stark, auch bei Microservices, in eine Richtung läuft, wo man sagt: Naja, eigentlich ist das eine Meetings-Vermeidungs-Architektur. Du hast es ja selbst gerade gesagt. Wenn man das Argument sozusagen ein bisschen umdreht, kann man sagen: Naja, aber das macht dann ja nur Sinn, wenn ich ein genügend großes Projekt habe mit ganz vielen Teams, weil, wenn ich alleine oder mit 5 Leuten an irgendeinem Projekt sitze, dann macht das ja keinen Sinn, weil dann hab ich ja eh keine Meetings. Wir sitzen dann halt alle in einem Raum und können uns sozusagen ohne Weiteres koordinieren. Ich glaube, und das ist etwas, das für Self-Contained Systems gilt wie auch für Microservices, dass es trotzdem gute Gründe dafür geben kann, diese Ansätze zu nutzen, weil es einfach eine ganze Menge von anderen Vorteilen auch gibt, über die wir ja auch gleich nochmal diskutieren werden. Und das ist auch etwas, das ich bei Kunden beobachte. Es ist mitnichten so, dass wir nur Projekte haben, die wir mit Self-Contained Systems aufsetzen, wo wir hunderte von Entwicklern haben.

Stefan Tilkov: Das ist richtig, genau. Ich finde es trotzdem wichtig, dass man auch diesen Ansatz hinterfragt. Wir finden den ja beide gut, sonst würden wir nicht darüber reden, ich halte den in ganz vielen Fällen für sehr, sehr angemessen, ich halte den für besser, als viele andere Ansätze. Aber er ist nicht immer angemessen und man muss das auch nicht zwingend machen, es ist nicht so, als ob das jetzt die einzig denkbare Architektur wäre. Es kann absolut schlüssig sein, zu sagen, ich brauche das nicht, ich brauche diesen Overhead nicht, denn ich brauche diese Nachteile nicht, die gibt es ja durchaus auch. Ich baue einfach einen Monolithen, zum Beispiel, weil mein System so klein ist und so handhabbar und so wenig sekundäre Anforderungen hat, dass ich da nicht großartig davon profitieren würde. Das ist legitim und in Ordnung, wie immer, solange ich ne Menge von Werkzeugen in meinem Werkzeugkasten habe und das Passende auswähle, ist alles in Ordnung. Nur ein bisschen blöd ist, wenn ich nur einen Hammer habe und glaube, mit dem Hammer kann ich jetzt die Schrauben in die Wand drehen, dann tut es halt weh.

Eberhard Wolff: Wobei ich gestehen muss, dass der Self-Contained-Systems-Ansatz nach meinem Empfinden auf erstaunlich viele Situationen passt.

Vielleicht an der Stelle noch ein Punkt, wir hatten das bei der letzten Folge schon diskutiert, wir haben ja gesagt: es gibt keine gemeinsame UI und es gibt häufig so eine Situation, in der gesagt wird: Naja, machen wir doch. Wir bauen eine große Angular-Single-Page-App, weil Single-Page-Apps sind ja die Lösung aller unserer Probleme. Und dann haben wir halt dahinter verschiedene Services, die aufgeteilt sind, was genau das ist, was wir mit Self-Contained Systems eigentlich nicht wollen. Definitiv ist das nicht die, die wir dort haben. An der Stelle finde ich es aber dann sinnvoll, eine Diskussion zu führen und zu sagen: Ihr wollt eine gemeinsame UI haben, das habe ich verstanden, ihr wollt aber dieses stark getrennte Backend haben. Warum? Da ist irgendwie ein Widerspruch. Ich glaube, dass dann ein gültiges Ergebnis der Diskussion sein könnte, dass man sagt: Okay, eigentlich brauchen wir auch diese krasse Trennung des Backends nicht. Nur, sozusagen, das Backend so stark zu trennen und das Frontend in einem zu lassen, das finde ich inkonsistent. Das passt zu dem, was du gesagt hast. Also ich finde es valide, wenn man sagt: Naja, vielleicht bauen wir das Backend auch als Deployment-Monolithen, aus folgenden Gründen. Nur, dass man sozusagen beide Architekturentscheidungen in dem selben System hat, das finde ich ein bisschen komisch, insbesondere weil der Preis, den man bezahlt dafür, dass man diese sehr starke Trennung im Backend hat, weil der eben doch signifikant ist.

Stefan Tilkov: Ich habe auch die Erfahrung gemacht, dass viele Leute, wenn man mit ihnen darüber redet, sich absolut bewusst sind, dass sie sich da einen Frontend-Monolithen bauen, oft aber gar nicht wissen, was eine Alternative sein könnte. Das ist vielleicht das, was mir am meisten wehtut, gar nicht so sehr, dass unbedingt immer der eine Ansatz der Richtige ist. Es ist oft so, dass nur ein Ansatz gesehen wird, aus welchen Gründen auch immer. Weil es zum Beispiel der Populäre ist, weil es der der Standard-Ansatz ist, der im Moment überall gepredigt wird. Das finde ich dann sehr schade. Wenn man sich aus guten Gründen für einen Ansatz entscheidet, ist das ja in Ordnung, man kann sich auch aus guten Gründen für eine Single-Page-App entscheiden, man kann sich aus guten Gründen für einen Frontend- oder Backend-Monolithen oder beides entscheiden, das sind gültige Varianten. Es gibt auch, das können wir auch noch in die Shownotes reinpacken, ich habe für SE-Radio einen Podcast aufgenommen, mit DHH, mit David Heinemeier Hansson, dem “Ruby on Rails”-Vater, der ganz stark den, wie er es sagt, majestätischen Monolithen verteidigt. Das ist eine sehr schlüssige Argumentation, finde ich absolut gültig, auch völlig legitim. Man sollte da alles in Frage stellen, und dann die Variante wählen, die einem persönlich am besten gefällt. Aber lass uns zurückkommen auf ein paar Begründungen, was wir noch so an positiven Dingen finden. Ich glaube, wir haben noch ein paar Dinge in unserer Liste, über die wir noch nicht gesprochen haben.

Eberhard Wolff: Unabhängige Skalierung ist ein Beispiel, ich kann jedes von den Self-Contained Systems in einer oder mehreren Instanzen betreiben und dadurch eben das unabhängig skalieren. Das ist etwas, das, glaube ich, eher unterschätzt wird. Ich kann theoretisch ja auch einen Deployment-Monolithen mit mehreren Instanzen betreiben und von daher ist dann auf den ersten Blick alles gut. Aber de facto ist es eben so, dass ich da eine ganze Menge an Ressourcen verbrauche und es halt auch schwierig ist, das Ding überhaupt zu betreiben und zu installieren, sodass die Aufteilung in Self-Contained Systems dort vorteilhaft ist.

Stefan Tilkov: Ich würde das sogar noch allgemeiner sagen: ich könnte mich entscheiden, ein Self-Contained System mit einer hoch-skalierbaren Technologie zu bauen, was auch immer das ist, muss ja nicht nur dieser Weg sein. Könnte ja auch irgendetwas anderes sein, vielleicht baue ich ja eines meiner Self-Contained Systems mit einem High-Performance-Messaging-System und irgendwelchen anderen, keine Ahnung, irgendeiner AP-NoSQL-Datenbank, die wahnsinnig toll skaliert, und betreibe das auf hunderten von Servern, während ein anderes Self-Contained System vielleicht nur von 10 Leuten im Backoffice benutzt wird. Und das baue ich dann als Standard-Webanwendung auf einer MySQL-Instanz oder so. Die Entscheidung unterschiedlich treffen zu können, ist der eigentliche Wert hier.

Eberhard Wolff: Genau. Ersetzbarkeit, auch ein klassischer Wert, den auch Microservices haben. Ich kann eben ein Self-Contained System gegen eine neue Version austauschen. Das ist für mich deswegen eigentlich zentral, weil eine ganze Menge Leute damit beschäftigt sind, Legacy-Anwendungen zu ersetzen und niemand macht denen das Leben einfacher. Normalerweise, wenn wir anfangen und ein System bauen, dann diskutieren wir nicht darüber, wie wir dieses System mal loswerden, diese Ersetzbarkeit, diese Aufteilung von Self-Contained Systems, das ist einer der wenigen Ansätze, die ich kenne, die halt in diese Richtung marschieren.

Stefan Tilkov: Genau. Man könnte sogar argumentieren, dass dieser Ansatz, die Gesamtarchitektur zu bauen, ist der Einzige, den ich nicht revidieren muss, wenn ich modernisieren will. Das ist dann ein Meta-Ansatz sozusagen. Ich habe es jetzt aufgeteilt, ich habe jetzt aus meinem einen großen System vielleicht zehn, fünfzehn Self-Contained Systems gemacht - das ist, glaube ich, eher die Zahl, die uns vorschwebt, als fünfhundert, also eher in der niedrigen zweistelligen Größenordnung. Wenn ich so eine Menge von Self-Contained Systems habe, dann kann ich eine Architektur modernisieren nach der anderen und die jeweils für ein einzelnes System machen. Das ist eines der größten Probleme, die viele unserer Kunden haben, dass sie zum Beispiel auf einem Persistenz-Layer festhängen, der irgendwann im Jahr 2003 mal eine hervorragende Idee war, also einem selbstgeschriebenen OR-Mapper mit eigenem Framework. Das war alles mal total “State of the Art” vor vielen, vielen Jahren, ist aber leider auch nicht so einfach zu modernisieren, weil jede Modernisierung eben bedeuten würde, dass man auch die anderen 10 Millionen Zeilen Code Fachlichkeiten, die daran hängen, mit modernisieren muss. Deswegen passiert es einfach nicht. In dem Self-Contained-Systems-Ansatz versucht man genau diesen Punkt mit diesen Grenzen zu adressieren.

Eberhard Wolff: Und umgekehrt bedeutet es eben auch, dass man eine Möglichkeit hat, neue Technologien mit geringem Risiko auszuprobieren. Ich kann meine neue Technologie in einem dieser Self-Contained Systems erstmal nutzen und schauen, ob es sich da halt bewährt, bevor ich das global ausrolle, was, glaube ich, auch wieder dazu führt, dass ein Szenario, wo ich jetzt sage: Naja, die nächsten zwei Jahre oder die nächsten Monate kümmern wir uns darum, das halt auf die aktuelle Java EE Version zu heben. So etwas passiert in so einem Szenario weniger, in einem Self-Contained System, weil ich eben eh schon mal einzelne Self-Contained Systems auf die neue Version heben kann oder vielleicht mal ganz andere Ansätze ausprobieren kann und dadurch kann ich dort modernisieren, wo es sozusagen sinnvoll ist. Ich bin also nicht dazu gezwungen, zu sagen: Okay, jetzt stoppen wir das mal kurz und machen eine Modernisierung, global-galaktisch, sondern ich kann sagen: Okay, jetzt machen wir an dieser Stelle, an der ich halt eh gerade neu implementiere, wo es mir halt gerade tatsächlich wehtut, dass wir diesen alten Technologiekram haben oder was auch immer.

Stefan Tilkov: Ja, das empfinde ich als einen ganz wichtigen Punkt, auch da finde ich nochmal wichtig zu betonen, der Grad, zu dem man da Freiheiten lässt, ist sehr, sehr organisationsabhängig und kulturabhängig. Es kann durchaus sein, dass man sehr konservativ ist. Es ist nicht nur etwas für Leute, die extrem innovativ und progressiv immer gleich jede neue Programmiersprache ausprobieren wollen, 3 Monate, nachdem sie herausgekommen ist. Selbst wenn meine gesamte revolutionäre, radikale Fortentwicklung darin besteht, mal von Java 7 auf Java 8 upzudaten, ist das sehr, sehr viel leichter, wenn ich diese Grenzen habe, in denen ich sowas ausprobieren kann. Also einfach moderate Dinger zu machen. Und selbst das konservativste Unternehmen, selbst die konservativste Teamzusammenstellung steht ja nicht still, auch die muss sich ja weiterentwickeln und das immer nur mit allen, überall, für alles gleichzeitig machen zu können, ist eine sehr, sehr schwere Last.

Eberhard Wolff: Genau. Das bringt uns eigentlich zu einem wichtigen Thema, das wir vielleicht noch nicht diskutiert haben, also diese Freiheit und die Unabhängigkeit und auch die Flexibilität, die man hat bezüglich Technologien, sind Optionen. Es ist nicht jemand dazu gezwungen, diese Optionen sofort einzulösen. Und die Konzepte, die wir da ja haben, sind eben Mikro- und Makro-Architektur, dass ich eben sage: Es gibt bestimmte Entscheidungen, die ich global fälle und so eine Entscheidung könnte sein, dass eben jedes von diesen Systemen, weiß ich nicht, mit Spring Boot und Java entwickelt ist. Und der wesentliche Punkt ist: die Aussage ist nicht, benutzt jede Technologie, die ihr jemals benutzen wollt, sondern: Ich habe die Option, das zu tun. Und selbst wenn ich die Option nicht einlöse, habe ich Vorteile. Ich kann nämlich jetzt sagen, okay, ich benutze in diesem System die neue Spring-Boot-Version, die hat gerade einen Bug Fix, den ich halt unbedingt benötige und die anderen Self-Contained Systems sind davon unbeeinflusst. Und unsere Erwartungshaltung wäre es – da hast du auch mal so eine schöne Folie gemacht – dass wir über die Zeit eher, also am Anfang wäre es wahrscheinlich so, dass wir alle sagen würden, okay, wir benutzen alle Spring Boot und unsere Erwartungshaltung wäre, dass wir halt über die Zeit dann eher in einen Bereich kommen, wo wir sagen: Naja, jetzt haben wir ein paar mehr Technologien, weil eben hier noch ein System reingekommen ist und dann müssen wir irgendetwas integrieren, was halt eh schon in Scala geschrieben ist oder was weiß ich. Und dann kommt man halt eher zu so einem breiteren Ding.

Die andere Sache, die da, glaube ich, auch wichtig ist, ist, dass ich durch eine geschickte Wahl von Mikro- und Makro-Architekturregeln mich in dem, was ich tue, fokussieren auf das, was tatsächlich notwendig ist. Was ich damit konkret meine, ist Folgendes: Typischerweise sind Leute, die halt so global-galaktische Regeln versuchen durchzusetzen, Leute, die sich nicht langweilen. Das bedeutet, wenn ich ein Architekt in so einem System bin und ich mich hinstelle und sage: Ihr müsst aber alle den Code folgendermaßen formatieren, ist das möglicherweise nicht das, was wirklich, wirklich wichtig ist. Ist es wichtig, durchzudrücken, dass jeder Spring Boot macht? Vielleicht. Aber was wahrscheinlich auf jeden Fall wichtig ist, wenn ich eine getrennte Betriebseinheit habe, ist, dafür zu sorgen, dass die Software sich einheitlich betreiben lässt. Und dadurch kann ich jetzt ein Regelset schreiben, was sagt: Ok, wenn ihr euch nicht so verhaltet, dass wir diese Software diesem Betrieb einfach geben können und halt die Standardverfahren funktionieren, also wenn ihr nicht das Standard-Logging, -monitoring oder was weiß ich macht, dann werdet ihr nicht in Produktion gehen und da gibt es keinen Kompromiss und keine Verhandlungslinie. Wenn ihr aber sagt, ihr wollt ein eigenes Framework benutzen, ja, das ist denkbar, im Rahmen dieser Parameter. Vielleicht muss man sich noch ein Okay holen, aber bestimmte Dinge sind dann tatsächlich fest, und auf die kann ich mich fokussieren. Das trägt dem Rechnung, dass ich argumentieren würde, dass diese Initiativen “Wir standardisieren uns alle” üblicherweise nicht funktionieren.

Stefan Tilkov: Ja, ich glaube, das ist ein relativ subtiler Unterschied, auf dem man durchaus noch ein bisschen rumreiten kann. Es gibt Regeln, die ich treffe, je nachdem, wie groß die Organisation ist, aber die meisten, selbst kleine Organisationen geben sich die dann selbst, die mache ich einfach, um Skill-Transfer zu vereinfachen, um Ausbildung zu vereinfachen, um Dinge nicht so kompliziert zu haben, um nicht 100 verschiedene Technologien zu haben, lege ich mich mal auf irgendetwas fest. Das ist gut und richtig, das stellen wir ja gar nicht in Frage. Das ist in Ordnung. Da lege ich zu einem Zeitpunkt X fest: Das ist mein Technologie-Stack. Oder vielleicht: Das sind meine zwei alternativen Technologie-Stacks. Je nachdem, wie variabel man da sein möchte. Und das sind Regeln, die vielleicht für alle gelten, aber das macht sie noch nicht automatisch zu Makro-Architektur-Regeln. Makro-Architektur-Regeln werden sie dann, wenn sie auch langfristig halten müssen. Das wäre zum Beispiel so etwas wie: “Ich standardisiere mich auf webbasierte Integrationen”. Weil dann kann ich nächstes Jahr eine andere Programmiersprache benutzen, eine andere Implementierungs-Technologie, ein anderes Framework, und mich trotzdem noch an diese Makro-Regel halten.

Diese Dinge zu vermischen, also das Langfristige, das zur Kommunikation und zur Integration und zum gemeinsamen Betrieb und zur gemeinsamen Überwachung dieser einzelnen Systeme notwendig ist, sollte man trennen von den Vorgaben, die man vielleicht für die Implementierung macht, auch wenn die überall gleich sind. Das hast du gerade sehr schön mit dem Beispiel genannt, dazu gibt es auch schöne Erfahrungsberichte von Otto, die den Shop nach diesem Muster gebaut haben. Da gibt es, glaube ich, auch einen Vortrag von Guido Steinacker von der GOTO in Berlin, den wir bestimmt verlinken können. Da geht es darum, dass die gestartet sind mit einem einheitlichen Technologie-Stack in all ihren einzelnen Systemen, sie nennen die Vertikale, im Prinzip der gleiche Ansatz, aber etwas andere Begrifflichkeit. Und dieser gemeinsame Technologie-Stack, mit dem alle losgelaufen sind, der hat sich dann eben im Laufe der Zeit verändert, weil die einzelnen Teams gemerkt haben: Hier, wir können vielleicht, ich weiß nicht mehr, wie rum es war, Spring MVC benutzen wir hier, Jax-RS oder anders herum, hier probieren wir jetzt mal Scala aus, hier probieren wir jetzt mal Clojure aus, es konnte sich im Laufe der Zeit weiterentwickeln, als die Organisation reif dafür war, das auszuprobieren. Und das hat nichts an den größeren Makro-Prinzipien kaputtgemacht.

Eberhard Wolff: Genau und das ist glaube ich ein wichtiger Punkt, weil sonst häufig, wie soll ich sagen, so ein Wildwuchs entsteht, der tatsächlich nicht mehr kontrollierbar ist. Hier sagt man halt: Naja, der Wildwuchs, der ist halt in gewissem Maße kontrolliert und an bestimmten Stellen machen wir eben keine Kompromisse.

Stefan Tilkov: Das finde ich auch sozusagen politisch, diplomatisch, von der Kommunikation her ein gutes Muster. Wenn ich sage: Ich mache nur wenige Regeln, ganz, ganz wenige, ich lasse viel Freiheit, ich bin jetzt der große Architektur-Chef, ich versuche meine Rolle zu finden, dann mache ich lieber wenige Regeln, die ich auch durchsetzen kann und lasse dafür Freiheiten, bei den Sachen, die mir nicht so wichtig sind, anstatt zu versuchen, alles zu standardisieren. Was aus genau den Gründen, die du gerade genannt hast, einfach sowieso nicht funktioniert. Ich kann nicht überall Polizei spielen und jeden Mist überwachen, das bringt auch gar nichts.

Eberhard Wolff: Genau. Da vielleicht noch einen letzten Gedanken zu. Ich glaube halt auch, dass es ein Problem ist, wenn ich sage: Ich bin der global-galaktische Architekt, der über das Gesamtsystem wacht. Viele von den Entscheidungen, die ich dann fällen kann, sind eigentlich Sachen, die nicht mich betreffen, sondern die Teams, die halt irgendetwas bauen. Und das ist, glaube ich, einer der Vorteile von den Self-Contained Systems, dass man dann sagen kann: Naja, entscheidet es halt, macht ihr es halt. Ich will dafür nicht die Verantwortung übernehmen, ihr müsst dafür die Verantwortung übernehmen, das ist eure Entscheidung, macht das. Was eben positiv gesagt auch bedeutet, dass die Teams die Werkzeuge auswählen können, die dann für sie besonders sinnvoll sind in dem jeweiligen Kontext. Und das verhindert, dass man sich hinstellt und sagt: „Ich entscheide das jetzt mal kurz für euch alle“, und das kann eigentlich nicht vernünftig funktionieren, weil man auf dem Detaillevel, das die Teams vor Ort haben, gar nicht in die Themen involviert sein kann. Und dann ist die Frage, warum sollte ich das überhaupt entscheiden, wenn es halt offensichtlich Leute gibt, die qualifizierter sind, weil sie sich jeden Tag mit dem Thema beschäftigen, während ich irgendwie da nur mal zentralisiert drüber gucke.

Stefan Tilkov: Die Grundphilosophie sieht man: sich als Architekt in der Rolle einfach alles besser zu wissen und allen Vorschriften zu machen, aufgrund höherer Kompetenz qua Amt. Oder glaubt man eben daran, dass die Entscheidung besser so nah wie möglich an der tatsächlichen Stelle passieren soll, wo die Arbeit passiert. Ich glaube, wir haben die gleiche Sicht, wir wollen das eher soviel wie möglich in die Teams bringen, Subsidiaritätsprinzip sozusagen. Soviel wie möglich ganz in der Hierarchie, sozusagen ganz weit unten, in Anführungszeichen, entscheiden und nur die Dinge, die eben wirklich übergreifend standardisiert werden müssen, auch tatsächlich übergreifend standardisieren. Nicht mehr.

Eberhard Wolff: Für mich ist auch ein Aspekt dabei: Wer es entscheidet, soll es sozusagen ausbaden. Das ist so die Gesamtstrategie. Was übrigens auch bedeutet, dass dieser Ansatz davon ausgeht, dass die Teams es tatsächlich anschließend ausbaden müssen. Ein Gegenbeispiel sozusagen, wenn ich jetzt sage "Okay, ich habe ein Team voller Externer und es ist absehbar, dass die Externen nach einem Jahr weg sind und die sagen jetzt “Naja, wir machen irgendwie…”

Stefan Tilkov: Haskell

Eberhard Wolff: Genau. Dann ist die Frage, will ich dem das wirklich zugestehen, weil wahrscheinlich die Leute, die es anschließend weiter warten und ausbaden müssen, andere Leute sind. Und das ist auch das, wo die strategische Ebene reinkommt, wo man, glaube ich, total zu Recht sagen kann: „Nein, das wollen wir nicht, weil wir andere Ziele haben, die global sind, also zum Beispiel, dass wir Leute auf dem Arbeitsmarkt finden wollen, dass wir Leute zwischen Teams austauschen wollen, deswegen entscheiden wir, dass wir Haskell nicht machen in diesem speziellen Fall, sondern eben auf irgendetwas anderes setzen.“

Stefan Tilkov: Wobei ich natürlich nichts gegen Haskell sagen wollte, das ist ja eine hervorragende Programmiersprache und vielleicht findet man dann die allerbesten Leute, wenn man sich mal durchringt, endlich mal konsequent in Haskell zu programmieren.

Eberhard Wolff: Genau.

Stefan Tilkov: Aber eher unwahrscheinlich bei den meisten unserer Kunden, leider.

Eberhard Wolff: So. Das also zu den Vorteilen. Herausforderung, ein Thema, das mir einfallen würde, ist tatsächlich das Thema rund um UI-Integration und die Art und Weise, wie man Querverbindungen baut. Die schlichte Beobachtung ist, über die man jetzt mehr oder weniger begeistert sein kann, dass eine ganze Menge Leute Angular Single Page Apps und solche Sachen machen. Und das ist etwas, was sich mit diesem Konzept relativ stark beißt. Da haben wir auch die Folge über UI-Integration, in der wir da nochmal im Detail drauf eingehen. Ich persönlich finde das ein bisschen absurd, weil wir eigentlich ja mit Self-Contained Systems ja eigentlich sagen: Baut richtige Web-Anwendungen mit HTML und so etwas, so wie Web-Anwendungen eigentlich sein sollen. Und wir leben halt in einer Welt, wo das tatsächlich etwas ist, wie man typischerweise Web-Anwendungen nicht mehr so häufig baut und das führt zu einem Problem bei der Adaption. Weil ich mich schwer hinstellen, also in der Technologie-Entscheidung zugunsten einer Single-Page-App-Technologie ist das relativ inkompatibel mit dem Self-Contained Systems-Ansatz. Das ist aber das, was Leute heutzutage typischerweise tun, das führt zu einer Herausforderung.

Stefan Tilkov: Ich habe gerade heute einen Post gelesen, in dem der Begriff SPE definiert wurde, das hat sich jemand ausgedacht, “Single Page Experience”. Das fand ich eine schöne Idee. Der argumentierte dafür, dass man im Prinzip das, was Endanwender an Single Page Apps gut finden, nämlich die User-Experience, ne? Das Schnelle, die Flüssigkeit in der Interaktion, und so weiter und so fort, dass man diese Dinge nicht nur erreichen kann, wenn man eine Standard Single Page App baut, sondern man kann das auch erreichen, wenn man Technologien verwendet, die mehr unobstrusive sind, die vielleicht Service-Worker benutzen, die schon auf Performance optimiert sind, die durchaus von JavaScript abhängen, aber eben nicht diese eine Seite, diese eine Interaktion haben, das ist ja eben das Problem.

Ich weiß nicht, ob das allen klar ist, wir verweisen sicherlich nochmal explizit auf diese beiden Frontend-Integrations-Folgen, die das in epischer Breite diskutieren. Das Hauptproblem ist ja, dass in diesem Self-Contained Systems-Ansatz der Seitenwechsel eine typische Grenze beim Übergang von einem System zum anderen ist. Wenn ich nun keine Seiten mehr wechsele, weil ich nur noch eine Seite habe in einer Single Page App, dann ist die offensichtlich der Integrationspunkt. Und ich kann das sogar nachvollziehen. Ich verstehe, warum das auf den ersten Blick attraktiv wirkt. Weil diese Architektur, die die meisten Leute im Kopf haben, wenn sie so eine Single Page App über einen Microservice-Wald drübersetzen, sieht irgendwie nett aus. Solange, bis man sich darüber klar wird, dass man eben jetzt einen Frontend-Monolithen baut und je nachdem, wie groß der wird und wie schwierig der wird und wie schwergewichtig, handelt man sich all die Probleme, die man im Backend hofft, loszuwerden, im Frontend gleich wieder ein. Und das merken, glaube ich, mehr und mehr Leute.

Ich will damit Folgendes sagen: Ich glaube, dass es eine Gegenbewegung gibt, die nicht bedeutet, wir verteufeln jetzt Javascript und wir wollen keine modernen Webanwendungen bauen. Natürlich wollen wir alle moderne Webanwendungen bauen, aber ich glaube, es geht ein bisschen weg von dieser Idee, dass man alles in einem Ding integriert, es oszilliert, es pendelt sozusagen ein kleines bisschen wieder zurück in eine Welt, die, glaube ich, dann irgendwo in der Mitte landen wird, und die diese Ansätze verheiratet.

Eberhard Wolff: Genau. Vielleicht an der Stelle noch ein Hinweis. Die Art und Weise, wie ich darüber denke, ist: ich will halt Software modularisieren, ich will, dass eine Änderung typischerweise nur in einem Modul stattfindet. Das ist insbesondere der Fall in Systemen wie Microservices oder Self-Contained Systems, wo ich relativ viel investiere, um diese Module unabhängig zu bekommen. Und wenn ich dann irgendwie Änderungen mache, die halt mehrere Module betreffen, warum habe ich dann überhaupt dieses Investment getroffen in diese starke Unabhängigkeit? Meine Erwartungshaltung wäre, dass eine typische Änderung, die UI und die Logik umfasst. Das führt dazu, dass man eigentlich dann zwangsläufig sagen muss: Wenn eine Änderung in einem Modul nur stattfinden soll, dann sollte ein Modul auch im UI-Logik und -Daten enthalten, sonst macht das irgendwie alles keinen Sinn.

Stefan Tilkov: Ich stimme dir absolut zu. Ich sage immer noch: Wenn ich jetzt alles in einer App habe, in einer Single Page App, dann kann ich natürlich auch da modularisieren, genauso wie ich im Backend auch einen modularen Monolithen bauen kann – mit all den Vor- und Nachteilen, die das halt hat. Ich muss immer noch gemeinsam releasen, ich muss alles abstimmen, kann keine Versionswechsel machen, geht natürlich alles, ist halt einfach deutlich schwächer als der andere Ansatz. Deswegen wäre meine Empfehlung: Wenn man schon unbedingt Single-Page-App-Technologie-Stacks benutzen möchte, weil man, zum Beispiel, sich strategisch auf Angular oder React oder was weiß ich was festgelegt hat, dann sollte man in Gottes Namen wenigstens nicht nur eine bauen, sondern wenigstens mehrere. Und das ist nicht so schön, wie bei einem Wechsel zwischen anderen, weil die halt Ladezeiten haben und das ein bisschen dauert. Aber es ist immer noch besser, weil ich dann zumindest in diesen einzelnen Anwendungen lokale Entscheidungen treffen kann, zum Beispiel Angular 1 durch Angular 2 zu ersetzen oder React auszuprobieren oder was auch immer nächste Woche das Framework des Tages sein wird.

Eberhard Wolff: Genau. Das ist eine Herausforderung: UI-Integration. Ich glaube, die andere Herausforderung ist der höhere Aufwand für den Betrieb. Ich habe halt, das ist eine relativ schlichte Wahrheit, du hast es vorhin gesagt, wir haben halt irgendwie so fünf bis fünfzehn Self-Contained Systems, das wäre auch das, was ich erwarten würde. Und das bedeutet, dass wir halt statt einem Deployment-Monolithen eben fünf bis fünfzehn Systeme haben, die wir eben deployen und monitoren und was weiß ich müssen, und das bedeutet halt einfach, dass ich da mehr Aufwand habe. Das bedeutet zum Beispiel auch, dass man sehr viel automatisieren muss, weil wir reden halt über eine Größenordnung, das ist eine Größenordnung mehr an Dingen, die ich deployen muss, das kann ich nicht lösen, indem ich sage: Liebe Betriebsmannschaft, arbeitet irgendwie ein paar Stunden mehr pro Woche, sondern das ist eine Geschichte, wo ich tatsächlich Dimensionen benötige, was Automatisierung impliziert und in bestimmten Situationen ist das fast schon ein Killerargument. Wenn ich halt sage, ich baue ein Stück Standardsoftware, und dann sage ich halt irgendwie meinen Kunden: Ihr müsst jetzt übrigens nicht ein System, sondern irgendwie fünfzehn Systeme betreiben, dann ist das vermutlich bei den Kunden keine super Nachricht.

Stefan Tilkov: Hmm. Ja, ja, das wird normalerweise so sein. Zugegebenermaßen haben wir gerade einen Kunden gehabt, der von seinen Kunden wiederum dazu gedrängt wurde, ein bisschen Cloud-kompatibler zu werden und lieber Topologien zu unterstützen, die ein bisschen mehr dazu passen, aber genau. In der Regel gebe ich dir Recht, der Aufwand steigt. Es gibt natürlich ein paar Vorteile, die sich daraus ergeben, das kann man immer wieder direkt als Gegenargument bringen. Zum Beispiel: höhere Autonomie bedeutet auch, ich kann eines der Systeme herunterfahren, die anderen können weiterlaufen, ich kann besser skalieren. Aber wenn ich weder Skalierbarkeitsanforderungen habe, noch das System besonders verfügbar sein muss, weil es vielleicht nur zu Standard-Bürozeiten in einem Land laufen muss, dann sind das eben einfach keine überzeugenden Vorteile und man kauft sich erst einmal eine Menge Nachteile ein. Und die Frage, ob es das wert ist oder nicht, das muss man kontextspezifisch und projektspezifisch entscheiden.

Eberhard Wolff: Genau. Und man kann Kompromisse eingehen, man kann sagen, okay, wir bauen eben kein Self-Contained System, sondern wir bauen ein System, das zwar getrennte Datenbank-Schemata hat und eine getrennte Datenbank hat, aber eben an anderen Stellen integriert ist.

Stefan Tilkov: Was haben wir noch als Themen?

Eberhard Wolff: Wo kommt der Begriff her?

Stefan Tilkov: Ich glaube, der Begriff ist Resultat eines Brainstormings, als wir gemeinsam auf der Suche waren nach, also “wir” war jetzt eine größere Gruppe von Leuten, als wir gemeinsam auf der Suche waren nach einem passenden Begriff für etwas, was wir an vielen Stellen beobachtet haben. Und das ist glaube ich eine ganz wichtige Aussage, das ist eine Beobachtung, die man an vielen Stellen sehen kann: Genauso wie es den Begriff “Microservice” gibt, gab es eben auch für etwas, das viele Leute beobachtet haben, hatten wir auch das Bedürfnis, eine Variante, für die uns der Begriff “Microservice” nicht ganz passend erschien, eben auch mit einem Namen zu versehen.

Das ist eigentlich die einzige Motivation dahinter gewesen, dass wir gesagt haben, wir wollen einem Architekturmuster, das wir häufig sehen, mit dem wir Erfahrungen gesammelt haben, die überwiegend positiv sind, dem wollen wir einen klaren Namen geben, damit wir darüber reden können. Das ist die tatsächliche Motivation. Das Ganze ist als Begriff mit einer Beschreibung verfügbar auf einer Webseite, die du irgendwann mal aufgesetzt hast, die wir dann gemeinsam weiterentwickelt haben mit vielen Kollegen, aber auch mit externen Partnern. Ich glaube, das ist eine ganz wichtige Sache. Das ist keine reine innoQ Geschichte, das ist uns auch sehr wichtig, es ist nicht “innoQ SCS”, und wir haben da kein Trademark drauf und wir verbieten niemandem, diesen Begriff zu verwenden. Wir legen einen gewissen Wert darauf, dass wenn er verwendet wird, auch dieses Ding bedeutet, das ist uns schon wichtig, weil es sonst das Ganze nutzlos macht, wenn man sich nicht auf einen Begriff einigt, aber es ist gezielt eben kein Produkt und kein Framework und keine mit uns verheiratete Variante.

Eberhard Wolff: Genau, also das bedeutet halt konkret Folgendes: Die Inhalte auf der Webseite stehen unter Creative Commons, das heißt, die kann man selbst benutzen, da gibt es auch eine Präsentation, die man irgendwie benutzen kann, wir haben auf der Webseite Links hin zu Leuten, die es benutzen, wie auch zu Mitbewerbern, die darüber irgendwelche Blogposts geschrieben haben. Und das unterstreicht irgendwie genau das, was du schon gesagt hast, dass das irgendwie, also innoQ hat sozusagen den Begriff erfunden, das ist es aber auch. Und wir haben jetzt nicht die Absicht, da Leute, also wir wollen eigentlich, dass das etwas ist, was die Industrie insgesamt weiterbringt und nicht etwas, womit innoQ irgendetwas macht. Das wäre halt total sinnlos.

Stefan Tilkov: Genau. Was auch wichtig ist, man kann uns sehr, sehr gerne Pull-Requests schicken für die Seite, das passiert auch ständig, Leute finden Banalitäten wie Schreibfehler, Leute machen inhaltliche Ergänzungen, Leute schicken uns Links auf irgendwelche Vorträge, auf Artikel, auf Erfahrungsberichte. Und wenn das nicht völlig abwegig ist, nehmen wir die sehr, sehr gerne an, finden wir eine gute Sache. Wir behalten sozusagen den redaktionellen Hut auf, wenn jemand Lust hat, sich aktiv zu beteiligen, dann haben wir auch keine Probleme, jemandem Committer-Rechte zu geben. Wenn es genügend Beiträge dafür gibt, also wir wollen, dass das als Community-Begriff und als Community-Seite weiterentwickelt wird.

Eberhard Wolff: Genau. Was zu der Frage führt, wie kann ich eigentlich mitmachen? Du hast es schon gesagt, Pull Requests, das Projekt steht auf Github, dann kann man auch Issues einstellen und halt sonstige Dinge tun. Es gibt auf der Webseite auch eine Online-Diskussion, da kann man auch sehr gerne mitmachen, wir beteiligen uns da auch, und Links einschicken hatten wir auch schon diskutiert. An der Stelle halt die Einladung an alle, auch mitzumachen.

Stefan Tilkov: Sie heißt übrigens “scs-architecture.org”, das packen wir natürlich in die Shownotes, aber falls irgendjemand das jetzt gerade…

Eberhard Wolff: Es gibt auch einen Twitter-Account. Wer macht es denn?

Stefan Tilkov: Also zum einen, klar, machen wir es natürlich, in verschiedenen Projekten, großen und kleinen, das habe ich vorhin auch schon erwähnt. Wir haben diverse Kunden, ein paar, über die wir auch sprechen, im Kleinen und im Großen, es gibt Erfahrungsberichte, zum Beispiel von Otto, die sehr, sehr aktiv sind. Die haben wir mal initial beraten, aber es ist gar nicht so, dass wir denen das in den Mund gelegt haben, sondern die haben da sehr, sehr viel selbst mit- und weiterentwickelt und schreiben da sehr viel darüber in ihrem Blog. Es gibt auch einen schönen Artikel dazu, es gibt ein paar Vorträge dazu. Die benutzen in der Regel einen anderen Begriff, die sprechen von Vertikalen und wir haben den Begriff auch überlegt zu verwenden, aber haben ihn nicht benutzt, weil er auf englisch ein bisschen was anderes bedeutet, aber es ist ein sehr, sehr kompatibler, ähnlicher Weg, den die da gegangen sind, mit kleinen Variationen, aber grundsätzlich sehr ähnlich.

Eberhard Wolff: Ja, da ist vielleicht noch wichtig an der Stelle: Ich finde dieses Thema besonders genau interessant, weil Otto, ich glaube, die globale Nummer 3 im E-Commerce ist. Das ist halt ein sehr, sehr großer Laden, der da ja auch in einem starken Konkurrenzverhältnis steht, für den also genau dieses Thema sehr zentral ist. Und die andere Sache, die da vielleicht noch wichtig ist, es gibt tatsächlich einen Blogbeitrag, wo Otto selbst sagt, ja, wir nennen es Vertikalen oder verticals, aber in Wirklichkeit ist das dasselbe wie Self-Contained Systems. Wo es so ist, dass sie selbst sagen, das ist SCS und wir haben dem eigentlich nur einen anderen Namen gegeben.

Stefan Tilkov: In aller Fairness muss man sagen, das war zuerst da, also der Begriff Vertikale war noch vor dem SCS da. Galeria Kaufhof ist ein schönes Beispiel…

Eberhard Wolff: Das illustriert das, was du grad eben gesagt hast, unser Ziel ist es halt, dafür einen vernünftigen Begriff zu haben und eine vernünftige Definition, und das ist genau ein Beispiel für ein Projekt, das das durchexerziert hat, ohne jetzt unter massivem innoQ Einfluss zu stehen.

Stefan Tilkov: Genau. Ein paar andere Beispiele, Galeria Kaufhof schreibt ebenfalls auch im eigenen Blog darüber, haben uns auch Links geschickt, da haben wir auch ein paar Dinge kontribuiert zu dem Ganzen. Wen haben wir noch in der Liste?

Eberhard Wolff: Kuehne + Nagel hatte sich auch dazu bekannt. Vielleicht sollte man dazu noch sagen, es wirkt tatsächlich wie ein europäisches Ding, es gibt, glaube ich, wenig Beispiele aus den USA.

Stefan Tilkov: Das stimmt, glaube ich, gar nicht. Ich habe kürzlich Gespräche geführt mit unseren Freunden von ThoughtWorks, also man kann ja auch mal ein paar Namen, wir können ja mal unsere Mitbewerber nennen, das ist ja nichts Schlimmes. Also die Codecentric-Leute haben einen Blog-Post dazu geschrieben, die ThoughtWorks-Kollegen, die uns auch häufiger begegnen – da habe ich mich neulich länger unterhalten – haben, nachdem ich das irgendwo präsentiert habe, gesagt, „Das ist genau der Ansatz, den wir im Projekt XY auch machen“. Was, glaube ich, überhaupt nichts Schlimmes ist. Das bedeutet nicht, dass irgendwer von irgendwem etwas abguckt, ganz im Gegenteil.

Das ist oft bei solchen Dingen, dass die aufpoppen an vielen Stellen und man feststellt, dass Leute unabhängig zu ähnlichen Ergebnissen kommen, das ist ja genau die Beobachtung, die ich auch habe. Also, vielleicht kriegen wir noch ein paar mehr Dinge mit rein, die das eben auch international illustrieren. Ich glaube auch, dass sehr, sehr viel bei Amazon sehr, sehr ähnlich nach diesem Prinzip funktioniert, auch wenn die den Begriff natürlich nicht benutzen und das bestimmt auch schon viel, viel länger machen, als wir darüber reden, ist zumindest mal dieses durchgängige Frontend bis Backend, auch dieses Ownership, dieses Team-Prinzip, “2 Pizza Teams”, Zwei-Pizza-Teams, kennen wahrscheinlich viele. Das ist etwas, was die durchziehen, die Komposition der Seite im Frontend funktioniert ein bisschen anders, aber auch nicht ganz, wenn man zum Beispiel bei Amazon, auf der Amazon-Shopping-Webseite auf den Checkout geht, dann spürt man deutlich, dass sich die User-Experience zwar noch ähnelt, aber ein bisschen anders aussieht, das ist, glaube ich, ein schönes Beispiel für einen Übergang. Man ist in einem anderen System gelandet, eben im Checkout-System, das immer nur den Weg nach vorne und nie zurück erlaubt und so ein bisschen genau auf diesen Checkout optimiert ist, das ist ein sehr typisches Beispiel für etwas, das man an vielen Stellen sieht.

Eberhard Wolff: Was übrigens, by the way, auch eine der Fragen ist, die ich mir sozusagen stelle. Was bedeutet es, wenn wir von einem gemeinsamen Look & Feel sprechen, aber in Wirklichkeit unterschiedliche Fachlichkeiten haben, die eben auch tatsächlich in der UI unterschiedlich repräsentiert sein werden?

Stefan Tilkov: Das ist eine sehr gute Frage. Ich glaube, die meisten Endanwender spüren drastische Änderungen. Also, wenn ich zum Beispiel vom Look & Feel der Altlösung aus dem Jahr 1999 auf einmal springe in etwas, das ich im Jahr 2017 entwickelt habe, das merke ich, das fühle ich. Ansonsten achte ich aber im Wesentlichen auf Farben, Fonts, Typographie, auf die Art und Weise, wie mit White Space umgegangen wird, auf so allgemeine, auf Brand Identity, auf Corporate Identity sozusagen, viel mehr, als darauf, dass alles gleich aussieht, das ist gar nicht das Ziel bei dem Ganzen.

Ich glaube, im Wesentlichen sind wir durch, wir freuen uns natürlich über Kommentare auf der Webseite zum Podcast und auch bei scs-architecture.org. Und ich denke, wir haben die wesentlichen Sachen erschlagen. Hat Spaß gemacht, Eberhard, danke dir für das Gespräch.

Eberhard Wolff: Mir auch. Und vielen Dank fürs Zuhören und vielleicht mal irgendwo auf einem Diskussionsforum oder so.

Stefan Tilkov: Ja, genau. Tschüss!