Microservices vs. Monolithische Architekturen
„Microservice“ ist ein modernes Schlagwort in der Softwareentwicklung. Im Gegensatz dazu werden andere Entwürfe und Designs gerne als „Monolithen“ bzw. „monolithische Architekturen“ bezeichnet. Wenn Sie nun als Software-Architekt für eine definierte Domäne eine neue Software entwerfen wollen, was tun Sie? Verwenden Sie Microservices, weil es hipp und angesagt ist, oder halten Sie für einen Moment inne und denken über die Infrastruktur des Unternehmens und die Kenntnisse der Mitarbeiter nach, um sich vielleicht dann für Microservices zu entscheiden? Als Architekten ist es unsere Pflicht, auf Microservices zu setzen, wenn sie tatsächlich Sinn ergeben. Wann ist dies der Fall? Welche Aspekte sind wichtig für die Einführung von Microservices? Meine Erkenntnisse basieren auf zahlreichen Implementierungen von Microservices und den so genannten monolithischen Architekturen, dennoch bin ich natürlich offen für alternative Vorschläge oder Aspekte.
Werfen wir einen Blick auf verschiedene Aspekte, die Sie berücksichtigen sollten bevor Sie Microservices als Standardarchitektur auswählen:
Die Fähigkeiten der Projektmitarbeiter
Der erste Aspekt beim Start eines Projekts sind die Mitarbeiter. Welche Erfahrungen und Fähigkeiten besitzen sie? Sie die Fähigkeiten im Bezug auf Microservices nur gering ausgeprägt, sollten Sie sich nicht für Microservices entscheiden. Sind die Fähigkeiten im Team nur auf ein oder zwei Kollegen verteilt, sollten Sie ebenfalls nicht auf Microservices setzen. Idealerweise übernimmt das gesamte Team die Verantwortung für einen Microservice, denn ansonsten können Probleme auftreten. Wenn nur ein oder zwei Personen die Verantwortung für zwei oder drei Microservices übernehmen, lässt sich das Motto „Entwickler sollten sich nur auf einen kleinen Teil konzentrieren, aber alles über den Microservice wissen“ nicht aufrecht erhalten. Diese beiden Mitarbeiter werden zu kritischen Ressourcen.
Das assoziierte Wissen
Im Kontext von Microservices es gibt verschiedene Konzepte wie verteilte Architekturregeln, Hochverfügbarkeit, Ausfallsicherheit, Service Discovery, das CAP-Theorem, domänengetriebenes Design, Unterbrechermuster, verteilte Cache-Mechanismen oder Routenverfolgung zu beachten. Darüber hinaus sind Microservices eng mit der DevOps-Kultur verknüpft, so dass sich die Teammitglieder sowohl mit CI/CD-Tools und der automatisierten Bereitstellung, als auch mit Cloud-Architekturen (PCF, Amazon, Bluemix usw.) oder Containerarchitekturen (Docker, Docker Swarm, Messos, Kubernetes usw.) auskennen sollten. Das assoziierte Wissen des Teams ist wesentlich für den Projekterfolg. Sollte nicht jedes Mitglied in allen Bereichen ausreichend Kenntnisse besitzen, so empfiehlt es sich zumindest, dass in jedem Team mehrere Mitarbeiter über das gesamte Wissen verfügen. Diese Mitarbeiter dienen intern als primäre Ansprechpartner und können so dazu beitragen, dass andere Teammitglieder entsprechendes Wissen schrittweise aufbauen.
Die organisatorische Infrastruktur
Ein weiterer Aspekt ist die organisatorische Infrastruktur. Bevor Sie Microservices einführen, prüfen Sie immer, in welchem Modus Ihre Organisation arbeitet. Gemäß dem Conway-Gesetz spiegelt sich die Struktur Ihres Unternehmens in Ihrer Code-Implementierung wider. Überprüfen Sie, ob Ihre Organisation agile Prinzipien und Techniken übernommen hat. Wie gut ist Ihr Team im Umgang mit User Interfaces, Middle Layer und Datenbanken? Wie sehen Bereitstellung und Testinfrastruktur aus? Operiert Ihr Unternehmen mit manueller Bereitstellung und manuellen Tests oder hat es bereits die DevOps-Kultur übernommen? Im Fall von manuellen Tests und manueller Bereitstellung ist die Übernahme von Microservices ein Albtraum für die Ops und QA-Teams, denn Änderungen und Test lassen sich nur sehr mühsam in das System Integration Testing aufnehmen. Und wo werden Artefakte bereitgestellt – auf eigenen Servern oder in der Cloud? Verfügt die Organisation über eigene Server, auf denen Anwendungsserver installiert sind, werden die verschiedenen Microservice-Artefakte meist auf demselben Serverbereich bereitgestellt. Die sogenannte horizontale Skalierung und damit die Verwendung von Microservices ist gefährdet.
Die Kritikalität und Komplexität der Domäne
Setzen Sie sich mit einem Business Analysten zusammen und überprüfen Sie die Art der Domäne, an der Sie gerade arbeiten. Muss möglicherweise die Domäne in Sub-Domänen aufgeteilt und verwandte Funktionen in einem Kontext gekapselt werden? Treffen Sie am besten anhand der Komplexität der Domäne eine Entscheidung. Bei einer einfachen Domäne könnten Sie sich für eine monolithische Architektur ohne Sub-Domäne und gekapselte Funktionen entscheiden.
Das Projektbudget
Das Budget des Projekts ist ein weiterer wichtiger Aspekt. Handelt es sich um ein Festpreis-Projekt oder wird nach Aufwand bezahlt? Da Microservice-Projekte in Bezug auf Infrastruktur, Ressourcen und Skills deutlich teurer als monolithische Ansätze sind, sollten Sie sich genau überlegen, über welches Budget Sie verfügen. Mein persönlicher Tipp als loyaler Architekt lautet: Denken Sie immer an die Gewinnmarge. Bei einem kleinen Budget eignet sich ein modularer Monolith besser als Microservices. Und wollen Sie zukünftig auf Microservices umstellen, ist dies natürlich ebenfalls möglich.
Fazit
Bei der Wahl zwischen Microservices oder monolithischen Architekturen sollten Sie sich Zeit für eine fundierte Entscheidung nehmen. Auch wenn vielleicht viele Entwickler auf mittlerer Ebene bei einem Monolithen an einen BBOM (Big Ball of Mud) denken, Monolithen sind häufig besser als ihr Ruf, insbesondere wenn die vorhandenen Projektressourcen endlich sind. In meiner Erfahrung ist es häufig sinnvoll, sich für einen Monolithen zu entscheiden, diesen aber modular zu gestalten. Nutzen Sie bspw. Java 9 sollten Sie Module verwenden. Auch bei der Implementierung von SOA empfiehlt sich eine modulare Architektur. Bei Bedarf könnten Sie zu einem späteren Zeitpunkt den Monolithen immer noch schrittweise in Richtung Microservice migrieren.
Ich würde Ihnen nicht empfehlen, Microservices zu nutzen, nur weil es angesagt ist und andere damit arbeiten. Ich habe zahlreiche Projekte erlebt, bei denen Microservices implementiert werden sollten, aber das notwendige Wissen und die benötigen Fähigkeiten fehlten. So wurden häufig nicht gekapselte Dienste erstellt, die miteinander so verkettet wurden, dass die betroffenen Teams nie unabhängige Entscheidungen in Bezug auf die Bereitstellung von Microservices treffen konnten. Häufig waren mehrere Teams und mehrere Artefakte voneinander abhängig. Die Teams gaben sich gegenseitig die Schuld an der Funktionalität, die sich über viele Dienste erstreckte – eine schreckliche Situation. Darauf gehe ich gerne in zukünftigen Beiträgen ein. Für jetzt möchte ich Ihnen Nahe legen, sich zweimal zu überlegen, ob Sie Microservices implementieren wollen, denn wie bereits Onkel Ben sagte „mit großer Macht kommt große Verantwortung.“
Hinweise:
Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.
Der Beitrag von Shamik Mitra ist im Original auf dzone als „microservice vs. monolith which one to choose“ erschienen. Mit seiner Zustimmung übersetzen wir verschiedene Beiträge von ihm hier in unserem Blog vom Englischen ins Deutsche.
Shamik Mitra
Shamik Mitra ist ein selbsternannter Java Maniac. Er arbeitet als technischer Projektmanager bei Tata Consultancy Services (TCS), und war zuvor bei Cognizant als Architekt und bei IBM als technischer Leiter aktiv. Er ist der Most Valuable Blogger bei DZone und Techathon Coding Competition Jury Award Winner. Er veröffentlicht regelmäßig Tutorials bei A4Academics und er ist technischer Reviewer bei PACKT Publication. Auf vielen dieser Plattformen teilt er sein Wissen zu Java, Java EE, Hibernate, Spring, Entwurfsmuster, Micro-Service, Bigdata und Agile.