Fidor Solutions Software Defined Everything and Breaking up the Monolith. marc grimme

Transcription

1 Fidor Solutions Software Defined Everything and Breaking up the Monolith marc grimme

2 Software Defined Everything?

3 Software defined everything? Codifying Business Logic THE code Micro services / domain driven Infrastructure Configuration (Infrastructure as Code, Immutable Infrastructure) Tests (Unit, Regression,..) (CI) Deployment (CD) Everything in code Software defined everything

4 Software defined everything and monoliths Good fit?? Everything in the code? (business logic) CD long deployment Long running tests (LOC Time for tests) CI even longer running tests (CD + test) Infrastructure as code

5 What is the Fidor Solution? FidorOS as Middleware that enables digital banking based on APIs Community based on Web Mobile Banking App (native ios/android) APIs to integrate partners (Bitcoin,..) Agnostic to Bank legacy infrastructure Support for P2P, SEPA, Mastercard,.. We call it Banking-as-a-Service (o2 Banking as example) Or on-premise (ADIB Arabic Islamic Bank - Smartmoney)

6 Technologies Main technology is RubyOnRails The framework to enable fast delivery high quality software enable XP software development build APIs start/build micro service infrastructures TDD, Ruby, ActiveRecord, ActiveSupport, Testing, MVC,.. Database MySQL (default)

7 FidorOS 2013 Community 50k LOC Banking 150k LOC Backoffice 30k LOC Cards 50k LOC

8 Software defined everything and monoliths Fidor - Goal: Extract functional domains for different customer needs Own domains and technology by dedicated teams Don t deploy code from customer A to customer B Granular scalability Conclusion This is very bad for a monolithic application We need to break it We need a flexible solution

9 Breaking up the Monolith!

10 Dealing with a Monolith is

11 Breaking the Monolith is... Maintaining a Software Caring about Software Continuous Refactoring Handle legacy without starting on a green field again (migration is just behind the corner!!)

12 st 1 Iteration: Extract Logic in modules Libraries 2014 izee Saving Products - Plugin (Engines, Plugins, 2015 Gems) izee PFM - Plugin Gateway - MasterCard - Engine Rails Engine/Plugin Yes or No 2016 Ripple - Plugin Community - Karma - Engine Banking - ShortLoan-Score - Engine DB_Lock - gem ApiFy - gem Make decision Vandenberg - gem about Bancos - gem modularizations Communication whatmethods technologies to use! Rabbit MQ -(Message Exploration Queues, Memory Cache) Ripple - Queue Moneytx CAS/SSO - Sinatra Identity - Sinatra CAS/SSO - Asynchronous o2 - Loyalty Micro Services Mailer (Community/Banking)o2 - Redemption (Rails Apps, Sinatra) Communication

13 Foundation for breaking the monolith st 1 iteration Fast tests, fast tests and automated fast tests As the precondition for refactoring Technologies like Docker (in terms of having deployable images and containers) Logging over domains!

14 2 nd Iteration: Domain Driven Design

15 Foundation for breaking the monolith nd 2 iteration Fast tests, fast tests, automated fast tests and automated fast end-2-end regression tests Domain Driven Design - Domain functions 12 factor compliant Scalable cloud infrastructure (private and public) Scale out over multiple DCs Support for synchronous and asynchronous communication Persistence layers (database and blob-buckets) Consistent auto naming and resolving

16 Foundation for breaking the monolith Cloud infrastructure Docker as container format ( different containers per installation) Rabbit MQ as default message queue (with support for at least once delivery vs eventual delivery Docker Swarm as cloud infrastructure On top of standard Linux or AWS standard Linux

17 Foundation for breaking the monolith Interfaces APIs to communicate Simple as possible (JSONapi, Restful) Synchronous vs Asynchronous Keep the interfaces as stable as possible

18 Foundation for breaking the monolith Tools Github Enterprise with Travis CI and Jenkins Docker and Docker Swarm (Kubernets as possible next step) Database MySQL or M$SQL NFS or S3 as Datastore Rabbit MQ

19 This is Our only constant is change... but only small changes can lead the way it s all about to balance Principles Shortest time to market Integration into standard environments Loosely coupled Domain Driven Design Communication via APIs Build-measure-learn You-build-it-you-run-it Minimal possible to no hand overs Cross-functional self organized teams

20 Thanks you for your attention!