Herausforderungen von Microservices und wann man sie vermeiden sollte

Die Microservices-Architektur – eine Variante der Service-Oriented Architecture (SOA) – ist ein weiterentwickelter Entwicklungsansatz, der aus der Welt des domänenorientierten Designs hervorgegangen ist und die:

• Ermöglicht effizientes Rechnen
• Hilft beim Aufbau widerstandsfähiger Anwendungen

Wie bei jedem Ansatz zur Anwendungsentwicklung hat die Microservices-Architektur jedoch ihre eigenen Herausforderungen. Es gibt auch Anwendungsfälle, in denen Organisationen eine erhöhte Komplexität und einen erhöhten Aufwand bei der Entwicklung von Anwendungen mit einem Microservice-Framework feststellen. Dieser Artikel behandelt solche Herausforderungen, einschließlich der Frage, wann Sie Microservices nicht nutzen sollten. Schauen wir uns das an.

Überblick über Microservices

Ein Microservices-Ansatz bedeutet, eine Anwendung als eine Gruppe locker gekoppelter Services zu entwerfen und zu entwickeln, die miteinander kommunizieren, um ein erklärtes Geschäftsziel zu erreichen. Ein steigendes Muster einer breiteren Akzeptanzrate bestätigt, dass es mehrere Anwendungsfälle gibt, in denen Unternehmen von der Nutzung von Microservices zur Entwicklung und Bereitstellung von Anwendungen profitieren. Schließlich werden Microservices oft als erster Schritt zur Umarmung einer DevOps-Kultur betrachtet, die ermöglicht:

• Automatisierung
• Verbesserte Skalierbarkeit
• Handhabbarkeit
• Agilität
• Schnellere Lieferung und Bereitstellung

Aus demselben Grund ist eine Microservice-Architektur in der Regel die erste Wahl für Unternehmen, die Legacy-Anwendungen für moderne Programmiersprachen und Technologie-Stacks umschreiben möchten. Bei all diesen Vorteilen fragen Sie sich vielleicht, welche Herausforderungen es geben könnte.

Herausforderungen von Microservices-Architekturen

Kommen wir nun zu den häufigsten Herausforderungen von Unternehmen oder Produktteams, die Microservices einführen.

Konstruktion

Im Vergleich zu monolithischen Anwendungen haben Organisationen eine erhöhte Komplexität bei der Gestaltung von Microservices. Bei der ersten Nutzung von Microservices könnte es schwierig sein, Folgendes zu bestimmen:

• Die Größe jedes Microservices
• Optimale Grenzen und Verbindungspunkte zwischen jedem Mikroservice
• Das Rahmenwerk zur Integration von Dienstleistungen

Das Design von Microservices erfordert die Erstellung dieser Aufgaben innerhalb eines begrenzten Kontexts. Daher sollte jeder Microservice eine spezifische Verantwortung klären, kapseln und definieren. Um dies für jede Verantwortung/Funktion zu erreichen, verwenden Entwickler bei der Modellierung einer Domäne meist eine datenzentrierte Sichtweise. Dieser Ansatz stellt eine eigene Herausforderung mit sich – ohne Logik sind die Daten unsinnig.

Sicherheit

Microservices werden häufig in Multi-Cloud-Umgebungen bereitgestellt, was zu einem erhöhten Risiko sowie dem Verlust von Kontrolle und Sichtbarkeit der Anwendungskomponenten führt – was zusätzliche Verwundbarkeitspunkte mit sich bringt. Zusätzlich kommt hinzu, dass jeder Microservice über verschiedene Infrastrukturschichten mit anderen kommuniziert, was es noch schwieriger macht, diese Schwachstellen zu testen.

Datensicherheit innerhalb eines microservices-basierten Rahmens ist ebenfalls ein zentrales Anliegen. Daher bleiben die Daten innerhalb eines solchen Rahmens verteilt, was es schwierig macht, die Vertraulichkeit, Integrität und Privatsphäre der Nutzerdaten zu wahren. Aufgrund des verteilten Rahmens stellt die Einrichtung von Zugriffskontrollen und die Verwaltung gesicherter Authentifizierung einzelner Dienste nicht nur eine technische Herausforderung dar, sondern erhöht auch die Angriffsfläche erheblich.

Tests

Die Testphase eines Softwareentwicklungslebenszyklus (SDLC) ist für microservices-basierte Anwendungen zunehmend komplex. Angesichts der eigenständigen Natur jedes Microservices muss man einzelne Services unabhängig testen. Um diese Komplexität zu verschärfen, müssen Entwicklungsteams auch die Integration von Services und deren Wechselwirkungen in Testpläne berücksichtigen.

Erhöhte operative Komplexität

Das Team jedes Microservices ist in der Regel damit beauftragt, die zu verwendende Technologie zu entscheiden und zu verwalten. Da jeder Service unabhängig eingesetzt und betrieben werden sollte, kann die Aufrechterhaltung der Betriebsabläufe für diejenigen, die nicht vorbereitet sind, eine Büchse der Pandora öffnen. Hier sind einige Herausforderungen:

1. Traditionelle Überwachungsformen funktionieren möglicherweise nicht für eine microservices-basierte Anwendung. Betrachten Sie ein Szenario, in dem eine Anfrage von der Benutzeroberfläche mehrere Dienste durchläuft, bevor sie zu dem Dienst gelangt, der die Anfrage erfüllen kann. Das Ergebnis dieser Durchquerung ist ein komplizierter Dienstpfad, und ohne geeignete Überwachungstools ist es nicht nur schwierig, die zugrunde liegende Ursache eines Problems zu identifizieren – sie ist oft auch unmöglich.
2. Skalierbarkeit ist eine weitere operative Herausforderung im Zusammenhang mit der Microservices-Architektur. Obwohl die Skalierbarkeit von Microservices oft als Vorteil gepriesen wird, ist es eine Herausforderung, Ihre microservice-basierten Anwendungen erfolgreich zu skalieren.
3. Optimierung und Skalierung erfordern eine komplexere Koordination. In einem typischen Microservices-Framework wird eine Anwendung in kleinere, unabhängige Dienste aufgeteilt, die auf separaten Servern gehostet und bereitgestellt werden. Diese Architektur erfordert die Koordination einzelner Komponenten, was eine weitere Herausforderung darstellt, besonders wenn man einen plötzlichen Anstieg der Anwendungsnutzung erlebt.
4. Fehlertoleranz ist für jeden Dienst erforderlich. Unternehmen müssen ihre Microservices robust genug haben, um interne und externe Ausfälle zu überstehen. In einer microservices-basierten Anwendung kann ein Ausfall einer Komponente das gesamte System beeinflussen. Daher sollte das von Ihnen verwendete Framework die Fehlertoleranz für jeden Dienst berücksichtigen, um ein Design zu gewährleisten, das einen Ausfall einer gesamten Anwendung im Falle eines einzelnen Service-Ausfalls verhindert.

Kommunikation

Unabhängig bereitgestellte Microservices fungieren als kleine, eigenständige Anwendungen, die miteinander kommunizieren. Um dies zu erreichen, müssen Sie Infrastrukturschichten konfigurieren, die eine Ressourcenteilung zwischen Diensten ermöglichen. Eine schlechte Konfiguration kann dazu führen:

• Erhöhte Latenz
• Reduzierte Geschwindigkeit der Anrufe zwischen verschiedenen Diensten

In dieser Situation haben Sie eine nicht optimierte Anwendung mit langsamer Reaktionszeit.

Wann man Microservices nicht nutzen sollte

Jede Organisation, die auf ein neues Framework umsteigt, sollte gründliche Sorgfaltspflicht durchführen, um sicherzustellen, dass es die richtige Wahl ist. Bei der Erkundung von Microservices helfen Ihnen diese drei Situationen immer dabei, zu entscheiden, wann Sie die Microservice-Architektur für Ihre gewählte Anwendung überspringen sollten.

Dein definiertes Domain ist unklar/unsicher

Denken Sie daran, dass Sie Microservices innerhalb eines begrenzten Kontexts erstellen. Wenn es daher logisch komplex ist, Ihre Geschäftsanforderungen in spezifische Domänen zu unterteilen, wird es ebenso schwierig sein, ausreichend große Microservices zu erstellen. Hinzu kommt die Herausforderung, ein angemessenes Kommunikationsmittel zwischen verschiedenen Diensten zu entwerfen – diese Komplexität ist wahrscheinlich zu groß, um den maximalen Nutzen aus Microservices zu erzielen. Denken Sie auch an die Zukunft. Wenn Sie sich nicht sicher sind, dass die Domain Ihrer Anwendung in den kommenden Jahren gleich bleiben wird, ist es ratsam, keinen microservices-orientierten Ansatz zu verwenden.

Eine verbesserte Effizienz ist nicht garantiert

Zur Wiederholung: Die Idee der Einführung von Microservices besteht darin, eine DevOps-Kultur zu übernehmen, die wiederum:

• Setzt Automatisierung ein
• Reduziert Kosten und Aufwand
• Bringt operative Effizienz

Führen Sie Ihre Due Diligence durch, um zu überprüfen, ob der Übergang zu einem Microservices-Framework tatsächlich hilft, diese Ziele zu erreichen. Kein Unternehmen möchte Komplexität und Aufwand aufbringen, nur um eine Unternehmenskultur zu übernehmen, ohne dabei mehr Effizienz zu erzielen.

Die Anwendungsgröße ist klein oder unkomplex

Wenn Ihre Anwendungsgröße es nicht rechtfertigt, sie in viele kleinere Komponenten aufzuteilen, ist die Verwendung eines Microservices-Frameworks möglicherweise nicht ideal. Es besteht keine Notwendigkeit, Anwendungen weiter zu zerlegen, die ohnehin schon klein genug sind. Denken Sie daran, dass die Idee eines Microservices-Frameworks darin besteht, eine komplexe Anwendung in eine Reihe verschiedener, kleinerer Services zu unterteilen. Wenn ein Anwendungscode bereits klein und unkompliziert – nicht komplex – ist, wird der Umstieg auf ein Microservice-Framework nur noch komplexer werden.

Sind Microservices das Richtige für mich?

Während die Einführung einer Microservice-Architektur eine schnellere Bereitstellung und eine verbesserte Softwarequalität bietet, sollten Unternehmen sorgfältig abwägen, ob sie sich für diesen Ansatz entscheiden. Die Vorteile des Übergangs von einem monolithischen zu einem Microservices-Modell sind zahlreich – aber es gibt dennoch Herausforderungen zu bedenken. Die allgemeine Faustregel für die Wahl von Microservices:

Wenn die Nachteile der Nutzung von Microservices die Vorteile überwiegen und/oder die Vorteile im Vergleich zum Aufwand und Geld vernachlässigbar sind, sind Microservices wahrscheinlich nicht der richtige Ansatz für die Anwendung.

Verwandte Literatur

• BMC DevOps Blog
• Die Rolle der Microservices in DevOps, Teil unseres DevOps-Leitfadens
• 15 Best Practices für den Aufbau einer Microservices-Architektur
• Was ist SOA? Serviceorientierte Architektur erklärt
• Was ist verhaltensgetriebene Entwicklung (BDD)?
• Docker-Überwachung: Wie man Container und Microservices überwacht

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