Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Sie brauchen doch gar keine Microservices (... oder?)

Sie brauchen doch gar keine Microservices (... oder?)

Vortrag, zusammen mit Renato Vinga-Martins, Java User Group Frankfurt, 29. Mai 2019

Abstract:
Hype, Innovation oder State-of-the-Art? Den Begriff Microservice gibt es seit 2011 und er wird inflationär verwendet. Ob man den Schritt hin zu Microservice wagen soll oder nicht, ist eine Entscheidung, die man sehr bewusst und gezielt treffen sollte.

Wir geben in diesem Talk eine Entscheidungshilfe und nähern uns dem Thema aus den Blickwinkeln Fachlichkeit und Architektur. Und wir machen es uns einfach: Wir raten in diesem Talk vom Microservices-Einsatz kurzerhand ab.

Äh, wie bitte? Ja, richtig gelesen - wir raten vom Microservice-Einsatz ab, ...

..., wenn fachliche und organisatorische Komplexität nicht groß genug ist! Schon Martin Fowler rät: Don't even consider microservices unless you have a system that's too complex to manage as a monolith. Doch was meint Fowler eigentlich mit "complex"? Wann ist ein IT-Vorhaben nur kompliziert?
..., wenn das Team nicht oder wenig dynamisch / flexibel agieren muss! In welchen Größenordnungen ist das eigentlich der Fall? Muss man schon Netflix sein oder geht's eine Nummer kleiner?
..., wenn der fachliche Schnitt nicht klar ist! Reicht da schon Datenhoheit als Kriterium aus? Wieviel fachliche Strukturierung brauchen wir? Wie groß oder klein ist denn "Micro"? Wie vermeidet man ein Microservice-Spaghetti?
..., wenn man sich nicht (vorher) die architektonischen und fachlichen Laufzeit-Auswirkungen klar macht! Das in Microservices geschnittene "Verteilte System" erfordert z. B., mit deutlich erhöhten Latenzen umzugehen. Und es zwingt einen, sich mit Eventual Consistency zu beschäftigen und mit teilfertigen, fachlich nicht (immer) konsistenten Teilzuständen.
..., wenn die Frage nach Integration nicht geklärt ist! Der ESB ist aus guten Gründen verpönt. Aber irgendeine Integrationstechnologie brauchen wir doch? Insbesondere ist auch die Integration bei gemeinsamen Benutzeroberflächen zu klären: Was für Web-Oberflächen recht einfach ist, ist für native oder andere Clients schon gar nicht mehr so klar.

Microservices sind also ... vor allem nicht trivial. Sie betreffen verschiedenste fachliche, architektonische und organisatorische Aspekte. Wer da nicht alle Herausforderungen durchdenkt oder sich ihrer zumindest bewusst ist - nun, dem hatten wir ja auch abgeraten :-)

Martin Lehmann

May 29, 2019
Tweet

More Decks by Martin Lehmann

Other Decks in Technology

Transcript

  1. Copyright © Accso – Accelerated Solutions GmbH 1 v.3 v.3.18

    Sie brauchen doch gar keine Microservices (... oder?) MARTIN LEHMANN, DR. RENATO VINGA-MARTINS @mrtnlhmnn @accso JUG Frankfurt, 29. Mai 2019
  2. Copyright © Accso – Accelerated Solutions GmbH 2 Martin Lehmann

    Accso - Accelerated Solutions GmbH Cheftechnologe Martin Lehmann ist Diplom-Informatiker und arbeitet als Cheftechnologe bei der Accso - Accelerated Solutions GmbH. Seit Ende der 90er-Jahre arbeitet er als Softwarearchitekt und -entwickler in der Softwareentwicklung in Individualentwicklungsprojekten für Kunden verschiedener Branchen. Er interessiert sich besonders für die Herausforderungen Verteilter Systeme. [email protected] @mrtnlhmnn www.xing.com/profile/Martin_Lehmann3 Dr. Renato Vinga-Martins Accso - Accelerated Solutions GmbH Dr. Renato Vinga-Martins arbeitet bei der Accso – Accelerated Solutions GmbH mit technologischem Schwerpunkt als Architekt, Berater und Projektleiter in allen Phasen der Individualsoftware-Entwicklung. Er begleitet seit über 20 Jahren Kunden in ihren Projekten. [email protected]
  3. Copyright © Accso – Accelerated Solutions GmbH 3 Hype, Innovation

    oder State-of-the-Art? Den Begriff Microservice gibt es seit 2011 und er wird inflationär verwendet. Ob man den Schritt hin zu Microservice wagen soll oder nicht, ist eine Entscheidung, die man sehr bewusst und gezielt treffen sollte. Wir geben in diesem Talk eine Entscheidungshilfe und nähern uns dem Thema aus den Blickwinkeln Fachlichkeit und Architektur. Und wir machen es uns einfach: Wir raten in diesem Talk vom Microservices-Einsatz kurzerhand ab. Äh, wie bitte? Ja, richtig gelesen - wir raten vom Microservice-Einsatz ab, ... ..., wenn fachliche und organisatorische Komplexität nicht groß genug ist! Schon Martin Fowler rät: Don't even consider microservices unless you have a system that's too complex to manage as a monolith. Doch was meint Fowler eigentlich mit "complex"? Wann ist ein IT-Vorhaben nur kompliziert? ..., wenn das Team nicht oder wenig dynamisch / flexibel agieren muss! In welchen Größenordnungen ist das eigentlich der Fall? Muss man schon Netflix sein oder geht's eine Nummer kleiner? ..., wenn der fachliche Schnitt nicht klar ist! Reicht da schon Datenhoheit als Kriterium aus? Wieviel fachliche Strukturierung brauchen wir? Wie groß oder klein ist denn "Micro"? Wie vermeidet man ein Microservice-Spaghetti? ..., wenn man sich nicht (vorher) die architektonischen und fachlichen Laufzeit-Auswirkungen klar macht! Das in Microservices geschnittene "Verteilte System" erfordert z. B., mit deutlich erhöhten Latenzen umzugehen. Und es zwingt einen, sich mit Eventual Consistency zu beschäftigen und mit teilfertigen, fachlich nicht (immer) konsistenten Teilzuständen. ..., wenn die Frage nach Integration nicht geklärt ist! Der ESB ist aus guten Gründen verpönt. Aber irgendeine Integrationstechnologie brauchen wir doch? Insbesondere ist auch die Integration bei gemeinsamen Benutzeroberflächen zu klären: Was für Web-Oberflächen recht einfach ist, ist für native oder andere Clients schon gar nicht mehr so klar. Microservices sind also ... vor allem nicht trivial. Sie betreffen verschiedenste fachliche, architektonische und organisatorische Aspekte. Wer da nicht alle Herausforderungen durchdenkt oder sich ihrer zumindest bewusst ist - nun, dem hatten wir ja auch abgeraten :-) Abstract
  4. Copyright © Accso – Accelerated Solutions GmbH 9 Zusammenfassung Welche

    Aufwände habe ich damit? Ich gewinne an Flexibilität! Agenda
  5. Copyright © Accso – Accelerated Solutions GmbH 10 gute funktionale

    Skalierbarkeit wachsende Komplexität, Größe Team, Geographische Verteilung Produktgröße / Fachlichkeit NfAs, Architektur, Technik wachsende (Team-) Autonomie Selbstorganisation Eigenverantwortung Organisatorische Koordinierung stetige/steigende Innovationsfähigkeit Liefergeschwindigkeit / Produktivität Änderbarkeit / Anpassbarkeit Erweiterbarkeit getrennte Lebens-/Deployment-Zyklen
  6. Copyright © Accso – Accelerated Solutions GmbH 11 Microservice-Architekturen fördern

    Wachstum und Flexibilität. Photo by Brian Breeden on Unsplash
  7. Copyright © Accso – Accelerated Solutions GmbH 12 Kosten und

    Nutzen sind abzuwägen! Netflix priorisiert Ziel „Innovation“ über „Zuverlässigkeit“ und „Effizienz“
  8. Copyright © Accso – Accelerated Solutions GmbH 13 Kosten und

    Nutzen sind abzuwägen! REWE priorisiert das Ziel „Wachstum“ 0-5 Teams 5-15 Teams 15-35 Teams 50+ Teams
  9. Copyright © Accso – Accelerated Solutions GmbH 14 Wie stellt

    sich Komplexität dar? Grad der Vernetzung Kommunikation wächst quadratisch mit der Anzahl der Teilnehmer
  10. Copyright © Accso – Accelerated Solutions GmbH 15 Wie stellt

    sich Komplexität dar? Rückkopplung Auch wenige Komponenten können bereits unvorhersehbares Verhalten bewirken
  11. Copyright © Accso – Accelerated Solutions GmbH 16 Microservices adressieren

    Komplexität, indem sie Kopplung reduzieren. Können wir wirklich mit Team-Skill Komplexität beherrschen?
  12. Copyright © Accso – Accelerated Solutions GmbH 17 Das Cynefin-

    Framework rät bei Komplexität zu Emergent Practices.
  13. Copyright © Accso – Accelerated Solutions GmbH 18 Komplexität senkt

    die Produktivität und erfordert eigene Lösungsstrategien.
  14. Copyright © Accso – Accelerated Solutions GmbH 19 Umgang mit

    Komplexität? Der Demingkreis: PDCA! Emergent Practice: Situativ reagieren – keine Allgemeinrezepte Im Unterschied zu komplizierten Situationen, wollen wir uns anpassen können, nicht optimieren. Es geht nicht primär um Kostenreduktion.
  15. Copyright © Accso – Accelerated Solutions GmbH 21 Aktuelles Erfahrungswissen

    greift bei Komplexität. Erklärung aus Wikipedia Komplexität bezeichnet das Verhalten eines Systems, dessen viele Komponenten auf verschiedene Weise miteinander interagieren können, nur lokalen Regeln folgen und denen Instruktionen höherer Ebenen unbekannt sind. „Intuition bedeutet, dass mein Gehirn Musterbildung gelernt hat, die jenseits meines rationalen Verstehens hilfreich sind.“ Prof. Peter Kruse über den menschlichen Umgang mit Komplexität Ignorieren: Trial & Error ist auf Dauer keine Lernstrategie Verdrängen: Beim Alten bleiben Verstehen: Kein Weiterkommen über rationales Verstehen Ausblenden: Simplify your Life – Trivialisierung durch Reduzieren auf einzelne Faktoren
  16. Copyright © Accso – Accelerated Solutions GmbH 24 Das Team

    muss Gesamtverantwortung übernehmen: Autonomie Produkte statt Projekte über den gesamten Lebenszyklus
  17. Copyright © Accso – Accelerated Solutions GmbH 25 Wie hängen

    Komplexität und Autonomie voneinander ab? Komplexität Autonomie niedrig hoch wenig viel
  18. Copyright © Accso – Accelerated Solutions GmbH 26 Wie hängen

    Komplexität und Autonomie voneinander ab? Komplexität Autonomie Monolithen niedrig hoch wenig viel Monolithen eignen sich für gut planbare Situationen.
  19. Copyright © Accso – Accelerated Solutions GmbH 27 Wie hängen

    Komplexität und Autonomie voneinander ab? Komplexität Autonomie Monolithen niedrig hoch wenig viel Monolithen eignen sich für gut planbare Situationen. Microservices Microservices eignen sich für hohe Flexibilität.
  20. Copyright © Accso – Accelerated Solutions GmbH 28 Zusammenfassung Welche

    Aufwände habe ich damit? Ich gewinne an Flexibilität! Agenda
  21. Copyright © Accso – Accelerated Solutions GmbH 29 gute funktionale

    Skalierbarkeit strenge Konsistenz wachsende Komplexität, Größe Team, Geographische Verteilung Produktgröße / Fachlichkeit NfAs, Architektur, Technik wachsende (Team-) Autonomie Selbstorganisation Eigenverantwortung Organisatorische Koordinierung gute technische Beherrschbarkeit technische Skalierbarkeit Automatisierung Dezentralisierung Berechtigungsschutz Resilience Refactoring-Fähigkeit stetige/steigende Innovationsfähigkeit Liefergeschwindigkeit / Produktivität Änderbarkeit / Anpassbarkeit Erweiterbarkeit getrennte Lebens-/Deployment-Zyklen Testbarkeit gute Beobachtbarkeit fachliches Monitoring technisches Monitoring
  22. Copyright © Accso – Accelerated Solutions GmbH 35 DDD hilft

    bei der Modellierung fachlicher Grenzen
  23. Copyright © Accso – Accelerated Solutions GmbH 36 DDD hilft

    bei der Modellierung fachlicher Grenzen Daten-orientierter Schnitt? Nutzer(gruppen) / Use-Case- orientierter Schnitt? Schnitt nach Konsistenz?
  24. Copyright © Accso – Accelerated Solutions GmbH 37 Onion-Architektur hilft

    bei der Umsetzung Umsetzung mit Onion / Hexagonaler Architektur / Clean
  25. Copyright © Accso – Accelerated Solutions GmbH 38 Domain Model

    Application API Onion-Architektur hilft bei der Umsetzung (oder Hexagonale Architektur oder Clean Architecture) Abhängig- keiten
  26. Copyright © Accso – Accelerated Solutions GmbH 41 Welche Qualitätseigenschaften

    sind zu erfüllen? Strenge Konsistenz durch Orchestrierung nötig?
  27. Copyright © Accso – Accelerated Solutions GmbH 42 Strenge Konsistenz

    durch Orchestrierung nötig? Reicht Choreography mit Eventual Consistency? Welche Qualitätseigenschaften sind zu erfüllen?
  28. Copyright © Accso – Accelerated Solutions GmbH 43 Verteilung bedingt

    getrennte Datentöpfe! Keine Konsistenz, nur „Eventual Consistency“ Daten Daten Daten Daten Daten Daten Daten Daten
  29. Copyright © Accso – Accelerated Solutions GmbH 45 Verteilung ermöglicht

    getrennte Datenmodelle! Keine Konsistenz, nur „Eventual Consistency“ Daten Daten Daten Daten Daten Daten Daten Daten
  30. Copyright © Accso – Accelerated Solutions GmbH 46 Wie spielen

    Autonomie und Konsistenz zusammen? Autonomie wenig viel viel wenig Konsistenz
  31. Copyright © Accso – Accelerated Solutions GmbH 47 Wie spielen

    Autonomie und Konsistenz zusammen? Autonomie Monolithen wenig viel viel wenig Konsistenz Monolithen eignen sich bei hoher fachlicher und organisatorischer Konsistenz.
  32. Copyright © Accso – Accelerated Solutions GmbH 48 Wie spielen

    Autonomie und Konsistenz zusammen? Autonomie Monolithen Microservices wenig viel viel wenig Konsistenz Monolithen eignen sich bei hoher fachlicher und organisatorischer Konsistenz. Microservices eignen sich für starke Entkopplung.
  33. Copyright © Accso – Accelerated Solutions GmbH 55 Verteilung wirkt

    sich aus: Latenz! … und weitere Fehler- quellen!
  34. Copyright © Accso – Accelerated Solutions GmbH 57 Der fachliche

    Gesamt- überblick darf nicht auf der Strecke bleiben! BAM? Dashboards? KPIs?
  35. Copyright © Accso – Accelerated Solutions GmbH 58 Verteilung wirkt

    sich aus: Schnittstellen! Application Component2 Component1 Component1 Component2 Versionierung? Keine Kenntnis über Nutzer Anpassungen über Refactoring nicht mehr möglich und schwer testbar Unterschiedliche Release-Zyklen (ggf.) Verlust von Synchronität und Reihenfolgen
  36. Copyright © Accso – Accelerated Solutions GmbH 59 Verteilung wirkt

    sich aus: Schnittstellen! Component1 Component2 Interaktionsarten bei DDD • Open-Host- Service • Conformist • Customer- Supplier • Anticorruption- Layer • … Versionierung? Keine Kenntnis über Nutzer Anpassungen über Refactoring nicht mehr möglich und schwer testbar Unterschiedliche Release-Zyklen (ggf.) Verlust von Synchronität und Reihenfolgen
  37. Copyright © Accso – Accelerated Solutions GmbH 60 Wie integriert

    man die Services, v.a. in „dem“ Client?
  38. Copyright © Accso – Accelerated Solutions GmbH 61 Wie integriert

    man die Services, v.a. in „dem“ Client?
  39. Copyright © Accso – Accelerated Solutions GmbH 62 Wie integriert

    man die Services, v.a. in „dem“ Client?
  40. Copyright © Accso – Accelerated Solutions GmbH 63 Zusammenfassung Welche

    Aufwände habe ich damit? Ich gewinne an Flexibilität! Agenda
  41. Copyright © Accso – Accelerated Solutions GmbH 64 gute funktionale

    Skalierbarkeit strenge Konsistenz wachsende Komplexität, Größe Team, Geographische Verteilung Produktgröße / Fachlichkeit NfAs, Architektur, Technik wachsende (Team-) Autonomie Selbstorganisation Eigenverantwortung Organisatorische Koordinierung gute technische Beherrschbarkeit technische Skalierbarkeit Automatisierung Dezentralisierung Berechtigungsschutz Resilience Refactoring-Fähigkeit stetige/steigende Innovationsfähigkeit Liefergeschwindigkeit / Produktivität Änderbarkeit / Anpassbarkeit Erweiterbarkeit getrennte Lebens-/Deployment-Zyklen Testbarkeit gute Beobachtbarkeit fachliches Monitoring technisches Monitoring
  42. Copyright © Accso – Accelerated Solutions GmbH 65 gute funktionale

    Skalierbarkeit strenge Konsistenz wachsende Komplexität, Größe Team, Geographische Verteilung Produktgröße / Fachlichkeit NfAs, Architektur, Technik wachsende (Team-) Autonomie Selbstorganisation Eigenverantwortung Organisatorische Koordinierung gute Beobachtbarkeit fachliches Monitoring technisches Monitoring gute technische Beherrschbarkeit technische Skalierbarkeit Automatisierung Dezentralisierung Berechtigungsschutz Resilience Refactoring-Fähigkeit stetige/steigende Innovationsfähigkeit Liefergeschwindigkeit / Produktivität Änderbarkeit / Anpassbarkeit Erweiterbarkeit getrennte Lebens-/Deployment-Zyklen Testbarkeit
  43. Copyright © Accso – Accelerated Solutions GmbH 66 fachliche und

    organisatorische Komplexität nicht groß genug ist! das Team nicht oder wenig dynamisch / flexibel agieren muss! der fachliche Schnitt nicht klar ist! architektonische und fachliche Laufzeit- Auswirkungen nicht geklärt sind! die Frage nach Integration nicht geklärt ist! Wir raten vom Microservice-Einsatz ab, wenn …
  44. Copyright © Accso – Accelerated Solutions GmbH 68 Leseliste für

    den Einstieg Prof. Peter Kruse Wie reagieren Menschen auf wachsende Komplexität 03/2008 https://www.youtube.com/watch?v=m3 QqDOeSahU Verdeutlicht die Bedeutung von Komplexität für unsere Lösungsstrategien Tobias Flohre Wer Microservices richtig macht, braucht keine Workflow Engine und kein BPMN 09/2015 https://blog.codecentric.de/2015/09/wer- microservices-richtig-macht-braucht-keine-workflow- engine-und-kein-bpmn/ Verdeutlicht die konträren Philosophien Orchestrierung und Choreographie
  45. Copyright © Accso – Accelerated Solutions GmbH 69 Leseliste für

    den Einstieg Martin Fowler The Many Meanings of Event-Driven Architecture GOTO 2017, 05/2017 https://www.youtube.com/watch?v=STKCRSUsyP0 Verdeutlicht die Konsequenzen von Events als First Class Citizen der Architektur, ggf. mit eigenem Lebenszyklus. Stefan Tilkov Microservices: Patterns und Antipatterns 02/2018 https://vimeo.com/256411314 Verdeutlicht, wieso in einer Microservice- Architektur die Zielsetzung Evolution vorrangig ist gegenüber Wiederverwendung.
  46. Copyright © Accso – Accelerated Solutions GmbH 70 Leseliste für

    den Einstieg embarc architektur SPICKER: Microservices http://architektur-spicker.de/ Gute Kurzeinführung in das Thema Microservices. Martin Fowler BoundedContext 01/2014 https://martinfowler.com/bliki/BoundedContext.html Erklärt die Möglichkeiten von BoundedContexts.
  47. Copyright © Accso – Accelerated Solutions GmbH 71 Leseliste für

    den Einstieg Stephan Schneider Onion-Achitektur und Ports-and- Adapters-Stil — ein Vergleich 10/2018 https://www.maibornwolff.de/blog/ddd- architekturen-im-vergleich Vergleicht verschiedene Umsetzungsstile zu DDD.
  48. Copyright © Accso – Accelerated Solutions GmbH 72 72 72

    Accso – Accelerated Solutions GmbH T | +49 6151 13029-0 E | [email protected] @ | www.accso.de Berliner Allee 58 | 64295 Darmstadt Moltkestraße 131a | 50674 Köln Balanstraße 55 | 81541 München Artikelserie in Informatik Aktuell https://www.informatik- aktuell.de/entwicklung/methoden/ microservices-fachliche- entscheidungshilfen-fuer-den- einsatz.html https://tinyurl.com/y2455sun
  49. Copyright © Accso – Accelerated Solutions GmbH 73 Quellen, Links

    Folien 4, 11, 30, 31, 32, 33 - Symbolbild Monolith Foto von Brian Breeden auf Unsplash; https://unsplash.com/search/photos/limestone?utm_source=unsplash&utm_medium=referral&utm_content=creditC opyText Folien 5, 30, 31, 32, 33 - Symbolbild Modulith Foto von Annie Spratt, Unsplash; https://unsplash.com/search/photos/limestone?utm_source=unsplash&utm_medium=referral&utm_content=creditC opyText Folien 7, 30 - Symbolbild Microservices Foto von Jarren Simmons, Unsplash; https://unsplash.com/search/photos/basalt- rock?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText Folie 12 - Netflix' Prioritäten Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned (GOTO 2016); Ruslan Meshenberg (Netflix); 09/2016; https://www.youtube.com/watch?v=57UK46qfBLY ; bei 16:40
  50. Copyright © Accso – Accelerated Solutions GmbH 74 Quellen, Links

    Folie 13 - REWE Wachstum Vom Testen von Monolithen zur Qualitätssicherung für Microservices; Oliver Monneke, Michael Kutz; 06/2018; https://prezi.com/p/4bwxooscihil/2018-06-26-rewe-digital-meetup-juni/ Folie 14 - Netflix Deathstar https://www.slideshare.net/adriancockcroft/goto-berlin Migrating to Microservices (GOTO14); Adrian Cockcroft (Netflix); 11/2014 Folie 15 - Video Doppelpendel Double Pendulum Chaos Light Writing (computer simulation) 4; Paul Nathan; 10/2010; https://www.youtube.com/watch?v=V4hvENrtMeE&feature=youtu.be Folie 16 - Martin Fowler https://martinfowler.com/ Folie 16 - Produktivität MicroservicePremium; Martin Fowler; 03/2015; https://martinfowler.com/bliki/MicroservicePremium.html
  51. Copyright © Accso – Accelerated Solutions GmbH 75 Quellen, Links

    Folie 17 - Dave Snowden https://cognitive-edge.com/our-people/dave-snowden/ Folie 17, 19 - Cynefin-Framework https://en.wikipedia.org/wiki/Cynefin_framework Folie 19 - William Edwards Deming https://de.wikipedia.org/wiki/William_Edwards_Deming Folie 19 - Demingkreis https://de.wikipedia.org/wiki/Demingkreis Folie 20 - Video Prof. Peter Kruse Wie reagieren Menschen auf wachsende Komplexität; 03/2008; https://www.youtube.com/watch?v=m3QqDOeSahU Folien 22, 23 - Cross-/Funktionale Teams Microservices - a definition of this new architectural term; James Lewis, Martin Fowler; 03/2014; https://www.martinfowler.com/articles/microservices.html
  52. Copyright © Accso – Accelerated Solutions GmbH 76 Quellen, Links

    Folien 22, 23 - Melvin Conway https://twitter.com/conways_law Folie 24 - Teambuilding Teambuilding Übungen: Bessere Teams bauen; https://karrierebibel.de/teambuilding/ Folie 24 - Teams Trudy Mandeville; https://globaltalentadvisors.com/2017/04/the-importance-of-cross-functional-instructional- design-teams/ Folie 24 - Delegation Poker https://management30.com/practice/delegation-poker/ Folie 31 - Simon Brown, Twitter https://twitter.com/simonbrown/status/962945350737825793 Folie 32 - Modular Monolith Simon Brown; http://www.codingthearchitecture.com/presentations/devnexus2016-modular-monoliths
  53. Copyright © Accso – Accelerated Solutions GmbH 77 Quellen, Links

    Folie 33 - Kirk Knoernschild Java Application Architecture; http://www.kirkk.com/modularity/ Folie 33 - Vortrag "Modularity Patterns"; Frankfurter Entwicklertag 2018 https://entwicklertag.de/frankfurt/2018/modularity-patterns-mit-java-9-jigsaw Folien 34, 35, 36, 37 - Bounded Context Martin Fowler; BoundedContext; 15.01.2014; https://martinfowler.com/bliki/BoundedContext.html Folien 39, 40 - Skalierung James Lewis; Martin Fowler; 25.3.2014; Microservices - a definition of this new architectural term; https://www.martinfowler.com/articles/microservices.html Folien 41, 42 - BPMN, Workflow Wer Microservices richtig macht, braucht keine Workflow Engine und kein BPMN; 09/2015; Tobias Flohre; https://blog.codecentric.de/2015/09/wer-microservices-richtig-macht-braucht-keine-workflow-engine-und-kein- bpmn/
  54. Copyright © Accso – Accelerated Solutions GmbH 78 Quellen, Links

    Folien 49, 53 - Uber Microservices Graph https://twitter.com/msuriar/status/1110244877424578560 Folien 50, 51, 52 - Netflix-Traffic-Flow (Vizceral) Mastering Chaos - A Netflix Guide to Microservices (QCon 2016); Josh Evans (Netflix); 06/2016; https://www.youtube.com/watch?v=CZ3wIuvmHeM ; 2:20 Folie 52 - Simian Army in Chaos Engineering; https://medium.com/netflix-techblog/the-netflix-simian-army- 16e57fbab116 ; https://en.wikipedia.org/wiki/Chaos_engineering Folie 55 - Latenz in der echten Welt https://imgur.com/8LIwV4C Folie 56 - Tools, Logos Logo Graylog - https://www.graylog.org/ Logo Prometheus - https://prometheus.io/ Logo Grafana - https://grafana.com/ Logo Elk-Stack - https://www.elastic.co/elk-stack
  55. Copyright © Accso – Accelerated Solutions GmbH 79 Quellen, Links

    Folien 60, 61, 62 - Client-Integration Architektur-Spicker Nr. 3: Microservices; Team embarc; 02/2016; http://www.embarc.de/wp-content/uploads/2016/06/Architektur-Spicker3-Microservices.pdf Folie 67 - Twitter, Phil Webb https://twitter.com/phillip_webb/status/1127233088478531584
  56. Copyright © Accso – Accelerated Solutions GmbH 80 80 80

    Accso – Accelerated Solutions GmbH T | +49 6151 13029-0 E | [email protected] @ | www.accso.de Berliner Allee 58 | 64295 Darmstadt Moltkestraße 131a | 50674 Köln Balanstraße 55 | 81541 München https://speakerdeck.com/mrtnlhmnn @accso @mrtnlhmnn https://accso.de/tag/microservices/ https://accso.de/ueber-uns/veroeffentlichungen- und-konferenzbeitraege/
  57. Copyright © Accso – Accelerated Solutions GmbH 81 SHARING YOUR

    CHALLENGE 81 Copyright © Accso GmbH Accso – Accelerated Solutions GmbH T | +49 6151 13029-0 E | [email protected] @ | www.accso.de Berliner Allee 58 | 64295 Darmstadt Moltkestraße 131a | 50674 Köln Balanstraße 55 | 81541 München