Microservices

Gegen Monolithen, für geringere Softwarekomplexität und einfachere Wartung

Microservices sind dadurch gekennzeichnet, dass jeder Service im Detail betrachtet einen mehr oder weniger isolierten Bereich einer Anwendung abbildet. Mittels Domain Driven Design richtig konzeptionell entworfen, ist die umzusetzende Fachlichkeit regelmäßig leicht verständlich und zu beherrschen. Das Wesen von Microservices besteht darin, dass sie als einzelne Services besser handhabbarer sind als monolithische Software. Im Idealfall können Microservices unabhängig voneinander erweitert, ausgetauscht und skaliert werden und Anwendungen funktionieren auch dann noch, wenn einzelne der Services nicht verfügbar sind. Sie bilden die fachlichen Blöcke einer Anwendung, statt alles aus „einem (schwer veränderlichen) Guss“ zu erstellen.

Die besondere Herausforderung für Microservice-Architekturen liegt dabei darin, die Services so zuzuschneiden, dass sie fachlich möglichst unabhängig voneinander sind. Ein Microservice bildet im Regelfall eine geschlossene Fachlichkeit, den Bounded Context, ab. Anders gesagt hat sich die Unterscheidung nach Anwendungsfällen und nicht nach Domänen-Entitäten bewährt. Für die Kommunikation der Microservices stehen Entwurfsmuster wie Tolerant Reader, Semantic Versioning und Consumer-Driven Contract zur Verfügung und helfen, die Schnittstellen über lange Zeit kompatibel zu halten. Zur verteilten Datenhaltung und Datenkonsistenz stellen gelockerte Konsistenzregeln wie BASE und die damit verbundene Eventual Consistency in Verbindung mit Datenreplikationen, Event-Mechanismen und einem geschickten Daten-Caching innerhalb der Microservices gangbare Lösungen dar.

Identifikation einer Domäne bzw. Subdomäne

  • Conway’s Law, Bounded Context und Ubiquitous Language
  • Grundlagen und Domain Driven Design in Bezug zu Microservices
  • Pro & Contra von Microservice-Architekturen
  • Was beim „Schneiden“ von Domains generell zu beachten ist
  • Verschiedene Microservices, die auf gleichen oder ähnlichen Daten (aber mit unterschiedlichen Zielsetzungen) operieren

Aufteilung von Microservices

  • Logische Aufteilung von bestehenden Applikationen in Microservices
  • Datenbankdesign in der Microservice-Umgebung (intern in Microservices oder extern in eigenem Datenbank-Cluster)
  • Caches zur Sicherstellung von App-States im Cluster (anhand von Protokolle wie Raft, Gossip vs. Replication
  • Tools für Bootstrapping von Caches und oder Containern (IP-Adressierung, Port-Adressierung bei unbekannter Anzahl von Hosts zur Laufzeit (dynamische Lastskalierung)
  • Credential-Storages in Microservices
  • Configuration-Storages in Microservices
  • Dynamische Lastskalierung außerhalb von Kubernetes mit anderen Tools wie nomad

Microservices im Fokus – technologieunabhängige Konzepte

Mittels Microservice-Architekturen können Anwendungen vergleichsweise zur normalen Entwicklung schneller neu entwickelt und bestehende Anwendungssysteme kontinuierlich erweitert werden, ohne „Release Big Bang“. Der richtige fachliche Schnitt erlaubt schnelleres Feedback vom Anwender und Methoden der Modularisierung beim Deployment eine flexible Release-Infrastruktur bis hin zu (Micro-)Service Level Agreements.

Eine Benutzeroberfläche kann z. B. so geschnitten werden, dass sie aus UI-Fragmenten der einzelnen Microservices besteht oder aber als „en bloc“, wobei bei letzterem API-Gateways die Daten für die Aufbereitung der UI bereitstellen. Eine weitere Möglichkeit wäre die Kombination dieser zwei Ansätze.

  • Conway’s Law, Bounded Context und Ubiquitous Language
  • HTTP als „First Class Citizen“ & 12-Factor Apps
  • Runtime-Registry und Service Discovery
  • Integration-Pattern für verteilte Anwendungen (darunter API-Gateway, GraphQL, Composite-UI, Messaging)
  • Consumer-Driven-Contracts, Versionierung, Dokumentation
  • Event-driven / Reactive Microservices via RabbitMQ, HTTP, HTTP/2 bzw. asynchrone Kommunikation zwischen Microservices mit RabbitMQ
  • Backing Services, Data-Integration und –Aggregation
  • Infrastruktur und Tools in Microservice-Architekturen mit Docker
  • Konfiguration, Deployment und Betrieb von Microservices mit Docker
  • Continuous Delivery von Microservices
  • Verfügbarkeit, Stabilität und Skalierung von Microservices
  • Monitoring und SLAs für Microservices im Betrieb

Praktische Umsetzung

Unsere Veranstaltungsorte von dieser / diesem Schulung, Training, Seminar, Kurs (nach oben): Berlin, Dresden, Frankfurt am Main, Hamburg, Hannover, Karlsruhe, Köln, Leipzig, Magdeburg, München, Stuttgart und Inhouse.

Fortbildung oder Weiterbildung zu Microservices – wir setzen nur auf erfahrene Talente als Microservices Trainer. Das Credo von Mike Bild lautet „Stück für Stück zu etwas Großem. Das ist für mich emergentes Design“. Mehr zu ihm und den Beweggründen unserer anderen Trainer erfahren Sie bei seiner Biographie (direkt erreichbar per Bild).

Nach oben