Anlässlich der EA-Community Rhien-Main Feb/2017 stellt Jan die Kerncharakteristika zu Microservice-Architekturen (MSA) vor und grenzt diese zu Service-orientierter Architektur (SOA) ab (No, it's not just another SOA). Dann zeigt er anhand weniger Slides wichtige Aspekte auf, auf die ein EA achten sollte, wenn das Thema ansteht. Abschließend fasst der Vortrag noch einmal zusammen und ordnet dem Architekturkonzept einen Platz in der IT-Landschaft zu.

1. 23.02.17 EACG GmbH 1
EA
or SOA strikes back?
Jan Thielscher, EA Community Rhein Main, 21. Feb 2017
Was Enterprise Acrhitects zu Microservices wissen sollten

2. Agenda
23.02.17 EACG GmbH 2
• EACG brief
• Zentrale Elemente einer Service-orientierten Architektur (SOA)
• Zentrale Elemente einer Micorservice-Architektur (MSA)
• Ausgewählte Gestaltungsaspekte von MSA
• Zusammenfassung

3. For over 12 years EACG supports its customers in gaining
competitive advantage from information Technology
23.02.17 Making IoT successful - some lessons 3
E A C G i s a p r o s p e r i n g A W S p a r t n e rE A C G S e r v i c e s
Cloud Service Rating Open Source Risk Management
E A C G i n n o v a t e sE A C G s e r v e s s t r o n g & u p c o m i n g b r a n d s

4. SOA entstand primär getrieben aus Integrationsnotstand
Grundidee:
Lose Kopplung von bestehenden Systemen und deren
Aktivierung für flexible Prozessgestatung
Zentrale Gestaltungscharakteristika einer SOA:
• Standards:
Datenaustausch, Kommunikationsformen
• Service Contract: Klar definiertes Interface mit spezifischer
Leistung existiert, keine „Backdoors“
• Unabhängigkeit/Lose Kopplung: Consumer und Provider
müssen einander nicht mehr kennen, Nutzung explizierter
Transport & Connectivity-Infrastrukturen (ESB!)
• Meta-Data:
Schemata, Explikation, Repositories, alles wird exponiert und
beschrieben
• Policy-driven:
Raum für nicht-funktionale Spezifika (Encryption, Protokolle,
andere technische Charakteristika)
• Dokumenten-basierter Datenaustausch:
XML bzw. SOAP-basierter Austausch entkoppelt von Daten-
Spezifika
23.02.17 EACG GmbH 4
Service Bus Repository
Provider
System2
Typische SOA-Struktur
Provider Sys1
Consumer

5. Microservice-Konzept entstand, um schnell viel zu erreichen
Grundidee:
Kleine Teams können kleine Aufgaben schneller lösen als
große Teams große Aufgaben
Zentrale Gestaltungscharakteristika einer
Microservice-Architektur (MSA):
• Services sind fokussiert auf eine kleine Aufgabe
• Services sind (weitgehend) autonom
Typische Vorteile einer MSA sind:
• Unabhängigkeit / Entkopplung
• Einfaches Deployment
• Leichte Ersetzbarkeit
• Dezentralisierung
• Technologische Heterogenität
• „Do one thing well“
• Operate your own code
• vereinfachte, organisatorische Abbildung
23.02.17 EACG GmbH 5
Svc1
Persis
tenz
Logic
UI
Svc2
Persis
tenz
Logic
UI
SvcN
Pesist
enz
Logic
UI
Mögliche MSA-Struktur
Beispiel: Bestellung Konto Kunde

6. Einfache organisatorische Abbildung – Was bedeutet das?
23.02.17 EACG GmbH 6
Team Code App Deploy
Traditionell(Branching)MSA-Ansatz
Amazon.com Fakten
~11,6 sec
Mean time between deployments (weekday)
1.079
Max # of deployments in a single hour
~10.000 server
Avg # of hosts updated simultaneously
PLEASE NOTE: Amazon has several thousands of developers ww!!
Gut gemacht, erlauben Microservice-Architekturen durch unbedingte Nebenläufigkeit exorbitante Liefergeschwindigkeiten

7. Geschwindigkeitsvorteile lassen sich nur bei hinreichender
prozessualer Reife erschließen
Anforderungen müssen für die Menge an Teams sinnvoll gestaltet werden
• Verständnis eines möglichen/sinnvollen Domänenschnitts auf PM-Seite wichtiges Erfolgskriterium, um
Arbeitsvorrat vorausschauend zu erzeeugen und zu verteilen
• Abhängigkeiten entlang von Prozessen sind rechtzeitig zu identifizieren und sinnvoll aufzulösen
Bsp.: Arbeitsanweisung => Messvorgang => Sollwerte => Sollwertabweichungen => Korrekturen
• Guter Überblick über die Bedarfe damit rechtzeitig technologische Meilensteine (bspw. zentrale Capabilities)
identifiziert und adressiert werden können. Nicht alles lässt sich mal eben im Sprint lösen.
Automation des Entwicklungs- und Deployment-Prozesses muss hinreichend fortgeschritten sein
• Hinreichende Testabdeckung im automatisierten Testen
• Keine manuelle Interaktion nach Freigabe
• Geeignete Rollback-Mechanismen
Operations-Verantwortung im DEV-Team
• keine langen Übergabe-Protokolle, Installationsanleitungen oder Quality-Gates
• Herausforderung der arbeitsvertraglichen Gestaltung meistern
23.02.17 EACG GmbH 7
Anforderungen an organisatorische Implementierung sind hoch und stellenweise nicht mit regulatorischen Anforderungen
bedingungslos vereinbar, jedoch Voraussetzung, um Geschwindigkeit wirklich zu erreichen => Es prüfe, wer sich binden will!

8. Lose Kopplung gibt es nicht kostenlos – Anforderungen an
Service-Design
Wichtiges Komponenten, über die ein solide aufgebauter
Dienst verfügen sollte:
• SERCVICE CONNECTOR:
Um externe Dienste aufzurufen, bietet sich die Entkapselung der
Logging und Monitoring –Aufgaben sowie der
Versionskompatibilität mit Hilfe eines Connectors an
• REPOSITORIES:
Der Dienst sollte über seine eigenes Persistenz-Management
verfügen. Abbildung auf den Aufgabenträger ist dann fast beliebig.
ACHTUNG! Kann bei hoher Skalierung zum Engpass werden
• RESOURCES/ API:
Um Dienste nach Außen bereitzustellen, ist ein API (REST)
bereitzustellen. Ideal, wenn dieses hausinternen Best-Practices und
Versionierungsregeln folgt.
• UI-FRAGENTS:
Richtig entkoppelt wird es erst, wenn der Dienst selbst sein UI
bereitstellt. Hierzu sind sinnvolle Snippets und „Seiten“
bereitzustellen, welche sich in ein beliebiges UI einbinden lassen.
ACHTUNG! => Interaktion mit Rechten und Rollen klären!
• DOMAIN LOGIC:
Der eigentliche, fachliche Inhalt des Service.
23.02.17 EACG GmbH 8
Typical Service Structure
Domain Logic
Repositories
Serviceconnector
API
External
Services
External Storage
Service
ResourcesUI fragments
Microservice

9. Einfluss auf Front-End-Architektur verstehen
23.02.17 EACG GmbH 9
Monolith Self contained Thin Front end
Svc 1
UI
API
Business
Logic
Persistence
Svc 2
UI
API
Business
Logic
Persistence
UI
API
Business
Logic
Persistence
UI UI1 UI2
Svc 1
API
Business
Logic
Persis-
tence
Svc 2
API
Business
Logic
Persis-
tence
FE-Architektur benötigt eine dynamische Steuerung (Registry) um auf das Vorhandensein von Diensten reagieren zu können
sowie das Routing entsprechend der Verfügbarkeit einzelner Versionen zu organisieren.
Lösungsansatz von Zalando s. https://github.com/zalando/tailor

10. Authentifikation und Autorisierung benötigen einen
allgemeinhin akzeptierten und verstandenen Mechanismus
Authentifikation und Autorisierung sind der verteilten Intelligenz
entsprechend anzupassen und zu organisieren:
• Identifikation bleibt unverändert, kann ausgelagert werden
(bspw. Auth0)
• Autorisierung kann nicht mehr zentral erfolgen, da
Ausprägung der Rechte Service-Angelegenheit ist
• Übergreifendes Rollenkonzept als konzeptuelles Bindeglied
erforderlich
• Rollen als Claim-Bestandteil klären und Standard für die
Abbildung bereitstellen
• Claims in Tokens packen und den Requests mitgeben
• Gleicher Mechanismus wie für API-Tokens denkbar
• Gültigkeit der Tokens und SSO orchestrieren
23.02.17 EACG GmbH 10
Svc 3
UIAP
I
Business
Logic
Persistence
Svc 2
UIAP
I
Business
Logic
Persistence
Svc 1
UIAP
I
Business
Logic
Persistence
Svc n
UIAP
I
Business
Logic
Persistence
Autorisierung wandert in die Dienste, übergreifend sind nur noch die Benutzertypen/-gruppen.
Rechtzeitig übergreifendes Claims-Konzept bereitstellen und etablieren
Authentifikation-
Provider

11. Vielzahl Teilnehmer erfordert neue Lösungsansatz für die
Verteilung von Informationen
Transaktionen gestalten sich im verteilten Umfeld
schwierig:
• Bedarf an Konsistenz erkennen und klären
• Auswirkung der Abweichung und (max.) akzeptable
Dauer einer möglichen Abweichung bestimmen
• Ggf. Service-Design anpassen
• Oder Prinzip der EVENTUAL CONSISTENCY
anwenden
„EVENTUAL CONSISTENCY“ beschreibt die
Akzeptanz, dass zeitweise auch ein inkonsistenter
Zustand wieder-gegeben werden könnte.
23.02.17 EACG GmbH 11
Svc 2
UI
API
Business Logic
Persistence
Svc 1
UI
API
Business Logic
Persistence
Event Store
Event Log
Event
Bedarf an verteilten Transaktionen rechtzeitig erkennen, Eventstore bereithalten,
Konsistenzerfordernis beretwillig auf den Prüfstand stellen
Event Store zur Event-Synchronisation

12. Entscheidung für die zu nutzende Abstraktion frühzeitig
herbeiführen: Pure Cloud vs. Container
Vorteile:
• Eine technische Komplexität weniger
• Einfacheres Debugging
• Weniger Anforderungen an Entwickler
Vorteile:
• Geringer Overhead für mehr Abstraktion
• Infrastrukturen inzwischen verfügbar und erprobt
• Wenn richtig gemacht, sehr hilfreich, cool & fancy
23.02.17 EACG GmbH 12
Wir empfehlen grundsätzlich zu entscheiden, ob Container-basiert oder nur
cloud-basiert: Je feiner die Service-Granularität, desto Container!
Hardware
Virtualisierung
Operating System
Service
Hardware
Virtualisierung
Operating System
Container
Service
Container
Service
Virtualisierung
Operating System
Container
Service
Container
Service
Virtualisierung
Operating System
Service
Container-basiertes Deployment on CloudPure Cloud-basiertes Deployment

13. Schnelle und autarke Deployments benötigen eine
vollautomatisierte Tool-Chain
Werkzeuge für die Automation der Tool-Chain sind vielfältig und nicht trivial zu organisieren
=> Zeit nehmen und Verantwortung definieren!
Wohlüberlegte Zusammenstellung und abgestimmte Konfiguration sind Erfolgsgarant für effektive Deployments
Komplexität einzelnen Teams zu überlassen ist aus unserer Sicht nicht empfehlenswert
23.02.17 EACG GmbH 13
Code Deploy
AWS Elastic
Container Registry Elastic Container
Service
AWS Elastic
Beanstalk
Elastic Load
Balancing
Lege frühzeitig Wert auf eine automatisierte, vollintegrierte Tool-Chain.
Schneller lässt sich Geld nicht sparen!
AWS
CodeCommit
instances
Container
?

14. MSAs nutzen Grundelemente der SOA, gehen aber weit
darüber hinaus
SOA entstand mit dem Bedarf, bestehenden Anwendungen entlang eines komplexen Unternehmens zu verbinden
• Fokus auf Integration, bzw. Explikation von Objekten und Funktionen einzelner Anwendungen
• Ambition Fluss- bzw. Prozess-Intelligenz auf eine autarke Instanz zu übertragen, unabhängig von den
„Anwendungen“
• Verliert durch Microservcie zu keinem Zeitpunkt seine Berechtigung oder Bedeutung im Unternehmenskontext
Microservices sind vor allem geeignet, die Entwicklungsgeschwindigkeit erheblich zu erhöhen, wenn
• Organisatorische als auch prozessuale Bedingungen (Anforderungen, Teams, Test, Deployment) stimmen
• Domäne hinreichend bekannt ist, um einen sinnvollen Service-Schnitt zu antizipieren
• Und die Architektur sinnvoll ist, da hier wirtschaftlich differenziert werden soll (eCommerce => Shop, Bank => UI)
und Änderungsgeschwindigkeit ein Erfolgskriterium ist.
23.02.17 EACG GmbH 14
Micoservice-Architekturen sind ein geeignetes Muster, um bei der Differenzierung im Wettbewerb mit viel
Man-Power schnell und effektiv zu sein. MSA sind kein Garant für effektive oder performante Architekturen.

15. Reading List (personal suggestions)
• Scaling Gilt: from Monolithic Ruby Application to Distributed Scala
Micro-Services Architecture
https://www.infoq.com/presentations/scale-gilt
• Nike‘s Jounrey to Microservices
http://www.slideshare.net/AmazonWebServices/arc308-nikes-journey-
into-microservices-aws-reinvent-2014
• Building Products at SoundCloud—Part III: Microservices in Scala and
Finagle
https://developers.soundcloud.com/blog/building-products-at-
soundcloud-part-3-microservices-in-scala-and-finagle
• Zalando: From Monolith to Microservices
https://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando
• IBM Redbooks: Best Practices for Microservices
https://www-01.ibm.com/marketing/iwm/dre/signup?source=mrs-form-
10410&S_PKG=ov53209
• Martin Fowler on Microservices (more Ressources)
https://martinfowler.com/articles/microservices.html
23.02.17 EACG GmbH 15

16. EACG GmbH – Enterprise Architecture Consulting Group
Taunustor 1 (TaunusTurm)
60310 Frankfurt am Main
T: +49 69 153 22 77 50
F: +49 69 153 22 77 51
W: https://www.eacg.de
Dipl.-Wirtsch.-Inf. Jan Thielscher, LL.M.
jan.thielscher@eacg.de