Der goldene Schnitt – Wie schneide ich Microservices richtig?

@ArneLimburg @_openknowledge #WISSENTEILEN
Der goldene Schnitt
Microservices maßgeschneidert

ÜBER MICH
Microservices maßgeschneidert | Arne Limburg
• Enterprise Architect bei der open knowledge GmbH
• Themen
• Microservices
• Domain Driven Design
• APIs
• Architektur
• Coaching
• Technologie (Java EE / Jakarta EE)
Arne Limburg

ÜBER OPEN KNOWLEDGE
Titel der Präsentation | Name des Sprechers
Branchenneutrale Softwareentwicklung und IT-Beratung

Warum Microservices?
klein
lose gekoppelt
einzeln deploybar

© Martin Fowler: https://www.martinfowler.com/bliki/MicroservicePremium.html
Warum Microservices?

Monolit / Layered Architecture vs. Microservices
Wartbarkeit
Skalierbarkeit
Ausfallsicherheit
Warum Microservices

Wie groß ist ein Microservice?

„Small enough
and not smaller“by Sam Newman (thoughtworks)Microservices maßgeschneidert | Arne Limburg

„Eine Einheit, die von einem kleinen Team
komplett – also fachlich und technisch –
beherrscht werden kann.”
Oliver Wegner (OTTO)

Wie groß ist ein Microservice
Number of microservices /
Smallness of microservice
Costs
Costs of:
- setup
- eventual consistency
- operational complexity
- redundant implementation
- …
Costs for:
- agility
- adaptivity
- communication times business:tech

Beispiel Online Shop

Wie finde ich Microservices?

Kandidaten für Microservices?
Kategorien
Suche
Produktkatalog
Historie
Empfehlungen
Benutzerverwaltung
Warenkorb

Fachlichkeit über Fachlichkeit

Domain Driven Design

Domain Driven Design
„For most software projects, the primary focus should be on the domain and domain
logic“
Eric Evans, Domain-Driven Design, Addison-Wesley, © Eric Evans, 2004

Ubiquitous Language
Fachsprache als Basis
Eindeutige Begriffe
Durchgängige Nutzung

DOMAIN DRIVEN DESIGN
„Complex Domain Design
should be based on a model “

DOMÄNENMODELL
Repräsentation der Domäne
Fachlich korrekt und konsistent
Weiterentwicklung durch alle Beteiligten

DOMÄNENMODELL
Repräsentation der Domäne
Fachlich korrekt und konsistent
Weiterentwicklung durch alle Beteiligten
„Das Domänenmodell ist das Bindeglied
zwischen Domänenexperten und
Entwicklern“

Domänenmodell Online-Shop
Customer
ShoppingCart
Product

Wie passt das zu Microservices?

Bounded Context

Mehrere Modelle – aber wie?
Customer
ShoppingCart
Product
Kein Verlust der Vorteile
Mögliche Konflikte
Verschiedene Modelle
Unterschiedliches Verständnis

Trennung nach
Domänenobjekten?
Customer
ShoppingCart
Product

„Small autonomous services
that work together.”
by Sam Newman (thoughtworks)

„Microservices are a
self-contained and easily understandable
realization of domain logic,
highly independent of each other.”by Adam Bien
(Freelancer)

„If every service has to be updated
at the same time, it‘s
not loosely coupled”
by Adrian Cockcroft (ehemals Netflix)

Wer hat welche Daten?

Dezentrale Datenhaltung
Daten-Ownership
Caching

Service nicht verfügbar
Shipping

Beispiel Lieferadresse

• Speichern in
• ShipmentService?
• CheckoutService?
• CustomerManagementService?
• Lieferadresse ändern
• Auswahl über CustomerManagementService?
• Setzen in CheckoutService/ShipmentService?
• CustomerManagementService offline à Chain of Failure?
Beispiel Lieferadresse

Dezentrale Datenhaltung
Daten-Ownership
Caching
Transaktionen

„Starbucks does not use
Two-Phase Commit“http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html

Verteilte Transaktionen via SAGAs
SAGA Idee:
Abbilden einer verteilten fachlichen
Transaktion durch eine Abfolge lokaler
Transitionen / Transaktionen

• 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

Die
„Saga“
Strategie

Die
„Saga“
Strategie
Fehler-
behandlung

Die
„Saga“
Strategie
CA = Compensation Algorith a.k.a.
Compensation Transaction

Die
„Saga“
Strategie
CA = Compensation Algorith a.k.a.
Compensation Transaction
„Every Ti has its Ci“

• 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!

Steuerung von SAGAs
• Choreographie
• Orchestrierung

Choreographie von SAGAs
• implizite Sequenzsteuerung
• verteilte Koordination durch Eventfluss
• „Wissen“ liegt bei den beteiligten Services

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?)

Orchestrierung von SAGAs
• explizite Sequenzsteuerung
• zentraler SAGA-Koordinator im Service
• Command / Handler Pattern
• beteiligte Services haben kein „Wissen“

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)

• contra
„Smart Orchestrator & Dump Services“ Pattern,
d.h. Risiko, zu viel Business Logic im
Orchestrator zu zentralisieren

• btw Orchestrator
Will man den wirklich selber bauen? Nein!
Alternative 1: Saga Framework
Alternative 2: Lightweight Workflow Engine

Worauf es ankommt
Klare Kontextgrenzen
Unabhängigkeit
Konsistenz

Charakteristika
Charakteristika
Schneiden von Microservices
Schnitt entlang der Prozesse
Fachlichkeit in einem Team
Konsistenz/Transaktionssicherheit
Wenig Kommunikation/Unabhängigkeit

Wie groß ist klein
Size of microservice
„guter“
Microservice
Modularisierung
Teamgröße
Austauschbarkeit
Infrastruktur
Verteilte
Kommunikation
Transaktionen &
Konsistenz

Size of microservice
Number of microservices

Context Map
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
keep model unified by
Context Map
assess/overview
relationships with

Context Map

Shared Kernel
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
Context Map
assess/overview
relationships with
Shared
Kernel
Overlap allied contexts through

Shared Kernel

Abstract Core

Abstract Core
Fachliche Basis
Saubere Modellierung
div. Repräsentationen
Zur Kommunikation
Trennen von common

Abstract Core Online Shop
Customer
ShoppingCart
Product
Fachliche Basis
Saubere Modellierung
div. Repräsentationen
Zur Kommunikation
Trennen von common

Conway‘s Law
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
Context Map
assess/overview
relationships with
Shared
Kernel
Organisationen, die Systeme entwerfen,
[…]
sind auf Entwürfe festgelegt,
welche die Kommunikationsstrukturen
dieser Organisationen abbilden.

Customer/Supplier Teams
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
Context Map
assess/overview
relationships with
Shared
Kernel
Customer
Supplier
Teamsrelate allied contexts as
Organisationen, die Systeme entwerfen,
[…]
sind auf Entwürfe festgelegt,
welche die Kommunikationsstrukturen
dieser Organisationen abbilden.

Conformist
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
Context Map
assess/overview
relationships with
Shared
Kernel
Customer
Supplier
Conformist
overlap unilaterally as

Open Host Services
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
Context Map
assess/overview
relationships with
Shared
Kernel
Customer
Supplier
Conformist
Open Host
Service
support multiple
clients through

CONSUMER-DRIVEN CONTRACT TEST
Consumer
Contract
Consumer Provider
Consumer
Tests
Provider
Tests

MICROSERVICES ARCHITEKTUR
Address Validation Service
Delivery Service
Customer Service
Billing Service

PIPELINE TO DEPLOY TO STAGE
Execute
Own
Provider
Tests
Generate
Consumer
Contract
Execute
Depending
Provider
Tests
Deploy
to
Stage

BREAKING CHANGE VOM PROVIDER
Execute
Own
Provider
Tests
Generate
Consumer
Contract
Execute
Depending
Provider
Tests
Deploy
to
Stage

BREAKING CHANGE VOM CONSUMER
Execute
Own
Provider
Tests
Generate
Consumer
Contract
Execute
Depending
Provider
Tests
Deploy
to
Stage

Published Language
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
Context Map
assess/overview
relationships with
Shared
Kernel
Customer
Supplier
Conformist
Open Host
Service
support multiple
clients through
Published
Language
formalize as

Anticorruption Layer
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
Context Map
assess/overview
relationships with
Shared
Kernel
Customer
Supplier
Conformist
Anticorruption
Layer
translate and insulate
unilaterally with
Open Host
Service
support multiple
clients through
Published
Language
formalize as

Separate Ways
Bounded
Context
Ubiquitous
Language
names
enter
Continous
Integration
Context Map
assess/overview
relationships with
Shared
Kernel
Customer
Supplier
Conformist
Separate
Ways
free teams to go
Anticorruption
Layer
translate and insulate
unilaterally with
Open Host
Service
support multiple
clients through
Published
Language
formalize as

ABWÄRTSKOMPATIBILITÄT
http://www.example.com/addresses/42
àLiefert Addresse
{
street: {
"name": "Poststraße",
"number": "1",
},
"city": "26122 Oldenburg"
}

Attribut hinzufügen
{
street: {
"number": "1",
"additionalAdressLine": "2. Obergeschoss"
},
}

Attribut hinzufügen
{
street: {
"number": "1",
"additionalAdressLine": "2. Obergeschoss"
},
}
Besondere Anforderung an den Client:
Unbekannte Attribute ignorieren à
Tolerant Reader Pattern

TOLERANT READER PATTERN
Server schickt
{
street: {
"number": "1",
"additionalAdressLine":
"2. Obergeschoss"
}...
}
Client erwartet
{
street: {
"number": "1",
}...
}

Attribut-Umbenennung
{
street: {
"streetName": "Poststraße",
"number": "1",
"houseNumber": "1",
},
}

àAbwärtskompatible Änderungen: Umbenennen durch Kopieren
{
street: {
"number": "1",
"houseNumber": "1",
},
}

MAGNANIMOUS WRITER PATTERN
Server schickt
{
street: {
"number": "1",
"houseNumber": "1“
}...
}
Client erwartet
{
street: {
"number": "1",
}...
}
http://tenderware.blogspot.de/2011/05/magnanimous-writer.html

Server schickt
{
street: {
"number": "1",
}...
}
Client erwartet
{
street: {
"houseNumber": "1",
}...
}

Server erwartet
PUT http://www.example.com/addresses/42
Client schickt
{
street: {
"number": "1",
}...
}
„Be conservative in what you do,
Be liberal in what you expect“
Postels Law (John Postel)

Client schickt
{
street: {
"number": "1",
}...
}
Server erwartet
{
street: {
"number": "1",
}...
}
oder
oder

Client schickt
{
street: {
"houseNumber": "1",
}...
}
Server erwartet
{
street: {
"number": "1",
}...
}
oder
oder

àZusammenführen und Teilen von Attributen
{
street: {
...
"houseNumber": "1",
"addressLine1": "Poststraße 1",
}
...
}

àHerausforderungen: Zusammenführen von Attributen
{
street: {
...
"houseNumber": "1",
}
...
}

àHerausforderungen: Teilen von Attributen
{
street: {
...
}
"city": "26122 Oldenburg",
"zipCode": "26122",
"cityName": "Oldenburg"
}

àHerausforderungen: Ebene von Attributen ändern
{
street: {
...
"addressLine1": "Poststraße 1"
}
...
}

{
...
"zipCode": "26122",
"cityName": "Oldenburg",
"location": {
"zipCode": "26122",
}
}

{
...
"zipCode": "26122",
"location": {
"zipCode": "26122",
}
}
Bei jeder Modelländerung muss
eine Migrationsstrategie
einbezogen werden!

{
street: {
"number": "1",
"houseNumber": "1",
"addressLine1": "Post... 1",
"addressLine2": ""
}
"addressLine2": "",
"zipCode": "26122",
"location": {
"zipCode": "26122",
}
}
http://www.example.com/v1/addresses/42
àBisher nur abwärtskompatible Änderungen

{
street: {
"number": "1",
"houseNumber": "1",
"addressLine2": ""
}
"addressLine2": "",
"zipCode": "26122",
"location": {
"zipCode": "26122",
}
}
àViele Attribute deprecated

VERSIONSSPRUNG
{
street: {
"number": "1",
"houseNumber": "1",
"addressLine2": ""
}
"addressLine2": "",
"zipCode": "26122",
"location": {
"zipCode": "26122",
}
}
àBisher nur abwärtskompatible Änderungen

INKOMPATIBLE ÄNDERUNG
àVersionssprung
{
"addressLine2": "",
"location": {
"zipCode": "26122",
}
}

Parallele Versionen – via Services

Parallele Versionen – via Endpoints

DOMÄNENMODELL ALS API
Schnittstelle Schnittstelle
{ street: {
"number": "1",
"houseNumber": "1",
"addressLine2": ""
}
"addressLine2": "",
"zipCode": "26122",
"location": {
"zipCode": "26122",
}
}
{
"addressLine2": "“,
"location": {
"zipCode": "26122",
}
}
V1 V2-SNAPSHOT

DOMÄNENMODELL ALS API
Schnittstelle
Schnittstelle
{ street: {
"number": "1",
"houseNumber": "1",
"addressLine2": ""
}
...
}
{
"city": {
"zipCode": "26122",
}
}
V1 V3-SNAPSHOT
Schnittstelle
{ "addressLine1": "Poststraße 1",
"location": {
"zipCode": "26122",
},
"city": {
"zipCode": "26122",
}} V2

• Über URL-Pfad
/v2/addresses
• Über Query-Parameter
/addresses?version=v2
• Über Version-Header
X-Api-Version: v2
• Über Version-Attribut am Media-Type
application/xml;version=v2
• Über Media-Type
application/vnd.de.openknowledge+v2+json
ERMITTELN DER VERSION

• Umbennen von Ressourcen
àHttp-Status-Code 301 „Moved Permanently“
• Semantische Änderung von Attributen
àAnderen Namen vergeben
• Neue Version hat anderes Verhalten
àNeue Schnittstelle
• PUT zum Setzen leerer Attribute
àUnterscheidung zwischen nicht vorhanden und empty
WEITERE HERAUSFORDERUNGEN

Schnittstellenversionierung
Klare Versionierungsstrategie
Mehrere Versionen parallel
Definiertes Versionsschema
Über Custom Header
Über Media-Type
Über die URL

Schneiden des User Interfaces

Seperate UIs

API Composition

API Gateway

Backends for Frontends

UI Fragment Composition

Fazit
Es kommt nicht auf die Größe an
Orientierung an Use Cases
Minimierung der Kommunikation
Gemeinsames Verständnis für Fachlichkeit
Modellierung der Core Domain
Context Map
Explizites Leben der Schnittstellen
Versionierung
Compensation

FRAGEN
? ? ?

KONTAKT
Arne Limburg,
Enterprise Architect
OFFENKUNDIGGUT
arne.limburg@openknowledge.de
+49 (0)441 4082 – 0 / 154
Icons in this presentation designed by “Freepik”, “Nice and Serious” and “Elegant
Themes” from www.flaticon.com

Der goldene Schnitt – Wie schneide ich Microservices richtig?

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (12)

Similaire à Der goldene Schnitt – Wie schneide ich Microservices richtig?

Similaire à Der goldene Schnitt – Wie schneide ich Microservices richtig? (20)

Plus de OPEN KNOWLEDGE GmbH

Plus de OPEN KNOWLEDGE GmbH (20)

Der goldene Schnitt – Wie schneide ich Microservices richtig?