Microservices vs. Monolithen: Welche ist die richtige Architektur für Ihre Business Software?

Wie Ihr Unternehmen mit der Entwicklung von Software umgeht, kann einen Einfluss darauf haben, wie gut Sie Ihre Kunden bedienen, wie effizient Ihre Mitarbeiter sind und wie agil Ihr Unternehmen ist.  Aus diesem Grund kann es von entscheidender Bedeutung sein, frühzeitig im Lebenszyklus der Software sowie in deren Entwicklung die richtigen architektonischen Entscheidungen zu treffen. Diese Entscheidungen können einen nachhaltigen Einfluss auf die Zukunft ihrer Unternehmung haben.

Es gibt viele Architektur- und Entwicklungsansätze, welche für Ihr Unternehmen geeignet sind. Die beliebtesten lassen sich in zwei Kategorien unterteilen:

   

 

 

Monolithische Architektur

Das Wort „Monolith“ stammt ursprünglich aus dem Griechischen und wurde verwendet, um einen einzelnen, berggrossen Steinblock zu beschreiben. Auch wenn das Wort heute weiter gefasst wird, bleibt die Idee gleich – ein monolithisches Softwareprodukt ist eine einzige, unteilbare Einheit, die in der Regel kontinuierlich heranwächst.

In einer typischen Client-Server-Architektur ist ein monolithisches Produkt auf dem Server installiert, wo es Anfragen (z.B. HTTP) verarbeitet, Logik ausführt und mit der Datenbank interagiert. Es enthält eine einzige ausführbare Datei (z.B. *.exe), die alle serverseitigen Funktionen für eine Anwendung ausführt.

In einer monolithischen Softwarearchitektur wird üblicherweise alles von der gleichen Stelle aus verwaltet und bedient. Um beispielsweise eine Anpassung auf Produkteebene zu bewerkstelligen, greift der Entwickler auf die gleiche Codebasis zu wie beim Hinzufügen einer neuen Kundendienstfunktion etc. Die Grösse und Einfachheit von monolithischen Softwareprodukten sind sowohl Stärke als auch Schwäche.

Darstellung: Monolithische Software-Architektur

Wie monolithische Architekturen zur Produktivität beitragen können

Der Hauptvorteil einer monolithischen Anwendung ist die Einfachheit ihrer Infrastruktur, die sie schneller implementieren und skalieren kann. Dasselbe gilt für die vereinfachte Bereitstellung (Verteilung) der Software. Um eine monolithische Anwendung bereitzustellen, muss nur eine Datei oder ein Verzeichnis behandelt werden. Dies macht die Bereitstellung ziemlich einfach und in den meisten Fällen auch zeitschonend.

Monolithen sind eine bequeme Möglichkeit, ein neues Softwareprojekt zu starten, ohne dass die Einrichtung auf einem Server oder einer Cloud-Umgebung erforderlich ist. Während die Komplexität mit der Zeit wachsen kann, kann eine angemessene Verwaltung der Codebasis dazu beitragen, die Produktivität über die gesamte Lebensdauer einer monolithischen Anwendung aufrechtzuerhalten.

Wie monolithische Architekturen die Produktivität beeinträchtigen

Monolithische Anwendungen werden mit der Zeit immer umständlicher. Gerade bei Weiterentwicklungen und Updates sind die Entwickler gefordert. Da immer ein Gesamtsystem betroffen ist, ist es ist von grösster Bedeutung, dass die Entwickler darauf achten wie der Code geschrieben und gepflegt wird. Ohne dies kann ein Monolith gefährlich spröde werden.

Gerade dies hat leider auf der Entwicklungsseite grosse Nachteile und Monolithen können die Agilität in der Entwicklung stark beeinträchtigen. Monolithische Anwendungen sind sehr eng miteinander verbunden und können mit der Entwicklung des Produkts zu einem komplexen Code-Netzwerk werden. Daher kann es für Entwickler äusserst schwierig sein, diese im Laufe der Zeit zu verwalten.

“An evolving system increases its complexity unless work is done to reduce it.” – Meir Lehman

Eine Herausforderung ist zudem, dass es in mittleren und grossen Entwicklungsunternehmungen üblich ist, dass jeder Entwickler nur einen Teil des Monolithen versteht. Dies hat zur Folge, dass nur wenige Entwickler die Gesamtheit der Anwendung kennen und erklären können. Da Monolithen als eine Einheit entwickelt und eingesetzt werden müssen, kann es schwierig sein, die Entwicklungsarbeit in unabhängige Teams zu unterteilen. Jede Code-Änderung muss sorgfältig abgestimmt werden, was die Entwicklung verlangsamt.

Dieses Risiko hat zur Folge, dass auch erfahrene Entwickler mehr Zeit damit verbringen die richtige Codezeile zu finden, um sicherzustellen, dass sie keine Nebenwirkungen hat. Dies anstatt die Zeit in das Schreiben von neuen Funktionen und Programmverbesserungen zu investieren. Zudem besteht das Risiko, dass bei der Einführung neuer Technologien in einem Monolithen unter Umständen die gesamte Anwendung neu geschrieben werden muss, was ein kostspieliges und zeitaufwendiges Unterfangen, welches nicht immer zu den gewünschten Fortschritten führt.

Monolithen sind – zumindest bei der Grundentwicklung – einfacher zu bauen als Microservices. Dieser anfängliche Vorteil hat jedoch seinen Preis, wenn sich herausstellt, dass die Anwendung für Wachstum und Veränderungen anfällig, aufwändig und sehr kostspielig ist.

 

Das Fazit monolithischer Architekturen

  • Es ist per se nicht schlecht, eine monolithische Anwendung zu erstellen oder eine solche einzusetzen, aber es ist eine Herausforderung, eine monolithische Anwendung auf Entwicklungsseite ausser Kontrolle geraten zu lassen.
  • Monolithen sind von Anfang an agil, so dass ein Unternehmen ein Produkt schnell auf den Markt bringen kann. Allerdings sollte die Architektur der Anwendung stärker berücksichtigt werden, wenn mehr Zeit damit verbracht wird, den bestehenden Code zu reparieren, anstatt neue Funktionen zu entwickeln.
  • Ab einem bestimmten Punkt sollten Sie überlegen, ob eine Microservices-Architektur besser geeignet ist.

Microservice-Architekturen

Während ein Monolith eine einzelne, grosse Einheit ist, verwendet eine Microservice-Architektur kleine, modulare Codeeinheiten, die unabhängig von den übrigen Komponenten eines Produkts eingesetzt werden können.

Darstellung: Microservices

Für den Aufbau von Microservice-Architekturen gibt es viele Möglichkeiten. Die meisten von ihnen haben einige grundlegende Eigenschaften:

  • Jeder Microservice ist nur für einen bestimmten Zweck oder eine bestimmte Aufgabe verantwortlich.
  • Üblicherweise verfügt ein Microservice über einen eigenen Datenspeicher.
  • Die Komponenten von Microservices sind stets modular aufgebaut, sodass jeder Service unabhängig von jedem anderen Code erstellt, aktualisiert und bereitgestellt werden kann.
  • Microservices abstrahieren Implementierungsdetails und zeigen in der Regel eine gut dokumentierte Schnittstelle, so dass APIs konsistent verwendet werden können. Dies unabhängig davon, wie und von wem der Service aufgebaut worden ist.

 

Wie Microservices zur Produktivität beitragen

Die Entwicklung von Microservices ermöglicht Entwicklern, schnell und äusserst flexibel zu arbeiten. Dabei können sie sich im Gegensatz zu den Monolithen auf die reine Produktfunktion konzentrieren, an der sie gerade arbeiten. Der Entwickler muss nicht die Implementierung eines anderen Microservice analysieren, sondern muss sich nur über dessen Zweck und Schnittstelle im Klaren sein.

Microservices sind voneinander isoliert und können so sehr einfach auch separat bereitgestellt werden. Dies bedeutet, dass bei einer Änderung (z.B. an einem Dienst) nur der betroffene Service und nicht die gesamte Anwendung getestet und bereitgestellt werden muss. Der Koordinationsaufwand ist bedeutend kleiner als bei der Entwicklung von Monolithen. Dadurch können Produkte schneller und in besserer Qualität an die Kunden ausgeliefert werden.

Cloud-Plattformen wie Amazon Web Services, Microsoft Azure oder Google Cloud Plattform erleichtern zudem auch die Bereitstellung, Wiederverwendung und Skalierung von Microservices.

Grundsätzlich kann auch behauptet werden, dass separate Microservices weniger anfällig auf Ausfälle oder Systeminstabilität reagieren. Dies weil normalerweise nur einzelne Services, und nicht das Gesamtsystem betroffen ist. Durch diese Trennung ist es möglich, dass auch bei Ausfall eines Microservices trotzdem mit anderen Services weitergearbeitet werden kann.

 

Wie Microservices die Produktivität beeinträchtigen können

Während Microservices-Architekturen im Allgemeinen agiler sind als Monolithen, bietet die von Microservices eingeführte Komplexität eine Reihe von Herausforderungen.

Die organisatorische Dynamik bei der Entwicklung verändert sich bei der Entwicklung von Microservices stark. Dies weil Microservices die Kombination mehrere Teile einer Anwendung erfordern – die alle von verschiedeneren Teams aus Entwicklern und Produktmanager verwaltet werden können. Teams müssen in der Lage sein, die Bandbreite der Entscheidungen, Planung und Implementierung, die den Lebenszyklus der Softwareentwicklung umfasst, zu bewältigen, und dies muss auf hoher Ebene über mehrere Teams hinweg geschehen. Der Abstimmungsaufwand mit Entwicklerteams von anderen Services kann zu Zeitverlust führen. Insbesondere dann, wenn ein Service mit einer anderen Sprache programmiert worden ist. Diese Kommunikation kann ohne geeignete Prozesse umständlich sein. Es wird auch erforderlich sein, dass die neue Funktionalität die Bestehende nicht beeinträchtigt, da es andere Microservices geben könnte, die sich darauf stützen. Aus diesem Grund ist eine Versionierung der Microservices eine absolute Notwendigkeit.

Das Fazit von Microservices

  • Ein Microservices-Ansatz bietet eine agile Entwicklungserfahrung für Entwickler und potenziell verbesserte Softwareprodukte für Endanwender. Im Idealfall bedeutet dies ein höheres Mass an Effizienz, mehr Flexibilität, geringere Wartungskosten, sowie die Sicherstellung der grösstmöglichen Skalierbarkeit.
  • Es ist jedoch wichtig, sich daran zu erinnern, dass die Übernahme einer Microservice-Architektur nicht etwas ist, das die Probleme, die mit einer komplexen monolithischen Codebasis einhergehen, auf magische Weise löst. Während der modularere Code die Wartung erleichtert, muss eine Microservices-Architektur sorgfältig und korrekt implementiert werden.

 

Aus Anwendersicht von Monolith- oder Microservicebasierter Software

Die Nachfrage nach immer flexibleren und auf Kundenbedürfnisse abgestützte Applikationen, welche frei skalierbar sind, steigt stetig. Der «Best-of-Breed»-Ansatz ist attraktiv und kann mit Microservices effizienter, kostengünstiger und vor allem schneller umgesetzt werden als mit der Monolith-Architektur. Die Standardisierung der Schnittstellen vereinfacht die Systemarchitektur insofern, dass Services und auch weitere Fachapplikationen sehr effizient und auch sicher an ein System angedockt werden können. Dies vereinfacht den Einsatz von Workflows innerhalb der Module was für eine exzellente User Experience führt. Zusätzlich bilden Microservices eine der Grundlagen für funktionierendes KI in einer Business Software.

Der Einsatz von Microservices ist zudem auch bezüglich Datenzugriff gerade im Zeitalter von restriktiven Datenschutzverordnungen wie DSGVO und den damit verbundenen kontrollierten personenbezogenen Datenzugriffsrechte  attraktiv, da die Rechte sehr einfach und servicebezogen vergeben werden können. Dadurch ist es möglich einfach und modular zu definieren welche Mitarbeiter oder Mitarbeitergruppen auf welche Services Zugriff haben. Im Gegensatz zu einer Monolithischen Softwarearchitektur in welcher ein zentrales Login das Scheunentor zur Hauptdatenbank öffnet. Eine durchdachtes Zugriffskonzept ist in diesem Fall Voraussetzung.

 

 

Veröffentlicht am 22. März 2019

Kommentar schreiben