alt="image"/>
Wie wir schon im vorherigen Abschnitt besprochen haben, wollen wir unsere Services als End-to-End-Scheiben der Businessfunktionalität betrachten, die UI, Anwendungslogik und Datenablage sauber kapseln. Denn wir wollen den Aufwand verringern, der notwendig ist, um businessbezogene Funktionalität zu verändern. Das so vorgenommene Kapseln von Daten und Verhalten sorgt für einen engen Zusammenhalt der Businessfunktionalität. Indem wir die Datenbank verbergen, die unseren Service unterstützt, stellen wir auch sicher, dass wir Kopplungen reduzieren. Zu Kopplungen und Zusammenhalt kommen wir gleich noch mal zurück.
Es kann schwer sein, sich das verständlich zu machen, besonders wenn Sie ein bestehendes monolithisches System mit einer riesigen Datenbank vor sich haben. Zum Glück gibt es Kapitel 4, das sich nur darum dreht, von monolithischen Datenbanken wegzukommen.
Welche Vorteile können Microservices haben?
Es gibt eine ganze Reihe unterschiedlicher Vorteile von Microservices. Die unabhängige Natur der Deployments eröffnet ganz neue Modelle für das Verbessern der Größe und Robustheit von Systemen und ermöglicht es Ihnen, Technologien sehr gemischt einzusetzen. Da an Services parallel gearbeitet werden kann, können Sie mehr Entwickler an ein Problem setzen, ohne dass sie sich in die Quere kommen. Es kann für diese Entwickler auch einfacher sein, ihren Teil des Systems zu verstehen, da sie ihre Aufmerksamkeit ganz auf diesen einen Teil richten können. Prozessisolierung ermöglicht uns zudem, verschiedene Technologien zu wählen, vielleicht unterschiedliche Programmiersprachen, Programmierstile, Deployment-Plattformen oder Datenbanken zu mischen, um den richtigen Mix zu finden.
Außerdem bieten Ihnen Microservices-Architekturen vor allem Flexibilität. Sie eröffnen Ihnen so viel mehr Möglichkeiten zum Lösen zukünftiger Probleme.
Aber es ist wichtig, darauf hinzuweisen, dass all diese Vorteile ihren Preis haben. Es gibt viele Wege, Ihr System auseinanderzunehmen, und Ihre Ziele sind dabei entscheidend dafür, wie Sie das umsetzen. Daher ist es wichtig, zu verstehen, was Sie mit Ihrer Microservices-Architektur erreichen wollen.
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.
Benutzeroberflächen
Allzu häufig sehe ich, dass sich Menschen bei ihrer Arbeit darauf konzentrieren, Microservices rein auf der Serverseite anzuwenden – und die Benutzeroberfläche als eine einzelne monolithische Schicht zu belassen. Wollen wir eine Architektur haben, die es uns erleichtert, neue Features schneller zu deployen, kann es ein großer Fehler sein, das UI als monolithischen Klumpen zu belassen. Wir können – und sollten – auch unsere Benutzeroberflächen aufbrechen. Darum kümmern wir uns in Kapitel 3.
Technologie
Es kann verlockend sein, sich haufenweise neue Technologien zu schnappen und sie zusammen mit Ihrer schicken neuen Microservices-Architektur einzusetzen, aber ich empfehle Ihnen dringend, dieser Verlockung zu widerstehen. Es kostet immer etwas, neue Technologien einzusetzen – sie führen zu Umbruch und Unruhe. Hoffentlich ist es das wert (wenn Sie die richtige Technologie eingesetzt haben, ist es das mit Sicherheit!), aber wenn Sie eine Microservices-Architektur das erste Mal übernehmen, haben Sie auch so schon genug zu tun.
Um herauszufinden, wie Sie eine Microservices-Architektur sauber entwickeln und betreuen, müssen Sie eine Vielzahl an Herausforderungen rund um verteilte Systeme meistern – Herausforderungen, denen Sie zuvor vielleicht noch nie begegnet sind. Ich denke, es ist viel sinnvoller, sich damit zu befassen, wenn Sie auf sie stoßen, während Sie einen Technologie-Stack einsetzen, der Ihnen vertraut ist. Dann können Sie sich immer noch Gedanken darüber machen, ob es sinnvoll ist, Ihre bestehende Technologie auszutauschen, um die Probleme zu lösen.
Wie wir schon erkannt haben, sind Microservices im Prinzip technologieagnostisch. Solange Ihre Services miteinander über ein Netzwerk kommunizieren können, ist der Rest nicht so