SlideShare ist ein Scribd-Unternehmen logo
Die Evolution zu Microservices
BAT 41 vom 2.November 2018
Pascal Auderset | Leiter IT Applikations- und Technologiearchitektur
Ausblick auf die nächsten 30 Minuten ….
Erfahrungen mit
Microservices
bei der Mobiliar
Einleitung
Digitale und agile Transformation in der Mobiliar
Die neue Zielarchitektur
Aus der Performance Krise hin zur neuen Zielarchitektur der IT-Landschaft, was waren
die Herausforderungen
Joint Application Plattform
Der nächste Schritt: Continuous Delivery, Docker und kleine Microservices im
Backend
1
2
3
2.11.2018Die Evolution zu Microservices 2
Die aktuellen Herausforderungen
Wo stehen wir heute; Demo
4
1 Einleitung
Das Verständnis von Microservices
2.11.2018
1 Einleitung
Die gemeinsamen Eigenschaften:
• Zerlegung in relativ kleine fachliche Services
• Services sind sehr lose gekoppelt
• Reduktion der Abhängigkeiten (Services
können einzeln installiert, aktualisiert und
verwaltet werden)
• Ermöglicht die dezentrale Datenhaltung
• Höherer Freiheitsgrad bei der Technologiewahl
Die Evolution zu Microservices 3
Chris Richardson https://microservices.io/index.html
• Microservices - also known as the microservice architecture - is
an architectural style that structures an application as a collection
of loosely coupled services, which implement business
capabilities. The microservice architecture enables the
continuous delivery/deployment of large, complex applications. It
also enables an organization to evolve its technology stack
Martin Fowler: https://martinfowler.com/articles/microservices.html
• The term "Microservice Architecture" has sprung up over the last
few years to describe a particular way of designing software
applications as suites of independently deployable services.
While there is no precise definition of this architectural style,
there are certain common characteristics around organization
around business capability, automated deployment, intelligence
in the endpoints, and decentralized control of languages and
data.
2.11.2018Die Evolution zu Microservices 4
….. 2015 2016 2017 2018
>
Digitale und agile Transformation in der Mobiliar
……
Performance Krise
Ökosysteme
Quantensprung
Digital Persönlich
2009
AI
Microservice
Architektur
209
Hybrid Cloud
Architecture
as Code
Continuous Delivery
Container Plattform
DevOps209
Start
FIT Vertrieb
PoC neue Zielarchitektur
Start agiles
Releasing
Einführung (NSP)
Schadenregulierung
Start der Umsetzung
End2End Digitalisierung
Agilisierung
Projekt Portfolio
Rechtsschutz
& Reise
Reset (NSP)
Schaden
Einführung (NSP)
Schadenaufnahme
Stau im
Portfolio
Neue
Zielarchitektur
209
Future IT (FIT)
Digitalisierung
2012
1 Einleitung
5
2. Die neue Zielarchitektur
Aus der Performance Krise hin zur neuen Zielarchitektur
2.11.2018
Flexibles Gesamtsystem in Bezug auf: Die gemeinsamen Eigenschaften:
• Neue fachliche Anforderungen schnell umsetzen
 Agiler werden:
 Klein (inklusive Datenhaltung) als Gegenmodell zu
Monolith
 lose Kopplung, leichte Austauschbarkeit (build for
rebuild before reuse)
 "Standard" Technologie Schnittstellen: REST
• Neue technologische Möglichkeiten schneller nutzen:
 Technologieauswahl auf aktuelle Versionen und
Konzepte heben (JEE6, verabschieden von den
alten J2EE Patterns)
 Frontend Technologie auf Internet ausrichten
• Schwankungen in der Last auffangen
 einzelne Services horizontal Skalieren (billiger)
 Services schnell restarten (LifeCycle einführen)
Die Evolution zu Microservices 6
• Zerlegung in relativ kleine fachliche Services
• Services sind sehr lose gekoppelt
• Reduktion der Abhängigkeiten (Services können
einzeln installiert, aktualisiert und verwaltet werden)
• Ermöglicht die dezentrale Datenhaltung
• Höherer Freiheitsgrad bei der Technologiewahl
2 Die neue Zielarchitektur
Die neue Zielarchitektur und deren Widerstände
• Vertikale Schneidung der
Komponenten entlang
der fachlichen Abhängigkeiten
und nicht der technischen
Layers
• Decompose by Business
Capability
2.11.2018Die Evolution zu Microservices 7
Ein einfaches, verständliches Modell zur Schneidung von Prozessen, Daten und
Managementinformationensystemen in Komponenten ist nötig!
2 Die neue Zielarchitektur
Die neue Zielarchitektur und deren Widerstände
grosse Diskussionen über
die Integrationsarten:
• Oracle Schema versus DB2
• MAIA MDA versus REST
• SOAP versus REST
• ESB versus wenig
Middleware
2.11.2018Die Evolution zu Microservices 8
Je eine Implementation als Integrationsart reicht:
Beispiel: Für Remote Procedure Invocation REST (oder auch gRPC, Apache Thrifth) und für Messaging Kafka
2 Die neue Zielarchitektur
Die neue Zielarchitektur und deren Widerstände
Interne Architektur
• DTO, versus, VO versus
Generiete Klassen um
Schnittstellen sicher und
versionierbar zu machen
• Abstraktionen innerhalb
eines Service (Layering)
2.11.2018Die Evolution zu Microservices 9
Mit Microservice ist die Innenarchitektur nicht mehr so wichtig wie früher, aber alle Anforderungen
müssen automatisch geprüft werden (automatische Governance)
2 Die neue Zielarchitektur
Die neue Zielarchitektur und deren Widerstände
Ergonomische Oberflächen die
Einheitlich aussehen, um die
manuellen Prozessbrüche zu
vereinfachen
2.11.2018Die Evolution zu Microservices 10
Einführen von einem einheitlichen Design ist aufwendig, aber nützlich um ein
Microservice Architektur auch im Frondend umzusetzen
2 Die neue Zielarchitektur
Ordnen der Entwicklungsplattformen und Umsetzung der Zielarchitektur
• Zielplattform für Eigenentwicklungen
festlegen und priorisieren
• Verantwortlichkeiten der
Entwicklungsplattformen festlegen
und regeln
• Roadmaps der einzelnen
Plattformen regeln
2.11.2018Die Evolution zu Microservices 11
Applikationsentwicklungsplattformen definieren und managen.
Nur eine präferierte Variante zulassen!
2 Die neue Zielarchitektur
2014
2017
Umsetzung der Zielarchitektur und priorisieren der Entwicklungsplattformen
Eine erste Version der JAP Plattform in einem
Projekt erfolgreich umsetzen und nutzen:
• Decompose by Business Capability
• Database per Service
• API Composition
• Service Component Testing
• Audit Logging
• Application Metrics
• Microservice Chassis
• External Configuration
• Remote Procedure Invication
• Distributet Tracing
• etc
2.11.2018Die Evolution zu Microservices 12
Standardisieren der nicht funktionalen Qualitätsanforderungen über Industriestandards
und wo nichts vorhanden selber umsetzen!
2 Die neue Zielarchitektur
https://microservices.io/patterns/index.html
Umsetzung der Zielarchitektur und priorisieren der Entwicklungsplattformen
Eine erste Version von Continuous
Integration und Continuous
Deployment einführen:
• bis auf die Testsysteme
• Automatisierung minimal
2.11.2018Die Evolution zu Microservices 13
Die 3 Grundprinzipien: Versionierung, Continuous Testing und Continuous Integration
müssen verankert werden um die Produktivität zu steigern!
2 Die neue Zielarchitektur
Herausforderungen bei der Umsetzung der Zielarchitektur
Aus Sicht Applikationsarchitektur:
• Wie klein / gross sind die
Microservices?
 Decompose by Business Capability
muss man lernen
• MDA versus Microservices
2.11.2018Die Evolution zu Microservices 14
2 Die neue Zielarchitektur
Decompose by Business Capability muss man lernen
Herausforderungen bei der Umsetzung der Zielarchitektur
Aus Sicht Technologiearchitektur
• Wie integrieren wir die "alten" Services und Applikationen
(inkl. Fehlerhandling)?
 viel Aufwand hineingesteckt, damit möglichst
Transparent und einfach für die Anwender
• DB welche DB2 versus Oracle Schemas
 Automatisieren der Bestellungen
• Trunked Bases Development
 durchsetzen
• Continuous Integration und Testing
 messen und vorgeben
• Fachliche Shared Libraries
 Kampf am Anfang verloren: nach gewisser Zeit von
selbst durchgesetzt
2.11.2018Die Evolution zu Microservices 15
2 Die neue Zielarchitektur
Die 3 Grundprinzipien: Versionierung, Continuous Testing und Continuous Integration
müssen verankert werden um die Produktivität zu steigern!
16
3. Joint Application Plattform
2.11.2018Die Evolution zu Microservices 17
….. 2015 2016 2017 2018
>
Digitale und agile Transformation in der Mobiliar
……
Performance Krise
Ökosysteme
Quantensprung
Digital Persönlich
2009
AI
Microservice
Architektur
209
Hybrid Cloud
Architecture
as Code
Continuous Delivery
Container Plattform
DevOps209
Start
FIT Vertrieb
PoC neue Zielarchitektur
Start agiles
Releasing
Einführung (NSP)
Schadenregulierung
Start der Umsetzung
End2End Digitalisierung
Agilisierung
Projekt Portfolio
Rechtsschutz
& Reise
Reset (NSP)
Schaden
Einführung (NSP)
Schadenaufnahme
Stau im
Portfolio
Neue
Zielarchitektur
209
Future IT (FIT)
Digitalisierung
2012
3 Joint Application Plattform
Continuous Delivery, Docker und kleine Microservices im Backend
Reduktion Aufwände für die Continuous Delivery
Pipeline (Effizient werden)
• Datenbank
• Incident Management
• Deployment Freigaben
Etablieren von automatischer Governance
• Build
• Codeverletzlichkeit und Coverage Analyse
• Testpyramide
• LifeCycle Methoden
• API Dokumentation
• DB Versionierung
2.11.2018Die Evolution zu Microservices 18
Automatisieren der Governance und erhöhen der Automatisierung der Continuous Pipeline führen zu effizienteren Teams
3 Joint Application Plattform
Continuous Delivery, Docker und kleine Microservices im Backend
Druck von den Entwickler für mehr Technologie in
den Services
JAP Version 2 der Plattform (Basis JEE7)
• Ersatz Single Service per VM durch Single
Service per Container
• Erweiterungen in allen Bisherigen Patterns und
neue zur Verfügung stellen:
 API Gateway (einfach)
 Erste Versionen von Messaging auf Basis JMS
(EventHub)
 Consumer Driven Contract Testing
 viel selbstgeschriebener Code entfernt
2.11.2018Die Evolution zu Microservices 19
Plattform weiter standardisieren, aber gleichzeitig Freiheiten für die Teams erarbeiten
3 Joint Application Plattform
Herausforderungen bei der Umsetzung der Joint Application Plattform
• Aus Sicht Applikationsarchitektur
 Der Zoo an Microservices wächst und wächst und wächst
 Mit den aktuellen Tools (EA und Casewise) halten wir
nicht Schritt
 Die Grösse der Microservices hat sich stabilisiert entlang
der Business Capabilities
 Frontend ist ein grosses Monolith
 Transaktionshandling (BASE, SAGA Pattern)
• Gewaltentrennung Dev / Ops
• Aus Sicht Technologie Architektur
 Neue Datenbanken ElasticSearch, Mongo
 Umbauen der gossen MS und Migration des Patterns
(viel Aufwand)
2.11.2018Die Evolution zu Microservices 20
Konsequent über alle Layer Microservices nutzen und Pain-Points entfernen
3 Joint Application Plattform
21
4. Die aktuellen Herausforderungen
2.11.2018Die Evolution zu Microservices 22
….. 2015 2016 2017 2018
>
Digitale und agile Transformation in der Mobiliar
……
Performance Krise
Ökosysteme
Quantensprung
Digital Persönlich
2009
AI
Microservice
Architektur
209
Hybrid Cloud
Architecture
as Code
Continuous Delivery
Container Plattform
DevOps209
Start
FIT Vertrieb
PoC neue Zielarchitektur
Start agiles
Releasing
Einführung (NSP)
Schadenregulierung
Start der Umsetzung
End2End Digitalisierung
Agilisierung
Projekt Portfolio
Rechtsschutz
& Reise
Reset (NSP)
Schaden
Einführung (NSP)
Schadenaufnahme
Stau im
Portfolio
Neue
Zielarchitektur
209
Future IT (FIT)
Digitalisierung
2012
4 Die aktuellen Herausforderungen
Aktuelle Herausforderungen
Architecture as Code
• Automatisieren
• Brainwork in den Soll Bildern
2009
SideCar
• Phyton
• GoLang
2009
JAP Version 3
• microprofile 2.0
• Service Registry
• SAGA Pattern und Events (Kafka)
• Nochmals Reduktion des selbstgeschriebenen Source-Codes
2009
Microservices im Frontend
• Modularisierung
2009
2.11.2018Die Evolution zu Microservices 23
4 Die aktuellen Herausforderungen
24.10.2018 24
Demo der Ist Werkzeuge
Aus Sicht:
- Applikationsarchitektur / Solutionarchitektur
- Teams
- Technologiearchitektur (Plattformarchitektur)
Zusammen-
fassung
3 Automatisieren der Governance
4
Versionierung, Continuous Testing und Continuous Integration
müssen verankert werden um Continuous Delivery zu leben
1
Konsequent über alle Layer Microservies nutzen und Painpoints
entfernen
2
Präferierte Entwicklungsplattform weiter standardisieren, aber
gleichzeitig Freiheiten für die Teams erarbeiten
Die Evolution zu Microservices 252.11.2018

Weitere ähnliche Inhalte

Was ist angesagt?

Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
engelschall
 
Continuous deployment in LeanIX @ Bonn Agile
Continuous deployment in LeanIX @ Bonn AgileContinuous deployment in LeanIX @ Bonn Agile
Continuous deployment in LeanIX @ Bonn Agile
LeanIX GmbH
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-Qualitätssicherung
Christian Baranowski
 
2011_Herbstcampus_Rapid_Cloud_Development_with_Spring_Roo
2011_Herbstcampus_Rapid_Cloud_Development_with_Spring_Roo2011_Herbstcampus_Rapid_Cloud_Development_with_Spring_Roo
2011_Herbstcampus_Rapid_Cloud_Development_with_Spring_Roo
Kai Wähner
 
Migration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud PlattformMigration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud Plattform
QAware GmbH
 
Evaluierung einer Hybris-Anbindung an Sitecore mittels Commerce Connect
Evaluierung einer Hybris-Anbindung an Sitecore mittels Commerce ConnectEvaluierung einer Hybris-Anbindung an Sitecore mittels Commerce Connect
Evaluierung einer Hybris-Anbindung an Sitecore mittels Commerce Connect
comspace GmbH & Co. KG
 
BATbern42 End-to-End Verantwortlichkeit in der Praxis: Scion Workbench
BATbern42 End-to-End Verantwortlichkeit in der Praxis: Scion WorkbenchBATbern42 End-to-End Verantwortlichkeit in der Praxis: Scion Workbench
BATbern42 End-to-End Verantwortlichkeit in der Praxis: Scion Workbench
BATbern
 
Webcast Azure Integration Migration - Von BizTalk in die Cloud
Webcast Azure Integration Migration - Von BizTalk in die CloudWebcast Azure Integration Migration - Von BizTalk in die Cloud
Webcast Azure Integration Migration - Von BizTalk in die Cloud
QUIBIQ Hamburg
 
Microsoft Azure Cloud mit der Sitecore Experience Platform
Microsoft Azure Cloud mit der Sitecore Experience PlatformMicrosoft Azure Cloud mit der Sitecore Experience Platform
Microsoft Azure Cloud mit der Sitecore Experience Platform
comspace GmbH & Co. KG
 
Hilfe, ich will meinen Monolithen zurück!
Hilfe, ich will meinen Monolithen zurück!Hilfe, ich will meinen Monolithen zurück!
Hilfe, ich will meinen Monolithen zurück!
OPEN KNOWLEDGE GmbH
 
Continuous Delivery @ FriendScout24 | Webinale 2012
Continuous Delivery @ FriendScout24 | Webinale 2012Continuous Delivery @ FriendScout24 | Webinale 2012
Continuous Delivery @ FriendScout24 | Webinale 2012
Michael Maretzke
 
Microservices mit dem MicroProfile
Microservices mit dem MicroProfileMicroservices mit dem MicroProfile
Microservices mit dem MicroProfile
OPEN KNOWLEDGE GmbH
 
Cloud Architekturen - von "less Server" zu Serverless
Cloud Architekturen - von "less Server" zu ServerlessCloud Architekturen - von "less Server" zu Serverless
Cloud Architekturen - von "less Server" zu Serverless
OPEN KNOWLEDGE GmbH
 
Microservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen solltenMicroservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen sollten
Jan Thielscher
 
Process Automation Forum Munich, Swiss Life
Process Automation Forum Munich, Swiss LifeProcess Automation Forum Munich, Swiss Life
Process Automation Forum Munich, Swiss Life
camunda services GmbH
 
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
OPEN KNOWLEDGE GmbH
 
SFScon16 - Edmund Schöpf: "Camunda BPM in Banking"
SFScon16 - Edmund Schöpf: "Camunda BPM in Banking"SFScon16 - Edmund Schöpf: "Camunda BPM in Banking"
SFScon16 - Edmund Schöpf: "Camunda BPM in Banking"
South Tyrol Free Software Conference
 
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
OPEN KNOWLEDGE GmbH
 
API-Design, Microarchitecture und Testing
API-Design, Microarchitecture und TestingAPI-Design, Microarchitecture und Testing
API-Design, Microarchitecture und Testing
OPEN KNOWLEDGE GmbH
 
Public Cloud Erfahrungsbericht SBB
Public Cloud Erfahrungsbericht SBBPublic Cloud Erfahrungsbericht SBB
Public Cloud Erfahrungsbericht SBB
BATbern
 

Was ist angesagt? (20)

Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
 
Continuous deployment in LeanIX @ Bonn Agile
Continuous deployment in LeanIX @ Bonn AgileContinuous deployment in LeanIX @ Bonn Agile
Continuous deployment in LeanIX @ Bonn Agile
 
Einführung in die Software-Qualitätssicherung
Einführung in die Software-QualitätssicherungEinführung in die Software-Qualitätssicherung
Einführung in die Software-Qualitätssicherung
 
2011_Herbstcampus_Rapid_Cloud_Development_with_Spring_Roo
2011_Herbstcampus_Rapid_Cloud_Development_with_Spring_Roo2011_Herbstcampus_Rapid_Cloud_Development_with_Spring_Roo
2011_Herbstcampus_Rapid_Cloud_Development_with_Spring_Roo
 
Migration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud PlattformMigration von Aftersales Systemen auf eine Cloud Plattform
Migration von Aftersales Systemen auf eine Cloud Plattform
 
Evaluierung einer Hybris-Anbindung an Sitecore mittels Commerce Connect
Evaluierung einer Hybris-Anbindung an Sitecore mittels Commerce ConnectEvaluierung einer Hybris-Anbindung an Sitecore mittels Commerce Connect
Evaluierung einer Hybris-Anbindung an Sitecore mittels Commerce Connect
 
BATbern42 End-to-End Verantwortlichkeit in der Praxis: Scion Workbench
BATbern42 End-to-End Verantwortlichkeit in der Praxis: Scion WorkbenchBATbern42 End-to-End Verantwortlichkeit in der Praxis: Scion Workbench
BATbern42 End-to-End Verantwortlichkeit in der Praxis: Scion Workbench
 
Webcast Azure Integration Migration - Von BizTalk in die Cloud
Webcast Azure Integration Migration - Von BizTalk in die CloudWebcast Azure Integration Migration - Von BizTalk in die Cloud
Webcast Azure Integration Migration - Von BizTalk in die Cloud
 
Microsoft Azure Cloud mit der Sitecore Experience Platform
Microsoft Azure Cloud mit der Sitecore Experience PlatformMicrosoft Azure Cloud mit der Sitecore Experience Platform
Microsoft Azure Cloud mit der Sitecore Experience Platform
 
Hilfe, ich will meinen Monolithen zurück!
Hilfe, ich will meinen Monolithen zurück!Hilfe, ich will meinen Monolithen zurück!
Hilfe, ich will meinen Monolithen zurück!
 
Continuous Delivery @ FriendScout24 | Webinale 2012
Continuous Delivery @ FriendScout24 | Webinale 2012Continuous Delivery @ FriendScout24 | Webinale 2012
Continuous Delivery @ FriendScout24 | Webinale 2012
 
Microservices mit dem MicroProfile
Microservices mit dem MicroProfileMicroservices mit dem MicroProfile
Microservices mit dem MicroProfile
 
Cloud Architekturen - von "less Server" zu Serverless
Cloud Architekturen - von "less Server" zu ServerlessCloud Architekturen - von "less Server" zu Serverless
Cloud Architekturen - von "less Server" zu Serverless
 
Microservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen solltenMicroservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen sollten
 
Process Automation Forum Munich, Swiss Life
Process Automation Forum Munich, Swiss LifeProcess Automation Forum Munich, Swiss Life
Process Automation Forum Munich, Swiss Life
 
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
 
SFScon16 - Edmund Schöpf: "Camunda BPM in Banking"
SFScon16 - Edmund Schöpf: "Camunda BPM in Banking"SFScon16 - Edmund Schöpf: "Camunda BPM in Banking"
SFScon16 - Edmund Schöpf: "Camunda BPM in Banking"
 
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
 
API-Design, Microarchitecture und Testing
API-Design, Microarchitecture und TestingAPI-Design, Microarchitecture und Testing
API-Design, Microarchitecture und Testing
 
Public Cloud Erfahrungsbericht SBB
Public Cloud Erfahrungsbericht SBBPublic Cloud Erfahrungsbericht SBB
Public Cloud Erfahrungsbericht SBB
 

Ähnlich wie BATbern41 Die Evolution zu Microservices

Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
Brockhaus Consulting GmbH
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
QAware GmbH
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
QAware GmbH
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
QAware GmbH
 
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
QAware GmbH
 
Citrix Day 2014: APPDNA
Citrix Day 2014: APPDNACitrix Day 2014: APPDNA
Citrix Day 2014: APPDNA
Digicomp Academy AG
 
CLOUDSERVICES FÜR ISVs
CLOUDSERVICES FÜR ISVsCLOUDSERVICES FÜR ISVs
CLOUDSERVICES FÜR ISVs
acentrix GmbH
 
Modulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine EinführungModulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine Einführung
Andreas Weidinger
 
PLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM TrendsPLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM Trends
Intelliact AG
 
Continuous Delivery as a Way of Life
Continuous Delivery as a Way of LifeContinuous Delivery as a Way of Life
Continuous Delivery as a Way of Life
Kremer Consulting
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DNUG e.V.
 
Innovations- und Informationskultur mit Web 2.0 (2010)
Innovations- und Informationskultur mit Web 2.0 (2010)Innovations- und Informationskultur mit Web 2.0 (2010)
Innovations- und Informationskultur mit Web 2.0 (2010)
Intelliact AG
 
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Bernd Zuther
 
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-StrategieCitrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
Digicomp Academy AG
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Peter Affolter
 
Nanoservice Architekturen
Nanoservice ArchitekturenNanoservice Architekturen
Nanoservice Architekturen
Leo Lindhorst
 
Swisscom runs SAP Lumira
Swisscom runs SAP LumiraSwisscom runs SAP Lumira
Swisscom runs SAP Lumira
Mohamed Abdel Hadi
 
HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien
HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien
HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien
DNUG e.V.
 
MEAN SCS in der Cloud
MEAN SCS in der CloudMEAN SCS in der Cloud
MEAN SCS in der Cloud
Torsten Fink
 

Ähnlich wie BATbern41 Die Evolution zu Microservices (20)

Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
 
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
Cloud Native Migration: Wie IT-Landschaften ihren Weg auf eine Cloud-Native-P...
 
Citrix Day 2014: APPDNA
Citrix Day 2014: APPDNACitrix Day 2014: APPDNA
Citrix Day 2014: APPDNA
 
CLOUDSERVICES FÜR ISVs
CLOUDSERVICES FÜR ISVsCLOUDSERVICES FÜR ISVs
CLOUDSERVICES FÜR ISVs
 
Modulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine EinführungModulare Enterprise Systeme - Eine Einführung
Modulare Enterprise Systeme - Eine Einführung
 
PLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM TrendsPLM Open Hours - Cloud PLM und PLM Trends
PLM Open Hours - Cloud PLM und PLM Trends
 
Continuous Delivery as a Way of Life
Continuous Delivery as a Way of LifeContinuous Delivery as a Way of Life
Continuous Delivery as a Way of Life
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
 
Innovations- und Informationskultur mit Web 2.0 (2010)
Innovations- und Informationskultur mit Web 2.0 (2010)Innovations- und Informationskultur mit Web 2.0 (2010)
Innovations- und Informationskultur mit Web 2.0 (2010)
 
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
Java Aktuell Bernd Zuther Canary Releases mit der Very Awesome Microservices ...
 
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-StrategieCitrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
Citrix Day 2014: BKW - Der Weg einer Enterprise-Mobility-Management-Strategie
 
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
Artikel Netzguide: SOA als Grundlage für "Composite Applications"​
 
Nanoservice Architekturen
Nanoservice ArchitekturenNanoservice Architekturen
Nanoservice Architekturen
 
OSLC in Aktion
OSLC in AktionOSLC in Aktion
OSLC in Aktion
 
Swisscom runs SAP Lumira
Swisscom runs SAP LumiraSwisscom runs SAP Lumira
Swisscom runs SAP Lumira
 
HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien
HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien
HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien
 
MEAN SCS in der Cloud
MEAN SCS in der CloudMEAN SCS in der Cloud
MEAN SCS in der Cloud
 

Mehr von BATbern

BATbern53 Post Data persistence in the business-critical and event driven env...
BATbern53 Post Data persistence in the business-critical and event driven env...BATbern53 Post Data persistence in the business-critical and event driven env...
BATbern53 Post Data persistence in the business-critical and event driven env...
BATbern
 
BATbern53 BKW Easy Migration through Clean Architecture
BATbern53 BKW Easy Migration through Clean ArchitectureBATbern53 BKW Easy Migration through Clean Architecture
BATbern53 BKW Easy Migration through Clean Architecture
BATbern
 
BATbern53 ETHZ Rethinking Cluster State Management for Lightweight Function a...
BATbern53 ETHZ Rethinking Cluster State Management for Lightweight Function a...BATbern53 ETHZ Rethinking Cluster State Management for Lightweight Function a...
BATbern53 ETHZ Rethinking Cluster State Management for Lightweight Function a...
BATbern
 
BATbern53 SBB Wieso in jeder Zugfahrt der SBB ein Stück MongoDB drinsteckt
BATbern53 SBB Wieso in jeder Zugfahrt der SBB ein Stück MongoDB drinstecktBATbern53 SBB Wieso in jeder Zugfahrt der SBB ein Stück MongoDB drinsteckt
BATbern53 SBB Wieso in jeder Zugfahrt der SBB ein Stück MongoDB drinsteckt
BATbern
 
BATBern53 - EPFL - Blue Brain and related technical challenges
BATBern53  - EPFL - Blue Brain and related technical challengesBATBern53  - EPFL - Blue Brain and related technical challenges
BATBern53 - EPFL - Blue Brain and related technical challenges
BATbern
 
BATbern53 Die Mobiliar Bring die Algorithmen zu den Daten – nicht umgekehrt
BATbern53 Die Mobiliar Bring die Algorithmen zu den Daten – nicht umgekehrtBATbern53 Die Mobiliar Bring die Algorithmen zu den Daten – nicht umgekehrt
BATbern53 Die Mobiliar Bring die Algorithmen zu den Daten – nicht umgekehrt
BATbern
 
BATbern53 ELCA Analyticsdatenhaltung in der Cloud
BATbern53 ELCA Analyticsdatenhaltung in der CloudBATbern53 ELCA Analyticsdatenhaltung in der Cloud
BATbern53 ELCA Analyticsdatenhaltung in der Cloud
BATbern
 
BATber53 AWS Modernize your applications with purpose-built AWS databases
BATber53 AWS Modernize your applications with purpose-built AWS databasesBATber53 AWS Modernize your applications with purpose-built AWS databases
BATber53 AWS Modernize your applications with purpose-built AWS databases
BATbern
 
BATbern52 Moderation Berner Architekten Treffen zu Data Mesh
BATbern52 Moderation Berner Architekten Treffen zu Data MeshBATbern52 Moderation Berner Architekten Treffen zu Data Mesh
BATbern52 Moderation Berner Architekten Treffen zu Data Mesh
BATbern
 
BATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data MeshBATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data Mesh
BATbern
 
BATbern52 SBB zu Data Products und Knacknüsse
BATbern52 SBB zu Data Products und KnacknüsseBATbern52 SBB zu Data Products und Knacknüsse
BATbern52 SBB zu Data Products und Knacknüsse
BATbern
 
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data MeshBATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
BATbern
 
BATbern52 InnoQ on Data Mesh 2019 2023 2024++
BATbern52 InnoQ on Data Mesh 2019 2023 2024++BATbern52 InnoQ on Data Mesh 2019 2023 2024++
BATbern52 InnoQ on Data Mesh 2019 2023 2024++
BATbern
 
Embracing Serverless: reengineering a real-estate digital marketplace
Embracing Serverless: reengineering a real-estate digital marketplaceEmbracing Serverless: reengineering a real-estate digital marketplace
Embracing Serverless: reengineering a real-estate digital marketplace
BATbern
 
Serverless und Event-Driven Architecture
Serverless und Event-Driven ArchitectureServerless und Event-Driven Architecture
Serverless und Event-Driven Architecture
BATbern
 
Serverless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der PraxisServerless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der Praxis
BATbern
 
Serverless at Lifestage
Serverless at LifestageServerless at Lifestage
Serverless at Lifestage
BATbern
 
Keynote Gregor Hohpe - Serverless Architectures
Keynote Gregor Hohpe - Serverless ArchitecturesKeynote Gregor Hohpe - Serverless Architectures
Keynote Gregor Hohpe - Serverless Architectures
BATbern
 
BATbern51 Serverless?!
BATbern51 Serverless?!BATbern51 Serverless?!
BATbern51 Serverless?!
BATbern
 
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen PartnersEin Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
BATbern
 

Mehr von BATbern (20)

BATbern53 Post Data persistence in the business-critical and event driven env...
BATbern53 Post Data persistence in the business-critical and event driven env...BATbern53 Post Data persistence in the business-critical and event driven env...
BATbern53 Post Data persistence in the business-critical and event driven env...
 
BATbern53 BKW Easy Migration through Clean Architecture
BATbern53 BKW Easy Migration through Clean ArchitectureBATbern53 BKW Easy Migration through Clean Architecture
BATbern53 BKW Easy Migration through Clean Architecture
 
BATbern53 ETHZ Rethinking Cluster State Management for Lightweight Function a...
BATbern53 ETHZ Rethinking Cluster State Management for Lightweight Function a...BATbern53 ETHZ Rethinking Cluster State Management for Lightweight Function a...
BATbern53 ETHZ Rethinking Cluster State Management for Lightweight Function a...
 
BATbern53 SBB Wieso in jeder Zugfahrt der SBB ein Stück MongoDB drinsteckt
BATbern53 SBB Wieso in jeder Zugfahrt der SBB ein Stück MongoDB drinstecktBATbern53 SBB Wieso in jeder Zugfahrt der SBB ein Stück MongoDB drinsteckt
BATbern53 SBB Wieso in jeder Zugfahrt der SBB ein Stück MongoDB drinsteckt
 
BATBern53 - EPFL - Blue Brain and related technical challenges
BATBern53  - EPFL - Blue Brain and related technical challengesBATBern53  - EPFL - Blue Brain and related technical challenges
BATBern53 - EPFL - Blue Brain and related technical challenges
 
BATbern53 Die Mobiliar Bring die Algorithmen zu den Daten – nicht umgekehrt
BATbern53 Die Mobiliar Bring die Algorithmen zu den Daten – nicht umgekehrtBATbern53 Die Mobiliar Bring die Algorithmen zu den Daten – nicht umgekehrt
BATbern53 Die Mobiliar Bring die Algorithmen zu den Daten – nicht umgekehrt
 
BATbern53 ELCA Analyticsdatenhaltung in der Cloud
BATbern53 ELCA Analyticsdatenhaltung in der CloudBATbern53 ELCA Analyticsdatenhaltung in der Cloud
BATbern53 ELCA Analyticsdatenhaltung in der Cloud
 
BATber53 AWS Modernize your applications with purpose-built AWS databases
BATber53 AWS Modernize your applications with purpose-built AWS databasesBATber53 AWS Modernize your applications with purpose-built AWS databases
BATber53 AWS Modernize your applications with purpose-built AWS databases
 
BATbern52 Moderation Berner Architekten Treffen zu Data Mesh
BATbern52 Moderation Berner Architekten Treffen zu Data MeshBATbern52 Moderation Berner Architekten Treffen zu Data Mesh
BATbern52 Moderation Berner Architekten Treffen zu Data Mesh
 
BATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data MeshBATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data Mesh
 
BATbern52 SBB zu Data Products und Knacknüsse
BATbern52 SBB zu Data Products und KnacknüsseBATbern52 SBB zu Data Products und Knacknüsse
BATbern52 SBB zu Data Products und Knacknüsse
 
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data MeshBATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
BATbern52 Mobiliar zu Skalierte Datenprodukte mit Data Mesh
 
BATbern52 InnoQ on Data Mesh 2019 2023 2024++
BATbern52 InnoQ on Data Mesh 2019 2023 2024++BATbern52 InnoQ on Data Mesh 2019 2023 2024++
BATbern52 InnoQ on Data Mesh 2019 2023 2024++
 
Embracing Serverless: reengineering a real-estate digital marketplace
Embracing Serverless: reengineering a real-estate digital marketplaceEmbracing Serverless: reengineering a real-estate digital marketplace
Embracing Serverless: reengineering a real-estate digital marketplace
 
Serverless und Event-Driven Architecture
Serverless und Event-Driven ArchitectureServerless und Event-Driven Architecture
Serverless und Event-Driven Architecture
 
Serverless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der PraxisServerless Dev(Ops) in der Praxis
Serverless Dev(Ops) in der Praxis
 
Serverless at Lifestage
Serverless at LifestageServerless at Lifestage
Serverless at Lifestage
 
Keynote Gregor Hohpe - Serverless Architectures
Keynote Gregor Hohpe - Serverless ArchitecturesKeynote Gregor Hohpe - Serverless Architectures
Keynote Gregor Hohpe - Serverless Architectures
 
BATbern51 Serverless?!
BATbern51 Serverless?!BATbern51 Serverless?!
BATbern51 Serverless?!
 
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen PartnersEin Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
Ein Rückblick anlässlich des 50. BAT aus Sicht eines treuen Partners
 

BATbern41 Die Evolution zu Microservices

  • 1. Die Evolution zu Microservices BAT 41 vom 2.November 2018 Pascal Auderset | Leiter IT Applikations- und Technologiearchitektur
  • 2. Ausblick auf die nächsten 30 Minuten …. Erfahrungen mit Microservices bei der Mobiliar Einleitung Digitale und agile Transformation in der Mobiliar Die neue Zielarchitektur Aus der Performance Krise hin zur neuen Zielarchitektur der IT-Landschaft, was waren die Herausforderungen Joint Application Plattform Der nächste Schritt: Continuous Delivery, Docker und kleine Microservices im Backend 1 2 3 2.11.2018Die Evolution zu Microservices 2 Die aktuellen Herausforderungen Wo stehen wir heute; Demo 4 1 Einleitung
  • 3. Das Verständnis von Microservices 2.11.2018 1 Einleitung Die gemeinsamen Eigenschaften: • Zerlegung in relativ kleine fachliche Services • Services sind sehr lose gekoppelt • Reduktion der Abhängigkeiten (Services können einzeln installiert, aktualisiert und verwaltet werden) • Ermöglicht die dezentrale Datenhaltung • Höherer Freiheitsgrad bei der Technologiewahl Die Evolution zu Microservices 3 Chris Richardson https://microservices.io/index.html • Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The microservice architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack Martin Fowler: https://martinfowler.com/articles/microservices.html • The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
  • 4. 2.11.2018Die Evolution zu Microservices 4 ….. 2015 2016 2017 2018 > Digitale und agile Transformation in der Mobiliar …… Performance Krise Ökosysteme Quantensprung Digital Persönlich 2009 AI Microservice Architektur 209 Hybrid Cloud Architecture as Code Continuous Delivery Container Plattform DevOps209 Start FIT Vertrieb PoC neue Zielarchitektur Start agiles Releasing Einführung (NSP) Schadenregulierung Start der Umsetzung End2End Digitalisierung Agilisierung Projekt Portfolio Rechtsschutz & Reise Reset (NSP) Schaden Einführung (NSP) Schadenaufnahme Stau im Portfolio Neue Zielarchitektur 209 Future IT (FIT) Digitalisierung 2012 1 Einleitung
  • 5. 5 2. Die neue Zielarchitektur
  • 6. Aus der Performance Krise hin zur neuen Zielarchitektur 2.11.2018 Flexibles Gesamtsystem in Bezug auf: Die gemeinsamen Eigenschaften: • Neue fachliche Anforderungen schnell umsetzen  Agiler werden:  Klein (inklusive Datenhaltung) als Gegenmodell zu Monolith  lose Kopplung, leichte Austauschbarkeit (build for rebuild before reuse)  "Standard" Technologie Schnittstellen: REST • Neue technologische Möglichkeiten schneller nutzen:  Technologieauswahl auf aktuelle Versionen und Konzepte heben (JEE6, verabschieden von den alten J2EE Patterns)  Frontend Technologie auf Internet ausrichten • Schwankungen in der Last auffangen  einzelne Services horizontal Skalieren (billiger)  Services schnell restarten (LifeCycle einführen) Die Evolution zu Microservices 6 • Zerlegung in relativ kleine fachliche Services • Services sind sehr lose gekoppelt • Reduktion der Abhängigkeiten (Services können einzeln installiert, aktualisiert und verwaltet werden) • Ermöglicht die dezentrale Datenhaltung • Höherer Freiheitsgrad bei der Technologiewahl 2 Die neue Zielarchitektur
  • 7. Die neue Zielarchitektur und deren Widerstände • Vertikale Schneidung der Komponenten entlang der fachlichen Abhängigkeiten und nicht der technischen Layers • Decompose by Business Capability 2.11.2018Die Evolution zu Microservices 7 Ein einfaches, verständliches Modell zur Schneidung von Prozessen, Daten und Managementinformationensystemen in Komponenten ist nötig! 2 Die neue Zielarchitektur
  • 8. Die neue Zielarchitektur und deren Widerstände grosse Diskussionen über die Integrationsarten: • Oracle Schema versus DB2 • MAIA MDA versus REST • SOAP versus REST • ESB versus wenig Middleware 2.11.2018Die Evolution zu Microservices 8 Je eine Implementation als Integrationsart reicht: Beispiel: Für Remote Procedure Invocation REST (oder auch gRPC, Apache Thrifth) und für Messaging Kafka 2 Die neue Zielarchitektur
  • 9. Die neue Zielarchitektur und deren Widerstände Interne Architektur • DTO, versus, VO versus Generiete Klassen um Schnittstellen sicher und versionierbar zu machen • Abstraktionen innerhalb eines Service (Layering) 2.11.2018Die Evolution zu Microservices 9 Mit Microservice ist die Innenarchitektur nicht mehr so wichtig wie früher, aber alle Anforderungen müssen automatisch geprüft werden (automatische Governance) 2 Die neue Zielarchitektur
  • 10. Die neue Zielarchitektur und deren Widerstände Ergonomische Oberflächen die Einheitlich aussehen, um die manuellen Prozessbrüche zu vereinfachen 2.11.2018Die Evolution zu Microservices 10 Einführen von einem einheitlichen Design ist aufwendig, aber nützlich um ein Microservice Architektur auch im Frondend umzusetzen 2 Die neue Zielarchitektur
  • 11. Ordnen der Entwicklungsplattformen und Umsetzung der Zielarchitektur • Zielplattform für Eigenentwicklungen festlegen und priorisieren • Verantwortlichkeiten der Entwicklungsplattformen festlegen und regeln • Roadmaps der einzelnen Plattformen regeln 2.11.2018Die Evolution zu Microservices 11 Applikationsentwicklungsplattformen definieren und managen. Nur eine präferierte Variante zulassen! 2 Die neue Zielarchitektur 2014 2017
  • 12. Umsetzung der Zielarchitektur und priorisieren der Entwicklungsplattformen Eine erste Version der JAP Plattform in einem Projekt erfolgreich umsetzen und nutzen: • Decompose by Business Capability • Database per Service • API Composition • Service Component Testing • Audit Logging • Application Metrics • Microservice Chassis • External Configuration • Remote Procedure Invication • Distributet Tracing • etc 2.11.2018Die Evolution zu Microservices 12 Standardisieren der nicht funktionalen Qualitätsanforderungen über Industriestandards und wo nichts vorhanden selber umsetzen! 2 Die neue Zielarchitektur https://microservices.io/patterns/index.html
  • 13. Umsetzung der Zielarchitektur und priorisieren der Entwicklungsplattformen Eine erste Version von Continuous Integration und Continuous Deployment einführen: • bis auf die Testsysteme • Automatisierung minimal 2.11.2018Die Evolution zu Microservices 13 Die 3 Grundprinzipien: Versionierung, Continuous Testing und Continuous Integration müssen verankert werden um die Produktivität zu steigern! 2 Die neue Zielarchitektur
  • 14. Herausforderungen bei der Umsetzung der Zielarchitektur Aus Sicht Applikationsarchitektur: • Wie klein / gross sind die Microservices?  Decompose by Business Capability muss man lernen • MDA versus Microservices 2.11.2018Die Evolution zu Microservices 14 2 Die neue Zielarchitektur Decompose by Business Capability muss man lernen
  • 15. Herausforderungen bei der Umsetzung der Zielarchitektur Aus Sicht Technologiearchitektur • Wie integrieren wir die "alten" Services und Applikationen (inkl. Fehlerhandling)?  viel Aufwand hineingesteckt, damit möglichst Transparent und einfach für die Anwender • DB welche DB2 versus Oracle Schemas  Automatisieren der Bestellungen • Trunked Bases Development  durchsetzen • Continuous Integration und Testing  messen und vorgeben • Fachliche Shared Libraries  Kampf am Anfang verloren: nach gewisser Zeit von selbst durchgesetzt 2.11.2018Die Evolution zu Microservices 15 2 Die neue Zielarchitektur Die 3 Grundprinzipien: Versionierung, Continuous Testing und Continuous Integration müssen verankert werden um die Produktivität zu steigern!
  • 17. 2.11.2018Die Evolution zu Microservices 17 ….. 2015 2016 2017 2018 > Digitale und agile Transformation in der Mobiliar …… Performance Krise Ökosysteme Quantensprung Digital Persönlich 2009 AI Microservice Architektur 209 Hybrid Cloud Architecture as Code Continuous Delivery Container Plattform DevOps209 Start FIT Vertrieb PoC neue Zielarchitektur Start agiles Releasing Einführung (NSP) Schadenregulierung Start der Umsetzung End2End Digitalisierung Agilisierung Projekt Portfolio Rechtsschutz & Reise Reset (NSP) Schaden Einführung (NSP) Schadenaufnahme Stau im Portfolio Neue Zielarchitektur 209 Future IT (FIT) Digitalisierung 2012 3 Joint Application Plattform
  • 18. Continuous Delivery, Docker und kleine Microservices im Backend Reduktion Aufwände für die Continuous Delivery Pipeline (Effizient werden) • Datenbank • Incident Management • Deployment Freigaben Etablieren von automatischer Governance • Build • Codeverletzlichkeit und Coverage Analyse • Testpyramide • LifeCycle Methoden • API Dokumentation • DB Versionierung 2.11.2018Die Evolution zu Microservices 18 Automatisieren der Governance und erhöhen der Automatisierung der Continuous Pipeline führen zu effizienteren Teams 3 Joint Application Plattform
  • 19. Continuous Delivery, Docker und kleine Microservices im Backend Druck von den Entwickler für mehr Technologie in den Services JAP Version 2 der Plattform (Basis JEE7) • Ersatz Single Service per VM durch Single Service per Container • Erweiterungen in allen Bisherigen Patterns und neue zur Verfügung stellen:  API Gateway (einfach)  Erste Versionen von Messaging auf Basis JMS (EventHub)  Consumer Driven Contract Testing  viel selbstgeschriebener Code entfernt 2.11.2018Die Evolution zu Microservices 19 Plattform weiter standardisieren, aber gleichzeitig Freiheiten für die Teams erarbeiten 3 Joint Application Plattform
  • 20. Herausforderungen bei der Umsetzung der Joint Application Plattform • Aus Sicht Applikationsarchitektur  Der Zoo an Microservices wächst und wächst und wächst  Mit den aktuellen Tools (EA und Casewise) halten wir nicht Schritt  Die Grösse der Microservices hat sich stabilisiert entlang der Business Capabilities  Frontend ist ein grosses Monolith  Transaktionshandling (BASE, SAGA Pattern) • Gewaltentrennung Dev / Ops • Aus Sicht Technologie Architektur  Neue Datenbanken ElasticSearch, Mongo  Umbauen der gossen MS und Migration des Patterns (viel Aufwand) 2.11.2018Die Evolution zu Microservices 20 Konsequent über alle Layer Microservices nutzen und Pain-Points entfernen 3 Joint Application Plattform
  • 21. 21 4. Die aktuellen Herausforderungen
  • 22. 2.11.2018Die Evolution zu Microservices 22 ….. 2015 2016 2017 2018 > Digitale und agile Transformation in der Mobiliar …… Performance Krise Ökosysteme Quantensprung Digital Persönlich 2009 AI Microservice Architektur 209 Hybrid Cloud Architecture as Code Continuous Delivery Container Plattform DevOps209 Start FIT Vertrieb PoC neue Zielarchitektur Start agiles Releasing Einführung (NSP) Schadenregulierung Start der Umsetzung End2End Digitalisierung Agilisierung Projekt Portfolio Rechtsschutz & Reise Reset (NSP) Schaden Einführung (NSP) Schadenaufnahme Stau im Portfolio Neue Zielarchitektur 209 Future IT (FIT) Digitalisierung 2012 4 Die aktuellen Herausforderungen
  • 23. Aktuelle Herausforderungen Architecture as Code • Automatisieren • Brainwork in den Soll Bildern 2009 SideCar • Phyton • GoLang 2009 JAP Version 3 • microprofile 2.0 • Service Registry • SAGA Pattern und Events (Kafka) • Nochmals Reduktion des selbstgeschriebenen Source-Codes 2009 Microservices im Frontend • Modularisierung 2009 2.11.2018Die Evolution zu Microservices 23 4 Die aktuellen Herausforderungen
  • 24. 24.10.2018 24 Demo der Ist Werkzeuge Aus Sicht: - Applikationsarchitektur / Solutionarchitektur - Teams - Technologiearchitektur (Plattformarchitektur)
  • 25. Zusammen- fassung 3 Automatisieren der Governance 4 Versionierung, Continuous Testing und Continuous Integration müssen verankert werden um Continuous Delivery zu leben 1 Konsequent über alle Layer Microservies nutzen und Painpoints entfernen 2 Präferierte Entwicklungsplattform weiter standardisieren, aber gleichzeitig Freiheiten für die Teams erarbeiten Die Evolution zu Microservices 252.11.2018