Microservices vs. Monolith – Paradigmenwechsel in der Software-Entwicklung

 

Microservices sind ein recht neuer Ansatz der Softwareentwicklung und entstammen der DevOps Bewegung, denn Microservices sind im Gegensatz zu Monolithen die Grundlage für DevOps und Continuous Delivery Methoden. In einer sich ständig wandelnden Geschäftswelt, müssen sich auch Anwendungen und Programme schnell an die Anforderungen der Nutzer anpassen können.

Und genau darin liegt die Stärke von Microservices. Denn Microservices unterstützen lose miteinander verbundene Architekturen und die unabhängige Skalierung der einzelnen Komponenten. Darin unterscheiden sie sich von der traditionellen monolithischen Softwareentwicklung.

Monolithen und Microservices: Unterschiede

Eine traditionelle monolithische Architektur ist als ein großes System gebaut und basiert meistens auf einem Code. Sie wird meistens im Ganzen bereitgestellt – das heißt, dass bei Änderungen von Details die ganze Architektur bearbeitet und geschlossen zur Verfügung gestellt werden muss. Bei Microservices hingegen sind Apps als eine Suite kleiner Services gebaut, die alle eine eigene Code-Basis haben. Diese Services sind rund um bestimmte Funktionalitäten gebaut und können unabhängig voneinander bereitgestellt werden. Das heißt, für Detailänderungen muss stets nur der entsprechende Microservice geändert werden und es muss nicht die gesamte App neu aufgelegt werden.

Das hat entscheidende Vorteile, was sich zum Beispiel in der Geschwindigkeit der Bereitstellung und Entwicklung im Rahmen von Continuous Delivery bemerkbar macht. In der Realität erhöhen Microservices aber auch die Komplexität, so dass sie schwerer zu managen sind. Und auch Themen wie die IT Governance und Compliance sind häufig ungeklärt.

Konventionell denkende Unternehmen und IT-Abteilungen tendieren daher dazu, zunächst mit einer traditionellen Monolith-Architektur zu beginnen, vor allem, wenn es sich um ein nur sehr kleines Team handelt und die Zeitvorgaben sehr eng sind. Dabei ist das nicht immer die richtige Entscheidung. Die richtige Wahl hängt ganz von der Projektart ab. Um das besser zu verstehen, ist zunächst eine klare Definition beider Optionen, sowie eine Auflistung ihrer Vor- und Nachteile notwendig.

Monolith: Was ist darunter zu verstehen?

Eine monolithische Anwendung ist als eine einzelne und zusammenhängende Einheit gebaut. Meistens besteht sie aus drei Teilen: einer Datenbank, einem User-Interface und einer serverseitigen Applikation. Diese handhabt Anfragen, führt domainspezifische Logik aus, ruft Daten von der Datenbank ab und sorgt für das entsprechende Update und pflegt die HTML Ansichten ein, die an den Browser geschickt werden.

In einer Monolith-Logik sind die Frontend Logik auf Seiten des Users, die Prozesse Hintergrund, die Server-Logik etc. alle in der gleichen massiven Code-Basis hinterlegt. Wenn Entwickler Veränderungen und Updates vornehmen, müssen sie den gesamten Stack komplett neu bauen und bereitstellen. Das heißt aber nicht, dass ein Monolith eine veraltete Architektur ist, die wir in der Vergangenheit lassen sollten. Für bestimmte Anwendungszwecke ist ein Monolith ideal, zum Beispiel bei einer kleinen Anwendung, bei der es viel zu aufwändig wäre, diese in einzelne Microservices aufzusplittern.

Vorteile von Monolithen

  • Der größte Vorteil einer monolithischen Architektur ist, dass es bei den meisten Apps viele Überschneidungen gibt – etwa bei Protokollierung oder Sicherheitsfunktionen und diese sich in monolithischen Architekturen einfacher handhaben lassen. Wenn alles über die gleiche App läuft, dann ist es einfach Komponenten anzuschließen.
  • Geringere betriebliche Gemeinkosten: Da es sich nur um eine große Applikation handelt, müssen auch nur für eine Applikation Logs, Monitoring und Tests eingerichtet werden. So ist die App auch ganz grundsätzlich einfacher bereitzustellen.
  • Performance: Auch hier können sich Vorteile bieten, da keine Kommunikation zwischen einzelnen Services stattfindet.

Nachteile von Monolithen

  • Feste Verkopplung: Monolithische Architekturen neigen dazu sich enger zu verzahnen und zu verstricken, wenn sich die Applikation weiterentwickelt, was es schwierig macht, einzelne Services für einen Zweck zu isolieren, wie etwa für eine unabhängige Skalierung oder Code-Wartung.
  • Höhere Komplexität: Monolithische Architekturen sind sehr viel schwieriger zu verstehen, denn es gibt immer Abhängigkeiten und Auswirkugen, die sich nicht eindeutig erkennen lassen, wenn man sich einen bestimmten Server oder Controller anschaut.

KOSTENLOSER DOWNLOAD: DIGITALISIERUNGS-REPORT

Ist Ihr Unternehmen auf die Stolpersteine und Herausforderungen der Digitalisierung vorbereitet? Erfahren Sie im kostenlosen Analyse-Report von Crisp Research, worauf geachtet werden sollte und welche Technologien dabei zum Einsatz kommen können.

Definition von Microservices

Microservices sind nicht unbedingt klein oder „micro“. Sie sind zwar in der Regel kleiner als klassische Monolithen, aber die Komplexität oder die Codebasis können durchaus sehr umfangreich sein. Die Microservice Architektur ist ein Ansatz, um eine Applikation bereitzustellen, die aus Satz kleinerer Services besteht, die alle über ihre eigenen Prozesse verfügen und über Schnittstellen (API) kommunizieren. Diese Services sind rund um Fähigkeiten gebaut, die ein Unternehmen bereitstellen muss und werden durch automatische Deployment-Mechanismen unabhängig voneinander bereitgestellt. Das Management dieser Services ist dabei zentralisiert und auf ein Minimum reduziert.

Vorteile von Microservices

  • Bessere Organisation: Microservice-Architekturen sind typischerweise besser organisiert, da jeder Microservice eine spezifische Aufgabe hat und sich nicht weiter mit den anderen Komponenten beschäftigt.
  • Entkoppelung: Entkoppelte Services sind einfacher wieder zu zerlegen und neu zu konfigurieren, um dem Zweck verschiedener Apps zu dienen (z.B. dem Authorisierungs- sowie Streaming-Dienst). Sie erlauben auch eine schnellere, unabhängige Auslieferung einzelner Teile innerhalb eines größeren, integrierten Systems.
  • Leistung: Unter den richtigen Umständen können Microservices Leistungsvorteile liefern, abhängig davon, wie sie organisiert sind, vor allem, weil stark beanspruchte Dienste isoliert und unabhängig vom Rest der App skaliert werden können.
  • Weniger Fehler: Microservices ermöglichen parallele Entwicklungen, da es schwer zu überschreitende Grenzen zwischen verschiedenen Teilen des Systems gibt. Das macht es schwieriger, das Falsche zu tun, nämlich Teile miteinander zu verbinden, die nicht verbunden gehören, oder Dinge, die verbunden gehören, zu eng zu verbinden.

Nachteile von Microservices

  • Der größte Nachteil von Microservices liegt in der Konvergenz verschiedener Services: Wer eine Miroservice-Architektur erstellt, wird feststellen, dass sich viele Ansätze überschneiden. Eine Lösung ist es, Schnittstellen komplett durch eine separate Schicht laufe zu lassen, die genau für die Prozesse zuständig ist. Sogar in monolithischen Architekturen läuft Traffic häufig durch eine äußere Service-Schicht für genau diese Überschneidungen, allerdings lassen sich die Kosten dieser Arbeit bei monolithischen Architekturen sehr viel länger herauszögern, also bis das Projekt sehr viel weiter vorangeschritten und gereift ist.
  • Höhere operative Gemeinkosten: Microservices werden häufig auf ihren eigenen virtuellen Maschinen oder in Containern bereitgestellt, was oft für einen Kostenzuwachs sorgt. Diese Aufgaben werden häufig automatisiert.

Grundsätzlich ist ein Blick auf die Vor- und Nachteile beider Ansätze sinnvoll. Als Entscheidungsgrundlage für Unternehmen sind sie allein aber nicht ausreichend. Vielmehr sollten sich Unternehmen einige essentielle Fragen stellen, um sicher zu gehen, dass sie den richtigen Ansatz für ihr Unternehmen wählen.

Microservices oder Monolith: Den richtigen Ansatz wählen

1. Bewegt sich das Unternehmen auf bekanntem Gebiet?

Wer sich in einem Bereich bereits gut auskennt und den entsprechenden Nutzen kennt, kann direkt mit Microservices experimentieren. Wer sich aber auf komplett unbekanntem Terrain bewegt und keinerlei Vorerfahrungen auf dem zu bearbeitenden Gebiet hat, ist bei monolithischen Architekturen häufig besser aufgehoben.

2. Ist das Team gut vorbereitet?

Hat das Team bereits Erfahrungen mit Microservices? Und sind Microservices der richtige Ansatz, wenn das Team sich weiter vergrößert? Die Dimensionen zu evaluieren ist essentiell für den Erfolg eines Projekts. Wenn ein Team bereits gut vorbereitet ist, dann ist es sinnvoll direkt mit den Microservices zu beginnen, damit sie sich an den Rhythmus der Entwicklung in einer Microservice-Umgebung gewöhnen – und das gleich von Anfang an.

3. Wie ist die Infrastruktur?

Damit Microservices für ein Projekt funktionieren, bedarf es einer Cloud-basierten Infrastruktur. Mit modernen Cloud Services wie Google Cloud und Amazon AWS ist die Bereitstellung sehr viel einfacher geworden, da nicht gleich die ganze Serverbasis eingekauft und verfügbar gemacht werden muss.

4. Risiko evaluieren

Microservices sind häufig ambitioniert und stellen daher auch ein Geschäftsrisiko dar, wenn Teams Microservices einsetzen, ohne im Umgang damit geübt zu sein oder der Einsatz nicht sinnvoll ist.

5. Kontext ist entscheidend

Der eigene Kontext und das eigene Szenario sind ausschlaggebend dafür, ob eine monolithische Architektur oder Microservices zu wählen sind. Unternehmen sollten sich dessen bewusst sein, bevor sie sich entscheiden, welche Architektur ihrer Situation angemessen ist.

Eine monolithische Architektur ist sinnvoll, wenn…

  • das Team sich noch in einer Gründungsphase befindet, es nur aus sehr wenigen Mitgliedern besteht und noch gar nicht in der Lage ist, die Komplexität einer Microservice-Architektur zu managen.
  • das Unternehmen ein neues, nicht bewiesenes Produkt baut, oder einen Wirksamkeitsnachweis (Proof of Concept) braucht: Handelt es sich um eine neue Idee, ist es wahrscheinlich, dass diese sich im Laufe der Zeit immer weiter entwickelt. Ein Monolith ist daher ideal, um eine schnelle Produktabfolge zu ermöglichen. Das gleiche gilt für ein Proof of Concept, bei dem es darum geht möglichst schnell, möglichst viel zu lernen, selbst wenn man das Projekt am Ende verwirft.
  • es keinerlei Vorerfahrung mit Microservices gibt: Wenn das Team keine Erfahrung mit Microservices hat, sollte es bei einem Monolith bleiben, es sei denn das Unternehmen riskiert ein „Learning by Doing“.

Gegen den Einsatz von Microservices spricht nichts, wenn…

  • das Unternehmen eine schnellere und unabhängige Service-Bereitstellung braucht: Microservices ermöglichen eine schnelle und unabhängige Bereitstellung individueller Teile innerhalb eines größeren, integrierten Systems.
  • ein Teil der Plattform effizient sein muss: Genau dieser Teil sollte in einer äußerst effizienten Programmiersprache gebaut sein. Für andere Bestandteile können unterschiedliche Programmiersprachen verwendet werden.
  • das Team wachsen soll: Wer mit Microservices beginnt, gewöhnt das Team von Anfang an daran, in separaten kleinen Services zu arbeiten. Wenn das Team wächst, muss nicht exponentiell eine größere Komplexität eingeführt werden, da die Teams ohnehin durch Service-Grenzen voneinander separiert arbeiten.

Kurz zusammengefasst: Es ist nicht das Ende monolithischer Architekturen, vielmehr sollten Microservices entsprechend des Kontexts zum Einsatz kommen. Unternehmen sollten immer den eigenen Nutzen an erste Stelle stellen und sich dann für die entsprechende Architektur entscheiden.

 

ÜBERSICHT ARTIKELSERIE

1) Microservices vs. Monolith – Paradigmenwechsel in der Software-Entwicklung
2) Microservices: Vorteile und Nachteile
3) Die größten Herausforderungen beim Einsatz von Microservices
4) Konfiguration & Betrieb von Microservices

Download: Marktübersicht für Digital Workplaces & Mobility-Lösungen

Unternehmen sind mit neuen Technologien und hohem Bedarf an Vernetzung & Schnelligkeit konfrontiert. Jetzt im Marktüberblick von Crisp Research erfahren, welche Anbieter hier unterstützen.

Klicken Sie zum Download einfach auf das Bild und Sie werden automatisch weitergeleitet.

Download: Markt- und Anbieterüberblick für Digital Workplaces und Mobility-Lösungen

Unternehmen sind mit neuen Technologien und hohem Bedarf an Vernetzung & Schnelligkeit konfrontiert. Jetzt im Marktüberblick von Crisp Research erfahren, welche Anbieter hier unterstützen.

Klicken Sie zum Download einfach auf den Button und Sie werden automatisch weitergeleitet.