Wie Microservice-Ansätze scheitern – 5 Anti-Patterns · Was sind Microservices? “In short, the...

Stefan Toth - embarc

Wie Microservice-Ansätze scheitern – 5 Anti-Patterns

embarc – Eine Architekturskizze

Was sind Microservices?

“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.”

Charakteristische Eigenschaften!  Zerlegung in relativ kleine (fachliche) Services   Services sehr lose gekoppelt   Services einzeln installierbar und upgradebar   Dezentrale Datenhaltung   Hoher Freiheitsgrad bei Technologieauswahl

(James Lewis, Martin Fowler)

Im Prinzip…

Schichten Vertikalen

Microservices yeah!

Google Trends: Web Search, weltweit, ab 2004

Ziele

•  Skalierbarkeit •  Autonomie von Subprojekten & Teams •  Schnellere Time-To-Market für neue Features •  Bessere Wartbarkeit •  Technologische Evolutionsfähigkeit

–  Langlebigkeit

•  … •  [WhateverYourManagerNeeds]

Herausforderungen

•  Komplexität •  (technischer) Overhead •  Datensegregation •  Top-Down Planbarkeit •  Verantwortungsübernahme

Microservices Flowchart

Quelle: https://www.stavros.io/posts/microservices-cargo-cult/

#1Wiederverwendung

Schrottkunst / “Das kann man noch Essen”

Das kann man !noch verwenden.!

Das ist Kunst!

Share as much as possible…

•  Wiederverwendetes Service ist von allen Services nutzbar

•  Abhängigkeitssenke •  Häufig ein Gateway zu Daten

–  Produkt –  Partner –  …

Warum nicht?

Abhängigkeiten bedeuten Kommunikation, schwere Abschätzbarkeit von Änderungen, technischen Schnitt

–  Skalierbarkeit –  Autonomie von Subprojekten & Teams –  Schnellere Time-To-Market für neue Features –  Bessere Wartbarkeit

1.  Komplexität im Shared Service 2.  Teamabhängigkeiten

3.  Bottleneck

Redundanz mit Variation…

•  Echte Vertikalen •  Eventuell unterschiedliche

Datenrepräsentationen von “überlappender” Fachlichkeit

•  Evtl. unterschiedliche Persistenz (optimiert auf Service-Zweck)

•  Weniger Interaktion beim Request

•  Asynchroner Abgleich notwenig

#2Orchestrierung

Konzert Klassisch

Einer hat den Überblick,!Die anderen machen !oder fliegen!

Orchestrierung - Middleware

•  Mehrere Services für einen Business Request

•  Middleware zur Koordinierung von Service Calls –  Intelligentes Routing –  Anreicherung von

Nachrichten –  Umformung von Nachrichten –  Protokoll-Transformationen

Master-Plan!

Das SOA Erbe

Warum nicht?

Jedes Service sollte unabhängig weiterentwickelbar, testbar, deploybar sein (“self-contained”)

–  Skalierbarkeit –  Autonomie von Subprojekten & Teams –  Schnellere Time-To-Market für neue Features –  Bessere Wartbarkeit

Unabhängigkeit

Interaktion…

Event!

x

!

x

Schnittstelle!Aufruf!

Änderungswünsche / Tests (Pact, Pacto)

API-Gateway ≠ Orchestrierung

•  Nicht in jeder Microservice-Ausprägung vorhanden

•  Unintelligent •  Services werden für das UI

“gesammelt” –  Usability –  Team-Optimierung

Facade!

#3Zu wenig Automatisierung

Dunkles Zeitalter

manuelle Arbeit!braucht !

(langsamen) Rythmus !

Monolith è …

(Deployment)Monolith!

•  Von 1 auf 20 oder mehrere100 •  Manuelle Tätigkeiten werden zu

aufwändig (weggelassen) •  Ops wird querschnittlich "

(ohne Know-How) •  Neue Fähigkeiten nötig:

–  Mehr Remote –  Mehr Ausfälle –  Logging (Interaktionspfade)

Themen für Automatisierung

•  Build •  Test

–  Funktionalität –  Performance/Last –  Security

•  Deployment •  Konfiguration •  Monitoring inkl. Failover •  …

Warum?

Warum?

Blindflug bringt Chaos und Verwässerung. Zu seltenes Deployment macht Fehler nicht nachvollziehbar und zuweisbar

–  Autonomie von Subprojekten & Teams –  Schnellere Time-To-Market für neue Features –  Bessere Wartbarkeit

1.  Etwas Einblick (Zustand, Fehler) 2.  Verantwortung spürbar machen 3.  Lauffähiges System garantieren

Build-Deploy-Monitoring

Altes Service-Deployment

Neues Service-Deployment Monitoring!

Deployment!

Build / Package!

Plattform-Teams helfen

•  Lernende Plattform-Teams: Separate Teams verantworten grundlegende Plattformen und Technologien. Plattform ist Selbstbedienung –  Deployment-Werkzeuge –  Infrastruktur-Technologien –  Datenbanken –  Container –  etc.

#4Fertigstellung zu Q4 201x

Work in progress!Zum Stichtag tuts weh!

Dann… Anderes Projekt…!

Die Microservice-Initiative…

jetzt! Q4 2016!

Q2 2017!

Q4 2017!

•  Vielleicht auch ein 3-Jahres-Plan… •  Noch immer: Projekt-Gedanke

Projekt- vs. Produktentwicklung

Projekt! Wartung!

Qualität!

Kosten!

Produktentwicklung!

Stetige Investition in Gesundheitszustand und Qualität!

Projekt! Wartung!

Warum nicht Projekte?

Ohne Kontinuität keine Verantwortungsübernahme, keine Innovation, keine Langlebigkeit

–  Autonomie von Subprojekten & Teams –  Schnellere Time-To-Market für neue Features –  Bessere Wartbarkeit –  Technologische Evolutionsfähigkeit

1.  Wir bauen Produkte (meistens) 2.  Verantwortung mit Enddatum?

3.  Microservice-Evolution ist stetig

Wie entsteht Innovation?

Freedom & !Responsibility!

Wie endet das nicht im Chaos?

•  Entwickler mit der Verantwortung konfrontieren (Ziele) !–  Tests für Qualitätskriterien (Latenz, Zuverlässigkeit, Last,…) –  Continuous Delivery, siehe #3

•  Geringe Zähigkeit fördern

“When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.” (Robert C. Martin)

Zähigkeit...!

Standard-Blueprint von Netflix

Abweichen vom Standard?

•  Hat einen “echten” Grund (nicht Gemütlichkeit) •  Man ist motiviert andere zu begeistern

–  Etwas als Standard zu etablieren bedeutet ein eigenes Team, weniger Druck, …

#5“Grenzzaun” Security

Nach der Aktion !darf man Alles…!

Firewalls, Berechtigungsservice, OWASP

Authentifizierung!Autorisierung !

Warum nicht?

•  Erste Hürde wird regelmäßig genommen •  Kein Monolith, mehr remote-Kommunikation •  Confused deputy

irgendwas!wichtiges!

Warum nicht?

•  Zentrale Autorisierung: –  Zentrales Angriffsziel –  Muss evtl. Feingranular über Funktionen und

Berechtigungen Bescheid wissen. Service-Kapselung wird verletzt

Authentifizierung!Autorisierung !

Authentication Security

•  Authentifizierung über OAuth 2.0 / Open ID Connect –  Authentifizierungsserver, von allen Services nutzbar

•  Passwort Daten schützen –  Salted, Peppered Hashes –  Passwort Hashing (HMAC SHA512) –  Passwort Stretching (PBKDF2 100 Durchläufe) –  Passwort Komplexität

•  Federated Authentication –  Google –  …

Ansätze im Microservices-Umfeld I

•  Capability-Based Security –  Use-once Tokens gg. Request Duplizierung –  siehe: JWT (Jason Web Tokens)

•  Mandatory Access Control (MAC) –  Statt DAC (Identität), RBAC (Rolle) gibt es Zonen für

Funktionen (Zugriff, Benutzung, Konvertierung) oder auch Ausschluss von Funktionen

–  Boundaries First!

irgendwas!wichtiges!

Ansätze im Microservices-Umfeld II

•  Sensiblen Daten nicht im System halten

User Agent

Eigene !App

Ext. Service! Sensible!

Daten!

Ansätze im Microservices-Umfeld III

•  Black Hole APIs –  Nicht nur READ und READ+WRITE –  WRITE erlaubt Datenzugriff loszuwerden

•  HTTPS für Service-Aufrufe –  Public Key Infrastructure (PKI): "

Zertifikate, Keys, Certification Authority –  Vereinfachungen für Entwickler: z.B. Netflix Lemur

write

read

#6Aber…

Antipatterns - Honorable Mentions

•  Starrer Serviceschnitt (kein Management) –  Führt zu breiteren Schnittstellen –  Führt zu fachliche Verwässerung

•  Fokus auf Business-Logik •  Kosteneinsparung als Grund •  Top-Down Organisation

–  Freiheit? Verantwortung? •  “Intelligente” Lösungen – weil wir können •  …

Ziele

•  Skalierbarkeit •  Autonomie von Subprojekten & Teams •  Schnellere Time-To-Market für neue Features •  Bessere Wartbarkeit •  Technologische Evolutionsfähigkeit

–  Langlebigkeit

•  … •  [WhateverYourManagerNeeds]

#1, #2 #1, #2, !#3, #4

#1, #2, #3, #4 #4

#5

Spicker #3: „Microservices“

è  http://architektur-spicker.de

Unsere Architektur-Spicker beleuchten die konzeptionelle Seite der Softwareentwicklung.

!In dieser Ausgabe:!•  Was ist bei Microservices

entscheidend? •  Wie nutzen Sie die Ansätze? •  Welche Kompromisse gehen

Sie dabei ein?

PDF, 4 Seiten Kostenloser Download.

stefan.toth@embarc.de

xing.to/sto

@st_toth

Vielen Dank.

DOWNLOAD FOLIEN: http://www.embarc.de/blog/