Microservices - Architekturansatz mit grossen Herausforderungen und gewissen Nebenwirkungen

.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)


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


Beispiele:

• X-Achse: Load Balancing

• Y-Achse: Microservice Architecture

• Z-Achse: Data Partitioning

Microservices

Motivation (3/3): Digital Transformation & Systems of Engagement


System of Record

Reverse Proxy

Client

Client

Client

Client

Intranet DMZ Internet

Microservices

Motivation (3/3): Digital Transformation & Systems of Engagement


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


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


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


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


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


Business Architecture

Software Architecture

System Architecture

Enterprise Architecture

Service-Oriented Architecture

Microservice Architecture

Microservice-Architecture vs. Service-Oriented Architecture (SOA)

Microservices


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


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


• 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


• 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


Microservices

Mic

rose

rvic

e 1

Mic

rose

rvic

e 2

Mic

rose

rvic

e 3

Mic

rose

rvic

e 4


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


• 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


Microservices

Herausforderung

Problem

Herausforderung 3/14: Design wird noch einen Schritt schwerer

Microservices


• 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


• 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


• 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


• 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


Microservices

Latency

Encoding/Decoding

Reconnection

Failure Detection

Asynchronism

Herausforderung 8/14: User Interface Approach (1/3)


Microservices


Microservices


• 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


Microservices


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


• 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


• 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


• 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


• 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


• 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


• 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


• „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)

• ...


Teil 3: Technology Trends Einige aktuelle Trends am Markt im Umfeld von Microservices

System Architecture: Trends, Trends, Trends, …

Microservices


DevOps Resource Virtualization Platform as a Service (PaaS)

Deployment Automation Configuration Automation Clustering & Service Discovery

FABRIC

Trend 1/6: DevOps

Microservices


• 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


• Virtual Machines & Hypervisors

• Container & Runtime Closures

Trend 3/6: Platform as a Service (PaaS) in der Cloud

Microservices


• Application Deployment

• Application Lifecycle Management

• Operating System Control

Trend 4/6: Deployment Automation

Microservices


• Virtual Machine Configuration

• Container Configuration

• Component Packaging

• Component Deployment

• Virtual Machine Lifecycle Management

FABRIC

Trend 5/6: Configuration Automation

Microservices


• Configuration Parameters

• Configuration Templates

• Service Lifecycle Management

Trend 6/6: Cluster Management & Service Discovery

Microservices


• Cluster Membership Management

• Cluster Leader Election

• Service Discovery

• Service Routing


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 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

Microservices - Architekturansatz mit grossen Herausforderungen und gewissen Nebenwirkungen

Software

Transcript of Microservices - Architekturansatz mit grossen Herausforderungen und gewissen Nebenwirkungen