Читать книгу Spring Boot - Mark Heckler - Страница 29

Das Zeitalter der monolithischen Anwendung, die alles macht, ist vorüber.

Das soll nicht heißen, dass Monolithen nicht mehr existieren oder nicht mehr entwickelt werden. Unter bestimmten Umständen ist eine monolithische Anwendung, die zahlreiche Funktionen in einem Paket vereint, immer noch sinnvoll, vor allem in folgenden Szenarien:

 Die Domäne und damit die Domänengrenzen sind größtenteils unbekannt.

 Die angebotenen Funktionen sind eng miteinander verkoppelt, und die Gesamtleistung der Modulinteraktionen ist wichtiger als Flexibilität.

 Skalierungsanforderungen für alle verbundenen Funktionen sind bekannt und konsistent.

 Die Funktionalität ist nicht unberechenbar, Änderungen sind langsam, im Umfang begrenzt oder beides.

Für alles andere gibt es Microservices.

Das ist natürlich grob vereinfacht gesagt, aber dennoch halte ich es für eine sinnvolle Zusammenfassung der Tatsachen. Durch das Aufteilen der Funktionen in kleinere, zusammenhängende »Brocken« können wir sie entkoppeln, wodurch sich potenziell flexiblere und robustere Systeme ergeben, die schneller ausgeliefert und einfacher gepflegt werden können.

In jedem verteilten System – und täuschen Sie sich nicht, ein System, das aus Microservices besteht, ist nichts anderes als das – ist die Kommunikation entscheidend. Kein Dienst ist eine Insel. Und auch wenn es zahllose Mechanismen zum Verbinden von Anwendungen/Microservices gibt, beginnen wir unsere Reise oft damit, dass wir das Grundgerüst unseres Alltags nachahmen: das Internet.

Das Internet wurde für die Kommunikation geschaffen. Um genau zu sein, planten die Entwickler seines Vorgängers, des ARPANET (Advanced Research Projects Agency Network), sogar die Notwendigkeit ein, eine systemübergreifende Kommunikation auch im Falle »erheblicher Störungen« aufrechtzuerhalten. Es ist daher vernünftig, anzunehmen, dass ein HTTP-basiertes Vorgehen ähnlich dem, das wir praktisch tagtäglich verwenden, uns auch erlauben dürfte, verschiedene Ressourcen »über die Leitung« zu erzeugen, abzurufen, zu aktualisieren und zu löschen.

So sehr ich auch Geschichte mag, ich werde nicht weiter auf die Geschichte der REST-APIs eingehen. Nur so viel: Roy Fielding beschrieb ihre Prinzipien im Jahre 2000 in seiner PhD-Dissertation, die auf dem HTTP-Objektmodell von 1994 aufbaute.