Interview mit Uwe Friedrichsen

Architekturtrend Microservices: „Die Effekte der Verteilung werden sehr oft stark unterschätzt“
Keine Kommentare

Software-Architektur im Jahr 2019 – welche Bedeutung hat sie, welchen Entwicklungen ist sie ausgesetzt, welche Herausforderungen muss sie bewältigen? Antworten gibt Uwe Friedrichsen, Software-Architekt bei codecentric und Sprecher auf dem Microservices Summit 2019, im Interview.

Plädoyer für Software-Architekten

Entwickler: Die Rolle des Software-Architekten wird immer wieder mal in Frage gestellt. „Sind sie in Zeiten der DevOps-Bewegung noch nötig? Muss nicht jeder Entwickler ein Architekt sein?“ Und so weiter…. Deshalb beginnen wir mal mit einem Plädoyer für den Berufsstand: Weshalb sind dezidierte Software-Architekten deiner Meinung nach auch im Jahr 2019 noch sinnvoll? Wo siehst du ganz persönlich deine Hauptaufgabe als Software-Architekt?

Die Rollen Entwickler und Architekt verlangen sehr unterschiedliche Skillsets.

Uwe Friedrichsen: Die Aussicht, dass jeder Entwickler die Rolle eines Architekten übernehmen kann, klingt verlockend. Aus meiner Erfahrung ist das aber nicht der Fall. Die Rollen „Entwickler“ und „Architekt“ verlangen sehr unterschiedliche Skillsets, und aus meiner Erfahrung verfügen nur relativ wenige Entwickler über das Skillset und die Erfahrungen, die man jenseits der reinen Entwicklung für Architekturarbeit benötigt. Das ist aber auch vollständig in Ordnung, denn umgekehrt sieht das häufig ähnlich aus.

Leider wird die Debatte um das Thema immer noch von vielen nicht zielführenden Vorstellungen beherrscht. Das geht von falsch verstandener Agilität über Technologie-Bingo bis hin zu den vollständig sinnlosen Karrieremodellen vieler Unternehmen, in denen der Architekt „über“ dem Entwickler steht. Wir brauchen beide Skills in Projekten, keiner ist „besser“ oder „wichtiger“ als der andere, und nur sehr wenige Personen vereinigen aus meiner Erfahrung beide Skillsets. Entsprechend bin ich der Überzeugung, dass wir auch im Jahr 2019 noch Architekten brauchen – und diese werden aus den zuvor skizzierten Gründen häufig weiterhin dezidierte Personen sein.

Zu deiner zweiten Teilfrage: Aus meiner Sicht besteht Architekturarbeit im Kern aus den folgenden Aktivitäten: Das Problem und den Kontext (über die verschiedenen Stakeholder-Gruppen hinweg) ganzheitlich verstehen, Lösungsoptionen identifizieren, die Vor- und Nachteile („Tradeoffs“) der einzelnen Optionen im gegebenen Kontext herausarbeiten (denn keine Lösung hat nur Vorteile) und letztlich den beteiligten Personengruppen helfen, die bestmöglichen Entscheidungen zu treffen, indem man sie dabei unterstützt, die Situation sowie die Optionen mit ihren Vor- und Nachteilen möglichst ganzheitlich zu verstehen. Obwohl der Satz jetzt recht lang war, ist das eine extrem kompakte Beschreibung der Aufgaben, die man aus meiner Sicht als Architekt(in) wahrnehmen sollte. Entsprechend beschreibt das auch meine Hauptaufgabe als Software-Architekt.

In der konkreten Ausgestaltung kommt da natürlich noch ganz viel dazu, z.B. wann man welche Aktivitäten in Abhängigkeit vom gegebenen Kontext in welchem Umfang wahrnimmt oder wie man mit den anderen Stakeholder-Gruppen, insbesondere auch dem Entwicklerteam zusammenarbeitet. Aber das würde den Rahmen hier bei weitem sprengen. Wichtig ist dabei aus meiner Sicht nur, dass es keine einzelne wichtigste Hauptaufgabe gibt. Wenn man überhaupt etwas als besonders wichtig darstellen möchte, dann ist es die Ganzheitlichkeit der Betrachtung und des Handelns.

Event-Tipp: Vom 17.-19. Juni findet das dreifache Trainings-Event Microservices Summit, API Summit und DDD Summit 2019 statt. Vergünstigte Early-Bird-Tickets gibt es noch bis kommenden Donnerstag, 16. Mai.

Architekturtrend „Serverless“

Entwickler: Software-Architektur beschäftigt sich traditionell stark mit Backend-Problematiken: Provisionierung, Skalierbarkeit, Resilienz, etc. Im Umfeld der sogenannten Serverless-Bewegung spricht man nun aber immer mehr von Managed Backends und Backend as a Service. Wird das Backend als solches für Architekten also immer uninteressanter?

Serverless vergrößert die Menge möglicher Lösungsoptionen.

Uwe Friedrichsen: Aus meiner Sicht nein. Serverless vergrößert ja die Menge möglicher Lösungsoptionen. Architekturarbeit bedeutet ja nicht, alles bis ins letzte Detail zu designen und jedes Rad wieder und wieder neu zu erfinden, sondern für eine gegebene Aufgabenstellung im Rahmen der gesetzten Rahmenbedingungen eine möglichst sinnvolle Lösung zu finden.

An der Stelle stellt Serverless mit Fokus auf Managed Services für mich eine Bereicherung dar. Wir haben einen ganz neuen Typus an Kauflösungen an die Hand bekommen, der ganz andere Eigenschaften als traditionelle Standard-Software hat, nämlich eher der Unix-Philosophie „Mache nur eine Sache und die gut“ folgt sowie „Integration first“ und „Pay per use“ ist. Das gibt mir in der Architekturarbeit ganz neue, spannende Optionen, die ich bislang in der Form nicht hatte.

Außerdem hilft uns Serverless noch an einer anderen Stelle. Schauen wir einmal auf die derzeit immer weiter explodierende technische Komplexität heutiger Individualentwicklungsprojekte: Microservices, Spring Boot, Docker, Kubernetes, Istio, ELK, SPA, React, React native, Prometheus, Jenkins, Webpack, Kafka, Cassandra, PostgreSQL, Swagger, GraphQL, und, und, und. Das ist ein heute typischer technischer Minimal-Stack. Und obgleich „minimal“ an der Stelle schon nach Hohn und Spott klingt, ist es damit ja noch nicht getan, denn zu dem Stack gesellen sich noch Dutzende weiterer Tools und Frameworks. Das war ja nur die offensichtliche Spitze des Technologieeisbergs.

Wenn wir dagegen die Notwendigkeit stellen, immer schneller auf sich verändernde Marktbedingungen zu reagieren, dann wird klar, dass sich das nicht durchhalten lässt. Wir müssen die Fertigungstiefe reduzieren, wenn wir ohne Qualitätsverluste schnell agieren können wollen. Genau hier hilft Serverless: Indem wir die nicht differenzierenden Teile der Anwendungslogik als Managed Services dazukaufen, können wir unsere Kapazitäten auf die differenzierenden Teile fokussieren und da einen richtig guten Job machen.

Also nein, ich finde nicht, dass Architekturarbeit im Backend weniger interessant wird. Ich finde sie sogar spannender durch die neuen Optionen, die Serverless bietet.

Entwickler: Simon Wardley hat die wilde These aufgestellt, dass Container und Kubernetes nur eine Randerscheinung in der Geschichte der Softwareentwicklung darstellen und bald schon obsolet werden könnten, da Serverless – wie einst Software – die Welt verschlingt. Wie stehst du dazu?

Container und Container-Scheduler wie Kubernetes werden weiter existieren, nur werden sie unsichtbar werden.

Uwe Friedrichsen: Die These finde ich persönlich überhaupt nicht wild. Tatsächlich sehe ich das ähnlich, wobei man etwas genauer hinschauen muss, wie Simon Wardley das aus meiner Sicht meint: Container und Container-Scheduler wie Kubernetes werden weiter existieren, nur werden sie „unsichtbar“ werden, sprich hinter höherwertigen Abstraktionen verschwinden.

AWS Fargate als Managed Container-Scheduler deutet den Weg an: In Zukunft werde ich mich nicht mehr mit den Komplexitäten von Docker und Kubernetes herumschlagen. Stattdessen werde ich meinen Anwendungscode schreiben, der als eigene Einheit, sprich Service bereitgestellt werden soll. An Metadaten gebe ich nur mit, auf welche fachlichen Events der Service reagieren soll. Die CI/CD-Pipeline sorgt dafür, dass am Ende ein fertiger (für uns unsichtbarer) Container in einem Repository bereitsteht, und der Scheduler kümmert sich darum, dass der Container immer dann verfügbar ist, wenn er gebraucht wird. Im Hintergrund mögen immer noch Docker, Kubernetes oder was auch immer werkeln, aber für unser Denkmodell ist das irrelevant, weil wir als Entwickler auf einer ganz anderen Abstraktionsebene mit der Infrastruktur interagieren werden.

Um noch eine alternative Entwicklung zu skizzieren: Es ist auch vorstellbar, dass sich Serverless Functions in Richtung vollständiger, tiefer Anwendungsentwicklung weiterentwickeln werden. Dafür sind sie derzeit eigentlich weder gedacht noch geeignet, aber das hat uns in der IT bekanntermaßen noch nie davon abgehalten, es trotzdem zu tun. In dem Fall würden, getrieben vom Bedarf, mächtigere Function-IDEs, bessere Strukturierungs- und Debug-Möglichkeiten, Laufzeitoptimizer, etc. für Functions entstehen.

Das würde sich dann ein wenig wie CICS für synchrone Verarbeitung und TSO/JCL für asynchrone Verarbeitung auf dem Host anfühlen. Klingt das jetzt sehr schräg? Ja, auf den ersten Blick vielleicht schon. Aber wir laufen derzeit gerade wieder durch eine weitere Technologie-Evolutionswelle in der IT – inklusive der typischen Effekte wie Technologieexplosion, Überforderung vieler betroffener Entwickler und mehr. Eine ähnliche Evolutionswelle gab es auf dem Host vor ca. 30 Jahren, und das Ergebnis findet man z.B. in CICS und TSO/JCL. Und was sich derzeit mit Step Functions und Co. andeutet, zeigt ganz stark in die gleiche Lösungsrichtung.

Persönlich bin ich mir noch nicht sicher, in welche Richtung sich das alles mit Serverless entwickeln wird. Allerdings teile ich die These, dass Container und deren Scheduler, wie wir sie heute kennen, in nicht ferner Zukunft von höherwertigen Abstraktionen abgelöst werden.

Microservices Summit 2019

Kubernetes Kickstarter

mit Jörg Müller (INNOQ)

In 7 Schritten zum Cloud-Native mit AWS

mit Matthias Rosenstock und Christian Schulz (OPEN KNOWLEDGE)

Microservices & Blockchain

Entwickler: Viele Jahre lang war der große, möglichst komplette Application Server das Ideal und die Basis vieler Software-Architekturen. Hat diese Metapher in Zeiten der Cloud und der Microservices ausgedient?

Uwe Friedrichsen: Aus meiner Sicht ein klares „Jein“. In einem echten Cloud-Native-Szenario hat der klassische Application Server natürlich keine Zukunft mehr. Aber Cloud Native ist am Ende auch nur ein Architekturstil unter vielen mit spezifischen Vor- und Nachteilen, und nicht jedes Unternehmen muss diesen Stil umsetzen. Es wird weiterhin Unternehmen bzw. Bereiche innerhalb von Unternehmen geben, die mit anderen Stilen besser fahren werden. Dazu gehört die Nutzung von Application Servern.

Rein inhaltlich wird es aus meiner Sicht daher immer noch einen Platz für umfassende Application Server geben. Der wird aber sehr viel kleiner sein als in der Vergangenheit.

Entwickler: Und dann die Blockchain – von der immer wieder zu hören ist, dass sie das gesamte Internet revolutionieren könnte. Siehst du das kommen? Oder bleibt die Blockchain eine mögliche Lösung für einen bestimmten Anwendungsfall?

Uwe Friedrichsen: Nun ja, eine differenzierte Antwort auf die Frage würde recht lang, und ich habe bereits einige lange Antworten gegeben. Also halte ich es hier einmal kurz: Die Revolution ist aus meiner Sicht ausgeblieben und wird auch nicht stattfinden. Blockchain und Smart Contracts werden ihre Nische finden, aber das Internet revolutionieren? Nein, das sehe ich nicht.

Auf dem Weg zu besserem Service-Design

Entwickler: Was ist momentan dein persönliches Steckenpferd: Welches Architekturthema liegt dir besonders am Herzen – und warum?

Uwe Friedrichsen: Im Bereich der Architektur gibt es zwei Themen: Das erste Thema ist, was Architekturarbeit überhaupt bedeutet und warum wir sie brauchen – eine Art Refokussierung. Ich beobachte sehr viele, häufig hitzige Debatten, die aus meiner Sicht leider regelmäßig am Ziel vorbeischießen, weil sie die eigentliche Kernfrage, nämlich das „Warum“, nicht stellen.

Da ich im Laufe meines Berufslebens immer wieder erlebt habe, wie viel Mehrwert Architekturarbeit stiften kann, wenn man sie sauber auf ihren eigentlichen Daseinszweck, auf das „Warum“, ausrichtet, habe ich damit begonnen, dieses Thema intensiver zu bearbeiten. So habe ich z.B. auf dem Software Architecture Summit einen Workshop über essentielle Architekturarbeit gehalten, und es werden noch diverse weitere Workshops unterschiedlichen Umfangs zu dem Thema folgen. Mein Ziel ist es, den Teilnehmern zu vermitteln, wie sie mit auf ihren eigentlichen Zweck ausgerichteter Architekturarbeit echten Mehrwert schaffen können.

Mein derzeitiges zweites Architekturthema ist fachliches Design in verteilten Systemen. Seit mehreren Jahren sind Microservices der populärste Architekturstil, und im Zusammenspiel mit Containern und Schedulern wie Kubernetes ergeben sich damit interessante Optionen. Allerdings schaffen wir mit Microservices auch eine stark verteilte Anwendungslandschaft, und die Effekte der Verteilung werden sehr oft stark unterschätzt.

Mit Microservices schaffen wir eine stark verteilte Anwendungs-Landschaft, und die Effekte der Verteilung werden sehr oft unterschätzt.

Die geschaffenen Anwendungslandschaften sollen ja üblicherweise zuverlässig verfügbar sein, kurze Antwortzeiten haben, im Fehlerfall ein robustes Verhalten zeigen, ohne Wartungsfenster auskommen, und so weiter. Dem steht das nicht-deterministische Verhalten verteilter Systeme und speziell entfernter Aufrufe im Weg. Mit jedem zusätzlichen entfernten Aufruf steigt die Wahrscheinlichkeit, dass wir die geforderten Eigenschaften der Anwendungslandschaft nicht einhalten werden.

Als Gegenmaßnahmen werden dann in der Regel entweder generische Maßnahmen wie z.B. der Einsatz eines Service Meshes (wie Istio oder Linkerd) oder technische Resilienzmuster auf Anwendungsebene (etwa Circuit Breaker oder Backpressure) genannt. Das ist aber nur die halbe Wahrheit. Auch wenn die genannten Maßnahmen grundsätzlich sinnvoll sind, können sie ihr Potential nur ausspielen, wenn der fachliche Schnitt zwischen den verschiedenen Services stimmt.

Ein simples Beispiel, das man fast täglich in der Praxis antrifft: Service A erhält eine externe Anfrage. Um diese Anfrage beantworten zu können, benötigt er auf fachlicher Ebene Informationen von Service B. Sollte Service B jetzt nicht verfügbar sein, kann Service A seine Anfrage nicht beantworten, sprich er ist ebenfalls nicht verfügbar. Und sollte Service B langsam antworten, antwortet Service A ebenfalls langsam, und so weiter. Auf technischer Ebene kann ich jetzt so viele Circuit Breaker (mit oder ohne Service Mesh) zwischen Service A und Service B einziehen wie ich will – alles, was diese mir im Fehlerfall sagen, ist: Service A ist jetzt auch kaputt!

Der Grund dafür liegt im fachlichen Design. Die Fachlichkeit ist so zwischen den Services aufgeteilt worden, dass ein Problem in Service B sich immer in Service A fortpflanzt, egal was wir auf technischer Ebene an Gegenmaßnahmen ergreifen. Deshalb hat gutes fachliches Design gerade in verteilten Systemen eine zentrale Bedeutung. Im Laufe der Zeit habe ich aber gelernt, dass die meisten verbreiteten Design-Methoden nicht geeignet sind, um verteilte Systeme fachlich zu strukturieren, weil sie die nicht-deterministische Kommunikation zwischen Prozessgrenzen nicht beachten.

Entsprechend bin ich auf die Suche gegangen und habe geschaut, wie man fachliches Design für verteilte Systeme sinnvoll gestalten kann. Interessanterweise bin ich dabei auf ganz alte Design-Praktiken aus den frühen 70er Jahren gestoßen, die ich allerdings ein wenig auf den veränderten Kontext anpassen musste – in den frühen 70er Jahren hatte man es ja noch nicht mit verteilten Systemen zu tun.

Über diese Herausforderungen beim Design verteilter Systemlandschaften sowie die Ansätze, die ich dazu gefunden habe, erzähle ich derzeit viel. Ich bilde mir nicht ein, dass ich die perfekte Lösung kenne. Aber ich hoffe, dass ich die Diskussion, wie man das Thema angehen sollte, damit ein wenig nach vorne bringe. Das Thema ist in der heute immer mehr verteilten Anwendungswelt wichtiger denn je – und aus meiner Sicht bei weitem nicht zufriedenstellend gelöst.

Entwickler: Du hältst auf dem Microservices Summit einen Workshop namens „Auf dem Weg zu besserem Service-Design – bodenständig und (mal) ohne DDD“. Dabei zeigst du, wie man ein gutes fachliches Design auch ohne DDD erreichen kann. Warum ist DDD nicht die neue Patentlösung für Microservices?

Uwe Friedrichsen: In dem Workshop geht es genau um das zweite Thema aus der letzten Frage, nämlich fachliches Design für verteilte Systeme wie z.B. Service-Landschaften.

Das „mal ohne DDD“ ist ein wenig ironisch gemeint, weil aus meiner Wahrnehmung Domain-Driven Design (DDD) derzeit in der Tat als Patentlösung für Service-Design propagiert wird. Das klingt dann häufig wie „Mach ein wenig Event Storming, wirf die Ergebnisse auf DDD und – schwupps – erhältst du auf automagische Weise ein super Service-Design – natürlich garantiert und ohne Nebenwirkungen“.

So einfach ist das leider nicht. Zunächst einmal gibt es ganz allgemein keine Patentrezepte. Wenn überhaupt, gibt es die für triviale Problemstellungen, und Design ist alles andere als trivial. Außerdem ist DDD selber alles andere als einfach zu verstehen und zu meistern. Ich habe schon eine Menge Designs gesehen, die für sich in Anspruch genommen haben, „Domain-Driven“ zu sein, es dann aber doch nicht waren. Letztlich ist die erste Hälfte des Buchs von Eric Evans, das immer noch gerne als Referenz für DDD herangezogen wird, sehr stark von traditionellem OO-Design geprägt – was nicht verwunderlich ist, weil es Anfang 2000 entstanden ist, also in der Blütezeit der Objektorientierung.

Leider ist traditionelles OO-Design für das Design verteilter Anwendungen nicht geeignet, weil es – wie die meisten anderen Design-Methoden auch – die Auswirkungen nicht-deterministischer Kommunikation zwischen Prozessgrenzen nicht berücksichtigt. Nun hat bereits Eric Evans viele Hinweise gegeben, wie man es besser machen kann (allerdings primär in der zweiten Hälfte des Buchs, die erfahrungsgemäß bis heute häufig nicht gelesen wird), und auch die DDD-Community hat sich mittlerweile deutlich weiterbewegt. Wenn man aber nur „mal eben“ die Muster anschaut und das oberflächlich mit seinen gelernten Design-Praktiken verheiratet, dann landet man mit DDD schnell bei den gleichen Problemen, die ich zuvor beschrieben habe.

Um Missverständnisse zu vermeiden: Ich halte persönlich viel von den Ideen des Domain-Driven Design, und wenn man sich noch nie damit auseinandergesetzt hat, dann kann ich das jedem empfehlen. Und auch die DDD-Community hat die ursprünglichen Ideen mit Blick auf Service-Design weiterentwickelt. Nur ist DDD kein Patentrezept.

Letztlich geht es bei fachlichem Design für verteilte Systeme primär darum, gewisse Grundeigenschaften zwischen den Service-Grenzen zu etablieren, die sich positiv auf die Robustheit der Gesamtlösung auswirken (und damit auf Verfügbarkeit, Antwortzeitverhalten und alle die anderen Eigenschaften). DDD – richtig angewandt – kann dazu beitragen, diese Grundeigenschaften im Design zu verankern. Ich gehe in meinem Workshop aber auf die Grundeigenschaften ein und zeige eine andere, etwas allgemeinere Art, sich diesen im Design anzunähern. Wenn das dann jemand mit den Ideen von DDD auf sinnvolle Weise verheiraten möchte – gerne!

Entwickler: Was ist die Kernbotschaft des Workshops, die du jedem mit auf den Weg geben möchtest?

Uwe Friedrichsen: Es gibt mehrere Botschaften, die ich den Teilnehmern des Workshops mit auf den Weg geben möchte. Vielleicht kann man es so zusammenfassen: Fachliches Design für verteilte Landschaften ist wichtiger, als die meisten annehmen. Außerdem ist es auch wesentlich schwieriger, als die meisten glauben. Im zweiten Teil des Workshops weite ich das Thema dann noch auf gutes API-Design aus, das in der Regel auch sträflich unterschätzt und primär auf technische Belange reduziert wird. Ich sage aber nicht nur, dass alles viel schwieriger ist, als die meisten denken. Ich biete auch Lösungsideen an … 😉

Entwickler: Vielen Dank für dieses Interview!

Uwe Friedrichsen ist ein langjähriger Reisender in der IT-Welt. Als CTO und Fellow der codecentric AG ist er stets auf der Suche nach innovativen Ideen und Konzepten. Seine aktuellen Schwerpunktthemen sind (verteiltes) Systemdesign und die IT von (über)morgen. Er teilt und diskutiert seine Ideen regelmäßig auf Konferenzen, als Autor von Artikeln, Blogposts, Tweets und im direkten Gespräch.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -