Embed Size (px)
Citation preview
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.
