Dégraissons le mammouth ou Darwin a encore frappé
La théorie de l'évolution appliquée au développement informatique - cas pratique de l'architecture du site PMU.fr
Depuis 1980, Lehman nous avertit: un programme doit évoluer ou péricliter, mais alors qu'il devient de plus en plus gros, la complexité résultante tend à limiter son évolution. Comment remédier à cela? Quelle architecture adopter pour un site à fort trafic comme celui du PMU?
Après avoir abordé les problématiques d'évolution et de maintenance d'une application monolithique, nous verrons pourquoi et surtout comment séparer les composants et les comportements de notre application.
Du monolithe aux micro services, du distribué, des messages, du publish/subscribe, du REST, une approche polyglotte, ... au cours de cet exposé, nous verrons quelques uns des choix retenus pour garantir la survie et l'évolution de notre application. Nous verrons comment nous avons construit un socle solide permettant de répondre aux nouvelles manières de faire du Web, d'être adapté aux applications mobiles et aux télés connectées. Ce sera l'occasion d'aborder aussi bien les principes architecturaux et les principes organisationnels qui nous ont permis d'atteindre cet objectif.
5. PMU Turf
Partner Paddy Power
Paris Sportifs
https://info.pmu.fr/entreprise/partenariats-et-sponsoring
Paris Hippiques
Poker
Partner PartyGaming
PMU Entreprise
12. How to Plug our own
Authentication
Search
doc.
Do It
Yourself
Google
stack
overflow
MAN/API
Sample
Just kidding!
obsolete
Give UP
! ⁉ ️
⚠ ️⚡ ️&
B
X
p
D
U
g
I
o
a
n
Hack
Framework Does Not
Work
21. LEGACY...
It’s OLD
It’s Crapy
It’s complicated
It’s not understandable
It does not reflect what it does
It’s not Tested
It’s not Testable
!
Someone else wrote it!
25. Cost of understanding
Knowledge scattering
Ripple Effect
« Big Ball of Mud »
http://www.laputan.org/mud/
http://akvo.org/blog/the-ball-of-mud-transition/
h
29. Customization
Enterprise Portal
User
Auth
Page JS
Conte
nt
Business Logic
API
SI
Auth
3rd
Party
Logic
PortletSSO
Customization
Enterprise Portal
User
Auth
Page JS
Conte
nt
Business Logic
API
SI
Auth
3rd
Party
Logic
PortletSSO
User « Manny »
1.1
1.2
Load Balancer
Session
1.3
30. Customization
Enterprise Portal
User
Auth
Page JS
Conte
nt
Business Logic
API
SI
Auth
3rd
Party
Logic
PortletSSO
Customization
Enterprise Portal
User
Auth
Page JS
Conte
nt
Business Logic
API
SI
Auth
3rd
Party
Logic
PortletSSO
User « Manny »
Load Balancer
Session
1.4
1.5
1.1
1.2 1.3
32. Customization
Enterprise Portal
User
Auth
Page JS
Conte
nt
Business Logic
API
SI
Auth
3rd
Party
Logic
PortletSSO
Customization
Enterprise Portal
User
Auth
Page JS
Conte
nt
Business Logic
API
SI
Auth
3rd
Party
Logic
PortletSSO
User « Manny »
2.1
Load Balancer
?
Session
Sticky Session
40. http://www.faqs.org/docs/artu/ch01s06.html
Write programs that do one thing and do it well. Write
programs to work together. Write programs to handle text
streams, because that is a universal interface.
Unix Philosophy
• Small is beautiful
• Make each program do one thing and one thing well
• Favor simplicity and portability over feature completeness
• Write programs to work together
41. Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for “one true way”.
Rule of Extensibility: Design for the future, because it will be here sooner than you think.
http://www.faqs.org/docs/artu/ch01s06.html
Write programs that do one thing and do it well. Write
programs to work together. Write programs to handle text
streams, because that is a universal interface.
Unix Philosophy
42. http://www.faqs.org/docs/artu/ch01s06.html
Write programs that do one thing and do it well. Write
programs to work together. Write programs to handle text
streams, because that is a universal interface.
Unix Philosophy
« Read a file of text, determine the n most frequently used
words, and print out a sorted list of those words along with
their frequencies. »
!
http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/
http://franklinchen.com/blog/2011/12/08/revisiting-knuth-and-mcilroys-word-count-programs/h
47. Account management
Racing & Horse
Information Distribution
Horse RACE Betting
Extra CONTENT
MANAGEMENT
Authentication
Information Updates
RACE Status
WINNERS
RUNNERS
METEO
Odds…
update
Login/OUT
Profile…
G
Y
N
U2
H
E
u
52. Communication
Broker less approach
e.g.: HTTP/REST, ZeroMQ,
distributed actors/process, …
http://zeromq.org/whitepapers:brokerless
http://www.openstack.org/assets/presentation-media/zmqslides2.pdf
h
54. Account management
Racing & Horse
Information Distribution
Horse RACE Betting
Extra CONTENT
MANAGEMENT
Authentication
Information Updates
RACE Status
WINNERS
RUNNERS
METEO
Odds…
update
Login/OUT
Profile…
G
Y
N
U2
H
E
u
55. Account
management
Racing & Horse
Information Distribution
AccountTurfInfoTurfPari
Update Listener
Horse RACE
Betting
Information Updates
TurfInfo
Lib
Account
Lib
TurfPari
Lib
Update
Lib
Auth
Lib
DTO
Lib
61. Spotify and the Feature Teams
http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify