Interview mit Stephan Kaps

Software-Architektur im Wandel: „Es reicht nicht mehr, die Package-Struktur vorzugeben und Module zu extrahieren“

Hartmut Schlosser

Stephan Kaps

Software-Architektur ist technisch, aber auch kulturell im Wandel: Wer heute als Architekt arbeitet, sieht sich mit ganz anderen Problemen konfrontiert, als dies in den Zeiten vor DevOps, Microservices, Cloud Computing und Serverless der Fall war. Wir haben mit Stephan Kaps, Leiter des Bereichs Softwareentwicklung im Bundesversicherungsamt, im Zuge der JAX 2019 über diese Entwicklungen gesprochen.

JAXenter: Die Rolle des Software-Architekten wird immer mal wieder in Frage gestellt – „Sind sie in Zeiten der DevOps-Bewegung noch nötig? Muss nicht jeder Entwickler ein Architekt sein?“ Und so weiter… Beginnen wir daher 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?

Stephan Kaps: Grundsätzlich ist auch mein Wunsch, dass das Entwickler-Team sich gemeinsam um die Architektur kümmert. Am Ende sind es meiner Erfahrung nach häufig jedoch nur Einzelne, die sich dafür interessieren und Verantwortung übernehmen. Ich denke, dass es in Zeiten flexibler, verteilter Architekturen ein sehr umfangreicher, komplexer Themenbereich ist. Es reicht nicht mehr, die Package-Struktur vorzugeben, Schichten einzuziehen oder Module zu extrahieren. Es erfordert die häufig erwähnte technische Exzellenz, um die richtigen Entscheidungen bzgl. Werkzeugen, Infrastrukturen oder Pattern für Integration oder Kommunikation treffen zu können. Das ist von den meisten Junior-Developern aber auch von manchen Erfahrenen nicht zu leisten, oder eben auch gar nicht gewollt.

Sicherlich hat der Bedarf nach Up-Front-Design stark abgenommen, da sich auch die Architektur inkrementell weiterentwickelt. Meine Hauptaufgabe als Teamlead und Architekt sehe ich daher darin, das langfristige Ziel (den Nordstern) aufzuzeigen, wo wollen wir technisch und architektonisch hin. Das mündet dann eventuell in so etwas wie Makro-Architektur. Und das, was wir aktuell als Mikro-Architektur bezeichnen, ist meist von Entwickler-Teams sehr gut zu gestalten, häufig besser als von einem dedizierten Architekten.

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?

BaaS hat sicherlich seine Daseins- berechtigung, ist aber für mich auch eher eine spezielle Form von Serverless.

Stephan Kaps: Das denke ich nicht. BaaS hat sicherlich seine Daseinsberechtigung, ist aber für mich auch eher eine spezielle Form von Serverless. Bei größeren Firmen mit einer drei- oder vierstelligen Zahl von (Business-)Anwendungen ist man meist eher noch dabei, die Infrastrukturen zu automatisieren und „Cloud Ready“ zu machen. Dort spielt das Backend noch eine große Rolle und vor allem auch Themen wie Skalierbarkeit, Resilienz usw.

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?

Stephan Kaps: Da habe ich noch keine klare Meinung zu, ich stecke noch im Container- / Cloud-native-Steinzeitalter fest 😉

Aber es ist natürlich offensichtlich, dass es wirtschaftlich sinnvoll ist, bestimmte Funktionen, wie einen Benachrichtigungsdienst à la AWS SNS nur dann zu starten (und vor allem beliebig zu skalieren), sobald er angesprochen wird und somit auch nur für die Dauer oder Häufigkeit der Nutzung zu bezahlen.

API Confernce 2019
 Maik Schöneich

gRPC – Ein neuer heiliger Gral?

mit Maik Schöneich

Oliver Drotbohm

REST Beyond the Obvious – API Design for Ever Evolving Systems

mit Oliver Drotbohm (Pivotal Software, Inc.)

 

Software Architecture Summit 2019
Stephan Pirnbaum

Lasst uns einen Monolithen (z)erlegen

mit Stephan Pirnbaum (buschmais GbR)

Scott Davis

Making Your Mobile Web App Talk

mit Scott Davis (ThoughtWorks)

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?

Stephan Kaps: In gewisser Weise schon. Meist werden mehrere Anwendungen auf einem App-Server betrieben, was gravierende Probleme mit sich bringt. Auf der anderen Seite ist es auch verständlich, einem eher klassisch aufgestellten IT-Betrieb nicht zumuten zu können, 100 oder mehr virtuelle Maschinen zu betreiben, um auf jeder jeweils eine Anwendung in einem App-Server laufen zu haben.

Wir betreiben selbst auch noch viele unserer Webanwendungen auf Wildfly-App-Servern. Aber durch die Einführung von Galleon soll sich der Wildfly zum Cloud-native EE-Application-Server entwickeln, wodurch das Betreiben im Container bzw. in Kubernetes oder OpenShift deutlich verbessert werden würde (siehe https://wildfly.org/news/2019/03/01/Galleon_Openshift/).

Dass es alternativ quasi Standard geworden ist, einen leichtgewichtigen Tomcat- oder Jetty-Server zu embedden (wie bei Spring Boot), brauche ich vermutlich an dieser Stelle nicht ausführlicher betrachten.

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?

Serverless ist allein schon aus wirtschaftlichen Aspekten sinnvoll.

Stephan Kaps: Ich bin jetzt kein Experte in Blockchains, aber bisher sehe ich lediglich den Proof of Work als etabliert, z.B. mit Kryptowährungen. Für öffentliche Kollaborationen, bei denen Verträge (Contracts) abgeschlossen werden müssen, unter Vermeidung einer zentralen Instanz, weil man dieser nicht vertrauen würde, ergibt das auf jeden Fall Sinn. Insgesamt sind diese Verfahren aber sehr langsam und ressourcenintensiv.

Für Proof of Authority sehe ich viele Anwendungsfälle, da hier anhand von Reputation festgelegt wird, wer mitspielen darf, also z.B. per Registrierungsverfahren. Das wiederum ergibt aber eher innerhalb einer Branche, eines Konsortiums oder ähnlichem Sinn, also z.B. unter Banken, wenn man den Teilnehmern dennoch nicht zu 100% vertraut, die Infrastruktur aber auch nicht zentral betreiben möchte.

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

Stephan Kaps: Es ist schwer, hier ein Thema herauszuheben. Alles entwickelt sich stetig weiter, sodass ständig neue Themen relevant werden. Container und Microservices sind jetzt etabliert, Themen der Infrastruktur wie Observability, also zentrales Logging, Monitoring, Metriken usw. eingeführt. Aktuell beschäftige ich mich z.B. mit Service Mesh und Cloud-native Proxy Services wie Traefik, Envoy oder Consul Segmentation. Die Anzahl der Container steigt kontinuierlich, sodass ein dynamisches Discovery und Routing notwendig wird, sowie eine zentrale Stelle für TLS und weitere Security-Themen.

Security ist generell ein Thema, dem ich mich intensiv widme. Seit einiger Zeit experimentieren wir mit Hashicorp Vault, um Secrets, Zertifikate und Schlüsselmaterial sicher zu verwalten.

JAXenter: Du hast auf der JAX eine Session namens Architekturen für Digitalisierung – mit Workflowautomation und Microservices gehalten. Dabei hast du ein automatisiertes Antragsverfahren mit einer Anbindung an Drittsysteme und einer Prozesssteuerung durch eine Workflow-Engine vorgestellt. Wie bringt man Workflowautomation und Microservices zusammen?

Kennt eure Domäne(n), akzeptiert eine sich ändernde Architektur, macht Experimente, lernt und adaptiert.

Stephan Kaps: Dafür gibt es unterschiedliche Ansätze. Wenn die Fachlichkeit über mehrere Microservices verteilt ist und es einen nicht trivialen Geschäftsprozess abzubilden gilt, dann entsteht ein Bedarf an Orchestrierung (im Gegensatz zu Choreographie). Dabei geht es häufig eher um synchrone Kommunikation. Hier können leichtgewichtige Workflow-Engines helfen, den Gesamtüberblick zu behalten. Zudem bieten sie meist Steuerungs- und Monitoring-Funktionen. Nachteilig könnte bewertet werden, dass man sich im Workflow um technische Aspekte wie Exception-Handling, Fallbacks, Kompensation oder Retries kümmern muss, es also tatsächlich modelliert. Zusätzlich ist eine asynchrone Verarbeitung (ähnlich Event-driven) möglich, z.B. für lang laufende Tasks.

JAXenter: Was ist die Kernbotschaft deiner JAX Session, die du jedem mit auf den Weg geben möchtest?

Stephan Kaps: Kennt eure Domäne(n), akzeptiert eine sich ändernde Architektur, macht Experimente, lernt und adaptiert. Wenn dabei eine für euch sinnvolle und tragfähige Lösung herauskommt, die pragmatisch ist, aber dadurch vielleicht nicht allen theoretischen Eigenschaften einer bestimmten Architektur-Form entspricht, dann ist das völlig ok!

Das Wichtigste ist, bewusste Entscheidungen zu treffen, die Dinge abzuwägen und die Vor- und Nachteile im eigenen Kontext zu überprüfen.

Stephan Kaps leitet die Softwareentwicklung im Bundesversicherungsamt und ist Gründer der Java User Group Bonn. Als Softwarearchitekt und Entwickler hat er seit 2002 mit Java zu tun. Weitere Schwerpunkte liegen in der Konzipierung und Optimierung von Softwareentwicklungsprozessen, DevOps und Open-Source-Werkzeugen. Darüber hinaus ist er als Speaker und Autor aktiv.
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

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: