Читать книгу Vom Monolithen zu Microservices - Sam Newman - Страница 13
Welche Probleme werden entstehen?
ОглавлениеServiceorientierte Architekturen wurden unter anderem deshalb so beliebt, weil Computer billiger wurden und wir mehr davon hatten. Statt Systeme auf einzelnen, riesigen Mainframes zu deployen, war es sinnvoll, mehrere billigere Maschinen einzusetzen. Serviceorientierte Architekturen waren ein Versuch, herauszufinden, wie sich Anwendungen am besten bauen lassen, die über mehrere Maschinen verteilt sind. Eine der größten Herausforderungen ist dabei der Weg, auf dem diese Computer miteinander reden: die Netzwerke.
Die Kommunikation zwischen Computern über Netzwerke geschieht nicht instantan (das hat offensichtlich etwas mit Physik zu tun). Wir müssen uns also mit Latenzen befassen – insbesondere mit Latenzen, die weit über das hinausgehen, was wir bei lokalen In-Process-Operationen gewohnt sind. Es wird noch schlimmer, wenn wir daran denken, dass diese Latenzen variieren können, wodurch das Systemverhalten unvorhersagbar werden kann. Und wir müssen berücksichtigen, dass Netzwerke manchmal fehlerhaft sein können – Pakete gehen verloren, Netzwerkkabel werden abgezogen und so weiter.
Diese Herausforderungen sorgen dafür, dass Aktivitäten viel schwieriger werden können, die bei einem Monolithen mit jeweils einem Prozess recht einfach sind – wie zum Beispiel Transaktionen –, und zwar so schwierig, dass Sie Transaktionen (und deren Sicherheit) mit wachsender Komplexität Ihres Systems vermutlich irgendwann hinauswerfen müssen, um auf andere Techniken umzusteigen (die leider wieder ganz andere Nachteile besitzen).
Darüber nachzudenken, dass jedes Netzwerk fehlerhaft agieren kann und wird, dass der Service, mit dem Sie kommunizieren, aus irgendwelchen Gründen offline gehen oder dass er sich komisch verhalten kann, wird Ihnen Kopfschmerzen bereiten. Außerdem müssen Sie sich darüber im Klaren werden, wie Sie eine konsistente Sichtweise auf Daten erhalten, die auf mehrere Maschinen verteilt sind.
Und dann haben wir natürlich noch ein ganzes Füllhorn an neuen Microservices-orientierten Technologien zu berücksichtigen – neuen Technologien, die, falsch eingesetzt, dazu führen können, dass Sie viel schneller viel interessantere, teurere Fehler machen. Ehrlich gesagt, scheinen Microservices eine echt dumme Idee zu sein – wären da nicht die ganzen Vorteile.
Es sei darauf hingewiesen, dass so gut wie alle Systeme, die wir als »Monolithen« betrachten, ebenfalls verteilte Systeme sind. Eine Ein-Prozess-Anwendung liest sehr wahrscheinlich Daten aus einer Datenbank, die auf einem anderen Rechner läuft, und übergibt Daten an einen Webbrowser. Das sind schon mindestens drei Rechner, die untereinander über das Netzwerk kommunizieren. Der Unterschied liegt darin, in welchem Umfang monolithische Systeme im Vergleich zu Microservices-Architekturen verteilt sind. Wenn Sie mehr Computer in diesem Spiel im Einsatz haben und mehr Kommunikation über mehr Netzwerke stattfindet, werden Sie auch eher schon auf die unerfreulichen Probleme stoßen, die mit verteilten Systemen verbunden sind. Diese schon kurz angerissenen Probleme müssen nicht sofort auftauchen, aber mit der Zeit (und einem wachsenden System) werden Sie vermutlich über die meisten, wenn nicht alle, stolpern.
Wie mein früherer Kollege, Freund, Gefährte und Microservices-Experte James Lewis gesagt hat: »Microservices erkaufen Ihnen Möglichkeiten.« James hat seine Worte bewusst gewählt – sie erkaufen Ihnen Möglichkeiten. Es gibt Microservices nicht umsonst, und Sie müssen entscheiden, ob die Möglichkeiten die Kosten wert sind. Dieses Thema werden wir detaillierter in Kapitel 2 angehen.