No content

Alle reden von Microservices und viele wollen sie einsetzen. Was 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? 

3 • 21 Jahre Erfahrung • Seit 3,5 Jahren Senior Technical Consultant bei bbv in München • Schwerpunkte: • Softwareentwicklung (Java), DDD • Architektur • Cloud • Software-Modernisierung / Refactoring Marc Koch 

1. Was ist ein Monolith? 2. Was sind Microservices? 3. Vor- und Nachteile 4. Wir zerlegen unseren Monolithen in Microservices 5. Microservices – kritische Stimmen 6. Alternativen 7. Nur ein Deploymentdetail? 8. Zusammenfassung 9. Fazit 10. Q&A 4 Inhaltsverzeichnis 

• Eine einzelne, „große“ Anwendung mit internen Modulen/Teilen/Paketen • i.d.R. 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 

• Eine Codebase für Entwickler einfach zu handhaben • Entwickler 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 

• Wenige Releases/Deployments im Jahr • Hohe technische Schulden • 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) 

8 Monolith = Big ball of mud? 

• Viele, „kleine“, mehr oder weniger eigenständige (Teil-)Anwendungen • i.d.R. 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 ist ein einzelner Microservice leicht überschaubar, anpassbar (schnelleres Onboarding) • Features schnell umsetzbar • Passgenaue, flexible Skalierung einzelner Microservices in der Cloud (à elastic!) • Jeder Microservice in eigener/anderer Programmiersprache/Technologie umsetzbar • Technische Migration schrittweise möglich • Voneinander unabhängige Entwicklung/Wachstum/Deployment • Ausfall einer Komponente legt nicht gesamtes System lahm (à resilient!) 10 Vorteile von Microservices 

• Evtl fragmentierte Codebasis (mehrere Repos, mehrere Sprachen, mehrere Projekte) • 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) 

Der Begriff „Microservice“ an sich ist problematisch! • Prefix „Micro-“ 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 

Hoffnung: Alles wird besser: • Features schneller umsetzen, d.h. schneller 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! 

ABER: • Der fachliche Umfang bleibt gleich – in Summe! • 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! 

ABER: • Die technische Komplexität (Breite des TechStacks) nimmt zu! à 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! 

ABER: • „operational complexity“ nimmt zu! • 8 fallacies of 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! 

Zusammenfassung: • Fachliche Komplexität à bleibt gleich oder nimmt zu! • 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! 

18 Microservices – kritische Stimmen https://twitter.com/sandofsky/status/1247629388104880129 

19 Microservices – kritische Stimmen https://twitter.com/jackkleeman/status/1190354757308862468 

20 Spot the difference! 

21 Microservices == die neuen Monolithen? 

22 Microservices – kritische Stimmen https://twitter.com/copyconstruct/status/1247130488667394049 

23 Microservices – kritische Stimmen https://twitter.com/gergelyorosz/status/1247132806041546754 

• Modulith • Modular aufgebauter Monolith (kein „big ball of 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 

• Serverless ? • „Microservices vs Serverless“ • Blogartikel von Shpend Kelmendi • www.bbv.ch/blog/ à coming soon! 25 Alternativen 

• Deploye ich das alles zusammen in einem Paket (auf einem Server) à Monolith/Modulith 26 «Monolith oder Microservices» ist nur Deploymentdetail A B C D E 

• Es ist aber „relativ einfach“ dann: • eines oder 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 

28 «Monolith oder Microservices» ist nur Deploymentdetail A D B E C D 

• Das wichtige (und schwierige!) ist aber das (interne) saubere 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 

30 «Monolith oder Microservices» ist nur Deploymentdetail - Fachliche Strukturen schaffen - Architektur definieren - Deployment - “Straight forward” Beides auf einmal 

• Mit Microservices (und Cloud) kann man manche Probleme wunderbar 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»? 

• Mit Microservices (und Cloud) kann man manche Probleme NICHT 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»? 

Zurück zum einleitenden Satz: Was sollte man bedenken, bevor man 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? 

Viele Firmen sind jetzt mit Microservices da, wo sie vor 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? 

• Monolith hat auch Vorteile! • Microservices haben auch Nachteile! • Kernprobleme liegen woanders: • Domain verstehen/analysieren • Schnitt der Komponenten/Module/Services („bounded context“, minimale Schnittstellen) • Managen von Abhängigkeiten • Probleme mit Architektur • Mangelndes Verständnis für Architektur bei Entwicklern und/oder Management • Mangelnde Dokumentation der Regeln • Knowhow Verlust / personelle Fluktuation 35 Fazit 

Meine Meinung: • Eher Fluch, weil viele Firmen es machen 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 

• Besuchen Sie unsere Webseiten: • bbv.ch • bbv.eu • Dort finden Sie: • Quality Map • Blog Artikel • Cheat sheets • Technica radar • Kundenindividuelle Workshops • + vieles mehr ! 37 Wollen Sie mehr wissen ? 

38 Umfrage Ergebnis 

39 Q&A 

[email protected] Direkt: +49 89 452 4383-33 www.bbv.eu Michael Schönwetter | Leiter bbv Deutschland bbv Software Services GmbH Elsenheimer Straße 9 80687 München [email protected] Marc Koch | Senior Technical Consultant