Upload
jan-thielscher
View
77
Download
1
Embed Size (px)
Citation preview
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
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
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
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
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
Persistenz
Logic
UI
Svc2
Persistenz
Logic
UI
SvcN
Pesistenz
Logic
UI
Mögliche MSA-Struktur
Beispiel: Bestellung Konto Kunde
Einfache organisatorische Abbildung – Was bedeutet das?
23.02.17 EACG GmbH 6
Team Code App Deploy
Trad
ition
ell (
Bra
nchi
ng)
MSA
-Ans
atz
Amazon.com Fakten
~11,6 secMean time between deployments (weekday)
1.079Max # of deployments in a single hour
~10.000 serverAvg # of hosts updated simultaneously
PLEASE NOTE: Amazon has several thousands of developers ww!!
Gut gemacht, erlauben Microservice-Architekturen durch unbedingte Nebenläufigkeit exorbitante Liefergeschwindigkeiten
Geschwindigkeitsvorteile lassen sich nur bei hinreichender prozessualer Reife erschließenAnforderungen 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ösenBsp.: 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!
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
Serv
ice
conn
ecto
r
API
ExternalServices
External Storage Service
ResourcesUI fragments
Mic
rose
rvic
e
Einfluss auf Front-End-Architektur verstehen
23.02.17 EACG GmbH 9
Monolith Self contained Thin Front end
Svc 1
UIAPI
Business Logic
Persistence
Svc 2
UIAPI
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önnensowie das Routing entsprechend der Verfügbarkeit einzelner Versionen zu organisieren.
Lösungsansatz von Zalando s. https://github.com/zalando/tailor
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
UIAPI
Business Logic
Persistence
Svc 2
UIAPI
Business Logic
Persistence
Svc 1
UIAPI
Business Logic
Persistence
Svc n
UIAPI
Business Logic
Persistence
Autorisierung wandert in die Dienste, übergreifend sind nur noch die Benutzertypen/-gruppen.Rechtzeitig übergreifendes Claims-Konzept bereitstellen und etablieren
Authentifikation-Provider
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
UIAPI
Business Logic
Persistence
Svc 1
UIAPI
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
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
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
instancesContainer
?
MSAs nutzen Grundelemente der SOA, gehen aber weit darüber hinausSOA 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.
Reading List (personal suggestions)
• Scaling Gilt: from Monolithic Ruby Application to Distributed Scala Micro-Services Architecturehttps://www.infoq.com/presentations/scale-gilt
• Nike‘s Jounrey to Microserviceshttp://www.slideshare.net/AmazonWebServices/arc308-nikes-journey-into-microservices-aws-reinvent-2014
• Building Products at SoundCloud—Part III: Microservices in Scala andFinaglehttps://developers.soundcloud.com/blog/building-products-at-soundcloud-part-3-microservices-in-scala-and-finagle
• Zalando: From Monolith to Microserviceshttps://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando
• IBM Redbooks: Best Practices for Microserviceshttps://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
EACG GmbH – Enterprise Architecture Consulting GroupTaunustor 1 (TaunusTurm)60310 Frankfurt am Main
T: +49 69 153 22 77 50F: +49 69 153 22 77 51W: https://www.eacg.de
Dipl.-Wirtsch.-Inf. Jan Thielscher, [email protected]