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

Break the Monolith - Microservices als Architekturstil für Enterprise Anwendungen

Break the Monolith - Microservices als Architekturstil für Enterprise Anwendungen

Einordnung von Microservices und der Prozesse zur deren Erstellung im Kontext von Enterprise Applikationen.

Joachim Rosskopf

November 29, 2015
Tweet

More Decks by Joachim Rosskopf

Other Decks in Programming

Transcript

  1. itm.net/cloud © ITM Beratungsgesellschaft mbH, 2015 AGENDA Page 2 ›

    Die ITM und aktuelle Entwicklungen / Herausforderungen in IT-Projekten › Microservices als Werkzeug zur Beherrschbarkeit › Betrachtung der fachlichen und technischen Herausforderungen von Microservices › Integration der Themen (Weiter-) Entwicklung & Betrieb › Die Notwendigkeit von DevOps & seiner Kultur › Konkrete Anwendungsfälle aus unserer Praxis 29.11.2016 go
  2. itm.net/cloud Monolithische Softwarearchitektur besitzt klare Abgrenzungen und starke Abhängigkeiten. WAS

    MACHT IT-PROJEKTE MOMENTAN UNANGENEHM? Page 7 › Erstellung neuer Features dauert zu lange. › Probleme geforderte Qualitätsziele zu erreichen. › Über Lebenszyklus hinweg geht architektuelle Qualität verloren. › Häufige, zeitnahes Deployment meist schwierig. › Vollständige Ablösung nur durch teure, risikoreiche Projekte. 29.11.2016 BESTEHENDE SYSTEME
  3. itm.net/cloud EVOLUTION EINES MONOLITHISCHEN SYSTEMS Page 8 29.11.2016 Initialer Zustand

    › Datenhaltung › Business Logik › Präsentation + Frameworks und Libraries Erweiterte Funktionalität Geänderte Verwendung Legende: Datenhaltung Business-Logik Präsentation / Interface
  4. itm.net/cloud Legende: Datenhaltung Business-Logik Präsentation / Interface BEISPIEL CONTENT MANAGEMENT

    SYSTEM Page 9 29.11.2016 Initialer Zustand Customer-Self-Service wird hinzugefügt Weltweites Ausrollen und mobile Anwendung
  5. itm.net/cloud Ziel ist es, den Anforderungsberg beherrschbarer zu machen und

    den Overhead zu begrenzen. KONSEQUENZEN Page 10 29.11.2016 REIBUNG VERRINGERN Änderungen sollen schneller durchgeführt werden. Alles was den Entwicklungsprozess ausbremst soll aus dem Weg geschafft werden. SKALIERBARKEIT ERREICHEN Zukünftige System müssen aus organisatorischer und technischer Sicht skalierbar sein. RISIKO BEGRENZEN Risiko ist ein immanenter Bestandteil komplexer Systeme. Die beste Strategie: auf Sicht fahren. Anforderungen
  6. itm.net/cloud © ITM Beratungsgesellschaft mbH, 2015 AGENDA › Die ITM

    und aktuelle Entwicklungen / Herausforderungen in IT-Projekten › Microservices als Werkzeug zur Beherrschbarkeit › Betrachtung der fachlichen und technischen Herausforderungen von Microservices › Integration der Themen (Weiter-) Entwicklung & Betrieb › Die Notwendigkeit von DevOps & seiner Kultur › Konkrete Anwendungsfälle aus unserer Praxis 29.11.2016 go Page 11
  7. itm.net/cloud LÖSUNGSANSATZ MIT MICROSERVICES Page 12 29.11.2016 Microservices Risiko begrenzen

    • Evolutionäres Design selbstkonsistenter Systeme • Continuous Integration • Testing Skalierbarkeit erreichen • Technische Skalierbarkeit durch Cloud-native Architekturen • Organisatorische Skalierbarkeit Reibung verringern • Shared-Nothing Architekturen • Continuous Integration, • Agile Teams, • Cloud, • Verteilte, hierarchische Governance (Strategic vs. Tactical)
  8. itm.net/cloud DER WEG ZUM MICROSERVICE Page 13 29.11.2016 ES GEHT

    UM BUSINESS FUNKTIONALITÄTEN Ein monolithisches System als Ausgangssituation
  9. itm.net/cloud MICROSERVICE - PRINZIPIEN & EIGENSCHAFTEN Page 14 29.11.2016 Microservices

    Kultur der Automation De- zentralisierung Abgrenzung interner Details Unabhängiges Deployment GEWÜNSCHT EIGENSCHAFTEN • Modularisierung und Rekombination der Funktionen • Möglichkeit Funktionsbausteine weiter zu entwickeln oder auszutauschen • Einfache, zeitnahe Bereitstellung neuer bzw. verbesserter Funktionen • Handhabung von Architektur- und Projektrisiken • Skalierbarkeit und Ausfallsicherheit Kleine, autonome Services
  10. itm.net/cloud © ITM Beratungsgesellschaft mbH, 2015 AGENDA › Die ITM

    und aktuelle Entwicklungen / Herausforderungen in IT-Projekten › Microservices als Werkzeug zur Beherrschbarkeit › Betrachtung der fachlichen und technischen Herausforderungen von Microservices › Integration der Themen (Weiter-) Entwicklung & Betrieb › Die Notwendigkeit von DevOps & seiner Kultur › Konkrete Anwendungsfälle aus unserer Praxis 29.11.2016 go Page 15
  11. itm.net/cloud EBENEN DER HERAUSFORDERUNG FÜR MICROSSERVICES Page 16 29.11.2016 GRANULARITÄT

    Maximierung von Kohäsion innerhalb eines Service INTEGRATION Spielregeln für Services; (LOHTSE prinzipien) PROZESS SYSTEM-SCHNITT Ausrichtung der System- grenzen an Domäne SERVICE-ARCHITEKTUR Service-Architektur: innere & äußere Sicht Analyse, Integration, Dokumentation, Qualitätssicherung PLATFORM Schaffung einer technischen Basis & Querschnittsfunktionen
  12. itm.net/cloud STUFE DER GRANULARITÄT ENTSCHEIDEND Page 18 29.11.2016 Modularisierung in

    wenige abgeschlossene Systeme Hochgradig verteiltes System aus vielen kleinen Funktionsbausteinen Konzentration auf das Wesentliche anhand der Fachlichkeit.
  13. itm.net/cloud Jedes System konzentriert sich auf einen Aspekt der Problemdomäne

    und liefert für sich genommen einen Mehrwert. FACHLICHER SCHNITT EINES E-COMMERCE-SYSTEMS Page 19 29.11.2016 News Downloads Aftersales Händler- suche Single- Sign-On Produkte Artikel
  14. itm.net/cloud Jeder fachliche Schnitt stellt ein abgeschlossenes System dar. ARCHITEKTUR

    DER ABGESCHLOSSENEN SYSTEME Page 20 29.11.2016 Jedes Abgeschlossene System enthält: › Präsentationsschicht oder APIs  Ausrichtung anhand der Use-Cases › Logik für die Geschäfts-Funktionen › Eigene Datenhaltung für Geschäftsobjekte Business Application Präsentation Persistenz
  15. 29.11.2016 Page 21 „If something is important, make it an

    explicit part of your design.“ James Lewis
  16. itm.net/cloud INNERE ARCHITEKTUR DES ABGESCHLOSSENEN SYSTEMS Page 22 29.11.2016 Persistenz

    RDB NoSQL DocDB Micro- service Micro- service Micro- service UI API API Monitoring / Logging Load Balancing / Autoscaling Jedes abgeschlossene System: › Muss sich an Spielregeln halten › Kann auf Infrastruktur zurückgreifen › Über innere Struktur selbst entscheiden › Skalierbarkeit › Ausfallsicherheit › Teamorganisation
  17. itm.net/cloud INTEGRATION VON ABGESCHLOSSENEN SYSTEMEN Page 23 › Übergeordnete Prinzipien

    zur Definition der Makro-Architektur notwendig › Freiheit und Unabhänigkeit bei Mikro-Architektur 29.11.2016 Makro-Architektur › Funktionale-Allokation › Data-Stewardship and -Governance › Kommunikations-Protokolle › Kein geteilter Zustand › Kein Code-Sharing › Integrationsidee › Betriebsgrundlagen Mikro-Architektur › Design Patterns › Technologie › Tools › Prozess/Workflow-Kontrolle › Make or Buy-Entscheidung Monitoring & Logging
  18. itm.net/cloud Kommunikation über die eigenen Grenzen hinweg, erfolgt nur über

    eine definierte Schnittstelle. INTEGRATION VON SELBSTKONSISTENEN SYSTEMEN Page 24 29.11.2016 Business Application Präsentation Persistenz Business Application Präsentation Persistenz
  19. itm.net/cloud © ITM Beratungsgesellschaft mbH, 2015 AGENDA › Die ITM

    und aktuelle Entwicklungen / Herausforderungen in IT-Projekten › Microservices als Werkzeug zur Beherrschbarkeit › Betrachtung der fachlichen und technischen Herausforderungen von Microservices › Integration der Themen (Weiter-) Entwicklung & Betrieb › Die Notwendigkeit von DevOps & seiner Kultur › Konkrete Anwendungsfälle aus unserer Praxis 29.11.2016 go Page 26
  20. itm.net/cloud MICROSERVICES IST AUCH EIN ORGANISATIONSTHEMA Page 27 29.11.2016 Analyse

    Implementierung Qualitätssicherung Delivery & Operations Dokumen- tation Themen der Microservices im Applikationslifecycle
  21. itm.net/cloud LIFECYCLE: AGILE ANFORDERUNGSANALYSE Page 28 29.11.2016 Analyse Implementierung Qualitätssicherung

    Delivery & Operations Dokumen- tation Grundideen › Für ein erfolgreiches Microservice System muss eine Zerlegung des Systems in Teil-Systeme Top-Down möglich sein. › Requirements Egineering ausgehend von Business Context nicht Product Context Agile Werkzeuge › Agile Analysewerkzeuge: › Priorisierung anhand von: • Value Proposition Design • Planning Poker Kooperativ vs. Autonom (Scope und Prozessgrenze) Erfassung von User-Stories Aufteilung auf Subsysteme Domänen-Analyse Fachliches Modell
  22. itm.net/cloud Ziel ist die Entwicklung einer evolutionären Architektur. LIFECYCLE: AGILER

    ENTWICKLUNGSPROZESS Page 30 29.11.2016 Strategie Analyse Imple- mentierung Qualitäts- sicherung Delivery & Operations Dokumen -tation Start Ziel vs. Strategisches taktisches Vorgehen
  23. itm.net/cloud LIFECYCLE: DOKUMENTATION Page 31 29.11.2016 Analyse Imple- mentierung Qualitäts-

    sicherung Delivery & Operations Doku- mentation › Sichtenbasierte, hierarchische Dokumentation › Teams teilen sich Struktur und Template Black Box White Box Black Box Black Box Black Box Gesamtsystem Abgeschlossenes System Microservice Komponente Detailierungsgrad
  24. itm.net/cloud LIFECYCLE: QUALITÄTSSICHERUNG Page 32 29.11.2016 Analyse Imple- mentierung Qualitäts-

    sicherung Delivery & Operations Doku- mentation Neue Herausforderungen & Bedeutung für das Testing › Interface des Systems › Negativ Verhalten beim Testen Consumer-Driven Contracts für Interface Destruktivität durch zufälliges Ausschalten einzelner Teile ANSÄTZE
  25. itm.net/cloud LIFECYCLE: DELIVERY & OPERATIONS Page 33 29.11.2016 Analyse Imple-

    mentierung Qualitäts- sicherung Delivery & Operations Doku- mentation › Mixed-Teams: Architekten, Administratoren, Technologen › Ziel: unabhängiges Arbeiten der Teams anhand übergeordneten Prinzipien FEDERATED GOVERNANCE Federated Coordination Teams A Team B Team C Architektur- zirkel Operations- Zirkel Technologie zirkel EA-Prinzipien
  26. itm.net/cloud © ITM Beratungsgesellschaft mbH, 2015 AGENDA › Die ITM

    und aktuelle Entwicklungen / Herausforderungen in IT-Projekten › Microservices als Werkzeug zur Beherrschbarkeit › Betrachtung der fachlichen und technischen Herausforderungen von Microservices › Integration der Themen (Weiter-) Entwicklung & Betrieb › Die Notwendigkeit von DevOps & seiner Kultur › Konkrete Anwendungsfälle aus unserer Praxis 29.11.2016 go Page 34
  27. 29.11.2016 Page 35 „Any organization that designs a system… will

    produce a design whose structure is a copy of the organization‘s communication structure.“ Mevlin Conway
  28. itm.net/cloud Continuous Integration mit DevOps: Verantwortung von der Erstellung bis

    hin zum Betrieb. AUTOMATISIERUNGSKULTUR: CONTINUOUS INTEGRATION › Beherrschbarkeit der Architektur durch Automatisierung. › Viele einzelne, lose Teile erfordern Überwachung, Reaktionsfähigkeit bei Updates und Fehlerbehebung. › Lokale Auswirkungen auf das Gesamtsystem  Aktualisierungen während dem Betrieb ermöglichen. „If it hurts do it more often“ Martin Fowler Page 36 29.11.2016
  29. itm.net/cloud Kurze Intervalle von Updates einzelner Microservices möglich. Evolutionäre Architektur,

    die das Gesamtgefüge fortentwickelt. ANSTUPSEN DES KOMPLEXEN SYSTEMS Continous Integration Big-Bang Releases Page 37 29.11.2016
  30. itm.net/cloud Reactive Manifest als Grundlage. CLOUD: UNTERSTÜTZT IN FLEXIBILITÄT UND

    REAKTIONSFÄHIGKEIT Page 38 29.11.2016 › Immutable Infrastructure › Infastructure as a Service › Platform as a Service › Rapid provisioning › Transparenz für Monitoring & Logging › Skalierbarkeit & Globalität › Untergeordnete Rolle der Datenmenge Reaktionsfähigkeit Nachrichten- orientierung Fehlerbehandlung Skalierbarkeit CLOUD
  31. itm.net/cloud Erstellung einer einheitlichen Basisplattform als wichtiger Grundstein für Gesamtarchitektur.

    PLATTFORMGEDANKE FÜR QUERSCHNITTSFUNKTIONEN › Ermöglich Standardisierung › Open-Source-Gedanke: Geschwindigkeit durch Offenheit ermöglichen › Bereitstellung von erfolgreichen Komponenten für andere Teams. › Code-Sharing ohne direkte Abhängigkeiten › Basis-Infrastruktur: Event-Sourcing, Asynchronität, Messaging, Monitoring › Entwicklung: Build-Tools, Testing › UI-Integration: Asset-Pipelines, Reverse-Proxies, Frontend-Server WERKZEUGKASTEN & PLATTFORM Page 39 29.11.2016
  32. itm.net/cloud Agile, CI, DevOps ROADMAP ZU EINER MICROSERVICE-ARCHITEKTUR Page 40

    29.11.2016 Team- & Prozess-Management Selbstkonsistente Applikationen Microservices 1 2 3 1 2 3 Schnitt, Integration, Plattform Skalierung der Funktionen innerhalb eines Sub-Systems Werkzeuge Phasen Microservice Monolith
  33. itm.net/cloud © ITM Beratungsgesellschaft mbH, 2015 AGENDA › Die ITM

    und aktuelle Entwicklungen / Herausforderungen in IT-Projekten › Microservices als Werkzeug zur Beherrschbarkeit › Betrachtung der fachlichen und technischen Herausforderungen von Microservices › Integration der Themen (Weiter-) Entwicklung & Betrieb › Die Notwendigkeit von DevOps & seiner Kultur › Konkrete Anwendungsfälle aus unserer Praxis 29.11.2016 go Page 41
  34. itm.net/cloud ANWENDUNGSFÄLLE: TYPO3 → CQRS Trennung von Schreib- und Lesezugriffen:

    › Ereignisgesteuerte Aktualisierung des lesenden Services › Datenhaltung jeweils getrennt für Anwendungsfall optimiert. › Unabhängige, gezielte Skalierbarkeit nach Bedarf möglich › Trennung von Verantwortlichkeiten Page 42 29.11.2016
  35. itm.net/cloud ANWENDUNGSFÄLLE: FLEET4ALL - ÜBERSICHT Page 43 29.11.2016 Reinigungsgeraet Reinigungsgeraet

    Reinigungsgeräte Reinigungsgeräte M2M Sensor- daten Fleet4All- Applikation Reinigungsgeraet Reinigungsgeraet Reinigungsgeräte Endkunden Reinigungsgeraet Reinigungsgeraet Reinigungsgeräte Interne Konsumenten
  36. itm.net/cloud ANWENDUNGSFÄLLE: FLEET4ALL - APPLIKATION Page 44 29.11.2016 Fleet4All Applikation

    Sensordaten- Anreicherung & Fusion Zustand / Benachrichtigung Stream Messwert- Extraktion Aggregation Stream Stream Langzeitspeicher (S3/Glacier) Ausfall und Schaden Verwendung Lokaler Zustand der Aggregationen Kampangen
  37. itm.net/cloud STRATEGIE › Identifikation › Applikations-Bewertung › IST-Stand der Bimodalen

    IT EMPFEHLUNG DER ROADMAP Page 45 29.11.2016 Proof of Concept Workshop 2 PLANUNG › Service-Definition › Fähigkeiten › Verantwortlichkeiten Workshop 3 IMPLEMENTIERUNG › Technologie mit EA-Prinzipien Workshop 4 BETRIEB › Lifecycle › Releaseplanung › Governance Technologische Umsetzung anhand geeignetem System Workshop 1 1 2 3 Microservice Monolith 4