Steinzeit war gestern! Die vielfältigen Wege der Cloud-nativen Evolution

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 #qaware #CloudNativeNerd

Transcript

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. OSMC OTP • • •
60. Process MQseries OTP APRIL Payment OpenShift Billing Payment APRIL UI B&P B2I LAAS EAI/SAP Saferpay OSMC