Interview mit Jens Deponte

Microservices: Vorsicht vor suboptimalen Kommunikationsmustern

Dominik Mohilo

Jens Deponte

Monolithen sind tot – lang leben die Microservices. So oder so ähnlich könnte der aktuelle Wahlspruch in modernen Software-Architekturen lauten. Wir sprachen im Rahmen der W-JAX 2019 mit Jens Deponte, Architekt und Berater bei der adesso AG, über die Best Practices beim Umgang mit Microservices-Architekturen. Er erklärt uns zudem, welche Probleme der Um- bzw. Einstieg auf Microservices entstehen können.

JAXenter: Hallo Jens und danke, dass du dir Zeit für dieses Interview genommen hast. In deiner Session auf der W-JAX 2019 sprichst du über Microservices. Was ist bei einem neuen Projekt, das diesem Architekturschema entsprechen soll, der erste Schritt zum Erfolg?

Jens Deponte: Zunächst sollte man sich schon sicher sein, dass man den richtigen Architekturansatz gewählt hat. Was ich definitiv nicht als Empfehlung gegen Microservices missverstanden wissen möchte, sondern als Plädoyer für fundierte Technologieentscheidungen. Leider erlebt man viel zu oft, dass eben solche Entscheidungen ohne oder auf zu dünner Faktenbasis getroffen werden, was dem Projekterfolg nicht gerade zuträglich ist.

Ist man über diesen Schritt hinaus, ist eine gründliche Analyse der Fachdomänen sehr wichtig, um einen guten initialen Schnitt der Services zu definieren. Das erspart einem später einiges an Refactoring-Aufwänden.

JAXenter: Welche Tools sollte jeder Programmierer nutzen, um den Einstieg in die Microservices-Entwicklung möglichst unkompliziert und einfach zu erleben?

Entwickler sollten sich mit ihrem Handwerkszeug, also in erster Linie IDE, Repository sowie Build Pipeline, auskennen und wohlfühlen.

Jens Deponte: Entwickler sollten sich mit ihrem Handwerkszeug, also in erster Linie IDE, Repository sowie Build Pipeline, auskennen und wohlfühlen. Wobei bei Letzteren natürlich ein Team-Konsens gefunden werden muss. Aber grundsätzlich muss ein Entwickler seine Tools beherrschen, damit er effizient seiner eigentlichen Aufgabe, fachliche Probleme zu lösen, nachkommen kann. Zwangsvorgaben helfen da nicht wirklich weiter, sondern man sollte hier schon auch auf individuelle Präferenzen achten. Darüber hinaus ist es wichtig, möglichst viele Dinge zu automatisieren und damit Fehler in der täglichen Nutzung zu vermeiden. Sonst läuft man sehr schnell Gefahr, dass Entwickler von der Komplexität überrollt und schließlich frustriert werden.

JAXenter: Gibt es Best Practices, an die man sich auch in späteren Phasen immer halten sollte?

Jens Deponte: Aus meiner Sicht sollte man sich in jeder Projektphase im Klaren darüber sein, was genau die aktuellen Probleme sind, die es zu lösen gilt. Ich bevorzuge immer die einfachste Lösung, die das gegebene Problem wirklich löst, aber auch nicht viel mehr macht. Dies erhöht einfach die Wahrscheinlichkeit, dass man keinen überkomplexen Code produziert, der später umgebaut werden muss, weil er eben doch nicht passt.

API Experten Dossier 2019

SIND SIE BEREIT FÜR DIE API-REVOLUTION?

In über 30 Seiten beleuchten Experten APIs aus allen Blickwinkeln und teilen ihre Erfahrung, Ideen und Lösungsansätze mit Ihnen.
Sichern Sie sich jetzt kostenlos sieben Fachbeiträge und Interviews zu spannenden Themen wie dem Design, der Entwicklung und der Systemintegration von APIs.

 

JAXenter: Welche Probleme sind bekannt und treten bei vermutlich jedem Projekt irgendwann auf?

Jens Deponte: Je nach Projektsituation können das ganz verschiedene Dinge sein. Was man immer wieder beobachten kann, ist ein ungünstiger Service-Schnitt, an dem zu lange festgehalten wird. Es kann nun immer mal passieren, dass sich das Projekt etwas anders entwickelt, als ursprünglich gedacht und man immer mehr Service-übergreifende Geschäftsprozesse implementieren muss. Dann sollte man aber zeitig innehalten und mit allen Konsequenzen nach besseren Lösungen suchen. Die dafür notwendige Zeit ist sicherlich besser investiert, als zu lange an alten Zöpfen hängen zu bleiben.

Eine andere häufige Beobachtung ist, dass bei der Kommunikation zwischen Services suboptimale Kommunikationsmuster verwendet werden. Gerade die Entscheidung, ob ich eine synchrone oder asynchrone Kommunikation verwende ist keine rein technische Entscheidung, die ich einmal für alles im Projekt treffen kann, sondern die anhand des jeweiligen Geschäftsprozesses immer wieder hinterfragt und neu getroffen werden muss. Das wird leider zu oft übersehen.

JAXenter: Warum sind Microservices deiner Meinung nach besser als eine monolithische Herangehensweise?

Monolithen sind in Verruf geraten, weil man in ihnen klare Architekturvorgaben viel leichter über Bord werfen kann, als dies mit Microservices möglich ist.

Jens Deponte: Monolithen sind in Verruf geraten, weil man in ihnen klare Architekturvorgaben viel leichter über Bord werfen kann, als dies mit Microservices möglich ist. Sie sind häufig schwerfällig, schlecht zu warten und damit teuer. Microservices-Architekturen bieten hingegen eine Menge Freiheiten und Flexibilität, die – richtig eingesetzt – viel Nutzen für das zu entwickelnde System stiften können. Leider bekommt man diese Vorteile nicht umsonst, so dass man wie in jedem anderen Architekturstil auch seine Architektur- und Technologieentscheidungen sehr bewusst treffen sollte, um das Maximum herausholen zu können. Unter den richtigen Bedingungen eingesetzt erleichtern Microservices eine effiziente, nachhaltige Softwareentwicklung.

JAXenter: Was ist die Kernbotschaft deiner Session, die jeder mit nach Hause nehmen sollte?

Jens Deponte: Ganz allgemein: Kenne Deinen Feind! In Bezug auf die Entwicklung von Microservices-Systemen können das ganz unterschiedliche Dinge sein, von der Toolchain mit der man Software entwickelt bis hin zu den technischen aber auch fachlichen Problemen, die es zu lösen gilt. Genau das versuche ich anhand typischer Fehler und möglichen Lösungsansätzen bzw. Best-Practices in der Microservices-Entwicklung herauszuarbeiten.

Jens Deponte ist bei der adesso AG vielfach als Architekt und Berater im Projektgeschäft unterwegs. Die dabei gesammelten Erfahrungen bringt er in die technologische Ausrichtung des Unternehmens und die Ausbildung von Architekten ein. Darüber hinaus beschäftigt er sich intensiv mit verschiedensten Aspekten der Informationssicherheit. Soweit noch Zeit bleibt, hält er Schulungen und spricht gelegentlich auf Konferenzen.
Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: