From 4 releases per year to 104 Joakim Lindbom - Redhat Summit 2020
•Download as PPTX, PDF•
0 likes•95 views
Legacy Modernisation - how we went from 4 releases per year to well over 104, by using an automate-anything-that-moves attitude.
Recommended
Recommended
More Related Content
Similar to From 4 releases per year to 104 Joakim Lindbom - Redhat Summit 2020
Similar to From 4 releases per year to 104 Joakim Lindbom - Redhat Summit 2020 (20)
More from Joakim Lindbom
More from Joakim Lindbom (13)
Recently uploaded
Recently uploaded (20)
From 4 releases per year to 104 Joakim Lindbom - Redhat Summit 2020
- 1. From 4 releases per year to 104 - using an automate-everything-that-moves attitude Legacy modernization Joakim Lindbom Certified Chief Architect Account Architect Capgemini Sweden
- 2. Joakim Lindbom Chief Architect Joakim.Lindbom@capgemini.com +4685368 3934 +46708166404 twitter: JoakimLindbom http://www.slideshare.net/JoakimLindbom http://www.linkedin.com/in/joakimlindbom Who am I?
- 3. 15 years of legacy modernisation Finance, banks, telco – mainframe system from 70s - COBOL Midrange from 80s - RPG Client/Server from 90s – SQL Windows Mainframe from 60s – 4th GL VAX from 80s - Pascal Retail – mainframe system from 70s - PL1
- 4. Legacy?
- 6. Legacy systems Anythin older than 15 days or not written in Java Systems having more control over you than you have over the systems Revenue generating systems
- 7. 7From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. We’ll se more change the next 5 years than the previous 100 in the auto industry. Ian Robertson, Chairman of Rolls Royce Chief of Sales and Marketing, BMW
- 8. 8From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Towards #ZeroDayForever
- 9. 9From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Lack of speed kills! 0 20 40 60 80 100 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 Best & Beautiful A Inc B Inc C Inc
- 10. 10From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved.
- 11. Cloud native
- 12. 12From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. The server don’t know what the consumer/client is doing https://en.wikipedia.org/wiki/Hypertext_Application_Language https://en.wikipedia.org/wiki/HATEOAS It presents Resources and Links – but don’t prescribe how to use them One key to decoupling: REST Level 3 + HAL & HATEOAS
- 13. 13From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. A REST service calling a REST service calling a REST service calling a REST service... One key to decoupling: Messages, Events & Eventual Consistency Enough is enough!
- 14. 14From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. You’ll not succeed if you copy the plain old patterns! Remember the CAP theorem! Remember the laws of physics! One key to decoupling: Cloud Native patterns C A P
- 15. 15From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Autonomous services Create agnostic & autonomous services Should act as Lego bricks ”No, I didn’t plan for you to use red lego bricks with the yellow ones. You need to file a CR...”
- 16. 4 to 104
- 17. 17From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Actually a lot more, I just stopped counting... 104? Drops to production last year 45+ in legacy system 400+ boring releases in API layer
- 18. 18From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Starting point FAT Client SOA Service 1 SOA Service 2 SOA Service 3 SOA Service 4 SOA Service 5 SOA Service 6 SOA Service .. SOA Service n ESB (Bespoke) 4 releases/year – one year only one release Most anything manual
- 19. 19From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. First evolution step SOA Service 1 SOA Service 2 SOA Service 3 SOA Service 4 SOA Service 5 SOA Service 6 SOA Service .. SOA Service n FAT Client ESB (Bespoke) Thin Client (Tablet) Open-ended REST Lvl3 + HAL + HATEOASµS µS µS µS Focus on time-to-market!
- 20. 20From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Second evolution step SOA Service 1 SOA Service 2 SOA Service 3 SOA Service 4 SOA Service 5 SOA Service 6 SOA Service .. SOA Service n FAT Client ESB (Bespoke) Open-ended REST Lvl3 + HAL + HATEOASµS µS µS µS Also include business logic µS µS µS µS µS µS Thin Client (Tablet) Thin Client (Kiosk) 3rd party 3rd party 3rd party
- 21. 21From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Third evolution step - Everything as code / GitOps Build: Jenkins Artifacts: Artifactory Deploy: Ansible + Python Test: Ansible + Python + UFT GIT HW OS Middleware Application Database User props CFG CFG Schema Test Data JAR etc CFG Config DB App Server PropInject Fine granular Auto generate delta
- 22. 22From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Third evolution step - Configuration modularisation Build: Jenkins Artifacts: Artifactory Deploy: Ansible + Python Test: Ansible + Python + UFT GIT CFG CFG Multi dimentional configuration CFG App Server 1 For one envCFG CFG CFG CFG For all App Servers For all envs ... ... GIT YAML Secrets App Server 2 Ongoing – at least 99% reduction expected due to massive duplication + improper use of config db Ansible and Jinja2 macros helps a lot!
- 23. 23From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. GitOps test and deployment Jenkins Github Enterprise Build Package Java code Database schema Deploy Server Execute API regression test Execute Client regression test Base environment config (App server Properties) Inject config into environmentGithub Enterprise Test suite Extract & configure test suite Github Enterprise Deploy Client Privat test Nightly Bi-weekly Project test Nightly Weekly On-demand Integration test On-demandWeekly Deploy Database Auto generate delta scripts
- 24. 24From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Deployment – gitops – new simplified setup
- 25. 25From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Daily, hourly, weekly, on-demand and at production deployment Some tests even every 5 minutes! Test automation Total savings so far: 4 FTEs With current plan: 8 FTEs But – we’re not replacing people! Now our manual testers focus on even more value add!
- 26. 26From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Automation in support and problem resolution S t e a d y S t a t e P r o b l e m S t a t e U s e r I d e n t i f i e s I s s u e U s e r R e p o r t s I s s u e W o r k O n I n c i d e n t F i x I n c i d e n t C l o s e I n c i d e n t R e a c t i v e R P A B o t sP r e v e n t i v e B o t s C h a t - B o t s C A P - M a s t e rM o n i t o r i n g A p p l i c a t i o n U s e r F A Q / S O P A p p l i c a t i o n D a t a P a s t I n c i d e n t s Machine Learning I n t e n t s R e c o m m e n d a t i o n s Q u e r i e s R e s p o n s eNaturalLanguageProcessing C r e a t e I n c i d e n t S o l u t i o n S t e p s E x e c u t e S o l u t i o n C o n v e r s a t i o n I n v o k e R P A B o t
- 27. 27From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Automation in support and problem resolution Send analysis report with root cause & solution Functional BOT Identify BOT and i/p parameter name based on ticket description Request Queue Initiator Dispatcher L2 Support Validates & implements solution Command Center Retrieve request Retrieve ‘new’ incidents 3 4 6 97 Create request Ticketing tool 5 Extract input parameter “value” from Remedy where applicable Invoke BOT passing input value 8 11 Application L2 Support Application Send execution status by email Execute solution 9 11 Send execution status 10 Application BOT Orchestrator Creates ticket in ticketing tool (Remedy) with supporting attachment 2
- 28. 28From 4 to 104 releases | Joakim Lindbom | 2020-04-03 © 2020 Capgemini. All rights reserved. Test suites Data driven development Client - UFT Test execution status @GCP Splunk Client - BDD SOA Services BDD SOA Service 1 SOA Service 1 SOA Service N API µservice 2 µservice … µservice 1 Fat Client Web Client New verson deployed Config change Test reports
- 29. From 4 releases per year to 104 - using an automate-everything-that-moves attitude Legacy modernization Joakim Lindbom Certified Chief Architect Account Architect Capgemini Sweden Photos from https://www.rgbstock.com/
Editor's Notes
- A - Tvetydig
- Hypermedia as the Engine of Application State
- Consistency Availability Partition tolerance
- Lego didn’t ask the kids what model they’d build!
- GIT Jenkins – basic usage UT 1000s – pretty good SWQ – pretty OK, if you trust the tools But still very hard to learn – 4+ MLoC
- Starting with nearly zero when it comes to test automation and modern tools in core system, we have come far with the modernization: Modern CICD pipeline built with modern tools (Github Enterprise, Jenkins, Ansible, Behave, etc.) Git used as single-source-of-truth, aka GitOps based design; all assets are maintained under version control, not only the Java or Kotlin code. Configuration items (App Server Properties) taken from a manual, UI-based update and brought into Github – this means there’s no manual intervention needed when deploying. Besides providing 100% automation, this approach cuts out manual errors, which is identified as the main cause of test environment issues; next step is to expand to include properties stored in DFP Data based versioning is now piloted where we auto generate the delta scripts for a particular environment. The database schema is under version control, tightly connected with the corresponding source code; the delta scripts are independent from the code and reflect the actual need for any environment. Test automation extracted from git and configured before execution. Test automation also running as part of daily/weekly/etc smoke/business critical scenarios. We’re using the TDBot to extract available test data, rather than e.g. using hard coded article numbers. We’re working closely with the TDBot team to expand reach and scope of the test data collection tool. We’re currently deploying to the various on-prem environments under our control, but the design of the CICD solution includes higher level environments (pre-prod and prod) as well as cloud based based hosting.
- This is a modern CICD pipeline built with modern tooling (Jenkins, Ansible, Behave, etc.) Git used as single-source-of-truth, aka gitops based design Configuration items (Properties) maintained under version control – no manual intervention needed when deploying (next step is to expand to include properties stored in DFP). The main reasons is to cut out manual errors and ned for human intervention during the deploy process. Test automation extracted from git and configured before execution. Test automation also running as part of daily/weekly/etc smoke/business critical scenarios Remaining work: All components work y themselves, integration work is ongoing in current sprint (as of 2020-09-19), including blocking deployment after SWQ and RegTest Pilot rollout for DB versioning and properties injection is ongoing. Selection of RegTest subset based on which service is deployed Rollout to all environments, up to and including Prod – principal agreement with platform team done.