Mainstream-Microservices-Manie: Mit der Einführung nehmen die Herausforderungen zu
Noch vor wenigen Jahren waren Microservices eine Kuriosität, über die Entwickler mit einer Art ausgelassener Aufregung angesichts der Möglichkeiten und Chancen diskutierten, die die junge App-Architektur bot.
Heute reden sogar wir Netzwerker darüber, weil sie – wie die neueste Studie von Lightstep zeigt – in Unternehmen so ziemlich zum Mainstream geworden sind. Ernsthaft. In unserem Bericht „State of Application Delivery“ von 2018 gaben sogar netzwerkbezogene Rollen an, dass sie die Bereitstellung von Anwendungsdiensten in Containern wünschten. Daher dürfte es nicht überraschen, dass die oben erwähnte Lightstep-Umfrage ergab, dass nicht nur 91 % der Befragten Microservices verwenden oder dies planen, sondern dass 86 % auch erwarten, dass sie innerhalb von fünf Jahren zum Standard gehören werden.
Das heißt jedoch nicht, dass es keine Herausforderungen gibt. Tatsächlich berichteten 99 % der Teilnehmer der Umfrage von Lightstep von Herausforderungen bei der Verwendung von Microservices. Aus den Antworten lässt sich schließen, dass mit Microservices so ziemlich alles schwieriger (und manchmal auch teurer) ist.
In der Umfrage wurden sowohl geschäftliche als auch betriebliche Herausforderungen festgestellt, die von steigenden Kosten für die Protokollaggregation (21 %) über die Ungewissheit, was mit der Datenzunahme zu tun ist (17 %), bis hin zu Schwierigkeiten bei der Fehlerbehebung (73 %) reichten.
Beunruhigender war jedoch die Feststellung, dass „98 % derjenigen, die Schwierigkeiten haben, die Grundursache von Problemen in Microservices-Umgebungen zu ermitteln, berichten, dass dies direkte Auswirkungen auf das Geschäft hat.“
Dies ist eine der wichtigsten Herausforderungen, die auch anderswo wieder aufgegriffen wird. Normalerweise wird dabei der Begriff „Sichtbarkeit“ oder „Beobachtbarkeit“ verwendet, je nachdem, ob Sie auf der Netzwerkseite stehen oder mit DevOps zu tun haben.
Beide beschreiben im Wesentlichen dieselben Fähigkeiten – die Möglichkeit zu sehen, was passiert, während Nachrichten das Netzwerk vom Client zum Dienst und zurück durchlaufen. Innerhalb einer Containerumgebung stellt dies aufgrund des Umfangs und der Größenordnung der beteiligten Dienste eine besondere Herausforderung dar.
Bei einer herkömmlichen dreistufigen Web-App haben Sie drei Protokollsätze und drei Systeme, die Sie verfolgen müssen. Bei einer Microservices-Architektur – der wahrscheinlich eine API zugrunde liegt, die sowohl von Web- als auch von Mobilclients verwendet werden kann – müssen Sie möglicherweise Dutzende oder Hunderte verschiedener Dienste im Auge behalten.
Das Skalierungsmodell ist immer noch dasselbe – wir skalieren horizontal (nach außen) mit Klonen – aber der Umfang innerhalb einer Containerumgebung ist wesentlich größer. Es ist, als würde man „Maulwurf schlagen“ mit hundert statt zehn Löchern spielen. Den Weg einer bestimmten Transaktion herauszufinden, wird, gelinde gesagt, eine Herausforderung sein. Insbesondere dann, wenn der Weg möglicherweise verschwunden ist. Schließlich besteht die Prämisse der meisten Containerumgebungen darin, schnell auszufallen und Instanzen zu ersetzen, anstatt auf manuelle Eingriffe zu warten.
Es gibt mehrere Möglichkeiten, diese Herausforderung zu bewältigen. An erster Stelle steht die Instrumentierung, die bei der Verfolgung und Fehlerbehebung hilft. Dieser Ansatz ist nicht neu, wird jedoch durch die volatile Natur von Containerumgebungen schwieriger. Dennoch kann das Einfügen von Tracing-Elementen (wie etwa benutzerdefinierte HTTP-Header mit eindeutigen Kennungen) für den Betrieb von großem Nutzen sein, wenn es darum geht, Fehler oder Leistungsprobleme aufzuspüren. Obwohl dies normalerweise keine Funktion nativer Container-Skalierungsoptionen ist, wird sie von Service-Meshes als Teil ihres Angebots berücksichtigt .
Zweitens besteht die Möglichkeit, fehlerhafte Microservices unter Quarantäne zu stellen, damit Betrieb und Entwicklung das System in dem Zustand untersuchen können, der den Fehler verursacht hat. Durch die Quarantäne wird der fehlerhafte Container grundsätzlich aus der aktiven Umgebung entfernt, sodass keine Anrufe mehr an ihn gesendet werden, er bleibt jedoch für die Analyse und Überprüfung am Leben.
Es gibt dafür keinen Zauberstab, aber die Fähigkeit, Container in auf Microservices basierenden Bereitstellungen zu verfolgen und unter Quarantäne zu stellen, kann dazu beitragen, die durchschnittliche Zeit bis zur Problemlösung (MTTR) zu verkürzen und die Auswirkungen auf das Geschäft zu verringern.