Interview mit Eberhard Wolff

Wozu brauchen wir noch Software-Architekten?

Hartmut Schlosser

Eberhard Wolff

Software-Architektur verändert sich – genauso wie die Rolle des Software-Architekten. Wir haben uns mit Eberhard Wolff, Architekt bei INNOQ und Sprecher auf dem Microservices-Summit, über aktuelle Architektur-Trends wie Microservices, Serverless und die Blockchain unterhalten. Wie relevant sind sie wirklich, und wie können Architekten davon profitieren?

Wozu brauchen wir Software-Architekten?

JAXenter: 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?

Der Titel Software-Architekt ist oft nur eine Stufe auf der Karriere-Leiter.

Eberhard Wolff: Auch 2019 gibt es den Titel „Software-Architekt“. Oft ist das aber „nur“ eine Stufe auf der Karriere-Leiter. Aber auch Personen, die tatsächlich Software-Architektur-Entscheidungen treffen, gibt es immer noch. Diese Aufgaben verschwinden ja nicht einfach.

Meiner Meinung nach ist das Problem, dass Software-Architekten in der Vergangenheit oft im Elfenbeinturm gelebt haben und sich nicht mit den realen Problemen beschäftigt haben. Das hat den Ruf der Software-Architekten beschädigt. Dennoch muss es eine Software-Architektur geben.

Eine moderne Auffassung von der Rolle von Software-Architekten, die moderieren und unterstützen statt zu diktieren, habe ich bei meinem Talk auf der letzten W-JAX dargestellt:

Serverless-Architekturen

JAXenter: 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?

Eberhard Wolff: Eine Software-Architektur ist erfolgreich, wenn sie eine technische Lösung für das Problem darstellt. Das ist nur möglich, wenn man Backend und Frontend betrachtet. Aspekte wie Benutzbarkeit hängen mehr vom Frontend als vom Backend ab. Benutzerfreundlichkeit beeinflusst die Akzeptanz bei Benutzern und ist damit entscheidend den Erfolg des Projekts. Wer sich auf das Backend konzentriert, vernachlässigt also oft wesentliche Fragestellungen.

Man darf natürlich auch das Backend nicht vernachlässigen, denn es beeinflusst ebenso viele Aspekte der Software. Architektur muss immer die gesamte Software betrachten und sicherstellen, dass sie das Problem tatsächlich löst.

JAXenter: 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?

Eberhard Wolff: Zahlreiche Kunden sind gerade dabei, viel in Kubernetes zu investieren und setzen Kubernetes in Projekten erfolgreich ein. Bei Serverless sehe ich das nicht so stark. Ich sehe zwischen den beiden aber keinen fundamentalen Widerspruch: Projekte wie Knative stellen eine Serverless-Plattform auf Kubernetes zur Verfügung. Amazons Fargate erlaubt es, Container zu betreiben, ohne sich um Server zu kümmern.

Tatsächlich neu sind Architekturen, die Cloud-Dienste beispielsweise für Datenbanken, Machine Learning oder das Verarbeiten von Events mit Hilfe von Serverless-Funktionen kombinieren. Solche Architekturen nutzen viel stärker die Cloud als Sammlung von Komponenten und implementieren eigentlich nur noch Glue Code selber.

Und mit Kubernetes entsteht eine Basis-Infrastruktur, auf der Dienste wie eben Knative aber auch beispielsweise schlüsselfertige Datenbanken einschließlich Skalierung, Snapshots oder Backups aufsetzen können. Solche produktionsreifen Installationen waren vorher sehr kompliziert umzusetzen. Das wird nun zu einer einfachen Installation von entsprechenden Paketen auf Kubernetes.

DDD Summit 2019
Nicole Rauch

Event Storming für Domain-driven Design

mit Nicole Rauch (Softwareentwicklung und Entwicklungscoaching)

Was kommt nach dem Application Server?

JAXenter: 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?

Ja, Application Server sind tot. Schon lange.

Eberhard Wolff: Ja, Application Server sind tot. Schon lange. Ich habe das schon 2014 argumentiert. Mittlerweile sind sie kaum noch im Einsatz und praktisch kein neues Projekt setzt auf sie auf.

JAXenter: 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?

Eberhard Wolff: Blockchains ermöglichen es, in einem verteilten System eine gemeinsame Datenstruktur zu erstellen, die authentisch ist, auch wenn sich nicht alle Parteien vertrauen. Das kann beispielsweise genutzt werden, um Transaktionen einer Kryptowährung zu speichern. Es gibt darüber hinaus weitere Anwendungsfälle. Schließlich kann dank Blockchain eine zentrale Datenhaltung auch dann gegen eine dezentrale ausgetauscht werden, wenn sich nicht alle Parteien vertrauen. Aber von einer „Revolution des Internets“ zu sprechen, scheint übertrieben.

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

Eberhard Wolff: Die fachliche Aufteilung der Systeme zum Beispiel mit Domain-driven Design ist sehr wichtig. Architektur dient dazu, die Funktionalität des Systems möglichst gut abzubilden. Sehr häufig sehe ich aber Diagramme, die lediglich die technische Aufteilung des Systems zeigen.

Architekten müssen außerdem die nicht-funktionalen Anforderungen bzw. Qualitätsziele genau kennen. Oft liegt der Fokus auf Skalierbarkeit oder Wartbarkeit, aber tatsächlich ist beispielsweise Benutzerfreundlichkeit wichtiger für den Erfolg. Selbst wenn Architekten die grundsätzlich richtigen Anforderungen erkannt haben, kann es in Details zu Missverständnissen kommen: Ist die Verfügbarkeit nachts genauso wichtig wie die tagsüber? 99,9% Verfügbarkeit sind fast 9 Stunden Ausfall im Jahr. Ist es OK, wenn das System 9 Stunden am Stück ausfällt? Und wenn diese Punkte klar sind, muss es in der Architektur auch technologische Antworten auf diese Herausforderungen geben. Zu häufig ist das aber leider nicht der Fall.

Wie Microservices umsetzen?

JAXenter: Du hältst auf dem Microservices Summit einen Workshop  Session namens Wie Microservices umsetzen? Dabei zeigst du, dass Microservices nicht unbedingt kleine REST-Services sein müssen. Welche Alternativen gibt es? Kannst du einmal ein Beispiel beschreiben, in dem etwas anderes als REST sinnvoll ist?

Asynchrone Kommunikation beispielsweise mit einem Messaging-System wie Kafka vereinfacht die zuverlässige Zustellung von Nachrichten.

Eberhard Wolff: Asynchrone Kommunikation beispielsweise mit einem Messaging-System wie Kafka vereinfacht die zuverlässige Zustellung von Nachrichten. Außerdem kann das System besser mit dem Ausfall von Systemen zurecht kommen: Nachrichten werden zwar später übertragen, aber asynchrone Systeme müssen eh mit Verzögerungen umgehen können.

UI-Integration führt zu einer guten Entkopplung und macht es möglich, die gesamte Fachlichkeit einschließlich der UI in einem Microservice zu implementieren und so eine bessere Aufteilung des Systems zu erreichen. Änderungen betreffen selbst dann nur einen Microservice, wenn sie sowohl Logik als auch UI beeinflussen. Sie können so auch mit dem Deployment eines einzigen Microservice in Produktion gebracht werden.

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

Eberhard Wolff: Die Technologie für die Integration und Kommunikation der Microservices ist eine sehr wichtige Entscheidung bei der Implementierung eines Microservice-Systems. Sie beeinflusst das gesamte System im Gegensatz zur Entscheidung für eine Programmiersprache oder ein Framework. Solche Entscheidungen können nämlich in jedem Microservice revidiert werden. Der Workshop zeigt konkrete Alternativen mit ihren Vor- und Nachteilen.

JAXenter: Vielen Dank für dieses Interview!

Eberhard Wolff arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater – oft an der Schnittstelle zwischen Business und Technologie. Er ist Fellow bei der INNOQ. Als Autor hat er über hundert Artikel und Bücher geschrieben, u. a. ein deutschsprachiges Buch zu Continuous Delivery. Als Sprecher hat er auf zahlreichen internationalen Konferenzen vorgetragen. Sein technologischer Schwerpunkt liegt auf modernen Architekturansätzen – Cloud, Continuous Delivery, DevOps, Microservices oder NoSQL spielen oft eine Rolle.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Wozu brauchen wir noch Software-Architekten?"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
G.M.
Gast

„Mittlerweile sind sie kaum noch im Einsatz“
Da sieht man irgendwie die Realitätsferne, von wegen Elfenbein und so….
Abgesehen davon dass sich JavaEE und Container absolut nicht wiedersprechen. Egal ob Microservice, SCS oder sonst irgendein erfundenes Kunstwort.