Matthias Haeussler, Thorsten Jakoby
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 - - 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
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 DB2 MQ 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
Micro Services
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
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
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
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
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
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
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 Client SOAP JMS REST
Clean on Applications landscape
28
Same host/network App DB2 Client REST
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 Base Image Derived App Image App Deployment Descriptor 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 Base Image 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 App Image
EAR repo
Derived app image
- Bring properties as environment variable
- What’s to do on boot ?
35 Derived App Image
Container repo
K8s deployment descriptor
- Know platforms Ingress and Egress policies
!
- Mind wiring database and messaging
services 36 App Deployment Descriptor 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
Azure SQL Cloud
Write lock
Migrator App
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
App
SOAP / 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
B r
- k
e r
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
App
SOAP / 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
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
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
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
Thanks ! Questions ! Visit us on
- ur booth in the cafeteria :)