you shall not paas let us be your guide to a successful
play

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


  1. You shall not PaaS ?! Let us be your guide to a successful cloud migration Matthias Haeussler, Thorsten Jakoby

  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

  3. Speakers & Novatec Consulting GmbH Thorsten Jakoby Matthias Häußler @jakobyte1024 @maeddes 3

  4. Our Locations Leinfelden- Echterdingen Berlin Frankfurt Hamburg Hannover Karlsruhe München Zweibrücken Granada 4

  5. Core competencies Data Intelligence IT Architecture und Agile Methods Value Engineering Cloud ▪ Data Analytics ▪ Agile Coach ▪ Agile Collaboration ▪ ▪ Data Engineering Application ▪ Agile Leadership Tooling ▪ Digital AI Operations Architecture ▪ ▪ Agile Training Agile Security ▪ Artificial Intelligence ▪ Architectural Review ▪ ▪ Agile Transformation Agile Testing ▪ Cloud Computing ▪ Management 3.0 ▪ Business Agility ▪ Scrum Master ▪ DevOps ▪ Professional Agile Development Digital Experience Enterprise Architecture Business Process Agile Software Management Management Engineering ▪ Digital Experience ▪ Analytics EAM Assessment ▪ ▪ BPMS Selection Methodical ▪ ▪ DE Engineering EAM Business Case ▪ BPM Technology modernization ▪ ▪ AM Introduction DE Governance Consulting ▪ Feedback-based ▪ ▪ AM Operationalization DE Monitoring ▪ Enterprise Task Development & Pairing ▪ ▪ Open DE Management AM Tool Selection and ▪ Management Build and test Introduction ▪ Process automatization automation ▪ T4IT Introduction ▪ Continuous Everything 5

  6. Application information 7

  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

  8. Application’s technical details • ~1.000.000 Requests / hour ~230 kloc • • Deployed in 3 geographics SOAP Client Based on Java EE 6 - running on • JMS WAS 8 Client Apps Connected to backend systems via • REST Client • JMS • HTTP DB2 MQ WAS • SOAP • JDBC (DB2) 9

  9. Initial Situation Kick-off Future Apps Apps Micro WAS Services Data Center Cloud Customers wants to • • modernize their technical infrastructure • Deploy more often and faster as currently • Separate their applications by domains Example: how to Hotfix • 10

  10. High level migration path Kick-off Future Apps App(s) Micro WAS Services Local Operating System Hosted CF / K8s App App App App App App WLP WLP WLP WLP WLP WLP App App App Local Operating System Hosted CF / K8s WLP WLP WLP “Cloud Dev VM” PCF-DEV / Minikube Local Operating System 11

  11. Application 12

  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

  13. Initial ideas App WAS Docker „WAS in Container container“ Cloud Platform App App WLP WAS „Liberty Profile“ Liberty Buildpack Local Operating System Cloud Platform App‘ App‘ „Cloud Native App‘ App‘ reimplementation“ Various Buildpacks Cloud Platform 14

  14. Initial ideas App WAS Docker „WAS in Container container“ Cloud Platform App App Liberty • WAS only fits with limited capabilities into a WAS „Liberty Profile“ Liberty container Buildpack Local Operating System • WAS Cluster not possible Cloud Platform • Boot takes a long time • Not recommended by IBM App‘ App‘ Cloud Native App‘ App‘ reimplementation Various Buildpacks Cloud Platform 15

  15. Initial ideas App WAS Docker • Is desired target situation „WAS in Container • Needs big rewriting effort container“ Cloud Platform • Assessed as to risky for online migration • Would mean two parallel development streams App App until Go-Live Liberty WAS „Liberty profile“ Liberty Buildpack Local Operating System Cloud Platform App‘ App‘ Cloud Native App‘ App‘ reimplementation Various Buildpacks Cloud Platform 16

  16. IBM Migration Tools ● IBM provides 2 migration tools ○ IDE Plugin ○ CLI Analyse ● https://developer.ibm.com/wasdev/docs/migration/ 17

  17. Surprising Results > 8000 required changes Exchange of JPA Providers 18

  18. Java EE 6 or 7 ? 19

  19. JEE 6 vs. JEE 7 compatibility - Helpful matrix 20

  20. Initial ideas: unwanted effort by maintaining parallel branches New “cloud” branch Deployment Cloud “old” master branch Deployment Legacy Manual merging delta code 21

  21. Initial ideas: apply One Codebase - Many Deploys Various configurations “One and only” Deployment Cloud master branch Deployment Legacy Delta code as usual 22

  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

  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

  24. Platform 25

  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

  26. Bring WLP on Cloud Platform • App running on Liberty in local development environment Local persistence and messaging services are wired into Minikube • App App Liberty Liberty Local Operating System Local cloud env Local Operating System 27

  27. Clean on Applications landscape SOAP Client JMS Client App REST Client DB2 MQ Liberty 28

  28. Applications landscape with local cloud VM App REST Client DB2 Cloud Platform Same host/network 29

  29. Deploy and wire where how ? 30

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

  31. Overall K8s’ing process Step 1 Step 2 Step 3 Derived App WLP Base K8s App Deployment Image Image Descriptor Container Git EAR repo repo 32

  32. 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 WLP Base Image Git 33

  33. 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 ? App Image EAR repo 34

  34. Derived app image - Bring properties as environment variable - What’s to do on boot ? Derived App Image Container repo 35

  35. K8s deployment descriptor - Know platforms Ingress and Egress policies ! - Mind wiring database and messaging services App K8s Deployment Descriptor Container repo 36

  36. Persistence 37

  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

  38. Persistence - Research and decision • DBMS candidates were • MySQL • AzureSQL • PostgreSQL • AzureSQL was selected 39

  39. Persistence - Data migration / GoLive • Migration will be done when load Non-Cloud Cloud is usually minimal • Write-Lock on DB2 => App will fall App @ WAS App @ WLP into a controllable error state per request Write lock Migrator Azure • Solution candidate #1 “Offline”: DB2 App SQL migration via migrator-app • Solution candidate #2 “Online”: linked databases 40

  40. 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

  41. Messaging 42

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

  43. Messaging - past • Apps using synchronous and asynchronous messaging patterns amongst various technologies Application’s landscape needs to • keep asynchronous messaging SOAP / REST / JMS Request App App SOAP / REST / JMS Response 44

  44. Messaging - Cloud • JMS is not flexible enough AMQP brokers with • JMS-interfaces possible with QPid. Could not be used due to Outbound REST Call incl. Callback-URL B incompatible JEE6 stack r acknowledge o App App k REST Callback e r acknowledge • Introducing Async-REST: • REST Call includes Callback-URL • AMQP-broker transparent to consumers 45

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend