sollte man bedenken, bevor man sich im Service Dschungel verliert…? Eine subjektive, “opinionated” Einschätzung von Marc Koch, bbv Software Services GmbH, München ([email protected]) 2 Microservices – Fluch oder Segen?
eine große Codebase/Repository • Einzeln entwickelt, einzeln deployt • Nicht bzw. sehr schwer skalierbar • Über viele Jahre gewachsen (keine Anwendung startet als Monolith!) • Kommunikation: • Intern à über direkte Methodenaufrufe (ohne Netzwerk) • Extern à über Netzwerk (potentiell unzuverlässig!) 5 Was ist ein Monolith? A B Nachbar- system
kann Anwendung lokal deployen/starten • Entwickler kann Bugs lokal nachvollziehen (lokales Debuggen in IDE) • i.d.R. einheitliche Programmiersprache • Schmaler Tech Stack, kurze BoM („bill of material“), wenige Frameworks 6 Vorteile vom Monolith
Unflexible Skalierung • Lange Entwicklungszeiten • Lange Testphasen, Automatisierte Tests nur schwer realisierbar • i.d.R. schon etwas älter • Technische Migrationen i.d.R. immer „big bang“ • Instabil (memory/CPU leak à kompletter Ausfall) • Sehr unflexibel, umfangreich, komplex, träge 7 Nachteile vom Monolith (oder Vorurteile)
mehrere, getrennte Codebases/Repositories/Projekte in der IDE • Einzeln entwickelt, einzeln deployt, einzeln skalierbar • Geht Hand in Hand mit Cloud • Kommunikation: • Intern à über Netzwerk • Extern à über Netzwerk 9 Was sind Microservices? A B Nachbar- system
• Für einen Entwickler Microservice-Landschaft nicht überschaubar • Breiter Techstack, viele Frameworks – von einzelnen Personen nicht mehr beherrschbar • Lokal schwer deploybar/nachvollziehbar, lokal nicht (oder schwer) debugbar • Prozesse/UseCases lokal nicht nachvollziehbar, erfordert aggregiertes Logging (ELK, Splunk, etc.) oder spezielle Tools (DynaTrace, etc.) • Voneinander unabhängige Entwicklung/Wachstum erfordert API-Versioning • System-interne Kommunikation zwischen den einzelnen Microservices über das potentiell unzuverlässige Netzwerk 11 Nachteile von Microservices (oder Vorurteile)
suggeriert Quantifizierbarkeit, Messbarkeit, Vergleichbarkeit • vgl. Mikrometer, Mikrogramm • Typische Frage bei Vorträgen/Meetups: „Wie groß darf denn ein Microservice sein?“ • Wettrennen: Wer schafft den kleinsten Microservice? • …und nennt es dann „Nanoservice“! • Frage lenkt von der eigentlichen Thematik ab Man sollte nicht in möglichst kleine Teile schneiden, sondern in möglichst sinnvolle! klein sollte sich auf Anzahl und Größe der Schnittstellen beziehen! 12 Microservices
entwickeln und schneller in Prod bringen • Erhöhte Flexibilität • Schnelleres bug fixing • Bessere Auslastung der Infrastruktur durch gezieltes Scaling • Senkung der technischen Schulden • Erhöhte Attraktivität für Entwickler (hype factor) 13 Wir zerlegen unseren Monolithen in Microservices!
• Bsp: Vorher bildet der Monolith 100 UseCases oder Features ab, à dann wird nach Zerlegung die MS-Landschaft auch 100 UseCases abbilden – in Summe! • Einzelne Teile werden kleiner/übersichtlicher, aber die Summe bleibt gleich • Fachliche Komplexität nimmt u.U. zu • wegen Netzwerk und potentiellen system-internen Ausfällen! (verträgt das der Fachprozess?) à retry und „circuit breaker“ • wegen Verteilung der Daten und ggf. Redundanz der Daten à „eventual consistency“, idempotency • Evtl fachliches Tracing zur Nachverfolgung von Anwenderaktionen 14 Wir zerlegen unseren Monolithen in Microservices!
à viele neue (zum Teil noch sehr junge) Frameworks/Technologien kommen in Spiel • Bulkhead pattern, sidecar pattern • service mesh • Log aggregation, correlation ids, tracing! • Monitoring, scaling / auto scaling, load balancer • API versioning 15 Wir zerlegen unseren Monolithen in Microservices!
distributed systems (https://www.simpleorientedarchitecture.com/8-fallacies-of-distributed-systems/) • Tracing! • Gutes und dediziertes Personal nötig! Experten nötig! 16 Wir zerlegen unseren Monolithen in Microservices!
• Technische Komplexität à nimmt zu! • Betrieb („operational complexity“) à nimmt zu! Dafür bekommt man: • Erhöhte Flexibilität bei: • Skalierung und Deployment • Entwicklung (features + bug fixing) • technische Migrationen à Kürzere time to market 17 Wir zerlegen unseren Monolithen in Microservices!
mud“) • Intern klare, fachliche Module mit wohl definierten Schnittstellen • Kann Zwischenschritt sein in Richtung Microservices à„Monolith done right!“ Oder besser: • INNOQ: Self-contained systems (https://macroservices.org/ à https://scs-architecture.org/) • „separation of the functionality into many independent systems “ à„Microservices done right!“ 24 Alternativen
mehrere (oder alle) dieser sauber gekapselten Teile herauszulösen • ein Remote-Interface davor zu packen (HTTP/REST Wrapper oder Messaging) • das getrennt vom Rest zu deployen à Man hat seine Microservices! 27 «Monolith oder Microservices» ist nur Deploymentdetail A B C E D
Strukturieren der Anwendung • Klare Kontexte/Subdomains/Schubladen! (die möglichst wenig miteinander interagieren) • Klare (interne) Schnittstellen • Wie ich die einzelnen Teile dann deploye, ist (fast nur) eine Detailsfrage…. 29 «Monolith oder Microservices» ist nur Deploymentdetail
lösen: • Selektives Deployment à kürzere time to market • Selektives Skalieren à Stabilität und Kosten („pay as you go“) • Schrittweise technische Migration à kürzere time to market, Risikosenkung • Wenn man diese Probleme aber NICHT hat, macht es wenig Sinn Microservices zu machen! • Die Lösung der o.g. Probleme erkauft man sich aber teuer mit anderen/neuen Problemen/Herausforderungen: • Komplexerer TechStack, neue Frameworks • Knowhow nötig in relativ jungen Technologien/Frameworks 31 Microservices – die «silver bullet»?
lösen: • Komplexität reduzieren (wenn die Fachlichkeit/Domäne komplex ist, ist es auch die Software!) • Abbau technischer Schulden • Architektonische Mängel • Lange Releasezyklen (Organisation) 32 Microservices – die «silver bullet»?
sich im Service Dschungel verliert…? Man muss: • genau wissen was man will/braucht und was nicht!! • die Probleme genau analysieren und Ursachen finden • die Fachlichkeit, die Prozesse, die Anforderungen genau verstehen und gut schneiden • wissen, dass ein „Rattenschwanz“ an neuen Tools/Frameworks dranhängt! • Architektur hinreichend priorisieren und einplanen! • Architektur kontinuierlich überprüfen/hinterfragen/anpassen (à „evolutionary architecture“) 33 Microservices – Fluch oder Segen?
Jahren mit dem Monolithen waren: Ein unüberschaubarer, kaum handhabbarer „Haufen“ von interagierenden „Dingen“ Schuld sind aber nicht die Microservices! Schuld sind • falsche Annahmen („Netflix macht das auch so, also brauchen wir das auch!“) • falscher Schnitt der Komponenten (zu klein à zu viele Einzelteile) • zu starre (Entwicklungs-)Prozesse/Organisation • falsche Prioritäten (feature >> refactoring, Architektur) • Unterschätzen der Komplexität Man macht die gleichen Fehler wieder wie bei Monolithen 34 Microservices – Fluch oder Segen?
OHNE es zu brauchen (sie lösen Probleme, die sie nicht haben) • Bei vielen Firmen kehrt Ernüchterung ein, Euphorie ist verflogen • Keine „silver bullet“ mit der alle Probleme beseitigt sind! • Viele Firmen wären besser beraten ihre Software aufzuräumen („continuous refactoring“) • bbv Technica Radar -> Microservices „reconsider“ ! https://www.bbv.ch/tech-radar/ 36 Fazit
Dort finden Sie: • Quality Map • Blog Artikel • Cheat sheets • Technica radar • Kundenindividuelle Workshops • + vieles mehr ! 37 Wollen Sie mehr wissen ?
linyows
shimabox
kciter
kazukima
jaguar_imo
inesmontani
andpad
mitsuharu
yoshiori
yuukit
.JPG){kind=avatar}
ymd65536
wadayusuke
chrislema
holman
garrettdimon
lara
schacon
bkeepers
keavy
sugarenia
searls
carmenintech
chriscoyier
eileencodes
![[email protected] Direkt: +49 89 452 4383-33 www.bbv.eu Michael Schönwetter |](https://files.speakerdeck.com/presentations/bc1179437d8343baaaa636cc7a834c87/slide_39.jpg){kind=link}