Embed Size (px)
Citation preview
Fidor Solutions – Software Defined Everything and Breaking up the Monolithmarc grimme
Software Defined Everything?
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
“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
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)
Technologies
● Main technology is RubyOnRails– The framework to
enable fast deliveryhigh quality softwareenable XP software developmentbuild APIsstart/build „micro“ service infrastructuresTDD,Ruby, ActiveRecord, ActiveSupport, Testing, MVC, ..
● Database MySQL (default)
FidorOS 2013
Community50k LOC
Banking150k LOC
Cards50k LOC
Backoffice30k LOC
“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
Breaking up the Monolith!
Dealing with a Monolith is
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!!)
1st Iteration: Extract Logic in modules
Communication Methods(Message Queues, Memory Cache)
Libraries(Engines, Plugins, Gems)
Micro Services(Rails Apps, Sinatra)
iZee – Saving Products - „Plugin“iZee – PFM - „Plugin“
Ripple - „Plugin“Rails Engine/Plugin Yes or No
CAS/SSO - Sinatra
Rabbit MQ - ExplorationRipple - „Queue Moneytx“
DB_Lock - gemVandenberg - gem
Bancos - gem
CAS/SSO - AsynchronousMailer (Community/Banking)
Make decision about
modularizationswhat technologies to use!
20162015
Community - „Karma“ - EngineBanking - „ShortLoan-Score“ - Engine
Identity - Sinatra
2014
ApiFy - gem
Gateway - „MasterCard“ - Engine
o2 - Loyaltyo2 - Redemption
Communication
Foundation for breaking the monolith - 1st 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!
2nd Iteration: Domain Driven Design
Foundation for breaking the monolith - 2nd 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
Foundation for breaking the monolith – Cloud infrastructure
● Docker as container format ( 20-40 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
Foundation for breaking the monolith - Interfaces
● APIs to communicate– Simple as possible (JSONapi, Restful)
– Synchronous vs Asynchronous
– Keep the interfaces as stable as possible
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
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
