You shall not PaaS ?! Let us be your guide to a successful cloud - - PowerPoint PPT Presentation

you shall not paas let us be your guide to a successful
SMART_READER_LITE
LIVE PREVIEW

You shall not PaaS ?! Let us be your guide to a successful cloud - - PowerPoint PPT Presentation

You shall not PaaS ?! Let us be your guide to a successful cloud migration Matthias Haeussler, Thorsten Jakoby Agenda Brief information speakers and Novatec Application details Initial problem High level migration path


slide-1
SLIDE 1

Matthias Haeussler, Thorsten Jakoby

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

slide-2
SLIDE 2

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

slide-3
SLIDE 3

Speakers & Novatec Consulting GmbH

Matthias Häußler @maeddes 3 Thorsten Jakoby @jakobyte1024

slide-4
SLIDE 4

Hannover Karlsruhe München Zweibrücken Leinfelden- Echterdingen Berlin Frankfurt Hamburg

Our Locations

Granada

4

slide-5
SLIDE 5

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

slide-6
SLIDE 6
slide-7
SLIDE 7

Application information

7

slide-8
SLIDE 8

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

slide-9
SLIDE 9
  • ~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 DB2 MQ Client Client Client SOAP JMS REST

slide-10
SLIDE 10

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

Micro Services

Apps

Kick-off Future

10

slide-11
SLIDE 11

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

Micro Services

High level migration path

Kick-off

WLP App WLP App WLP App WLP App WLP App WLP App WLP App WLP App WLP App

slide-12
SLIDE 12

Application

12

slide-13
SLIDE 13

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

slide-14
SLIDE 14

14

Local Operating System

WAS App

Cloud Platform

Docker Container

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

slide-15
SLIDE 15

15

Local Operating System

WAS App

Cloud Platform

Docker Container

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
slide-16
SLIDE 16

Local Operating System

WAS App

Cloud Platform

Docker Container

WAS App

Cloud Platform

Liberty Buildpack

Liberty

App

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

slide-17
SLIDE 17

17

IBM Migration Tools

  • IBM provides 2 migration tools

○ IDE Plugin ○ CLI Analyse

  • https://developer.ibm.com/wasdev/docs/migration/
slide-18
SLIDE 18

18

> 8000 required changes Exchange of JPA Providers

Surprising Results

slide-19
SLIDE 19

19

Java EE 6 or 7 ?

slide-20
SLIDE 20

20

JEE 6 vs. JEE 7 compatibility - Helpful matrix

slide-21
SLIDE 21

Initial ideas: unwanted effort by maintaining parallel branches

New “cloud” branch “old” master branch Deployment Cloud Deployment Legacy Manual merging delta code 21

slide-22
SLIDE 22

Initial ideas: apply One Codebase - Many Deploys

“One and only” master branch Deployment Cloud Deployment Legacy Various configurations Delta code as usual 22

slide-23
SLIDE 23

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

slide-24
SLIDE 24

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

slide-25
SLIDE 25

Platform

25

slide-26
SLIDE 26

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

slide-27
SLIDE 27

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

slide-28
SLIDE 28

Liberty App DB2 Client MQ Client Client SOAP JMS REST

Clean on Applications landscape

28

slide-29
SLIDE 29

Same host/network App DB2 Client REST

Cloud Platform

Applications landscape with local cloud VM

29

slide-30
SLIDE 30

Deploy and wire where how ?

30

slide-31
SLIDE 31

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

slide-32
SLIDE 32

Overall K8s’ing process

32 WLP Base Image Derived App Image App Deployment Descriptor Git EAR repo Container repo K8s Step 1 Step 2 Step 3

slide-33
SLIDE 33

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 Base Image Git

slide-34
SLIDE 34

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 App Image

EAR repo

slide-35
SLIDE 35

Derived app image

  • Bring properties as environment variable
  • What’s to do on boot ?

35 Derived App Image

Container repo

slide-36
SLIDE 36

K8s deployment descriptor

  • Know platforms Ingress and Egress policies

!

  • Mind wiring database and messaging

services 36 App Deployment Descriptor Container repo K8s

slide-37
SLIDE 37

Persistence

37

slide-38
SLIDE 38

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

slide-39
SLIDE 39

Persistence - Research and decision

  • DBMS candidates were
  • MySQL
  • AzureSQL
  • PostgreSQL
  • AzureSQL was selected

39

slide-40
SLIDE 40

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

Azure SQL Cloud

Write lock

Migrator App

slide-41
SLIDE 41

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

slide-42
SLIDE 42

Messaging

42

slide-43
SLIDE 43

Requirements

43

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

Messaging - past

  • Apps using synchronous and

asynchronous messaging patterns amongst various technologies

  • Application’s landscape needs to

keep asynchronous messaging

44

App

SOAP / REST / JMS Request SOAP / REST / JMS Response

App

slide-45
SLIDE 45

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

B r

  • k

e r

slide-46
SLIDE 46

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

slide-47
SLIDE 47

Security

47

slide-48
SLIDE 48

Requirements

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

48

slide-49
SLIDE 49

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

App

SOAP / REST / JMS Request SOAP / REST / JMS Response

App

UserReg Sec Sec

slide-50
SLIDE 50

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

slide-51
SLIDE 51

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

slide-52
SLIDE 52

Work in Progress & Lookout

52

slide-53
SLIDE 53

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

Micro Services

High level migration path

Kick-off

WLP App WLP App WLP App WLP App WLP App WLP App WLP App WLP App WLP App

slide-54
SLIDE 54

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
slide-55
SLIDE 55

Monolith’s decomposition

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

55

Cloud Platform

Spring

„new“

REST

Liberty

App

Cloud Platform

Liberty

App‘

Liberty

App‘

Nodejs

App‘

Spring

new

Ruby/ Go/ Swift

MS‘

New dev Decomposition

slide-56
SLIDE 56

Thanks ! Questions ! Visit us on

  • ur booth in the cafeteria :)