Die gute Nachricht vorweg: Einen einzelnen Microservice zu implementieren ist dank Bounded Context, loser Kopplung und klar definierter Kommunikationsschnittstellen denkbar einfach. Nur leider macht ein Frühling noch keinen Sommer und ein einzelner Microservice noch lange keine sinnvolle Anwendung aus! Um am Ende nicht im Chaos zu versinken, benötigt auch eine Microservices-basierte Anwendung eine Architektur und die Verwendung von Patterns. Wie zum Beispiel stellt man die Evolution von Schnittstellen sicher? Oder wie soll die UI eingebunden werden? Welche Aufgaben übernimmt ein API Gateway und wird es überhaupt benötigt? Sollten Microservices synchron oder asynchron kommunizieren? Oder gar beides? Fragen über Fragen, deren Klärung über Erfolg oder Misserfolg der eigenen Anwendung entscheiden kann. Der Workshop gibt einen Einblick in die verschiedenen Herausforderungen bei der Umsetzung einer Microservices-basierten Anwendung und diskutiert verschiedene Lösungsansätze, Patterns und Best Practices. Ein optimaler Einstieg in den Microservices-Summit.
3. #WISSENTEILEN
ÜBER MICH
Wer bin ich - und wenn ja, wie viele?
• CIO New Technologies
• Enterprise & Mobile
• Autor, Speaker, Coach & Mentor
• Snowboard & MTB Enthusiast (a.k.a. “stets bemüht“)
Lars Röwekamp (a.k.a. @mobileLarson)
LR
7. #WISSENTEILEN
Wie groß ist klein
„A microservices ecosystem (ME) is a platform of
services each encapsulating a business capability.
Developers can build, test and release each
microservice independently.
ME enforces an organizational structure of
autonomous long standing teams, each
responsible for one or multiple services.“
(Zhamak Dehghani, ThoughtWorks)
32. #WISSENTEILEN
„Wie kommunizieren
Services untereinander?“
„Wer oder was ist
für die UI zuständig?“
„Wie gehen wir mit Cross-Cutting
Themen wie Logging, Tracing,
Profiling oder Security um?“
„Database per Service Pattern,
wie soll das bitte gehen?“
„Und welche Bedeutung spielt
die Versionierung der Services
und ihrer Schnittstellen?“
36. #WISSENTEILEN
Communication via REST
• Ressourcen basiert
• eindeutige Identifikation via URI
• State Transfer via HTTP Methoden
• Caching via ETag, Last-Modified, …
• Request/Response Modell
• synchrone Kommunikation
37. #WISSENTEILEN
RESTful Step 1: Create order
A: POST /orders/ {order}
B: CREATED 201
Location /orders/123
Step 2: Update order
A: PUT /orders/123 {order}
B: OK 200 {order}
38. #WISSENTEILEN
Communication via REST
HTTP Methoden korrekt verwendet:
POST „creates a child resource at a server
defined URL“
PUT „creates/replaces the resource as a
whole at the client defined URL“
PATCH „updates part of the resource at that
client defined URL“
40. #WISSENTEILEN
Communication via REST
HTTP Methoden korrekt verwendet:
SAFE
„No changes to resources at all*“
IDEMPOTENT
„No changes to resources when called repeatedly**“
*GET, HEAD, OPTIONS
** GET, HEAD, OPTIONS, PUT, DELETE
50. #WISSENTEILEN
Communication via Messaging
• Messages zur Kommunikation
• lose Kopplung durch Queues & Topics
• ein Sender, 0 bis N Receiver
• asynchrone Kommunikation
• garantierte Auslieferung möglich
103. #WISSENTEILEN
Plan B: Lazy Evaluation
a.k.a. die „es wird schon gutgehen“ Strategie
• TX fachlich aufsplitten, sequentiell
durchführen und schauen, ob es klappt
• im Problemfall alternative Logik ausführen
124. #WISSENTEILEN
Geänderte Servicegrenzen
• technologisch eine super Lösung, aber …
• Problem der Verantwortlichkeiten
• Problem Bounded Context / Domänen Modell
• Vorteile der Microservices gehen verloren
• „Big Ball of Mud“ lässt grüßen
128. #WISSENTEILEN
Verteilte Transaktionen via XA
• aus Developer-Sicht wie lokale TX, aber …
• Verlust der losen Kopplung, da synchrone IPC
• kein Support durch „moderne Plattformen“*
* Cloud-Komponenten, noSQL, MQs
133. #WISSENTEILEN
Verteilte Transaktionen via SAGAs
SAGA Idee:
Abbilden einer verteilten fachlichen
Transaktion durch eine Abfolge lokaler
Transitionen / Transaktionen
135. #WISSENTEILEN
Verteilte Transaktionen via SAGAs
• Konsistenz von Daten zwischen Services
wird durch eine wohldefinierte Abfolge lokaler
Transitionen/Transaktionen erreicht.
• Service kommuniziert „erfolgreiche“ lokale
Transition/Transaktion an den nächsten
beteiligten Service*.
*mehr dazu später
147. #WISSENTEILEN
Verteilte Transaktionen via SAGAs
• wohldefinierte Abfolge von Compensation
Algorithms realisieren verteiltes Rollback
• Compensation Algorithms sind fachlicher
Code und somit Applikationslogik
• Abfolge von lokalen TX & CAs kann beliebig
komplex werden!
159. #WISSENTEILEN
Choreographie von SAGAs
• pro
lose gekoppelt (Teilnehmer kennen sich nicht)
relativ einfach zu implementieren
• contra
i.d.R. zyklische Abhängigkeiten
erhöhte Komplexität im Domänen-Modell
kein zentraler Business-Code (wann valide?)
160. #WISSENTEILEN
Choreographie von SAGAs
• btw lose Kopplung
Teilnehmer kennen sich zwar nicht, wissen aber
genau, was bei einem Event zu tun und wie im
Anschluss – durch ein eigenes Event – zu
antworten ist (a.k.a. pseudo lose Kopplung)
162. #WISSENTEILEN
Orchestrierung von SAGAs
• explizite Sequenzsteuerung
• zentraler SAGA-Koordinator im Service
• Command / Handler Pattern
• beteiligte Services haben kein „Wissen“
174. #WISSENTEILEN
Orchestration von SAGAs
• pro
Logik ist einfach(er) zu verstehen
fachliche Kopplung nur unidirektional
keine zyklischen Abhängigkeiten
Separation of Concerns (Domain Logic vs. TX)
175. #WISSENTEILEN
Orchestration von SAGAs
• contra
„Smart Orchestrator & Dump Services“ Pattern,
d.h. Risiko, zu viel Business Logic im
Orchestrator zu zentralisieren
176. #WISSENTEILEN
Orchestration von SAGAs
• btw Orchestrator
Will man den wirklich selber bauen? Nein!
Alternative 1: Saga Framework
Alternative 2: Lightweight Workflow Engine
178. #WISSENTEILEN
Konsistenz von Daten und Nachrichten
• Services veröffentlichen „Erfolgs“-Nachricht
direkt nach lokaler TX
• lokale TX und „Erfolgs“-Nachricht sind
atomare Einheit aus Sicht des Services
• garantierte Beendigung der Business TX*
*Message Broker buffered bei Bedarf die Message
192. #WISSENTEILEN
Server Side (SSI)
• Page Composition auf Web Server Level
• Server Side Scripting Language
• einfach Syntax inkl. Kontroll-Direktiven (if, …)
• erlaubt u.a. <!--#include file|virtual=„…“ -->
• Apache httpd, LiteSpeed, nginx, lighttpd, IIS
193. #WISSENTEILEN
Server Side (ESI)
• Page Composition auf Edge Server Level
• XML basierte Syntax
• erlaubt u.a. <esi:include src=„…“ onerror=„…“ />
• CDN (Akamai)
• Proxy Caching Server (Varnish, Squid, Mongrel)
194. #WISSENTEILEN
UI Gateway
• Page Composition auf App (Server) Level
• Single Point of Entry ruft Service auf, baut aus
Ergebnissen UI zusammen und liefert sie aus
Achtung: Web UI / API Monolith!
Achtung : Kein Platz für Logik(!?)
198. #WISSENTEILEN
Warum ein API Gateway?
• Clients mit unterschiedlichsten Anforderungen
kommunizieren mit dem Backend.
• Client ruft mehrere Services auf und aggregiert
intern das Ergebnis (Chatty Communication).
• Direkte Kommunikation führt zu starker
Abhängigkeit zwischen Clients und Services.
202. #WISSENTEILEN
Was genau ist ein API Gateway?
• „Haupteingang“ für Anwendungen, um auf
Daten, Geschäftslogik oder Funktionen der
Backend-Services zuzugreifen.
• Zusätzlicher Layer zur Entkoppelung von
Client(s) und Backend-Services.
233. #WISSENTEILEN
Best Practices: technisch
• gar nicht (via „ignore“)
• gar nicht (via zusätzlicher Ressourcen)
• gar nicht (via erweiterbarer Datenformate)
• Versionsnummer in URL
• Versionsnummer in Header (via Custom-Header)
• Content Negotiation (via Accept-Header)