DigiTalk Oktober 2017, München: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware).

1. Mario-Leander Reimer, QAware GmbH
mario-leander.reimer@qaware.de
Migration von BMW Aftersales
Systemen auf eine Cloud Plattform
DigiTalk
München, 19. Oktober 2017

2. Die Verwirklichung der Strategie Number ONE > NEXT
führt zu einer Transformation hin zu einer Tech Company.
„DieWertschöpfungverschiebt
sichvonder Hardwarein
RichtungSoftwareund
Services.“
HaraldKrüger, 16.03.2016
BMWGroupBilanzpressekonferenz
Today
Products
Mobility&Services
Software&Services(Tech)
Tomorrow
Digitalcustomer experience, connected and automated driving and digitalized business processes leadto atransformation of
the BMWGrouptowards software and services (Tech).
Products
Mobility&Services
Effect on:
• Customer Experience
• Shareholder/Analysts
• Stakeholder /Partner
• Employees /Attractiveness
2

3. 3
Lassen sich Bestandssysteme mit vertretbarem
Aufwand in Richtung Cloud entwickeln?
Containerization
12-Factor App Principles
Microservices
Cloud-native Apps
Monolithic Deployment
Traditional Infrastructure

4. A <<System / Plattform>>
IO Business Applications (BDR)
A <<Ext. System>>
Saferpay
A <<System>>
SMTP.MUC
A <<System>>
SOFAK
Berechtigter Dritter (PKW),
Berechtigter Dritter (Motorrad)
A <<System>>
P-CODE (BDR)
A <<Subsystem>>
Tuner APP (BDR)
A <<Subsystem>>
VIN Decoder (BDR)
A <<System>>
ITSM SUITE
OSMC User Security Context
A <<System>>
Integrierte Web-Applikation
B2I Security Context
B2I Security Context
A <<System>>
OSMC (BDR)
H <<System>>
Fahrzeug
H <<System>>
Fahrzeuginterface (PTT)
I <<System>>
LAAS
A <<System>>
AOS (BDR)
A <<Subsystem>>
AOS-TS (BDR)
B2I Security Context
A <<System>>
B2I-UA (BDR)
A <<Ext. System>>
BZAFS
A <<System>>
Group Directory
A <<System>>
APRIL (BDR)
A <<System>>
Integr. Client-Appl.
OSS Tech Security Context
(OSS Client Zertifikat)
A <<System>>
externes System
B2I-UB DB
AOS-TS DB
OSMC DB
AOS DB
P-CODE DB
B2I Security Context
I <<Execution Unit>>
OpenShift CNAP
A <<System>>
Billing Service
A <<System>>
Payment Service
A <<System>>
Process Service
A <<Ext. System>>
ASBC
A <<Ext. System>>
SAP (EAI/TBB)
4
Hyperscale, Antifragilität und Continuous Delivery sind
wesentliche Treiber für die Evolution unserer Systeme.
Systemverbund
Berechtigte Dritte (BDR)
Stand R1711

5. Fakten schaffen. Wir brauchen eine belastbar Aufwands-
und Ressourcenprognose.
5
Fragenkatalog
Welche Komplexität hat das System?
Welche Musterlösung verwendet das System?
Welche Technologien werden verwendet?
….
Software-Analyse
Statische Analyse mit Windup
Architektur Analyse mit S101
Proof of Concepts
Migration von APRIL
Migration der B2I-UA
QAware Know How
Erfahrung aus anderen Migrationen
Kontenrahmen
Eingespieltes Team

6. Wichtige Design Prinzipien Cloud-nativer Applikationen
dienen als Leitplanken für benötigte Umbauten.
6
Design for Distribution: Containers; microservices; API getriebene Entwicklung.
Design for Performance: Responsive; Concurrent; Ressourcen effizient.
Design for Automation: Automatisierung von Dev & Ops Tasks.
Design for Resiliency: Fehlertolerant und selbstheilend.
Design for Elasticity: Skaliert dynamisch und reagiert auf Stimuli.
Design for Delivery: Kurze Roundtrips und automatisierte Provisionierung.
Design for Diagnosability: Cluster-weite Logs, Metriken und Traces.

7. 7
Ein gestuftes Vorgehen macht die Migration planbar, die
technologische Risiken werden leichter beherrschbar.
Loosely coupled microservices.
Scales dynamically based on load.
Level 3: Cloud Native
Fault tolerant and resilient design.
Metrics and monitoring built-in.
Level 2: Cloud Resilient
Adheres to the 12-factor app principles.
Cloud friendly app server runtime.
Level 1: Cloud Friendly
Executed as self-contained image.
Runs on virtualized HW and file system.
Level 0: Cloud Ready
https://www.opendatacenteralliance.org/docs/architecting_cloud_aware_applications.pdf

8. Software
Industrialisierung

9. Software Industrialisierung ist eine Schlüsselanforderung
für erfolgreiches DevOps und Continuous Delivery.
9
Hoher Automatisierungsgrad von arbeits-
intensiven und wiederkehrenden Tasks
Bessere Software-Qualität durch eine
abgestimmte Tool-Chain
Mehr Produktivität und Zufriedenheit der
Entwickler-Teams
Bessere Kosten-Effizienz und
Wettbewerbsfähigkeit

10. Nutzung der Agile Delivery Tool Chain (ATC)
Migration aller BDR Repositories von SVN nach
Git mit voller Historie innerhalb 1 Woche
Anpassung und Migration aller Jenkins Build-Jobs
auf neue Build Infrastruktur
More improvements to come …
Durch die Evolution der Build Toolchain werden schnelle
Roundtrips und effiziente Feature Entwicklung möglich.
10
Drastisch reduzierte Build-Zeiten für mehr
Produktivität und Qualität
Migration von Bestandsprojekten mit Augenmaß
https://gradle.org/gradle-vs-maven-performance/

11. Unsere Continuous Integration & Deployment Pipeline.
11

12. Einfaches Nachrüsten von Metriken, Health Endpoints,
und Resilienz durch Verwendung von OSS Bibliotheken.
12
<dependencies>
<dependency>
<groupId>io.dropwizard.metrics</groupId>
<artifactId>metrics-core</artifactId>
<version>${metrics.version}</version>
</dependency>
</dependencies>
Verwendung von Dropwizard Metrics für
Metriken und Health Endpoints
Einfache Integration in ML GFv4 Anwendungen
Definition von Custom Health Checks möglich
Verwendung als Liveness und Readiness Probes
Verwendung von Netflix Hystrix für den
resilienten Aufruf von Fremdsystemen
Einfache Integration in ML GFv4 Anwendungen
Circuit Breaker und Bulk Heading
Integriert sich nahtlos mit Dropwizard Metrics
<dependencies>
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-core</artifactId>
<version>${hystrix.version}</version>
</dependency>
</dependencies>

13. Industrialisierte Migration aller Deployment Artefakte für
eine schnelle und einheitliche Containerisierung.
13
BMW Staging Tool
XML Files
kompose
OpenShift Deployment
YAML Files
Dockerfile +
docker-compose.yml
go2cnap
Local Development Cloud DeploymentTraditional Deployment

14. Microservices

15. 15
„Decomposing the Monolith“ am Beispiel von APRIL.
Base Runtime (Mule ESB 3.7)
Monitoring
Finance
Adapter
Logging
Cert
Adapter
Vehicle
Adapter
Commercial
Adapter
Security
APRIL Runtime
Tracing
…
Portal
Adapter
B2I
Adapter
Session
Adapter
Log
Adapter
Score
Adapter
Legacy
Adapter
Togglz
FASTA
Adapter
Alle fachlichen Komponenten und
Schnittstellen in einer riesigen,
gemeinsamen Deployment Einheit
Querschnittskomponenten

16. 16
Dev Components Ops Components?:1
System
Subsystems
Components
Services
Guter Ausgangspunkt
DecompositionTrade-Offs
Microservices
Nanoservices
Macroservices
Monolith
+ Flexiblere Skalierung möglich
+ Runtime Isolation (Crash, Slow-Down, …)
+ Unabhängige Releases, Deployments,Teams
+ Bessere Ressourcennutzung
− Verteilungsschulden: Latenz
− Steigende Infrastruktur Komplexität
− SteigendeTroubleshooting Komplexität
− Steigende Integration-Komplexität

17. 17
„Decomposing the Monolith“ am Beispiel von APRIL.
Base Runtime (Mule ESB 3.7)
Monitoring
B2I
Adapter
Logging
User
Adapter
Portal
Adapter
Integration
Adapter
Security
APRIL AOS Deployment
Tracing
… Base Runtime (Mule ESB 3.7)
Monitoring Logging
Commercial
Adapter
Security
APRIL Commercial
Deployment
Tracing
Base Runtime (Mule ESB 3.7)
Monitoring Logging
Vehicle
Adapter
Security
APRIL Vehicle
Deployment
Tracing
Base Runtime (Mule ESB 3.7)
Monitoring Logging
Finance
Adapter
Security
APRIL Finance
Deployment
Tracing
Base Runtime (Mule ESB 3.7)
Monitoring
Score
Adapter
Logging
FASTA
Adapter
Cert
Adapter
OSS Legacy
Adapter
Security
APRIL Client Deployment
Tracing
…
Ein Deployment pro
System-Context

18. Transform: ein Teil der Bestandsfunktionalität wird extrahiert
und in ein neues, modernes System eingebaut.
Coexist: beide Systeme koexistieren für eine Zeit. Aufrufe
der alten Funktionalität werden umgeleitet.
Eliminate: alte Funktionalität wird aus dem Bestandssystem
entfernt sobald diese nicht mehr genutzt wird.
Eignet sich besonders für Web - oder API-Monolithen.
Problematisch bei Non-RESTful URL Strukturen.
Schnittweise Evolution und Cloud-nativer Neubau mit
dem Strangler Pattern.
18https://martinfowler.com/bliki/StranglerApplication.html

19. QAware GmbH München
Aschauer Straße 32
81549 München
Tel.: +49 (0) 89 23 23 15 – 0
Fax: +49 (0) 89 23 23 15 – 129 github.com/qaware
linkedin.com/qaware slideshare.net/qaware
twitter.com/qaware xing.com/qaware
youtube.com/qawaregmbh