Enterprise-Anwendungen werden trotz SOA und Komponenten immer noch als Monolithen integriert, getestet und betrieben. Das kostet viel Zeit und steht agilen Geschäftsmodellen im Weg. Cloud-Technologie verspricht grenzenlose Skalierung, kurze Release-Zyklen, schnelle Deployments, Robustheit und Antifragilität. Kann man vorhandene Systeme mit vernünftigem Aufwand in Richtung Cloud entwickeln? Was bedeutet die Cloud für den Betrieb, was ändert sich für die Software-Entwicklung? Welche Risiken gibt es? Wir verraten es Ihnen. Viele unserer Kunden sind in Aufbruchsstimmung. Sie beschäftigen sich mit Themen wie DevOps, Continuous Delivery, Microservices und Cloud-basierten Betriebsmodellen. Häufig werden wir mit der Frage konfrontiert, was man mit den zahlreichen Bestandssystemen machen soll. Muss man diese Systeme nun alle komplett neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg in die Cloud. Dieser Vortrag berichtet aus der Praxis, wie wir bei zwei unserer Großkunden dabei geholfen haben, Hunderte (!) von Bestandsanwendungen industrialisiert in die Cloud zu migrieren und fit für die Zukunft zu machen. Wir sprechen nicht nur über die nötigen Veränderungen der Software-Architektur und Technik, sondern berichten auch über die nötigen Prozessveränderungen. #OOPMuc #CloudNativeNerd #qaware

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

11. A <<System>>
APRIL (BDR)

12. A <<System>>
AOS (BDR)

13. A <<System>>
OSMC (BDR)

17. •
•
•
•
•
•
•

22. •
•
•
•
•

23. •
•
•

36. FROM payara/micro:174
# copy the WAR file into deployments directory
COPY target/april-bdr-runtime-1.5.0-SNAPSHOT.war /opt/payara/deployments/
USER root
RUN mkdir -p /april/logs && chown -R payara:payara /april
USER payara
ENTRYPOINT ["java", "-server", "-Dcom.bmw.mastersolutions.gf.domain.dir=/april",
"-Dcom.bmw.iap.april.gf.project.data.shared=/april/data",
"-Dcom.bmw.mastersolutions.gf.project.logs=/april/logs",
"-jar", "/opt/payara/payara-micro.jar"]
CMD ["--deploymentDir", "/opt/payara/deployments", "--noCluster"]

37. FROM payara/server-full:174
COPY *.asadmin /tmp/
RUN $AS_ADMIN start-domain $PAYARA_DOMAIN &&
$AS_ADMIN $AS_ADMIN_LOGIN multimode --file /tmp/jvm_options.asadmin &&
$AS_ADMIN $AS_ADMIN_LOGIN multimode --file /tmp/payara_optimization.asadmin &&
$AS_ADMIN stop-domain $PAYARA_DOMAIN
COPY target/april-bdr-runtime-1.5.0-SNAPSHOT.war $DEPLOY_DIR
RUN ${PAYARA_PATH}/generate_deploy_commands.sh
# RUN $AS_ADMIN start-domain --dry-run --postbootcommandfile $DEPLOY_COMMANDS $PAYARA_DOMAIN
COPY start-domain.sh $PAYARA_PATH/start-domain.sh
ENTRYPOINT $PAYARA_PATH/start-domain.sh

38. version: '3'
services:
postgres:
...
april-aos-runtime:
image: april-aos-runtime:1.0.1
environment:
- DB_HOST=postgres
- DB_PORT=1527
- DB_USER=${DB_USER}
- DB_PASSWORD=${DB_PASSWORD}
depends_on:
- postgres
ports:
- "8080:8080"
networks:
- april-net
$ docker-compose build
$ docker-compose up –d --build
$ docker-compose logs
$ docker-compose down

39. apiVersion: v1
kind: DeploymentConfig
metadata:
name: april-aos-runtime
spec:
replicas: 3
template:
metadata:
labels:
tier: backend
spec:
containers:
- name: april-aos-runtime
image: april-aos-runtime:1.0.1
ports:
- containerPort: 8080
env:
- name: DB_HOST
value: postgres-service

42. -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
-XX:ParallelGCThreads=2 -XX:ParallelGCThreads=2
-server
-Xmx320m -Xss256k -XX:MaxMetaspaceSize=160m -XX:CompressedClassSpaceSize=32m
# Do not use G1GC?
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewRatio=1 -XX:+CMSParallelRemarkEnabled
# Use for small heaps on 64-bit VMs
-XX:+AggressiveOpts -XX:+UseCompressedOops -XX:+UseCompressedClassPointers
# optional
-XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary

43. resources:
# CPU is specified in units of cores
# Memory is specified in units of bytes
# required resources for a Pod to be scheduled and started
requests:
memory: "128Mi"
cpu: "1"
# the Pod will be restarted if limits are exceeded
# so be careful not to set them too low!
limits:
memory: "1Gi"
cpu: "2"

46. <dependencies>
<dependency>
<groupId>io.dropwizard.metrics</groupId>
<artifactId>metrics-core</artifactId>
<version>${metrics.version}</version>
</dependency>
</dependencies>
<dependencies>
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-core</artifactId>
<version>${hystrix.version}</version>
</dependency>
</dependencies>

47. # container will receive requests if probe succeeds
readinessProbe:
httpGet:
path: /admin/ping
port: 8080
initialDelaySeconds: 30
timeoutSeconds: 5
# container will be killed if probe fails
livenessProbe:
httpGet:
path: /admin/healthcheck
port: 8080
initialDelaySeconds: 60
timeoutSeconds: 10

56. +
+
+
+





59. OSMCOTP
•
•
•

60. Process
MQseries
OTP
APRIL
Payment
OpenShift
Billing
Payment
APRIL
UI
B&P
B2ILAAS EAI/SAP
Saferpay
OSMC