you shall not paas ?! let us be your guide to a successful ......devops professional agile...

Matthias Haeussler,Thorsten Jakoby

You shall not PaaS ?!Let us be your guide to a successful cloud migration

Agenda

• Brief information speakers and Novatec• Application details• Initial problem• High level migration path• Topics in detail

• Application and it’s runtime• Platform• Persistence and Messaging• Security

2

Speakers & Novatec Consulting GmbH Matthias Häußler

@maeddes

3

Thorsten Jakoby @jakobyte1024

Hannover Karlsruhe München Zweibrücken

Leinfelden- Echterdingen Berlin Frankfurt Hamburg

Our Locations

Granada

4

Agile Methods

▪ Agile Coach▪ Agile Leadership▪ Agile Training▪ Agile Transformation▪ Management 3.0▪ Scrum Master

Agile Software Engineering

▪ Methodical modernization

▪ Feedback-based Development & Pairing

▪ Build and test automation

▪ Continuous Everything

Value Engineering

▪ Agile Collaboration Tooling

▪ Agile Security▪ Agile Testing▪ Business Agility▪ DevOps▪ Professional Agile

Development

Data Intelligence

▪ Data Analytics▪ Data Engineering▪ Digital AI Operations▪ Artificial Intelligence

IT Architecture und Cloud

▪ Application Architecture

▪ Architectural Review▪ Cloud Computing

Digital Experience

▪ Digital Experience Analytics

▪ DE Engineering▪ DE Governance▪ DE Monitoring▪ Open DE Management

Enterprise Architecture Management

▪ EAM Assessment▪ EAM Business Case▪ AM Introduction▪ AM Operationalization▪ AM Tool Selection and

Introduction▪ T4IT Introduction

Business Process Management

▪ BPMS Selection▪ BPM Technology

Consulting▪ Enterprise Task

Management▪ Process automatization

Core competencies

5

Application information

7

Application’s business context

- Central backend component in connected car context- Connects user with vehicle- Enables use cases like “Open car via smartphone”- Enables B2B use cases like “Pay as you drive”

8

• ~1.000.000 Requests / hour• ~230 kloc• Deployed in 3 geographics• Based on Java EE 6 - running on

WAS 8• Connected to backend systems via

• JMS• HTTP• SOAP• JDBC (DB2)

Application’s technical details

9

WAS

Apps

DB2MQ

Client

Client

Client SOAP

JMS

REST

Initial Situation

• Customers wants to • modernize their technical infrastructure• Deploy more often and faster as currently• Separate their applications by domains

• Example: how to Hotfix

Data Center

WAS

Apps

Cloud

MicroServices

Apps

Kick-off Future

10

11

Local Operating System

WAS

Apps

Hosted CF / K8s

App(s)

Local Operating System

Local Operating System

Hosted CF / K8s

“Cloud Dev VM”PCF-DEV / Minikube

Future

MicroServices

High level migration path

Kick-off

WLP

App

WLP

App

WLP

App

WLP

App

WLP

App

WLP

App WLP

App

WLP

App

WLP

App

Application

12

Requirements

• Make the applications “cloud ready”. That means• runnable in container• scaleable• stateless

• Choose the path with the least risk• Enable online-migration / Zero-downtime

13

14

Local Operating System

WAS

App

Cloud Platform

DockerContainer

WAS

App

Cloud Platform

Liberty Buildpack

WLP

App

Cloud Platform

Various Buildpacks

App‘ App‘

App‘ App‘

„WAS in container“

„Liberty Profile“

„Cloud Native reimplementation“

Initial ideas

15

Local Operating System

WAS

App

Cloud Platform

DockerContainer

WAS

App

Cloud Platform

Liberty Buildpack

Liberty

App

Cloud Platform

Various Buildpacks

App‘ App‘

App‘ App‘

„WAS in container“

„Liberty Profile“

Cloud Native reimplementation

Initial ideas

• WAS only fits with limited capabilities into a container

• WAS Cluster not possible• Boot takes a long time• Not recommended by IBM

Local Operating System

WAS

App

Cloud Platform

DockerContainer

WAS

App

Cloud Platform

Liberty Buildpack

LibertyApp

Cloud Platform

Various Buildpacks

App‘ App‘

App‘ App‘

„WAS in container“

„Liberty profile“

Cloud Native reimplementation

• Is desired target situation• Needs big rewriting effort• Assessed as to risky for online migration• Would mean two parallel development streams

until Go-Live

Initial ideas

16

17

IBM Migration Tools● IBM provides 2 migration tools

○ IDE Plugin○ CLI Analyse

● https://developer.ibm.com/wasdev/docs/migration/

18

> 8000 required changes

Exchange of JPA Providers

Surprising Results

19

Java EE 6 or 7 ?

20

JEE 6 vs. JEE 7 compatibility - Helpful matrix

Initial ideas: unwanted effort by maintaining parallel branches

New “cloud” branch

“old” master branch Deployment Cloud

Deployment Legacy

Manual merging delta code

21

Initial ideas: apply One Codebase - Many Deploys

“One and only” master branch

Deployment Cloud

Deployment Legacy

Various configurations

Delta code as usual

22

Real Findings

• Apache Axis2 API not available• WebSphere WorkArea API/SPI not available• WebSphere Web Services Security API not available• Java API for RESTful Web Services (JAX-RS) needs to be v2.0 • No JNDI Lookups with “ejblocal” Prefix

• In general: WAS is more tolerant (also outside Java EE Specs)• For example: class with @Singleton and @Stateless annotations are accepted

23

Lessons learned

• WAS is more tolerant than WLP -> code becomes more clean with WLP• IBM Tools helpful, but not always accurate - “sounds more bad than it actually is”• IBM Support helpful

24

Platform

25

Requirements and plan

• Operate “cloud-ready” applications in Kubernetes• Try migration local Minikube and use existing database and messaging

services• Migrate to owned and managed K8s

26

Bring WLP on Cloud Platform

• App running on Liberty in local development environment• Local persistence and messaging services are wired into Minikube

Local Operating System

Liberty

App

Local Operating System

Liberty

App

Local cloud env

27

Liberty

App

DB2

Client

MQ

Client

ClientSOAP

JMS

REST

Clean on Applications landscape

28

Same host/network

App

DB2

ClientREST

Cloud Platform

Applications landscape with local cloud VM

29

Deploy and wire where how ?

30

Use Liberty to get app as “self-contained” deploy artifact

Overall K8s’ing process

32

WLP BaseImage

DerivedApp

Image

AppDeploymentDescriptor

Git EAR repo Container repo

K8s

Step 1 Step 2 Step 3

Base image in detail- Look for available base images- Choose base OS wisely- Do not use latest tags- Automate creation and push of your base

image- clarify licensing of used software

33

WLP BaseImage

Git

Prepare app container- Draft how to build the container as script- Write a pipeline-job according to your draft- Mind runtime dependencies- How and when will who migrate your

database ?

34

AppImage

EAR repo

Derived app image- Bring properties as environment variable- What’s to do on boot ?

35

DerivedApp

Image

Container repo

K8s deployment descriptor- Know platforms Ingress and Egress policies

!- Mind wiring database and messaging

services

36

AppDeploymentDescriptor

Container repo

K8s

Persistence

37

Requirements

• Use a relational “cloud-native” database• Continue using JPA and Flyway• Needs to be at least as good as DB2 regarding

• Transactional DDL• Backup / Restore• Scaling• Maintenance• Monitoring / Analysis

38

Persistence - Research and decision

• DBMS candidates were• MySQL• AzureSQL• PostgreSQL

• AzureSQL was selected

39

Persistence - Data migration / GoLive

• Migration will be done when load is usually minimal

• Write-Lock on DB2 => App will fall into a controllable error state per request

• Solution candidate #1 “Offline”: migration via migrator-app

• Solution candidate #2 “Online”: linked databases

40

App @ WAS

DB2

Non-Cloud

App @ WLP

AzureSQL

Cloud

Write lock

MigratorApp

Lessons learned

• Switching the database system can be easier as expected. • See Novatec Blog “The Myth of Easily Changing the Database System Underneath a

Persistence Layer”

41

Messaging

42

Requirements

43

• Use “Cloud native” communication services...• … but keep compatibility to non-cloud-native messaging applications

Messaging - past

• Apps using synchronous and asynchronous messaging patterns amongst various technologies

• Application’s landscape needs to keep asynchronous messaging

44

AppSOAP / REST / JMS Request

SOAP / REST / JMS Response App

Messaging - Cloud

• JMS is not flexible enough• AMQP brokers with

JMS-interfaces possible with QPid.Could not be used due to incompatible JEE6 stack

• Introducing Async-REST:• REST Call includes Callback-URL• AMQP-broker transparent to

consumers

45

App

Outbound REST Call incl. Callback-URL

acknowledge

REST Callback

acknowledge

App

Broker

Lessons learned

• Used Async REST to clean up messaging technology stack• Async REST as transition step will be removed as the landscape will allow it • AMQP will be introduced as a replacement• Read more on Novatec blog “Why We Left JMS on the Ground”

46

Security

47

Requirements

- Needs to work- Integrate existing corporate Identity and Access Management

48

IAM Integration past

- Apps were using corporate specific security stack

- Stack implementation changed throughout each deployment stage

- Human user SSO & Technical User non-interactive sign on

49

AppSOAP / REST / JMS Request

SOAP / REST / JMS Response App

UserReg

Sec Sec

Modernizing SecStack- Use JWT instead of basic auth and user reg- Create side-car-container to

- distinguish between interactive human login and non-interactive technical login

- connect to different corporate user registries- get the security config out of App container

50

Lessons learned

• Understand corporate directories is not fun• Understand corporate directories policies is also not fun• Clarify early which certificates needs to be in app and security container

51

Work in Progress & Lookout

52

53

Local Operating System

WAS

Apps

Hosted CF / K8s

App(s)

Local Operating System

Local Operating System

Hosted CF / K8s

“Cloud Dev VM”PCF-DEV / Minikube

Future

MicroServices

High level migration path

Kick-off

WLP

App

WLP

App

WLP

App

WLP

App

WLP

App

WLP

App WLP

App

WLP

App

WLP

App

Cross functional team

Skill sets:• Product Owner• JEE development (JSF/JPA)• AppServer administration (WAS/WLP)• Container/Cloud (docker/K8s)• CICD Pipelines• Security

54

Typical tasks:• clarify migration options with stakeholders /

sell workarounds• Fix incompatibilities inside the application• Optimize app dependencies / WLP profile• Make configurations k8s-ready• Deploy/test on different environments• Automate build/deployment processes

Monolith’s decomposition

• New functions are not implemented in monoliths• Instead we started using separating monoliths using Strangler Pattern

55Cloud Platform

Spring

„new“REST

Liberty

App

Cloud Platform

Liberty

App‘

Liberty

App‘

Nodejs

App‘

Spring

new

Ruby/Go/

Swift

MS‘

New devDecomposition

Thanks ! Questions ! Visit us on our booth in the cafeteria :)