Rex scale-up: les impacts du passage à l'échelle

Transcript

1. Charles Bouttaz - Guillaume Ehret Scale-up les impacts du passage à l'échelle RE X orga tech ops métier archi
2. il était une fois… C
3. il était une fois… C
4. 2009 startup aggrégateur de flexibilité électrique C
5. flexibilité ou objectif équilibre du réseau électrique consommation = production G
6. flexibilité ou objectif équilibre du réseau électrique consommation < production consommation > production G
7. Petite équipe de dev 5 - 7 personnes G 1 Pays 2009
8. aujourd’hui… C
9. Multi pays & timezones C 12 équipes, ~70 devs 2024
10. How to scale ? orga dev ops métier archi C
11. orga Organisation 1 équipe 12 équipes, 70 devs G
12. métier Métier 1 métier (flex) 1 pays 3 métiers (flex, microgrid, simulation) >10 pays C
13. dev Technique Focus TTM & qualité Technos Jboss Play! Framework Focus Qualité & TTM Spring Boot, Angular G
14. archi Architecture Monolithe Monolithe modulaire + modules C
15. ops Ops JBoss on premise AWS, managed services (Lambda, K8s, Aurora) G
16. Événement perturbateur C
17. Problème Solution mise en place Takeaway positif Takeaway négatif
18. Charles Bouttaz Guillaume Ehret G
19. Back in 2017 G
20. Besoin de développer + de services + vite G
21. dev SOS Devs Mauvaise expérience développeur 😣 → ralentissement des devs (Jboss & Play! fwk) Migration Spring Boot & Angular JS Business case, analyse charge & impacts Roadmap
22. archi Les limites du monolithe Monolithe trop gros → difficile à maintenir Problèmes de performance (data) Nouveaux produits / métier Création de nouvelles applications hors monolithe mais dans monorepo Mono repository Git pour profiter du tooling commun Uniquement pour des applis très “éloignées” du métier actuel G
23. Besoin de déployer + de services + fréquemment C
24. ops SOS Ops ! Pas assez d’Ops déployer & maintenir tous les services sur tous les envs Difficile de gérer les demandes d’infra on premise Recrutement Pénurie compétences & montée en compétence longue
25. ops Migration Cloud Migration Cloud AWS → difficile mais payant sur le long terme Automatisation de la gestion des ressources→ infra as code Reprise en main du paramétrage réseau (LB, VPN, DMZ) Attention à la facture Migration Oracle RDS → PostgreSQL Utilisation lambda à la place d’EC2
26. dev Migration cloud, services managés Opportunité d’utiliser de nouveaux outils plus rapidement (MQTT, machine learning) plus facile à tester en dev plus facile à déployer en prod moins de maintenance
27. Objectif x30 en 2030 !!!
28. orga Besoin de renforts ! Peu d’internes (90% prestataires) Recrutement par le réseau → Pas scalable Recrutement: - ESN, Freelances - Embauche - Internaliser les externes historiques
29. orga Besoin de renforts ! Contexte: manque de devs sur le marché (post-covid) Comment définir nos critères objectivement ? Erreurs de casting qui coûtent cher (coût temps & humain) Onboarding Fiches de poste, focus Soft skills Chemin de carrière
30. Trop nombreux pour une seule équipe
31. orga Trop de personnes dans une équipe Périmètre fonctionnel trop gros (surtout pour les nouveaux) Rituels agiles compliqués Synchronisation / communication difficile Découper ⇒ 😵
32. orga Cartographier & découper les domaines fonctionnels
33. orga Loi de conway the organisation design is likely to be mirrored the product design
34. orga Limites & charge cognitive Bounded Context Bounded Context Bounded Context
35. orga Problème de gouvernance Bounded Context Bounded Context Bounded Context
36. orga Séparer les responsabilités Bounded Context Bounded Context Bounded Context
37. orga Idéalement aligner business, software & team Selling Shipping SAV Domain Team App(s)
38. orga Comment découper ? Comment découper ? Il nous faut de meilleures questions: - Quels critères ? - Quelles contraintes ?
39. orga Critère découpage: la taille "Miller's Law": 7 ± 2 - George A. Miller
40. orga Critère découpage: la taille "Pizza rule": 5 - 8 ppl - Jeff Bezos
41. orga Critère découpage: besoin de communication & synchro
42. orga Critère découpage: besoin de communication & synchro
43. orga Critère découpage: besoin de communication & synchro
44. orga Critères de découpage: Criticité métier / différenciateur
45. orga Découpage takeaways Réduction du scope équipe → charge mentale allégée → motivation Montée en compétence plus rapide Périmètres identifiés → plus facile de trouver des interlocuteurs Confusion aux frontières des domaines (au début) Transverse technique “oublié” Difficile de bien dimensionner les équipes (scope & roadmap)
46. 30 devs 2 métiers 👫😓 2 supports 👬
47. orga Recrutement Déséquilibre dev / PO / support → goulot d’étranglement Beaucoup d’externes → apparente “fragilité” pour les investisseurs Recruter pour constituer les équipes type: Poste clés: PO & Lead Dev → internaliser
48. orga Equipe type pluridisciplinaire 1 PO 1 Lead tech 4/ 6 devs (1 ops) 1 QA
49. orga Recrutement: Takeaways Internaliser les devs historiques en position de lead dev Pas de coût / difficulté pour monter en compétence Un bon dev ne fait pas forcément un bon lead dev / manager Recrutement PO externes Difficile de monter en compétence sur l’existant Organisation “ateliers métier” chaque semaine 1h pour focus sur une partie de l’appli
50. Télescopage & régressions inter- équipes
51. archi Couplage inter équipes Évolutions d’une équipe → crée des régressions dans une autre équipe Frontières floues: qui est responsable de quoi ? Tension de modèle Limiter le code commun entre plusieurs équipes Modulariser: créer des frontières et des contrats d’interface entre les domaines
52. archi A) Modulariser dans le monolithe Arrêter d’empiler → nouveau besoin → nouveau package Réorganiser legacy package by layer → packages by feature/domain Attention aux entités qui appartiennent à plusieurs domaines Complexe et cher à découper Attention aux application orientées données (on vient d’excel !) Données → 1 modèle unique qui traverse toutes les couches ⇒ fort couplage Domaine → N modèles par domaine
53. archi B) Modulariser via les Lambda Lambda everywhere ! - Meilleur scaling & prix vs EC2 - Limite des tailles machine (EC2 XLarge) Une fonction n’est pas une application Montée en compétence écosystème Stack java pas idéale (mais ok) Besoin d’autonomie sur l’infra (droits ou Ops dispos)
54. archi C) Modulariser via les containers Des apps dans des containers + plateforme Kubernetes On est libre du runtime qu’on veut utiliser build once, run everywhere Rapide à prototyper Shift left Ops les devs montent en autonomie et les Ops s'occupent de l’outillage
55. Modulariser ne pas dupliquer
56. archi Modulariser oui ! mais dupliquer non ! Besoins communs aux applis modularisées Briques techniques: sécurité, messaging, SOAP, metrics Build & prod: cycle de vie (lint, test, build), dépendences, CI, health checks
57. archi Convention over configuration Libs communes Pas mélanger tech & fonctionnel Gradle Version Catalog (cf Spring BOM) Moins de combinatoire de libs → moins de pb d’incompatibilités Synchroniser les montées de versions techniques Gradle plugins: tâches partagées entre les builds (docker, sonar, liquibase, etc.) on ne se pose plus de questions Magie noire: fonctionnement opaque
58. Baisse de la qualité: augmentation des bugs
59. orga Plus de bugs ⇒ besoin de plus de tests Manque de connaissance des nouveaux (périmètre complexe) Impacts des changements d’une équipe sur l’autre Manque de tests automatisés end 2 end & manuels Mise en place de plus de tests e2e Scénario tech, pas assez métier + SUT trop grand / variable Recrutement QA + centre tests offshore Ralentissement cycle de livraison Shift left QA
60. orga Plus de bugs ⇒ besoin de plus de communication Silotage des équipes → moins de communication → plus de bugs Chaque équipe sur son sujet → plus personne pour les sujets transverses Divergence & problèmes de cohérence Communautés de pratiques volontariat, motivation, 1 personne par équipe & dégager du temps hors projet vision pas claire, pas de moyens d’action Task force 1 sujet transverse, 1 scope restreint, 1 limite de temps pas adapté pour du récurrent / long terme
61. Contraintes de sécurité: limiter l’accès au code
62. archi Monorepo: SOS porte ouverte Tout le monde voit tout Tout le monde peut tout modifier Toute la CI / CD est basée sur ce monorepo (release train) Github Code Owners Création de nouveaux repos Extraction des commons (identifier couplages cachées) Changement du mode de release Souplesse cycle de déploiement Matrice de versions compatibles & limiter nb de version
63. 7 nouveaux projets à lancer !
64. ops archi dev Ne pas réinventer la roue le bootstrap projet coûte trop cher / trop long l’application d’exemple n’est pas production ready Golden Path chemin par défaut pour créer une application Design system bibliothèque de composant Coût d’investissement Lean spirit (scope, simplicité, walking skeleton en prod)
65. orga Comment prioriser ? Comment avancer à la fois sur la modularisation et les nouveaux sujets ? Prioriser Cost of Delay
66. Fin
67. Fin Suite au prochain épisode !
68. orga dev ops métier archi Containers & autonomie aux devs Nouvelle organisation, platform team, mouvement & casser silos projet → produit poste responsable produit Modulariser, Hexagonal, com inter modules Standardiser, bibliothèque composants & libs
69. Takeaways
70. orga Equipe pluridisciplinaire <10
71. orga ops Démarche cloud : infra as cloud, abstraction Kube Equipe pluridisciplinaire <10
72. orga ops métier Démarche cloud : infra as cloud, abstraction Kube Equipe pluridisciplinaire <10 Privilégier vos critères différenciateurs
73. orga dev ops métier Démarche cloud : infra as cloud, abstraction Kube Equipe pluridisciplinaire <10 Privilégier vos critères différenciateurs Veiller à l’XP dev (cadre, DRY, KISS)
74. orga dev ops métier archi Démarche cloud : infra as cloud, abstraction Kube Equipe pluridisciplinaire <10 Privilégier vos critères différenciateurs Modulariser loi de Conway Veiller à l’XP dev (cadre, DRY, KISS)
75. Mot de la fin Pragmatisme
76. Merci ! Pour votre attention et vos feedbacks: