Als Microservices entwickelte Software kann, per Definition, in mehrere Komponentendienste aufgeteilt werden. Warum? Damit jeder dieser Dienste unabhängig ausgeliefert, optimiert und dann erneut ausgeliefert werden kann, ohne die Integrität einer Anwendung zu kompromittieren. Als Ergebnis hieraus müssen Sie gegebenenfalls nur einen oder mehrere bestimmte Dienstprogramme ändern, anstatt gesamte Anwendungen neu auszuliefern. Aber dieser Ansatz hat seine Nachteile, einschließlich vieler Remote-Aufrufe (anstelle von Aufrufen im selben Prozess), gröberer Remote-APIs und erhöhter Komplexität bei der Neuverteilung von Aufgaben zwischen Komponenten.

Der Microservices-Stil ist üblicherweise rund um geschäftliche Funktionen und Prioritäten organisiert. Anders als ein traditioneller, monolithischer Entwicklungsansatz – bei dem verschiedene Teams sich jeweils auf ein Gebiet konzentrieren, z. B. GUI, Datenbanken, Technologieebenen oder serverseitige Logik – nutzt die Microservice-Architektur funktionsübergreifende Teams. Die Verantwortungen jedes Teams sind es, bestimmte Produkte basierend auf einem oder mehreren individuellen Diensten zu erstellen, die über den Messaging-Bus kommunizieren. Bei Microservices ist ein Team für die Lebenszeit seines Produktes für es verantwortlich, wie in Amazon’s zitiertem Leispruch: “Du entwickelst es, du betreibst es.

Microservices agieren in etwa so wie das klassische UNIX-System: sie empfangen Anfragen, verarbeiten sie und generieren eine entsprechende Antwort. Dies ist das Gegenteil davon, wie viele andere Produkte wie etwa ESBs (Enterprise Service Buses) arbeiten, bei denen High-Tech-Systeme für das Message-Routing, die Choreographie und die Anwendung von Geschäftsregeln eingesetzt werden. Man könnte sagen, dass Microservices über intelligente Endpunkte verfügen, die Informationen verarbeiten und Logik darauf anwenden, sowie über dumme Leitungen, durch welche die Informationen fließen.

Da Microservices eine Vielzahl von Technologien und Plattformen miteinschließen, sind traditionelle Methoden der zentralen Überwachung nicht ideal. Die Microservices-Community bevorzugt eine dezentrale Überwachung, da ihre Entwickler danach streben, nützliche Tools zu produzieren, die dann von anderen für die Lösung derselben Probleme eingesetzt werden können. Genau wie eine dezentrale Überwachung bevorzugt die Microservice-Architektur auch eine dezentrale Datenverwaltung. Monolithische Systeme verwenden eine einzige logische Datenbank in mehreren Anwendungen. In einer Microservice-Anwendung verwaltet üblicherweise jedes Dienstprogramm seine eigene Datenbank.

Wie ein gut ausgebildetes Kind sollen auch Microservices mit Fehlern klarkommen können. Da mehrere einzigartige und unterschiedliche Dienste miteinander kommunizieren, ist es durchaus möglich, dass aus dem einen oder anderen Grund ein Dienst ausfällt (z. B. wenn der Lieferant nicht verfügbar ist). In diesen Fällen sollte der Client es seinen benachbarten Diensten ermöglichen, weiterhin zu funktionieren, während er sich so elegant wie möglich zurückzieht. Allerdings kann die Überwachung von Microservices das Risiko von Fehlern verringern. Aus naheliegenden Gründen fügt diese Anforderung im Vergleich zu monolithischen Systemarchitekturen mehr Komplexität zu Microservices hinzu.

Die Microservices-Architektur ist ein evolutionäres Design und, noch einmal, eignet sich ideal für evolutionäre Systeme, bei denen Sie die Art der Geräte nicht vollständig voraussehen können, die eines Tages vielleicht auf Ihre Anwendung zugreift. Viele Anwendungen beginnen auf Basis einer monolithischen Architektur, können aber, während verschiedene unvorhergesehene Anforderungen auftauchen, langsam in Microservices verwandelt werden, die über eine ältere monolithische Architektur hinweg per APIs kommunizieren.