Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Une plateforme moderne pour le groupe
SIPA/Ouest-France 🚀
François-Guillaume Ribreau
@FGRibreau
—
Architect & Head of development @Ouest-France (10 months 🎂)
—
🌟 Founded @Redsmin @...
I am quite convinced that in fact computing will become a
very important science. (🐶💩)
But at the moment we are in a very ...
DONC(la slide suivante est la plus importante du talk 😉)
Deux principes
fondamentaux
—
Separation of Concerns
Single Source of Truth
Separation of Concerns
a-k-a "la séparation d'intérêt"
Tout organiser en terme de rôle, de responsabilité.
Chaque rôle rés...
... des valeurs,
aux fonctions,
aux types,
aux modules,
à l'organisation du projet,
aux (micro)services,
aux clusters
aux ...
Single Source of Truth
a-k-a "unique source de vérité"
Une seule source de vérité,
une seule source d'état.
Tout part de l...
(EXEMPLE(avec des technologies et approches trendy 🤩)
Il n'y a pas si longtemps...
Une app
- portait sa configuration
(e.g. fichier)
- savait où envoyer ses logs
(e.g. socket, fic...
Orchestrateur
L'orchestrateur :
- gère et injecte la configuration des
apps (SoC, SSOT)
- récupère les logs de stderr & std...
Au delà de l'orchestration...
Service Mesh
L'application délègue le paramétrage de:
- rate-limiting (SoC)
- l'access control (SoC)
- request-retries (So...
)
Avant de parler plateforme,
parlons CMS
des sites internets dans le monde
(60% des CMS installés)
27%
https://bit.ly/29KsVqn
Initialement une plateforme de blogging
Extensibilité via des plugins
Personnalisation via des thèmes
------------
--------------
—
Separation of Concerns
Single Source of Truth
1 BDD pour tout
(technique + fonctionnel)
(content + plugins + ...)
1 instance pour tout
(e.g. code, /upload, ...)
1 base ...
des sites internets dans le monde1%
Tentative de découplage
entre technique et fonctionnel
(node & modules)
Approche par module,
indépendants, juxtaposables, et combinables
possible dépendances inter-module
Node (structure & données), 

module (traitement),
thème (présentation)
------------
--------------
—
Separation of Concerns
Single Source of Truth
modulemodulemodulenode
modulemodulemodulemodule
presentation
1 BDD pour tout
(technique + fonctionnel)
(nodes + modules + ...
Autres CMS...
BDD monolithique,
codebase ~monolithique,
respecte SSoT
mais pas SoC jusqu'à un certain point...
Et c'est toujours la même histoire.
Mise en place d'un
CMS
monolithique
Evolutions par
petite touche...
🤩
Accumulation progressive de dette
(e.g. règles métiers implicites dans le code)
Jusqu'au point où les évolutions sont trop coûteuses 😫
Refonte. 💸 💸
Et en (micro)service ?
En headless CMS ?
En Content-API ?
(#spoiler nous allons y revenir 😉)
Historique des sites internets
www.ouest-france.fr
All-in-one
1998-2008
(Galaad, Prism)
❌ 1 codebase (❌ SoC)
✅ 1 database
✅ 1 back-office
❌ 1 release life...
"L'effet balancier"
www.ouest-france.fr
EntrepriseEtudiant
...
...
Satellite network
2008-2017
(Drupal & Wordpress)
✅ N codebase (per website,...
2017.
Refonte. 🚀
Refonte 2017 🚀
- (Ré)intégrer les différents sites et services 

du groupe au sein d'une même plateforme
- Mise en place S...
All-in-one
1998-2008
(Galaad, Prism)
www.ouest-france.fr
www.ouest-france.fr
Entreprise
Etudiant
...
...
Satellite network...
All-in-one
1998-2008
(Galaad, Prism)
www.ouest-france.fr
www.ouest-france.fr
Entreprise
Etudiant
...
...
Satellite network...
All-in-one
1998-2008
(Galaad, Prism)
www.ouest-france.fr
www.ouest-france.fr
Entreprise
Etudiant
...
...
Satellite network...
Headless CMS
Content
API
Front
Widget
API
IAM ...
PartnersEditorial
Back-Office
Job done right?
------------
--------------
—
Separation of Concerns
Single Source of Truth
Headless CMS
Content
API
Front
Widget
API
IAM
...
API
PartnersEditorial
Back-Office
Job done right?
ArticleDetail tmpl Widge...
Retour aux sources
Atomic design ⚛
Atoms, molecules, organisms, templates, and pages
Templates
Pages
Organisms
Molecules
Atoms
"atoms are the...
Atomic design ⚛
Atoms, molecules, organisms, templates, and pages
Header
Trending
Breadcrumb
ArticleList
Weather
Funeral
Atomic design ⚛
Atoms, molecules, organisms, templates, and pages
“Pourquoi vous faut-il tant de temps pour mettre à jour les headers ?”
Header == un seul et unique composant ? 

Un seul b...
La cohérence est une conséquence de SSoT
Block configurable (e.g. theme) => cohérence
Block Header intégré au code-source du CMS ?
Et si ce block était indépendant du CMS ?
Gérer, administré en autonomie par ...
Naissance du concept de CMS Agnostic 🎉
Agnostic
CMS
“Pour qu'un CMS soit agnostique, 

le fonctionnel métier doit vivre en...
CMS 

Product Team
Agnostic
CMS
Back-office
Editorial 

Product Team
Header
(API)
Footer
(API)
ArticleList
(API)
ArticleDet...
Utilisons des conventions !
Comment garantir des API consistantes ?
API HTTP/REST
Contract
Il nous faut un contrat 📜 pour chaque Block qui défini :
- (meta) son nom, sa version
- (configuratio...
Un service qui fourni 1...N Block(s) au CMS
Agnostique est un BlockProvider
API BlockProvider
Contract
Header
Block
Agnost...
(internal team)
production env.
(external team)
prod. env.
(partner team)
prod. env.
(partner team)
prod. env.
Navigation
...
Platform = Eat your own dog food
Le schéma du BlockProvider
est décrit en json-schema
API BlockProvider
Contract
Header
Block
... permet de générer un validator-cli #rust
API BlockProvider
Contract
Header
Block
validator-cli
CMS
Agnostic
schemasSSo...
... permet de générer la documentation
#WiP /
https://github.com/FGRibreau/json-schema-
documentation
SSoT
sans oublier le block-runner
exécution d'un BlockProvider en local/CI
SoC #WiP /
BlockProviderConfig
Schem
a
SSoT
Première traction (et autonomie) 

en interne et à l'externe 🎉
Partner 1
Chaque Block est exposé via un API BlockProvider
✅ cycle de dev indépendant
✅ domaine de bug indépendant
✅ garan...
Comment rendre l'administration des Blocks scalable ?
Administration des Blocks scalable = json-schema + ui-schema => GUI
https://github.com/mozilla-services/react-jsonschema-f...
Comment garantir la cohérence graphique?
Impossible de passer à l'échelle
sans guidelines (design system)
https://github.c...
Comment (proposer un premier niveau pour) garantir 

la sécurité 🔑 et la vie privée 1 ?
Etape de validation (auto + manuel...
CMS Team Editorial Team
Navigation
BlockProvider
Editorial
BlockProvider
Chaque block
est un BlockProvider
✅ cycle de dev ...
QoS
Progressive degradation
Static rules engine
Routing engine
ACL
Auditability
PageLayout
ConfigMap
Caching techniques
Blo...
Free plans for Redis
administration & monitoring
at redsmin.com
We are looking for Front-end Developers
twitter.com/iadviz...
Une plateforme moderne pour le groupe SIPA/Ouest-France 
Une plateforme moderne pour le groupe SIPA/Ouest-France 
Upcoming SlideShare
Loading in …5
×

Une plateforme moderne pour le groupe SIPA/Ouest-France 

844 views

Published on

Comment imaginer et implémenter une plateforme (au sens Apple Store) from-scratch au sein d'un groupe média ? Quelle philosophie ? Quels principes ? Quelle architecture choisir ? Comment assurer la scalabilité des développements interne comme externe ?

Nous aborderons aussi le tournant numérique du groupe par cette plateforme ouverte. Le développement d'un écosystème avec nos partenaires et filiales basé sur des contrats json-schema/open-api et les conséquences sur diverses dimensions.

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Une plateforme moderne pour le groupe SIPA/Ouest-France 

  1. 1. Une plateforme moderne pour le groupe SIPA/Ouest-France 🚀
  2. 2. François-Guillaume Ribreau @FGRibreau — Architect & Head of development @Ouest-France (10 months 🎂) — 🌟 Founded @Redsmin @ImageCharts @MailPopin — 🚀 Trainer @EPSI_Nantes @UnivNantes — Ex-Bringr cofounder & CTO Ex-Architect @iAdvize
  3. 3. I am quite convinced that in fact computing will become a very important science. (🐶💩) But at the moment we are in a very primitive state of development; we don't know the basic principles yet and we must learn them first. 
 If universities spend their time teaching the state of the art, they will not discover these principles and that, surely, is what academics should be doing. — Christopher Strachey, 1969 (49 yrs ago) (quote by Edsger W. Dijkstra) https://bit.ly/2pMI7aJ “ ”
  4. 4. DONC(la slide suivante est la plus importante du talk 😉)
  5. 5. Deux principes fondamentaux — Separation of Concerns Single Source of Truth
  6. 6. Separation of Concerns a-k-a "la séparation d'intérêt" Tout organiser en terme de rôle, de responsabilité. Chaque rôle résout un problème "Quel est le rôle — la responsabilité — de chaque chose ?"
  7. 7. ... des valeurs, aux fonctions, aux types, aux modules, à l'organisation du projet, aux (micro)services, aux clusters aux datacenters, ... corollaire : divide & conquer, OSI model, HTML/ CSS/JS, n-tier, ui components, (micro)services, ...
  8. 8. Single Source of Truth a-k-a "unique source de vérité" Une seule source de vérité, une seule source d'état. Tout part de la source de vérité, ensuite nous en exposons des représentations corollaire : event-sourcing / vue matérialisée, master/slave, 3NF/FNBC, référentiels, ...
  9. 9. (EXEMPLE(avec des technologies et approches trendy 🤩)
  10. 10. Il n'y a pas si longtemps... Une app - portait sa configuration (e.g. fichier) - savait où envoyer ses logs (e.g. socket, fichier) - etc... app.
  11. 11. Orchestrateur L'orchestrateur : - gère et injecte la configuration des apps (SoC, SSOT) - récupère les logs de stderr & stdout de toutes les apps (SoC, SSoT) L'application : - récupère sa config via var. env. (SoC) - log sur stderr / stdout (SoC) app. orchestrator cluster-wide-logging conf.
  12. 12. Au delà de l'orchestration...
  13. 13. Service Mesh L'application délègue le paramétrage de: - rate-limiting (SoC) - l'access control (SoC) - request-retries (SoC) - etc... Le service mesh standardise (de manière agnostique), centralise, la gestion : - rate-limiting (SSoT) - l'access-control (SSoT) - request-retries (SoC, SSoT) app. orchestrator service-mesh
  14. 14. )
  15. 15. Avant de parler plateforme, parlons CMS
  16. 16. des sites internets dans le monde (60% des CMS installés) 27% https://bit.ly/29KsVqn
  17. 17. Initialement une plateforme de blogging
  18. 18. Extensibilité via des plugins Personnalisation via des thèmes
  19. 19. ------------ -------------- — Separation of Concerns Single Source of Truth
  20. 20. 1 BDD pour tout (technique + fonctionnel) (content + plugins + ...) 1 instance pour tout (e.g. code, /upload, ...) 1 base de code pour tout (technique + fonctionnel) Approche monolithique
  21. 21. des sites internets dans le monde1%
  22. 22. Tentative de découplage entre technique et fonctionnel (node & modules)
  23. 23. Approche par module, indépendants, juxtaposables, et combinables possible dépendances inter-module
  24. 24. Node (structure & données), 
 module (traitement), thème (présentation)
  25. 25. ------------ -------------- — Separation of Concerns Single Source of Truth
  26. 26. modulemodulemodulenode modulemodulemodulemodule presentation 1 BDD pour tout (technique + fonctionnel) (nodes + modules + ...) 1 instance pour tout (e.g. code, fs, ...) ~ 1 base de code pour tout (technique + fonctionnel) Approche monolithique, chaque module à la connaissance d'où il se hook (caché dans le code, non statique) presentation traitement
  27. 27. Autres CMS... BDD monolithique, codebase ~monolithique, respecte SSoT mais pas SoC jusqu'à un certain point...
  28. 28. Et c'est toujours la même histoire.
  29. 29. Mise en place d'un CMS monolithique
  30. 30. Evolutions par petite touche... 🤩
  31. 31. Accumulation progressive de dette (e.g. règles métiers implicites dans le code)
  32. 32. Jusqu'au point où les évolutions sont trop coûteuses 😫
  33. 33. Refonte. 💸 💸
  34. 34. Et en (micro)service ? En headless CMS ? En Content-API ? (#spoiler nous allons y revenir 😉)
  35. 35. Historique des sites internets
  36. 36. www.ouest-france.fr All-in-one 1998-2008 (Galaad, Prism) ❌ 1 codebase (❌ SoC) ✅ 1 database ✅ 1 back-office ❌ 1 release lifecycle ❌ 1 bug domain Monolithe de plus en plus difficile à maintenir dans le temps. Refonte. 💸
  37. 37. "L'effet balancier"
  38. 38. www.ouest-france.fr EntrepriseEtudiant ... ... Satellite network 2008-2017 (Drupal & Wordpress) ✅ N codebase (per website, (~ SoC)) ❌ N database (SSoT) ❌ N back-office ✅ 1 release lifecycle ✅ 1 bug domain Monolithes séparés Facile de créer un nouveau site Silos de données Difficile de maintenir une cohérence globale
 (e.g. SSO, design (headers)) Refonte. 💸
  39. 39. 2017. Refonte. 🚀
  40. 40. Refonte 2017 🚀 - (Ré)intégrer les différents sites et services 
 du groupe au sein d'une même plateforme - Mise en place SSO, etc... - Intégrer des partenaires externes - Assurer une cohérence graphique (e.g. header)
  41. 41. All-in-one 1998-2008 (Galaad, Prism) www.ouest-france.fr www.ouest-france.fr Entreprise Etudiant ... ... Satellite network 2008-2017 (Drupal & Wordpress) Refonte 2017 🚀 ?
  42. 42. All-in-one 1998-2008 (Galaad, Prism) www.ouest-france.fr www.ouest-france.fr Entreprise Etudiant ... ... Satellite network 2008-2017 (Drupal & Wordpress) Refonte 2017 🚀 Platform
  43. 43. All-in-one 1998-2008 (Galaad, Prism) www.ouest-france.fr www.ouest-france.fr Entreprise Etudiant ... ... Satellite network 2008-2017 (Drupal & Wordpress) Refonte 2017 🚀 Platform
  44. 44. Headless CMS Content API Front Widget API IAM ... PartnersEditorial Back-Office Job done right?
  45. 45. ------------ -------------- — Separation of Concerns Single Source of Truth
  46. 46. Headless CMS Content API Front Widget API IAM ... API PartnersEditorial Back-Office Job done right? ArticleDetail tmpl Widget1 tmpl Widget2 tmpl ... tmpl porte tous les tem plates (org.) Non indépendance de l'équipe Editorial dev. pour chaque 
 partenaire à intégrer. 
 mélange des intégrations. Bottleneck ❌ release-cycle ~indépendant ❌ évolutions fonctionnelles indépendantes SoC SSoT SoC
  47. 47. Retour aux sources
  48. 48. Atomic design ⚛ Atoms, molecules, organisms, templates, and pages Templates Pages Organisms Molecules Atoms "atoms are the smallest functional unit" SoC SSoT
  49. 49. Atomic design ⚛ Atoms, molecules, organisms, templates, and pages
  50. 50. Header Trending Breadcrumb ArticleList Weather Funeral Atomic design ⚛ Atoms, molecules, organisms, templates, and pages
  51. 51. “Pourquoi vous faut-il tant de temps pour mettre à jour les headers ?” Header == un seul et unique composant ? 
 Un seul block ?
  52. 52. La cohérence est une conséquence de SSoT Block configurable (e.g. theme) => cohérence
  53. 53. Block Header intégré au code-source du CMS ? Et si ce block était indépendant du CMS ? Gérer, administré en autonomie par une équipe ?
  54. 54. Naissance du concept de CMS Agnostic 🎉 Agnostic CMS “Pour qu'un CMS soit agnostique, 
 le fonctionnel métier doit vivre en dehors” block(fonctionnel) block(fonctionnel) block(fonctionnel) block (fonctionnel) block (fonctionnel) block (fonctionnel)
  55. 55. CMS 
 Product Team Agnostic CMS Back-office Editorial 
 Product Team Header (API) Footer (API) ArticleList (API) ArticleDetail (API) Chaque block serait donc une API ? ✅ cycle de dev ~indépendant ✅ domaine de bug ~indépendant ❌ aucune garantie sur la consistence des API ❌ une API —par définition— ne porte pas ses templates (présentation) ❌ aucune garantie sur la cohérence graphique globale ❌ le CMS doit avoir la connaissance de chacune des APIs (SoC) ❌ le Back-office doit avoir la connaissance de chacune des APIs (SoC) ❌ n'explique pas comment scale les développements interne / externe ❌ security & privacy by design ? Partner 2 Funerals (API) Partner 1 Weather (API) Partner X ... (API) Partner X ... (API) Partner X ... (API) #inverseConwayLaw #(micro)services #containers #kubernetes
  56. 56. Utilisons des conventions ! Comment garantir des API consistantes ?
  57. 57. API HTTP/REST Contract Il nous faut un contrat 📜 pour chaque Block qui défini : - (meta) son nom, sa version - (configuration) comment le paramétrer - (view) ses thèmes (templates + assets) - (state) comment appeler le composant - (et plus encore...) Garantir des API consistantes ? Header
  58. 58. Un service qui fourni 1...N Block(s) au CMS Agnostique est un BlockProvider API BlockProvider Contract Header Block Agnostic CMS http/json low-barrier entry BlockProvider register & configuration
  59. 59. (internal team) production env. (external team) prod. env. (partner team) prod. env. (partner team) prod. env. Navigation BlockProvider Editorial BlockProvider Weather BlockProvider Funeral BlockProvider Agnostic CMS BlockProvider register & configuration Header Trending Breadcrumb ArticleList Weather Funeral ... BlockProvider ... BlockProvider ... BlockProvider Back-Office (RIA/SPA) Admin.API Presentation
  60. 60. Platform = Eat your own dog food
  61. 61. Le schéma du BlockProvider est décrit en json-schema API BlockProvider Contract Header Block
  62. 62. ... permet de générer un validator-cli #rust API BlockProvider Contract Header Block validator-cli CMS Agnostic schemasSSoT SoC
  63. 63. ... permet de générer la documentation #WiP / https://github.com/FGRibreau/json-schema- documentation SSoT
  64. 64. sans oublier le block-runner exécution d'un BlockProvider en local/CI SoC #WiP / BlockProviderConfig Schem a SSoT
  65. 65. Première traction (et autonomie) 
 en interne et à l'externe 🎉
  66. 66. Partner 1 Chaque Block est exposé via un API BlockProvider ✅ cycle de dev indépendant ✅ domaine de bug indépendant ✅ garantie sur la consistence des API ✅ le BlockProvider par définition porte sa présentation ❌ aucune garantie sur la cohérence graphique globale ✅ quand le CMS sait gérer 1 BlockProvider il sait tous les gérer ❌ le Back-office doit avoir la connaissance de chacune des APIs (SoC) ✅ un BlockProvider est identique, qu'il soit développé en interne ou en externe, modèle scalable ❌ security & privacy by design ?Météo BlockProvider CMS Team Agnostic CMS Back-office Editorial Team Header (BlockProvider) Footer (BlockProvider) ArticleList (BlockProvider) ArticleDetail (BlockProvider)Partner 2 Funerals (BlockProvider) Partner 1 Weather (BlockProvider) Partner X ... (API) Partner X ... (API) Partner X ... (BlockProvider)
  67. 67. Comment rendre l'administration des Blocks scalable ?
  68. 68. Administration des Blocks scalable = json-schema + ui-schema => GUI https://github.com/mozilla-services/react-jsonschema-form ✅ Configuration (technique) : OpenAPI (ex. swagger) ✅ Configuration (fonctionnel) : ui-schema ✅ Contrôle complet par l'équipe en charge du BlockProvider
 SSoT Le Back-office a uniquement la connaissance de comment afficher le ui-schema de chaque Block provenant des BlockProviders (BlockProviderConfig schema) oC
  69. 69. Comment garantir la cohérence graphique? Impossible de passer à l'échelle sans guidelines (design system) https://github.com/ouest-france/sipaui #html #mustache #view SoC
  70. 70. Comment (proposer un premier niveau pour) garantir 
 la sécurité 🔑 et la vie privée 1 ? Etape de validation (auto + manuel) la soumission d'un Block : - (auto) enregistrement des assets dans notre CDN - (auto) validation des performances - (manuel) inspection des templates (suivi des guidelines) - (manuel) inspection des JS/CSS pour usage dangereux (inclusion de JS externes, appel externes etc..) & fuite donnée SSoT
  71. 71. CMS Team Editorial Team Navigation BlockProvider Editorial BlockProvider Chaque block est un BlockProvider ✅ cycle de dev indépendant ✅ domaine de bug indépendant ✅ garantie sur la consistence des BlockProviders (json-schema) ✅ le BlockProvider par définition porte ses templates (présentation) ✅ garantie sur la cohérence graphique globale (guidelines + validation) ✅ quand le CMS sait gérer 1 BlockProvider il sait tous les gérer ✅ le Back-office n'a que la connaissance du contrat d'un BlockProvider ✅ un BlockProvider est identique, qu'il soit développé en interne ou externe, modèle scalable ✅ security & privacy by design Agnostic CMS Back-office Partner 1 Météo BlockProvider Partner 2 Funerals (BlockProvider) Partner 1 Weather (BlockProvider) Partner X ... (API) Partner X ... (API) Partner X ... (BlockProvider)
  72. 72. QoS Progressive degradation Static rules engine Routing engine ACL Auditability PageLayout ConfigMap Caching techniques BlockProvider Testability Monitoring Smoke-tests Versioning Authorization Block reusability Scalability SSoT SoC Et d'autres choix guidés par SSoT & SoC Static Graph Resolution Performance
 (e.g. referential transparency) To be continued...
  73. 73. Free plans for Redis administration & monitoring at redsmin.com We are looking for Front-end Developers twitter.com/iadvizetech Questions? @FGRibreau No more server-side rendering pain, 1 url = 1 chart image-charts.com

×