microservices - architekturansatz mit grossen herausforderungen und gewissen nebenwirkungen
TRANSCRIPT
.consulting .solutions .partnership
Microservices Architekturansatz mit großen Herausforderungen und gewissen Nebenwirkungen Dipl.-Inf. Univ. Ralf S. Engelschall msg Applied Technology Research
Version: 1.2.7 (2016-02-11)
.consulting .solutions .partnership
Teil 1: Name of the Game Um was geht es? Motivation, Beispiel, begleitende Trends/Hypes? Characteristics.
Microservices
Motivation (1/3): Gartner‘s 10 Strategic Technology Trends for 2016
© msg | 2015 | Microservices 4
• The Device Mesh (IoT)
• Ambient User Experience (Digital Transformation)
• 3D Printing Materials (Manufacturing)
• Information of Everything (Big Data)
• Advanced Machine Learning (Neural Networks)
• Autonomous Agents and Things (IoT)
• Adaptive Security Architecture (Self-Protection)
• Advanced System Architecture (FPGA)
• Mesh App and Service Architecture (Microservices)
• Internet of Things Platforms (IoT)
(2015-10-06)
Motivation (2/3): Skalierbarkeit anhand des „Scale Cube“
Microservices
© msg | 2015 | Microservices 5
Beispiele:
• X-Achse: Load Balancing
• Y-Achse: Microservice Architecture
• Z-Achse: Data Partitioning
Microservices
Motivation (3/3): Digital Transformation & Systems of Engagement
© msg | 2015 | Microservices 6
System of Record
Reverse Proxy
Client
Client
Client
Client
Intranet DMZ Internet
Microservices
Motivation (3/3): Digital Transformation & Systems of Engagement
© msg | 2015 | Microservices 7
System of Record
Gateway
Client
Client
Client
Client
System of Engagement
Third-Party SoE
Third-Party SoE
Intranet DMZ Cloud Internet
Name of the Game: Microservice-Architecture (MSA)
• Bei einer Microservice-Architektur werden Anwendungen, anstatt wie üblich als Monolith, über lose-gekoppelte fachlich-abgeschlossene funktionale Services kompositioniert.
• Die Architektur folgt somit primär einem vertikalen (Fachliche Domänen), anstatt wie sonst üblich einem horizontalen Schnitt (Frontend/Backend Tiers).
• Die einzelnen Services einer Anwendung können insbesondere mit unterschiedlichen Technologien implementiert werden, einen individuellen und von anderen Services unabhängigen Entwicklungs- und Release-Prozess durchlaufen und flexibel in Cloud-Umgebungen installiert werden.
• Microservices erlauben eine sehr hohe Skalierbarkeit sowohl in der Entwicklung (Effizienz über Full-Stack) als auch im Betrieb (Performance).
Microservices
© msg | 2015 | Microservices 8
Heterogeneity Resilience Scalability
Easy Deployment Organizational Alignment
Composability Reusability
Replaceability
Beispiel: Anwendung mit Microservice-Architecture
• Ein Online-Shop wird aus 9 Microservices kompositioniert: Portal Frontend Desktop
(Rich-Client, HTML5/JS, REST)
Portal Frontend Mobile (Rich-Client, HTML5/JS, REST)
Portal Backend (Thin-Server, Node/JS, REST+AMQP, Redis)
Customer (Thin-Server, Java EE, AMQP, PostgreSQL)
Authentication & Authorization (A&A) (Thin-Server, Node/JS, AMQP, Redis)
Product Catalog (Thin-Server, Node/JS, AMQP, MongoDB)
Shopping Cart (Thin-Server, Java EE, AMQP, PostgreSQL)
Payment (Thin-Server, Java EE, AMQP, PostgreSQL)
Shipping (Thin-Server, Java EE, AMQP, PostgreSQL)
Microservices
© msg | 2015 | Microservices 9
RabbitMQ RabbitMQ
Customer PostgreSQL Shipping PostgreSQL
A&A Redis Payment PostgreSQL
Product Catalog MongoDB
Shopping Cart PostgreSQL
Portal Frontend Desktop
Portal Backend Redis
Portal Frontend
Mobile
Bitte darüber nachdenken: Echt? Auch zur Arbeit mit dem Formel 1 Auto fahren?
Microservices
© msg | 2015 | Microservices 10
Standard Street Car: 10-15 year runtime standard approach mass technology general solutions optimized for daily basis
Formel 1 Racing Car: saison focus esoteric approach individual technology unique solutions optimized for speed
Business Information System Monolithic Architecture
24x7 Streaming Platform Microservice Architecture
Microservice-Architecture vs. Aktuelle Trends/Hypes
• Lose-gekoppelte fachlich-abgeschlossene funktionale Services.
• Vertikaler Schnitt über fachliche Domänen
• Mit unterschiedlichen Technologien implementierbar
• Individueller unabhängiger Entwicklungs- und Release-Prozess.
• Flexibel in Cloud-Umgebungen installierbar.
• Hohe Skalierbarkeit in Entwicklung und Betrieb.
Microservices
© msg | 2015 | Microservices 11
Domain-Driven Design (DDD): Modellierung von Software wird maßgeblich von den Fachlichkeiten der Anwendungsdomäne beeinflusst.
Conway‘s Law: Architektur folgt der Organsationsstruktur (bzw. Skill-Struktur)
DevOps: Angleichen der bei Entwicklung und Betrieb genutzten Anreize, Prozesse und Werkzeuge, um Brüche zwischen Entwicklung und Betrieb zu überwinden.
Agile Software Entwicklung: von den Anforderungen her „auf Sicht fahren“, kontinuierliche Releases eines „potentially shipable products“, flexibel auf Änderungen reagieren können.
Cloud Computing: Resourcen „on-demand“ und elastisch/skalierbar bereitstellen und über „pay-per-use“ abrechnen.
Polyglotism, SOA, IoT, EDA, CI, CD, IaaS, PaaS, ...
Business
Business Service
Infrastructure Service
Application
Infrastructure
Landscape Singleton Component
Microservice-Architecture vs. Service-Oriented Architecture (SOA)
Microservices
© msg | 2015 | Microservices 12
Business Architecture
Software Architecture
System Architecture
Enterprise Architecture
Service-Oriented Architecture
Microservice Architecture
Microservice-Architecture vs. Service-Oriented Architecture (SOA)
Microservices
© msg | 2015 | Microservices 13
Microservice Architecture Service = Provider Focus of Roles: Software Architect System Architect
Service Oriented Architecture Service = Consumer + Provider Focus of Roles: Enterprise Architect Software Architect
Monolith vs. Microservice vs. Self-Contained System (SCS)
Microservices
© msg | 2015 | Microservices 14
Monolith
Self-Contained System *
Microservice
Standalone User Interface YES YES MAYBE
User Interface Integration NO Hyperlinking Composition
Vertical Splitting NO Macro Level Micro Level
Service Integration NO NO YES
* http://scs-architecture.org/
Microservice-Architecture Characteristics (1/2)
Microservices
© msg | 2015 | Microservices 15
• Heterogeneity Vorteil: Flexibilität in Technologie-Wahl Nachteil: Mehr Know-how notwendig, höhere Betriebskosten, mehr Komplexität
• Resilience Vorteil: Sicherheit gegen Infrastruktur-Ausfall Nachteil: muss explizit dafür programmiert werden („Circuit Breaker“ Pattern, Auto-Reconnect, etc)
• Scalability Vorteil: höhere Entwickler-Effizienz, höhere Runtime-Performance Nachteil: erhöhte Komplexität, Service Discovery, schwierigeres Monitoring
• Easy Deployment Vorteil: jeder einzelne Microservice leichter installierbar/upgradebar Nachteil: Gesamtanwendung hat viele Abhängigkeiten
Microservice-Architecture Characteristics (2/2)
Microservices
© msg | 2015 | Microservices 16
• Organizational Alignment Vorteil: stärkerer Fokus auf fachliche Einheiten (wirkt Conway‘s Law — Architektur folgt Organisationsstruktur — entgegen) Nachteil: eventuell mehrere technische Durchstiche notwendig
• Composability Vorteil: Funktionalitäten flexibel zusammenbaubar Nachteil: erhöhte Komplexität durch Orchestrierung, mehr Abhängigkeiten entstehen
• Reusability Vorteil: Funktionalitäten in mehreren Anwendungen, nur einmal pflegen Nachteil: Alle Anwendungen gleichzeitig betroffen
• Replaceability Vorteil: Funktionalitäten getrennt austauschbar (Update/Upgrade) Nachteil: Alle Anwendungen gleichzeitig betroffen
Achtung, kein gegenseitiger Ausschluss: Architecture of Microservices = Layered Architecture
© msg | 2015 | Microservices 17
Microservices
Mic
rose
rvic
e 1
Mic
rose
rvic
e 2
Mic
rose
rvic
e 3
Mic
rose
rvic
e 4
.consulting .solutions .partnership
Teil 2: Herausforderungen Herausforderungen, die man meistern muss, um Microservice-Architecture in der Praxis sinnvoll einsetzen zu können...
Herausforderung 1/14: User Experience, Interoperabilität, Infrastruktur-Redundanz
Microservices
© msg | 2015 | Microservices 19
• Application-Cluster Releases 1-4 Mal pro Jahr wird eine ganze Gruppe von Anwendungen in einer neuen Version zur Verfügung gestellt. Alle Anwendungen sind dabei aufeinander abgestimmt.
• Application Releases 1-12 Mal pro Jahr wird jede Anwendung (unabhängig von den anderen Anwendungen) in einer neuen Version zur Verfügung gestellt.
• Microservice Releases 12-52 Mal pro Jahr wird ein Microservice in einer neuen Version zur Verfügung gestellt.
(-) Fachliche Redundanz (+) User Experience (+) Interoperabilität
(+) Flexibilität (+) Reaktionsfähigkeit (-) Gesamtkomplexität (-) Infrastruktur-Redundanz
Herausforderung 2/14: Etliche Architekturprinzipien gebrochen
© msg | 2015 | Microservices 20
Microservices
Herausforderung
Problem
Herausforderung 3/14: Design wird noch einen Schritt schwerer
Microservices
© msg | 2015 | Microservices 21
• Strukturierung eines Monolithen ist bereits schwer, Strukturierung von Microservices ist noch viel schwerer.
• Makro-Ebene: vertikale/fachliche Zerlegung Mikro-Ebene: horizontale/technische Zerlegung
• Weiterhin wichtige Aspekte: Modularization Bounded Contexts Separation of Concerns Simple Responsibility Principle ...
• Aber zusätzlich kommen neue Aspekte hinzu: [Microservice Instance] Service Discovery Service Liveness Network Partitioning Network Latency Data Consistency ...
Herausforderung 4/14: Dezentrale Datenhaltung und Datenvernetzung
Microservices
© msg | 2015 | Microservices 22
• Datenvernetzung („JOIN“) Microservice-übergreifend ist schwieriger.
• Entweder: Redundanzen über Datenversorgungsprozesse schaffen (und dann echten JOIN in der Datenbank des Microservice machen)
• Oder: ad-hoc Anfragen an andere Microservices stellen und den „JOIN“ im Microservice selbst machen.
• Im Idealfall: Microservice-Schnitt über ganze Use-Cases anstatt nur Domain Entities, um die Notwendigkeit für „JOINs“ zu vermeiden.
Herausforderung 5/14: Dezentrale Datenhaltung und Skalierbarkeit
Microservices
© msg | 2015 | Microservices 23
• Microservices sollen „self-contained“ sein, also u.a. ihre eigene Datenhaltung besitzen.
• Dies steht im Konflikt mit der Skalierbarkeit der Microservices über das Deployment mehrfacher Instanzen eines individuellen Microservices und einem Load-Balancer davor.
• Sharding: Entweder muss man im Load-Balancer eine fachliche Partitionierung der Daten vorsehen…
• Master-Slave: …und/oder man darf von N Instanzen des Microservice nur 1 in der Rolle Master (read/write) und (N-1) in der Rolle Slave (read-only) betreiben.
• Anti-Pattern Shared-Storage: N Microservices nutzen 1 Datenhaltung ist bei Microservice-Architecture kontraproduktiv!
B
P
LB
B B B
P
B B
Partition 1 Partition 2
Master Slave Slave Master Slave Slave
Herausforderung 6/14: Dezentrale Datenhaltung und Garantien
Microservices
© msg | 2015 | Microservices 24
• ACID (Atomicity, Consistency, Integrity, Durability) ist gutes Programmiermodel, aber nur innerhalb Microservice sinnvoll nutzbar.
• Verteilte ACID-Transaktionen bei Microservice-Architekturen sind eher ein Anti-Pattern, da schwergewichtig und kontraproduktiv.
• CAP-Theorem (C=Consistency, A=Availability, P=Partition-Tolerance): da bei Microservices P inhärent notwendig und A gewünscht, muß man auf C verzichten und kann nur noch „Eventual Consistency“ erhalten.
Herausforderung 7/14: Hoher Stellenwert der Schnittstellen
© msg | 2015 | Microservices 25
Microservices
Latency
Encoding/Decoding
Reconnection
Failure Detection
Asynchronism
Herausforderung 8/14: User Interface Approach (1/3)
© msg | 2015 | Microservices 26
Microservices
Herausforderung 8/14: User Interface Approach (2/3)
Microservices
© msg | 2015 | Microservices 27
• Ansatz 1: Microservice ist (Web-)Thin-Client und rendert seine zugehörige UI Dialoge selbständig (in HTML). UI ist entweder „standalone“ oder wird als Fragmente in Portal dargestellt.
• Ansatz 2: Microservice ist nur Thin-Server mit Daten-Schnittstelle und die UI ist nicht Teil der Microservice-Architektur der Anwendung.
• Ansatz 3: Microservice ist „standalone“ Rich-Client und rendert seine zugehörige UI (als Ganzes) selbständig (in HTML).
• Ansatz 4: Microservice ist „partial“ Rich-Client und integriert sich in Portal, um dort seine UI Dialoge selbständig zu rendern.
UI
Client Interface
Server Interface
Mask
UI
Client Interface
SV
UI
Client Interface
Mask
Server Interface
UI
SV
UI
Clie
nt
(Bro
wse
r)
Mic
rose
rvic
e
SV
UI
Mask
HT
ML
UI
Client Interface
Mask
Server Interface
SV
RE
ST
Ansatz 1 Ansatz 2 Ansatz 3 Ansatz 4
Herausforderung 8/14: User Interface Approach (3/3)
Microservices
© msg | 2015 | Microservices 28
L0-Shell (Operating System)
L1-Shell (Virtual Machine)
L2-Shell (Bootstrapping Framework)
L3-Shell (Runtime Framework)
L4-Shell (Environment Framework) L4-Shell (Environment Framework)
L5-Shell (Environment Library) L5-Shell (Environment Library)
Rich Client Code Thin-Client Mask
<iframe>
container
browser
window
background
process
HTML5 Rich-Client UI HTML5 Thin-Client UI
Herausforderung 9/14: Kommunikationsaufwand und Schnittstellen-Protokoll
Microservices
© msg | 2015 | Microservices 29
• Application Programming Interfaces (API) kosten recht wenig, Remote Network Interfaces (RNI) dagegen sehr viel mehr, wegen: Authentication Data Encoding/Decoding Data Validation Network Latency Handling Network Partitioning Handling Network Reconnection
• Konflikt: REST sehr fein-granular und Resourcen-orientiert, Microservices grob-granularer und Service-orientiert.
• Konflikt: REST ist Request/Response, Inversion of Control und Event-Emitter Patterns benötigen Rückkanal bzw. Publish/Subscribe. Anti-Pattern: Long-Polling über REST.
• Pattern: statt NxM Kommunikationskanälen zwischen Microservices, Reduktion auf N+M mit Hilfe einer Message-Queue.
„MQTT over Secure-Websockets“ als Protokoll erlaubt einheitlich sowohl
Browser zu Microservice als auch Microservice zu Microservice!
Herausforderung 10/14: Asynchronous Programming Model
Microservices
© msg | 2015 | Microservices 30
• Aufgrund der Verteilung der Microservices und der Kommunikation über Netzwerk-Protokolle erhält man unweigerlich ein asynchrones Progammiermodell. Dies ist bei der Entwicklung schwieriger („Callback-Hell“).
• Ohne Sprach- und Framework-Unterstützung ist dies zu aufwändig. Der Einsatz von höherwertigen Konzepten wie Promises/Futures, Reactive Streams, Actors, Generators, etc. ist notwendig.
Herausforderung 11/14: Versionierung und Abhängigkeiten
Microservices
© msg | 2015 | Microservices 31
• Schnittstellen zwischen Microservices: Versionierung und Backward-Compatibility ist ein absolutes Muss, Forward-Compatibility ist optional.
• Don‘t Repeat Yourself (DRY): Wiederverwendung nicht um jeden Preis, sondern die Alternativen klar abwegen: Zentrale Instanz des Microservice
(siehe: „aaa.example.com“) Lokale Instanz des Microservice pro Applikation
(siehe: „app1-aaa.example.com“) Integration gemeinsamer Build-Artefakte
(siehe: Maven/Nexus) Integration gemeinsamer VCS-Artefakte
(siehe: Git Submodules)
• Fachwelt ist sich uneinig: einerseits „technische Microservices wiederverwenden, fachliche Microservices sind tabu“ vs. (klassische SOA-Sichtweise) „generelle Wiederverwendung, insbesondere der fachlichen Microservices“.
V1 V2 V3 ComponentA (Consumer):
V1 V2 V3 Component B (Provider):
backward compatibility
forward compatibility
Herausforderung 12/14: Traceability & Monitoring
Microservices
© msg | 2015 | Microservices 32
• Aufgrund der Verteilung der Microservices und der Kommunikation über Netzwerk-Protokolle ist die Nachvollziehbarkeit (Traceability) und die Laufzeit-Überwachung (Monitoring) deutlich schwieriger.
• Hier ist ein zentraler Logging- und Monitoring-Service mit Event-Correlation unerläßlich, am besten sogar Anwendungs-übergreifend.
• Außerdem sollten im Idealfall Instanzen eines Microservice automatisch gestartet/gestoppt werden können, abhängig von einem gemessen Workload.
Herausforderung 13/14: Automatisierung des Deployments
Microservices
© msg | 2015 | Microservices 33
• Microservice Architecture ist in der Praxis nur mit Continuous Deployment wirklich effektiv.
• Development, Testing und/oder Cloud Environments benötigen stark automatisierte Deployment-Prozesse.
• Zusätzlich Prozesse eventuell über Container-Technologien unterstützen.
• Die Microservice-übergreifende konsistente Konfiguration einer Anwendung in einem Environment ist eine große Herausforderung.
Herausforderung 14/14: Security
Microservices
© msg | 2015 | Microservices 34
• Microservice Architecture führt zu einem hochgradig verteilten System, einschließlich vieler externer Netzwerk-Schnittstellen. Dies bedingt eine erhöhte Sicherheitsbetrachtung!
• Authentication („wer ist er?“): muss sich jeder Microservice getrennt darum kümmern oder wird ein zentraler Microservice dafür genutzt? Pattern: Querschnittlicher Authentication-Service und Token Passing zwischen Microservices.
• Authorization („was darf er?“): entscheidet das jeder Microservice getrennt oder wird im das zentral gesagt? Pattern: Querschnittlicher Authorization-Service und „Role Based Access Control“ über abgefragte und gecachte Zugriffsinformationen. Anti-Pattern: Netzwerk-Abfrage bei jeder Aktion.
Herausforderungen: Und (leider) viele weitere...
Microservices
© msg | 2015 | Microservices 35
• „Wie bringt man eine Vielzahl unterschiedlicher Microservices lokal als Entwickler zum Laufen?“ (z.B. über Container-Technologien)
• „Wie macht man sinnvolle Integrations-Tests in einem stark verteilten System von Microservices?“ (z.B. über separate Environments)
• „Wie geht man damit um, daß Heterogenität genau das Gegenteil von dem ist, was man bei Enterprise Architecture vom Mindset her anstrebt?“ (z.B. durch Vorgabe weniger alternativer Technologie-Stacks)
• ...
.consulting .solutions .partnership
Teil 3: Technology Trends Einige aktuelle Trends am Markt im Umfeld von Microservices
System Architecture: Trends, Trends, Trends, …
Microservices
© msg | 2015 | Microservices 37
DevOps Resource Virtualization Platform as a Service (PaaS)
Deployment Automation Configuration Automation Clustering & Service Discovery
FABRIC
Trend 1/6: DevOps
Microservices
© msg | 2015 | Microservices 38
• Ziel: Starke Verzahnung von Entwicklung (DEVelopment) und Betrieb (OPerationS)
• Vorteil: Synergie-Effekte zwischen Entwicklung und Betrieb nutzen
• Nachteil: Personen unterschiedlicher Ausbildung und Attitüde treffen aufeinander.
Quelle: http://www.nimbleams.com/blog/2014/2/12/my-devops-take-aways/
Trend 2/6: Virtualization Technology
Microservices
© msg | 2015 | Microservices 39
• Virtual Machines & Hypervisors
• Container & Runtime Closures
Trend 3/6: Platform as a Service (PaaS) in der Cloud
Microservices
© msg | 2015 | Microservices 40
• Application Deployment
• Application Lifecycle Management
• Operating System Control
Trend 4/6: Deployment Automation
Microservices
© msg | 2015 | Microservices 41
• Virtual Machine Configuration
• Container Configuration
• Component Packaging
• Component Deployment
• Virtual Machine Lifecycle Management
FABRIC
Trend 5/6: Configuration Automation
Microservices
© msg | 2015 | Microservices 42
• Configuration Parameters
• Configuration Templates
• Service Lifecycle Management
Trend 6/6: Cluster Management & Service Discovery
Microservices
© msg | 2015 | Microservices 43
• Cluster Membership Management
• Cluster Leader Election
• Service Discovery
• Service Routing
.consulting .solutions .partnership
Teil 4: Fazit Mein persönliches Fazit zu Microservice-Architecture!
Zum Schluss: Mein persönliches Fazit
• Interessanter „Nicht-Ganz-Neuer“ Ansatz: Microservice-Architecture ist ein interessanter Architektur-Ansatz, der als extremer Gegenpol zur klassischen monolithischen 3-Tier-Architecture verstanden werden kann.
• Aktuell noch überzogener Hype: Microservice-Architecture ist seit 18 Monaten auf dem „Gipfel der überzogenen Erwartungen“. Bevor das „Plateau der Produktivät“ kommt, muss das „Tal der Enttäuschungen“ und „der Pfad der Erleuchtung“ erst noch genommen werden.
• Selbe Herausforderungen wie SOA: Microservice-Architecture ist eine Ausprägung von Service-Oriented Architecture (SOA) und begegnet leider den selben heftigen Herausforderungen wie SOA und generell Distributed Systems (eines der schwierigsten Disziplinen der Informatik).
• Nur wenn man es wirklich braucht: Microservice-Architecture sollte nur gewählt werden, wenn fachliche Reaktionsgeschwindigkeit und Wiederverwendung, organisatorische Autonomie und organisatorische und Laufzeit-technische Skalierbarkeit absolut notwendig sind und der Betrieb flexibel genug ist.
• Notwendiger „Trade-In“: Bevor man eine Microservice-Architecture wählt, sollte man sich über den zu zahlenden Preis aufgrund der Nebenwirkungen sehr gut im Klaren werden!
• Aber dann ist Microservice Architecture wirklich cool!
Microservices
© msg | 2015 | Microservices 45
.consulting .solutions .partnership
msg systems ag (Headquarters) Robert-Buerkle-Str. 1, 85737 Ismaning/Munich Germany Phone: +49 89 96101-0 Fax: +49 89 96101-1113 [email protected] www.msg-systems.com