Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Similar a A Blueprint for Cloud-Native Financial Institutions
Similar a A Blueprint for Cloud-Native Financial Institutions (20)
Último
Último (20)
A Blueprint for Cloud-Native Financial Institutions
- 2. ANGELO AGATINO NICOLOSI 2 https://dk.linkedin.com/in/anicolosi
- 3. AGENDA The Dream A New Beginning The Cloud-Native Financial Institution Fast-Track to Evolutionary Architecture 3
- 6. AN ENTERPRISE APPLICATION 6 Network Compute Databases API Management Monitoring Application Security Message Broker Application Logs Audit Logs Resource Management Deployment Collaboration Integration PKI
- 7. AN ENTERPRISE APPLICATION 7 Network Compute Databases API Management Monitoring Application Security Message Broker Application Logs Audit Logs Resource Management Deployment Collaboration Integration PKI Audit Risk and Security Assessment …
- 8. AN ENTERPRISE APPLICATION 8 Network Compute Databases API Management Monitoring Application Security Message Broker Application Logs Audit Logs Resource Management Deployment Collaboration Integration PKI Audit Risk and Security Assessment …
- 9. OUR DREAM: AGILE ENTERPRISE 9
- 10. ADOPT EVOLUTIONARY ARCHITECTURE 10 Refocus resources and efforts in building a future-proof architecture. …and stop trying to predict what the business and technology will look like in the future.
- 11. AGENDA The Dream A New Beginning The Cloud-Native Financial Institution Fast-Track to Evolutionary Architecture 11
- 13. - Current status - Tight coupling - High complexity - Large Regression tests - Operational Issues - Local and Enterprise Change Advisory Boards - Release is a pain - Serious business losses Image from: https://disrupt-and-innovate.org 2015
- 14. • 05.2013: Release • 12.2013: ≈ 1M users Data from Wikipedia
- 15. 15 • 05.2013: Release • 12.2013: ≈ 1M users • 05.2015: Release • 11.2015: 1M users Data from Wikipedia
- 16. 2015
- 17. 2015
- 18. - Is the mainframe really the issue? 2015
- 19. - Is the mainframe really the issue? - Thousands of modules, programs, copybooks, etc. in PL1 and Cobol. - External interfaces have been estimated to be > 50K. - No documentation. - Multiple versions with no way to know which one to use. - Same functionality implemented multiple times. 2015
- 20. - Is the mainframe really the issue? - Thousands of modules, programs, copybooks, etc. in PL1 and Cobol. - External interfaces have been estimated to be > 50K. - No documentation. - Multiple versions with no way to know which one to use. - Same functionality implemented multiple times. 2015
- 21. THE OUT OF MAINFRAME PROJECTS! A.K.A. THE ”RECODE THE BANK” PROJECTS 2015
- 22. - The system was complex to develop in. However: - All transactions hit one single DBMS. - Very skilled DBA central unit with dedicated specialists in any development team. - Constant monitoring and optimization. - RCAs on incidents seldom located root causes on this platform. DB2 2015
- 23. - Is the mainframe really the issue? - It was true that the system was complex. But just to develop in. - All transactions hit one single DBMS. - Very skilled DBA central unit with dedicated specialists in any development team. - Constant monitoring and optimization. - RCAs on incidents seldom located root causes on this platform. DB2 2015
- 26. Illustration: Jim Nelson for his book ”On the shoulder of a giant”” #1 STAND ON THE SHOULDERS OF GIANTS And remove technical debt
- 27. Q4 2015 Identify Technical Debt Q1 2016 Public Cloud!
- 28. Q4 2015 Identify Technical Debt Q1 2016 Public Cloud! Q2 2016 Private Cloud
- 29. Q4 2015 Identify Technical Debt Q1 2016 Public Cloud! Q2 2016 Private Cloud Q3 2016 Production
- 30. #2 BE SMART 30 - Define an Exit Strategy - Use containers - Segregate business logic from ”infrastructure wiring” - Adopt an evolutionary architecture
- 31. AGENDA The Dream A New Beginning The Cloud-Native Financial Institution Fast-Track to Evolutionary Architecture 31
- 33. APIGateway APIGateway STEP 1: ENSURE SEGREGATION Old middleware
- 34. APIGateway APIGateway STEP 2: MIGRATE BUSINESS LOGIC
- 35. STEP 3: PERFORM DATA MIGRATION APIGateway APIGateway
- 36. ENCLAVE - DEFINITION MICROSERVICES FOR THE ENTERPRISE 36 An enclave is a self-sufficient, secured and isolated platform composed of a set of services supporting any number of external or internal applications that resides within the same enterprise business domain.
- 37. - It has a single inbound (API Gateway) and a single outbound (Integration) network microsegment. - Microservices in the API Gateway and Integration Context are completely stateless (regarding the transactions). - It segregates business domains in different microsegments of network - Synchronous communication is discouraged (besides for data queries). - Mutual TLS everywhere microsegments are crossed. - Authorization through JWTs SOME DETAILS Security Business DomainsBusiness DomainsBusiness Domains API Gateway Integration
- 38. - It has a single inbound (API Gateway) and a single outbound (Integration) network microsegment. - Microservices in the API Gateway and Integration Context are completely stateless (regarding the transactions). - It segregates business domains in different microsegments of network - Synchronous communication is discouraged (besides for data queries). - Mutual TLS everywhere microsegments are crossed. - Authorization through JWTs SOME DETAILS Security Business DomainsBusiness DomainsBusiness Domains API Gateway Integration
- 39. ENCLAVES IN THE ENTERPRISE 39 L O C A L E N T E R P R I S E
- 40. PRACTICAL EXAMPLE: PAYMENTS 40 Private Banking Mobile Pay Payment Systems • A payment is requested by a user in MobilePay [Status: Pending]
- 41. PRACTICAL EXAMPLE: PAYMENTS 41 Private Banking Mobile Pay Payment Systems • A payment is requested by a user in MobilePay [Status: Pending] • The request is committed in the MobilePay enclave and a Local Event is fired. [Status: Pending]
- 42. PRACTICAL EXAMPLE: PAYMENTS 42 Private Banking Mobile Pay Payment Systems • A payment is requested by a user in MobilePay [Status: Pending] • The request is committed in the MobilePay enclave and a Local Event is fired. [Status: Pending] • Payment systems perform the required checks and operations and fires an Enterprise Event [Status: Pending]
- 43. PRACTICAL EXAMPLE: PAYMENTS 43 Private Banking Mobile Pay Payment Systems • A payment is requested by a user in MobilePay [Status: Pending] • The request is committed in the MobilePay enclave and a Local Event is fired. [Status: Pending] • Payment systems perform the required checks and operations and fires an Enterprise Event [Status: Pending] • Both Private Banking and MobilePay enclaves receives the Enterprise Event and update their state [Status: Approved]
- 44. PRACTICAL EXAMPLE: PAYMENTS 44 Private Banking Mobile Pay Payment Systems • Why do we use Local Events instead of simple queues? Audit
- 45. #3 FUTURE PROOF YOUR APPLICATIONS EASY TO CHANGE, EXTEND AND EXPERIMENT
- 46. WHAT ABOUT SECURITY? 46 Security Business DomainsBusiness DomainsBusiness Domains API Gateway Integration • The Enclave setup helps minimizing the blast radius in case of attacks. • Moreover, with the concept of EUP Ticket, cross platform communication is much more complicated to misuse
- 47. NEW TECH SOMETIMES MEANS INSTALL NEW STUFF… ENDPOINT SECURITY 47 • Great idea with having Device Management as security cornerstone. • However, that Access Proxy can be very complex to implement. Image from https://www.praetorian.com
- 48. ENCLAVES TO THE RESCUE 4848 • Great idea with having Device Management as security cornerstone. • Specific enclaves for internal applications will only be available to authorised devices. • For any other specialised use evaluate on a per needed basis avoiding the construction of complex systems (SSH tunnelling, Citrix, Jump Hosts, etc.)
- 49. AGENDA The Dream A New Beginning The Cloud-Native Financial Institution Fast-Track to Evolutionary Architecture 49
- 50. OPEN SERVICE BROKER API 50 A simple set of API endpoints which can be used to provision, gain access to and managing service offerings.
- 51. ENCLAVES AT SCALE: OPEN SERVICE BROKER API 51 Business Unit API Cloud2 Delivery Non-Production Production API Create Enclave API Create Business Domain API Create Microservice Cloud2 Engine Cloud2 Engine Cloud2 Engine
- 52. ENCLAVES ARE JUST ONE OF THE POSSIBLE BLUEPRINTS 52 Cloud Development Guild (R&D) Automation Application Blueprints
- 53. AN ENTERPRISE APPLICATION 53 Network Compute Databases API Management Monitoring Application Security Message Broker Application Logs Audit Logs Resource Management Deployment Collaboration Integration PKI Audit Risk and Security Assessment …
- 54. AN ENTERPRISE APPLICATION 54 Network Compute Databases API Management Monitoring Application Security Message Broker Application Logs Audit Logs Resource Management Deployment Collaboration Integration PKI Audit Risk and Security Assessment …
- 56. HOWEVER 56
- 57. HOWEVER 57 - Building a cloud is hard (surprise!) - Customer Expectations - DevOps culture cannot be there in a project oriented organization.
- 58. #5 ORGANIZATION FIRST INVEST ON YOUR PEOPLE 58
- 59. AT BESTSELLER WE STARTED FROM THE ORGANIZATION 59 Customer Consumer Products Operations Finance & BI Workforce - Products instead of Projects - PO & SM as leaders - DevOps culture
- 60. AND NOW WE TACKLE THE TECH: A NEW ERP SYSTEM 60 PL/SQL
- 61. WRAP UP 1.Stand on the shoulders of giants (your legacy) 2.Be Smart (avoid vendor lock-ins and expect migrations) 3.Future proof your applications 4.Automate and use Standards 5.Start from the organization and invest on your people 61
Notas del editor
- Angelo, worked in several companies during my carreer. Both in start-ups and large enterprises. About the latter, I have been in Danske Bank for 7 years where I grew from IT Developer to Head of Software Engineering. Recently I joined BESTSELLER, one of the leaders in the Fashion Business.
- Start-ups, you have a lot by default: Quick decisions, Fail fast DevOps Amazing development experience 0 legacy and full green field projects very fast development quick releases fast, strong and direct feedback loops. It is a real pleasure to work. However the challenge and impact is not there yet.
- The Enterprise is quite the opposite. Your company has already an impact on today’s market and you need to maintain it and expand it. Your may be constrained by: Current tech landscape Organizational hirerarchy Processes supporting different way of working Needed integration to existing systems
- In more detail, you are required to develop solutions that are already integrated in the enterprise technological landscape
- And respect specific processes
- From idea generation to production at Danske Bank you had to factor at leasr 70 days on top of the effort needed to develop and release the application or feature you wanted.
- Our dream was the one shared by any other enterprise: to bring the way of working and time to market you can have in start-ups while having the amazing challenges that only the enterprise world can offer you. From this the need for a higher degree of agility.
- We were tasked with the great assignment of building a new Mobile Bank for the following reasons: Higher availability Higher release quality Shorter time-to-market … and at the same time remove dependencies from external IT company
- We started in 2015 and we were standing on a platform on fire
- Just to understand what this meant business wise, let’s take the MobilePay example. A very successfull peer-to-peer payment app Danske Bank released in Denmark in 2013. Currently won the full market and aggregated 60+ banks in that market.
- Danske Bank could not release it in time to other markets. Vipps was released 2 years later in Norway, before Mobile Pay, winning the market. When MobilePay was released it was too late and it was later on closed down.
- A lot of people blamed it on the mainframe!
- Just because it was ugly…
- But was it really that the issue?
- Let’s look at its status…
- And you may conclude that it is actually true…
- Tens of projects were started with the only purpose of ”solving this issue”. However this really cannot be it. We have built a humongous business completely on the mainframe… can this really be this useless?
- However it really was not!
- Legacy is not necessarily technical debt.
- Let’s just zoom out a little and we will actually notice a middleware ring which every single transaction from our internal and customer facing applications must cross.
- This was actually where most of the technical debt resided.
- IMPORTANT STUFF #1 You work in an enterprise. If you deny your legacy you will have no compentitive advantage over the upcoming new players in the market. You will be destroyed. Leverage on your legacy while removing technical debt instead.
- So we started 2016 with getting code out there on several public cloud providers
- To just be shut down 3 months later since we were forced back on prem. Management decided to build our own private cloud, so we started reinventing the wheel.
- However, we did manage to get into prod by Q3 same year.
- IMPORTANT STUFF #2 Be smart!
- But was it really that the issue?
- Step 1: Create segregation through a layer of well defined APIs
- Build business logic reusing data on the existing system
- Migrate data while migrating to event driven design
- We started to define a set of best practices that then, based on input from our experiences in production, turned into a full blown architecture description.
- The microservices of course will be inside the network microsegments.
- Different applications hitting different domains, as for instance B2B and B2C, or processing of external streams of data hit the enclaves ”above the stream”. Then we have central systems hosting cross functional systems and business logic ”below the stream”. These systems host complex business logic, committing data continuously and emitting specific enterprise events.
- From idea generation to production at Danske Bank you had to factor at leasr 70 days on top of the effort needed to develop and release the application or feature you wanted.
- From idea generation to production at Danske Bank you had to factor at leasr 70 days on top of the effort needed to develop and release the application or feature you wanted.
- Split the IT organization based on Domains.