Cloud-native Java EE-volution

Mario-Leander Reimer, QAware GmbH
mario-leander.reimer@qaware.de
Cloud-native Java EE-volution
Cloud Native Night Munich
München, 06. November 2017

2
Can we evolve existing enterprise applications into the
cloud with reasonable effort?
Containerization
12-Factor App Principles
Microservices
Cloud-native Apps
Monolithic Deployment
Traditional Infrastructure

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
A <<System>>
OSMC (BDR)
H <<System>>
Fahrzeug
H <<System>>
Fahrzeuginterface (PTT)
I <<System>>
LAAS
A <<System>>
AOS (BDR)
A <<Subsystem>>
AOS-TS (BDR)
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
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)
3
Hyperscale, Antifragility and Continuous Delivery are the
driving motivations for the evolution of our systems.
Systemverbund
Berechtigte Dritte (BDR)
Stand R1711

4
Stateless Mule ESB
No UI, No Database
A <<System>>
APRIL (BDR)

5
StatefulWebapp
JEE6: JSF, EJB3, JPA
A <<System>>
B2I-UA (BDR)

6
StatefulWebapp
Spring MVC, JPA
A <<System>>
OSMC (BDR)

Facts. We need to establish a single source of truth for a
reliable forecast of resources, time and effort.
7
Questionnaire
What is the complexity of the application?
Which GF ML version is used?
Which technology stack is used by X?
….
Software Analysis
Static code analysis with Windup
Architecture analysis with S101
Proof of Concepts
Migration of APRIL
Migration of B2I-UA
QAware Know How
Experience from other migrations
Time Sheets
Veteran Team

The essential Design Principles for Cloud Native
Apps act as guidelines for the required changes.
8
Design for Distribution: Containers; microservices; API driven development.
Design for Performance: Responsive; concurrent; resource efficient.
Design for Automation: Automated Dev & Ops tasks.
Design for Resiliency: Fault-tolerant and self-healing.
Design for Elasticity: Scales dynamically and reacts to stimuli.
Design for Delivery: Short roundtrips and automated provisioning.
Design for Diagnosability: Cluster-wide logs, metrics and traces.

9
Favor a gradual transition instead of big bang migration
to reduce and handle technological risks involved.
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

Software Industrialization is a key requirement for
successful DevOps and Continuous Delivery.
11
High degree of automation for laborious and
repetitive tasks is mandatory
Better software quality through a optimized
and streamlined tool chain
More productivity and satisfaction of the
development teams
Better efficiency and competitiveness

Usage of the Agile Tool Chain (ATC)
Migration of all BDR repositories from SVN to Git
with full history within 1 week
Migration of all existing Jenkins build jobs tothe
new build infrastructure
More improvements to come …
The evolution of the associated build tool chain enables
short roundtrips and efficient feature development.
12
Drastically reduced build times for a higher
developer productivity and quality
Use common sense. Only migrate if you suffer
from excessive build times.
https://www.slideshare.net/QAware/von-maven-zu-gradle-in-45-minuten-81244540

Our Continuous Integration & Deployment Pipeline.
13

FROM payara/micro:173
# 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"]
Simple Dockerfile for Payara Micro.
15

version: ‘2’
services:
april-bdr-runtime:
build: .
image: "april-bdr-runtime:1.5.0"
volumes:
- ./src/test/glassfish/data:/april/data
- ./target/glassfish/logs:/april/logs
ports:
- "8080:8080"
A docker-compose.yml for building and running locally.
16
Use volumes to mount
local host directories
into the container

FROM payara/server-full:173
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
More sophisticated Dockerfile for Payara Server.
17

Industrialized migration of all deployment artifacts for a
quick, easy and unified containerization.
18
BMW Staging Tool
XML Files
kompose
OpenShift Deployment
YAML Files
Dockerfile +
docker-compose.yml
go2cnap
Local Development Cloud DeploymentTraditional Deployment

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"
Define Resource Constraints carefully.
20

-XX:+UnlockExperimentalVMOptions
-XX:+UseCGroupMemoryLimitForHeap
-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 -XX:+UseStringDeduplication
# optional
-XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary
Tune your JVM!
21
Since jdk8_131
Extra memory settings
GC tuning.
Fancy tuning.
Diagnostics.

apiVersion: v1
kind: ConfigMap
metadata:
name: april-aos-runtime-config
data:
april-aos.properties: |
com.bmw.iap.april.jwt.secret=some-secret
osmc.username=april
osmc.url=https://osmc-int.bmwgroup.net
...
april-feature-togglz.properties: |
WRITE_TEXT5_TO_SOFAK_INVOICES=false
...
log4j2.xml: |
<?xml version="1.0" encoding="UTF-8"?>
<Configuration monitorInterval="60">
<Appenders> ... </Appenders>
<Loggers> ... </Loggers>
</Configuration>
23
Use ConfigMaps, Secrets and Volumes to provide file
based configuration data to your deployments.
spec:
containers:
- name: april-aos-runtime
image: 'april-aos-runtime:1.5.0'
imagePullPolicy: Always
ports:
- containerPort: 8080
volumeMounts:
- mountPath: /april/data
name: april-aos-runtime-config-vol
volumes:
- name: april-aos-runtime-config-vol
configMap:
name: april-aos-runtime-config

Use Apache DeltaSpike for some extra configuration
features as well as other CDI extension magic.
24
DeltaSpike consists of a number of portable CDI extensions that provide useful features for Java
application developers.
Set of ready-to-use modules, including a core module and a number of optional modules for providing
additional enterprise functionality to your applications.
Core module with type-safe project stages and powerful interface based configuration mechanism
Data and JPA module enhanced JPA experience with declarative queries, reducing boilerplate to a
minimum
Security module for intercept and security checking on method calls.
Test-Control module for writing CDI-based tests easily
@Configuration(prefix = "some.", cacheFor = 30, cacheUnit = TimeUnit.SECONDS)
public interface SomeConfiguration {
@ConfigProperty(name = "url")
String url();
@ConfigProperty(name = "timeout", defaultValue = "30000")
long timeout();
}

# 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
Liveness and Readiness Probes for Metrics endpoints.
26

<servlet>
<servlet-name>adminServlet</servlet-name>
<servlet-class>
com.codahale.metrics.servlets.AdminServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>adminServlet</servlet-name>
<url-pattern>/admin/*</url-pattern>
</servlet-mapping>
27
Retrofitting metrics, health and admin endpoints using
the Dropwizard Metrics library in 30 minutes.
<dependencies>
<dependency>
<groupId>io.dropwizard.metrics</groupId>
<artifactId>metrics-core</artifactId>
<version>${metrics.version}</version>
</dependency>
</dependencies>
Usage of Dropwizard Metrics to retrofit metrics,
health and admin endpoints
Easy integration with any JEE7 application
Definition of Custom Health Checks
Used as Liveness und Readiness Probes

29
Retrofitting resiliency using Netflix Hystrix is easy.
Use Netflix Hystrix for the resilient (synchronous) call of any external system
Circuit Breaker and Bulk Heading implementation
Easy integration with any JEE7 application
Can be used easily with Jersey Client for REST Calls
Can be integrated easily with JSR 236 Concurrency API via HystrixConcurrencyStrategy
Integrates seemlessly with Dropwizard Metrics
<dependencies>
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-core</artifactId>
<version>${hystrix.version}</version>
</dependency>
</dependencies>

Alternatively, just use the MicroProfile 1.2 APIs.
31

<hazelcast>
<properties><property name="hazelcast.discovery.enabled">true</property></properties>
<network>
<join> 
<multicast enabled="false"/>
<tcp-ip enabled="false" />

<discovery-strategies>
<discovery-strategy enabled="true" class="com.hazelcast.kubernetes.HazelcastKubernetesDiscoveryStrategy">
<properties>

<property name="service-name">MY-SERVICE-NAME</property>
<property name="service-label-name">cluster01</property>
<property name="service-label-value">true</property>
<property name="namespace">MY-KUBERNETES-NAMESPACE</property>
</properties>
</discovery-strategy>
</discovery-strategies>
</join>
</network>
</hazelcast>
https://github.com/hazelcast/hazelcast-kubernetes
33

35
Cloud-native Application Development:
Components all along the software lifecycle.
DESIGN BUILD RUN
1:1 ?:1
Complexity unit
Data integrity unit
Coherent and cohesive feature unit
Decoupled unit
Planning & Assignment unit
Knowledge unit
Development unit
Integration unit
Release unit
Deployment unit
Runtime unit (crash, slow-down, access)
Scaling unit

36
Dev Components Ops Components?:1
System
Subsystems
Components
Services
Current starting point
DecompositionTrade-Offs
Microservices
Nanoservices
Macroservices
Monolith
+ More flexible to scale
+ Runtime isolation (crash, slow-down, …)
+ Independent releases, deployments, teams
+ Higher utilization possible
− Distribution debt: Latency
− Increasing infrastructure complexity
− Increasing troubleshooting complexity
− Increasing integration complexity

Logical view on the package structure of APRIL.
37

38
„Decomposing the Monolith“
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
All the business components with
their REST and SOAP interfaces are
contained in one single humongous
deployment unit.
Cross-cutting components

39
„Decomposing the Monolith“
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
Monitoring Logging
Vehicle
Adapter
Security
APRIL Vehicle
Deployment
Tracing
Monitoring Logging
Finance
Adapter
Security
APRIL Finance
Deployment
Tracing
Monitoring
Score
Adapter
Logging
FASTA
Adapter
Cert
Adapter
OSS Legacy
Adapter
Security
APRIL Client Deployment
Tracing
…
One deployment unit per
system context

Transform: extract a portion of the existing functionality into
a new and modern system.
Coexist: both systems coexist for some time. Calls agains
the old functionality are diverted.
Eliminate: old functionality will be removed from legacy
system once no more clients are using it.
Ideal for Web- and API-Monoliths.
Slightly problematic for Non-RESTful URL structures.
Stepwise evolution of legacy systems and Cloud-native
reconstruction using the Strangler Pattern.
40https://martinfowler.com/bliki/StranglerApplication.html

High level overview after the reconstruction.
41
Process
MQseries
OTP
APRIL
Payment
OpenShift
Billing
Payment
APRIL
UI
B&P
B2ILAAS EAI/SAP
Saferpay
OSMC

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

Cloud-native Java EE-volution

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Cloud-native Java EE-volution

Similaire à Cloud-native Java EE-volution (20)

Plus de QAware GmbH

Plus de QAware GmbH (20)

Dernier

Dernier (20)

Cloud-native Java EE-volution