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 

752 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

×