Microservices vs. Nanoservices: Abwägungsrahmenoptionen

Im Laufe der Jahre entfernte sich die Softwareentwicklung von traditionellen monolithischen Architekturen und adressierte ihre Komplexitäten mit eng gekoppeltem, miteinander verbundenem Code. Dies führte zur Einführung von Microservices, effizienten cloudnativen Ansätzen, die verteiltes Rechnen durch mehrere, kleinere Dienste ermöglichen.

Seit Microservices zum Mainstream geworden sind, haben sich Nanoservices in den letzten Jahren zu einem weiteren Muster entwickelt, das hauptsächlich darauf ausgelegt war, die Komplexität von Microservices zu überwinden. Im Wesentlichen teilen Nanoservices die Services weiter auf, um zusätzliche Effizienz zu erzielen.

Dieser Artikel erläutert, wie die Entwicklung kleinerer Komponenten zur Entwicklung einer Anwendung ein bevorzugter Ansatz ist, daher werde ich folgendes tun:

• Erkläre sowohl Mikro- als auch Nanoservices
• Entdecken Sie Vorteile und Herausforderungen
• Teilen Sie Beispiele und Best Practices, die Ihnen helfen, das richtige Rahmenwerk für Ihre Bedürfnisse zu bestimmen

Verbesserung der Entwicklungspraktiken

Aufgrund ihres elementaren Designs haben monolithische Anwendungen einige ernsthafte Herausforderungen:

• Sie sind umständlich.
• Sie verbrauchen viel Speicherplatz.
• Sie sind schwer zu skalieren.

Wenn Monolith-Anwendungen ausgereift sind, bringt die Einführung der neuesten Technologien oder die Einführung erweiterter Frameworks viele Feinheiten mit sich. Diese Hindernisse beschränken sich nicht auf die Integration auf Codeebene. Testen und Bereitstellung sind ebenfalls herausfordernd.

Außerdem ist ein komplettes Projekt, um die gesamte Anwendung neu zu schreiben, oft zeitaufwendig und äußerst riskant.

(Erfahren Sie mehr über die Komplexität der App-Modernisierung und Code-Refaktorisierung.)

Microservices über Monolithen

Microservices wurden aufgebaut, um:

• Überwinde die Probleme mit einem monolithischen Ansatz.
• Bieten Sie eine effektive Lösung für die Entwicklung verteilter, cloudbasierter Anwendungen bereit.

Ein Microservice fragmentiert eine Anwendung in eine Assembly mehrerer lose gekoppelter Services. Typischerweise sind Microservices:

• Isoliert entwickelt und getestet
• Organisiert nach den Prozessen, die sie abwickeln
• Unabhängig eingesetzt.

Jeder dieser Dienste hat eigene separate Prozesse und ist so konzipiert, dass er unabhängig ohne Ressourcenteilung funktioniert, um Konflikte zu vermeiden.

Nanoservices

Eine typische Illustration zeigt, wie sich ein zentrales, mehrstufiges Framework eines Monolithen von einer Microservices-Architektur mit verteilten Diensten unterscheidet.

(Vergleichen Sie die Mikroservice-Architektur mit der monolithischen Architektur.)

Microservices sind üblicherweise in cloudbasierten Containern enthalten, die über Web-APIs mit anderen Diensten kommunizieren. Solche APIs fungieren als Nachrichtenwarteschlangen, die auf eingehende Ereignisse wie Benutzeroberfläche, das Aufrufen anderer Dienste, das Empfangen von Daten usw. reagieren.

Aufgrund ihres verteilten Modells werden Microservices entwickelt und gewartet, ohne andere Dienste zu beeinträchtigen. Dies unterstützt im Wesentlichen auch ein DevOps-Modell , indem es erlaubt:

• Effiziente Automatisierung
• Hohe Verfügbarkeit 

(Sehen Sie, wie sich Microservices und APIs unterscheiden, aber zusammenarbeiten.)

Vorteile von Microservices

Das komponentenbasierte Design eines Microservice-Frameworks bietet mehrere Vorteile, darunter:

• Microservices sind leichter zu warten, zu skalieren und zu teilen
• Sie funktionieren gut mit Behältern.
• Entwicklung und Testing sind schneller, was den Bereitstellungszyklus verkürzt und ideal für DevOps-Praktiken ist.
• Die isolierte Natur der Dienste ermöglicht eine sicherere Implementierung und eine schnellere Fehlerbehebung.
• Microservices bieten größere Flexibilität, indem sie Wiederverwendbarkeit für den Aufbau ähnlicher Dienste ermöglichen.
• Es gibt keine Einschränkungen hinsichtlich der spezifischen Technologien, die verwendet werden sollen, was eine höhere Entwicklungsproduktivität (und vielleicht Innovation) ermöglicht.
• Da sie interoperabel sind, können Microservices sowohl mit Open-Source- als auch mit Closed-Source-Plattformen verwendet werden.

Was sind Nanoservices?

Der grundlegende Unterschied zwischen den beiden Frameworks besteht darin, dass Nanoservices als kleinere Geschwister von Microservices betrachtet werden. Nanoservices sind so konzipiert, dass sie eine einzelne Funktion ausführen, deren Ausgabe über einen spezifischen API-Endpunkt (Befehl) bereitgestellt wird.

Nanoservices sind vollständig untereinander auffindbar. Jeder kann sich mit anderen Diensten verbinden, um zusätzliche Aktionen auszuführen und die Funktionalität zu erweitern.

Nanoservices sind designweise:

• In sich geschlossen
• Wiederverwendbar
• Weniger komplex als Microservices
• Unterstützt durch unterschiedliche Funktionsdateien für jede

Nanoservices gelten als effizienter als Microservices, insbesondere aufgrund von:

• Einfache Anfangseinrichtung
• Reduzierte Latenz zwischen Diensten, bei der der Funktionscode jedes Nanoservices auf Abruf ausgeführt werden kann, ohne dass dedizierte Container oder Server für jeden einzelnen Dienst gehostet werden.

Nanoservice-Anwendungsfall in der realen Welt

Die folgende Abbildung hebt einen interessanten Anwendungsfall hervor, wie die BBC-Website Tausende von Nanoservices nutzt , um dynamische Webseiten darzustellen. Jeder Dienst dient dazu, eine bestimmte Komponente der Webseite einzuspeisen, wie zum Beispiel:

• Generierung einer Überschrift
• Beschaffung von Wetterdaten
• Aktualisierung eines Spielergebnisses
• Und so weiter.

Eine hochrangige Nanoservice-Architektur der BBC-Website beschreibt, wie mehrere, kleinere Services gemeinsam funktionieren, um Inhalte einer Webseite bereitzustellen:

Vorteile von Nanoservices

Nanoservices sind besonders vorteilhaft aufgrund ihrer einfachen Kapselung spezifischer Funktionen. Dies bringt ein Anwendungsrahmen mit folgenden Vorteilen mit sich:

• Fokussierter und leichter als Microservices
• Mehrere Teams können an einem bestimmten Service oder mehreren Services arbeiten
• Jeder Dienst kann sein eigenes Sicherheitsprotokoll haben
• Kann unabhängig entwickelt, getestet und eingesetzt werden
• Ermöglicht schnellere und häufigere Codeveröffentlichungen
• Zusätzliche Flexibilität, verschiedene Dienste zur Erweiterung der Funktionalität zu verknüpfen

Aktuelle Herausforderungen

Obwohl Microservices und Nanoservices bedeutende Verbesserungen gegenüber einem Monolithen darstellen, sind sie nicht ohne Herausforderungen.

Bestimmte Anwendungsfälle deuten auch darauf hin, dass die Entwicklung einer Anwendung durch Kombination kleinerer Dienste die Komplexität auf verschiedene Weise erhöht, darunter:

• Mehr Aufwand wird in die Erstellung und Pflege duplizierter Dienste investiert
• Der Bedarf an einer hocheffizienten Infrastruktur ist komplex im Bau und teuer in der Instandhaltung
• Höherer Ressourcenverbrauch, aufgrund der schieren Anzahl der Dienste, die Sie unterstützen
• Engere Service-Level-Abhängigkeiten können zu komplexer Fehlerverfolgung führen

Auf den ersten Blick mag eine verstärkte Isolation innerhalb von Nanoservices verlockend erscheinen. Doch die weitverbreitete Nutzung von Nanoservices könnte zu einer Vielzahl von Problemen und erhöhter Komplexität führen.

Vor allem für relativ komplexe Anwendungen kann die Einführung eines Nanoservice-Frameworks tatsächlich Ressourcen überfordern und manuelle Arbeiten skalieren – etwas, das DevOps-Praktiken minimieren wollen.

(Bereiten Sie sich auf andere häufige Microservice-Herausforderungen vor.)

Wahl von Mikro- oder Nanodienstleistungen

Sowohl Microservices als auch Nanoservices haben sich weiterentwickelt, um Effizienz gegenüber traditionellen Architekturen zu steigern, indem komplexe Anwendungscodes in mehrere kleinere Services innerhalb eines cloud-nativen Setups verteilt werden.

Vor diesem Hintergrund laufen die wichtigen Überlegungen bei der Wahl des besten Rahmens letztlich auf zwei Hauptkomponenten hinaus:

• Entwicklererfahrung
• Die Funktionalitätsanforderungen der Anwendung

Wann Microservices verwendet werden sollten

Im Vergleich zu Nanoservices sind Microservices ein etablierter und bekannter Designansatz, der mit einer Vielzahl von Technologien arbeiten kann.

Es gibt mehrere erfolgreiche Anwendungsfälle großer Branchenakteure – Netflix und AWS –, die bereits die Microservice-Architektur nutzen, um mehrere hochmoderne Dienste anzubieten. Das bedeutet, dass Microservices eine Vielzahl von Ressourcen und Gruppen zur Unterstützung von Lern- oder Reife-Microservices-Strategien haben.

Microservices eignen sich in der Regel gut für:

• Ein agiler Entwicklungsprozess
• Situationen, in denen Entwicklungsteams funktional oder geografisch verteilt sind
• Ein Minimum Viable Product (MVP) zu schaffen, das Sie funktional im Laufe der Zeit erweitern werden, nicht alles auf einmal

Vor diesem Hintergrund ist es ebenso wichtig zu beachten, dass Microservices nicht für jeden Anwendungstyp geeignet sind. Bestimmte Anwendungsfälle zeigen, dass ohne gründliche Due Diligence und effiziente Planung eine zufällige Erweiterung der Services das Framework so groß und umständlich wie eine monolithische Architektur machen kann.

(Befolgen Sie die Best Practices für Microservice von der Planung bis zur Wartung.)

Nanoservices sind deutlich neuer. Bewährte Anwendungsfälle ihres vollen Potenzials sind noch nicht entdeckt. Obwohl sie kleiner, flexibler, isolierter und funktional fokussiert sind, gibt es noch Unbekannte zu folgenden Punkten:

• Kompatibilität mit aufkommender Technologie
• Exponentielle Skalierung

Daher gibt es widersprüchliche Denkrichtungen darüber, wie und wann Microservices genutzt werden sollten.

Erstens wirft die bloße Natur von Nanoservices die Frage auf, ob sie bei umfangreicher Anwendung vor Angriffsvektoren geschützt sind.

Manche betrachten Nanoservices auch als Anti-Pattern aufgrund ihrer fragmentierten Funktionalität. Es ist bekannt, dass dies dazu führt, dass der Wartungsaufwand den Wert der Vorteile des Frameworks übersteigt.

Da Nanoservices noch in den Kinderschuhen stecken, meiden konservative und große Organisationen sie (vorerst) meist, hauptsächlich wegen der unsicheren Unterstützung für Skalierbarkeit im Framework. Für diejenigen, die es übernehmen, ist eine Best Practice zur Nutzung des Frameworks:

Vermeiden Sie Nanoservices, wenn deren Nutzung das System verkompliziert, das sie vereinfachen soll.

Bewusstes Entwerfen

Ob man sich für Nanoservices statt Microservices entscheidet oder umgekehrt, wird je nach Anwendungsfall immer unterschiedlich sein. Das Endziel bleibt jedoch dasselbe: die richtige Architektur zu wählen, die Automatisierung unterstützt und Anwendungen entwickelt, die robust, skalierbar und sicher sind.

Verwandte Literatur

• BMC DevOps Blog
• Microservices vs. Miniservices: Die Wahl des richtigen Frameworks
• Microservices vs. Serverless: Was ist der Unterschied?
• Kubernetes vs. Docker Swarm: Vergleich von Container-Orchestrierungstools, Teil unseres Kubernetes-Leitfadens
• Agile vs. Wasserfall-SDLCs: Was ist der Unterschied?
• Top-DevOps-Trends heute

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.