Interview mit Stefan Tilkov

„Ich bin keinesfalls der Meinung, dass man immer Microservices einsetzen sollte“

Hartmut Schlosser

Stefan Tilkov

Microservices oder Software-Monolithen – über diese Architekturfrage wird momentan teils kontrovers diskutiert. Wir haben Stefan Tilkov, Principal Consultant bei der innoQ und Sprecher auf dem Software Architecture Summit, um einen Beitrag zur Debatte gebeten. Dabei kommt auch das Problem in den Blick, wie Legacy-Anwendungen an moderne Architektur-Ansätze herangeführt werden können.

JAXenter: Wir wollen uns ein wenig über aktuelle Themen der Software-Architektur unterhalten. Momentan kommt das Konzept des Domain-driven Design wieder in Mode – ein Konzept, das ja schon 2003 geprägt wurde. Weshalb wird heute wieder verstärkt über DDD gesprochen?

DDD liefert ein Rezept für erfolgreiche Modularisierung.

Stefan Tilkov: Unsere Systeme werden immer mächtiger und größer – und als Konsequenz leider auch immer komplexer. Die daraus entstehenden Probleme, die ganz besonders bei einer großen, monolithischen Code-Basis entstehen, plagen im Moment eine Vielzahl unterschiedlicher Organisationen und Unternehmen. Genau dabei helfen die strategischen Bestandteile von DDD, also Bounded Context & Co., weil sie große Modelle handhabbar machen und ein Rezept für erfolgreiche Modularisierung liefern.

JAXenter: Nun  ist die Umsetzung von DDD in die Praxis nicht einfach. Wo liegt deiner Erfahrung nach die Hauptschwierigkeit – und wie kann man diese überwinden?

Stefan Tilkov: Wie immer ist das eine Mischung aus unzureichender Ausbildung und dem verständlichen Festhalten am vermeintlich Notwendigen. So können sich viele Architekten und Entwickler nicht vorstellen, wie die unweigerlich bei DDD entstehende Redundanz eine gute Sache sein soll. Wenn man sich aber ein konkretes Modell vornimmt, stellt man man recht schnell fest, dass die ach so zentralen Strukturen nur aus Bequemlichkeit zentral sind und sich häufig sehr gut in weitgehend disjunkte Bestandteile zerlegen lassen. Hat man das ein paar Mal gemacht, fragt man sich, wieso man nicht von vornherein so vorgegangen ist. In Kurzform: Man muss es einfach einmal „durchziehen“, die Erfahrung hat oft große Konsequenzen.

W-JAX
Mike Wiesner

Data- und Event-driven Microservices mit Apache Kafka

mit Mike Wiesner (MHP – A Porsche Company)

Niko Köbler

Digitization Solutions – a new Breed of Software

with Uwe Friedrichsen (codecentric AG)

Software Architecture Summit 2017
Dr. Carola Lilienthal

The Core of Domain-Driven Design

mit Dr. Carola Lilienthal (Workplace Solutions)

Sascha Möllering

Reaktive Architekturen mit Microservices

mit Sascha Möllering (Amazon Web Services Germany)

JAXenter: Im Rahmen der Microservice-Debatte hast du vor einigen Monaten die u.a. von Martin Fowler vertretene Idee zurückgewiesen, man solle zunächst einen Software-Monolithen bauen und diesen dann in Microservices aufteilen. „Don’t start with a monolith – … when your goal is a microservices architecture“, hieß dein Beitrag. Was ist für dich ausschlaggebend gewesen, dazu zu raten, gleich mit Microservices zu beginnen?

Stefan Tilkov: Um es vorab noch einmal klar zu sagen: Ich bin keinesfalls der Meinung, dass man immer Microservices einsetzen sollte und Monolithen immer schlecht sind. Ich finde Monolithen prima und bin deswegen der Meinung, dass wir ganz viele davon bauen sollten … Aber zu der konkreten Aussage: Wenn es so leicht wäre, ein monolithisches System so modular zu entwickeln, dass man es im Nachhinein in Microservices aufteilen kann – bräuchten wir die Aufteilung nicht mehr! Oft helfen die klaren Grenzen zwischen einzelnen Systemen oder Services, die sich nicht bzw. nur mit Aufwand überwinden lassen: Sie stellen sicher, dass die nun stärker getrennten einzelnen Module ihre eigenen lokalen Optima wählen können und stärker isoliert sind.

JAXenter: Nun sieht die Realität in Unternehmen meist so aus, dass bereits eine Anwendungslandschaft vorliegt – und meist besteht diese aus Software-Monolithen. Wir kommen damit zu deinem Thema auf dem Software Architecture Summit, nämlich dem Thema der Architektur-Transformation. Wie schafft man es (technologisch), eine Legacy-Anwendung an moderne Architektur-Ansätze wie Microsrvices, PaaS, Cloud, Continuous Delivery heranzuführen?

Man kann nicht alle Schlachten gleichzeitig kämpfen.

Stefan Tilkov: Zunächst einmal muss man sich der Tatsache stellen, dass man nicht alle Schlachten gleichzeitig kämpfen und gewinnen kann, sondern die wichtigsten Dinge in den Mittelpunkt stellen. Für eine Legacy-Anwendung führt der Weg in die Zukunft aus meiner Sicht über die Umsetzung von neuen fachlichen Anforderungen in eine neue Architektur. Dazu gibt es eine Reihe von Mustern, die sich in der Praxis bewährt haben. Mindestens genau so wichtig ist aber auch der organisatorische Aspekt – wenn man die Teams nicht abholt und die Organisation den Plan sabotiert, wird auch die tollste Technologie scheitern. Das Ganze muss deshalb aus einem (schlanken) strategischen Teil bestehen, der mithilfe kurzfristig nützlicher taktischer Maßnahmen umgesetzt wird. Der genaue Weg ist in jedem Kontext ein anderer.

JAXenter: Du sagst in deinem Session-Abstract, dass bei solchen Transformationen auch Politik und Betriebswirtschaft eine wichtige Rolle spielen. Kannst du hier einmal ein Beispiel nennen?

Stefan Tilkov: Politik spielt – gerade in großen Unternehmen – natürlich immer eine wichtige Rolle. Nur indem man die wichtigen Personen auf allen Ebenen „mitnimmt“, kann man letztlich erfolgreich sein. Betriebswirtschaft ist wichtig, weil Architekturumbaumaßnahmen Geld kosten, der Nutzen aber für die Geldgeber oft in keiner Weise transparent ist. Die meisten Architekturtransformationen müssen daher mit einem fachlichen Thema kombiniert werden – die Businessseite bekommt ein neues Feature mit fachlichem Nutzen und die Architekturverbesserung kommt nebenbei mit.

JAXenter: Vielen Dank für dieses Interview!

stefan_tilkovStefan Tilkov ist Geschäftsführer und Principal Consultant bei der innoQ Deutschland GmbH, wo er sich vorwiegend mit der strategischen Beratung von Kunden im Umfeld von Softwarearchitekturen beschäftigt. Er ist Autor des Buchs „REST und HTTP“, Mitherausgeber von „SOA-Expertenwissen“ (beide dpunkt.verlag), Autor zahlreicher Fachartikel und häufiger Sprecher auf internationalen Konferenzen.

 

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.