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

Slide 1

Slide 1 text

Charles Bouttaz - Guillaume Ehret Scale-up les impacts du passage à l'échelle RE X orga tech ops métier archi

Slide 2

Slide 2 text

il était une fois… C

Slide 3

Slide 3 text

il était une fois… C

Slide 4

Slide 4 text

2009 startup aggrégateur de ﬂexibilité électrique C

Slide 5

Slide 5 text

ﬂexibilité ou objectif équilibre du réseau électrique consommation = production G

Slide 6

Slide 6 text

ﬂexibilité ou objectif équilibre du réseau électrique consommation < production consommation > production G

Slide 7

Slide 7 text

Petite équipe de dev 5 - 7 personnes G 1 Pays 2009

Slide 8

Slide 8 text

aujourd’hui… C

Slide 9

Slide 9 text

Multi pays & timezones C 12 équipes, ~70 devs 2024

Slide 10

Slide 10 text

How to scale ? orga dev ops métier archi C

Slide 11

Slide 11 text

orga Organisation 1 équipe 12 équipes, 70 devs G

Slide 12

Slide 12 text

métier Métier 1 métier (ﬂex) 1 pays 3 métiers (ﬂex, microgrid, simulation) >10 pays C

Slide 13

Slide 13 text

dev Technique Focus TTM & qualité Technos Jboss Play! Framework Focus Qualité & TTM Spring Boot, Angular G

Slide 14

Slide 14 text

archi Architecture Monolithe Monolithe modulaire + modules C

Slide 15

Slide 15 text

ops Ops JBoss on premise AWS, managed services (Lambda, K8s, Aurora) G

Slide 16

Slide 16 text

Événement perturbateur C

Slide 17

Slide 17 text

Problème Solution mise en place Takeaway positif Takeaway négatif

Slide 18

Slide 18 text

Charles Bouttaz Guillaume Ehret G

Slide 19

Slide 19 text

Back in 2017 G

Slide 20

Slide 20 text

Besoin de développer + de services + vite G

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

archi Les limites du monolithe Monolithe trop gros → difﬁcile à maintenir Problèmes de performance (data) Nouveaux produits / métier Création de nouvelles applications hors monolithe mais dans monorepo Mono repository Git pour proﬁter du tooling commun Uniquement pour des applis très “éloignées” du métier actuel G

Slide 23

Slide 23 text

Besoin de déployer + de services + fréquemment C

Slide 24

Slide 24 text

ops SOS Ops ! Pas assez d’Ops déployer & maintenir tous les services sur tous les envs Difﬁcile de gérer les demandes d’infra on premise Recrutement Pénurie compétences & montée en compétence longue

Slide 25

Slide 25 text

ops Migration Cloud Migration Cloud AWS → difﬁcile 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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Objectif x30 en 2030 !!!

Slide 28

Slide 28 text

orga Besoin de renforts ! Peu d’internes (90% prestataires) Recrutement par le réseau → Pas scalable Recrutement: - ESN, Freelances - Embauche - Internaliser les externes historiques

Slide 29

Slide 29 text

orga Besoin de renforts ! Contexte: manque de devs sur le marché (post-covid) Comment déﬁnir 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

Slide 30

Slide 30 text

Trop nombreux pour une seule équipe

Slide 31

Slide 31 text

orga Trop de personnes dans une équipe Périmètre fonctionnel trop gros (surtout pour les nouveaux) Rituels agiles compliqués Synchronisation / communication difﬁcile Découper ⇒ 😵

Slide 32

Slide 32 text

orga Cartographier & découper les domaines fonctionnels

Slide 33

Slide 33 text

orga Loi de conway the organisation design is likely to be mirrored the product design

Slide 34

Slide 34 text

orga Limites & charge cognitive Bounded Context Bounded Context Bounded Context

Slide 35

Slide 35 text

orga Problème de gouvernance Bounded Context Bounded Context Bounded Context

Slide 36

Slide 36 text

orga Séparer les responsabilités Bounded Context Bounded Context Bounded Context

Slide 37

Slide 37 text

orga Idéalement aligner business, software & team Selling Shipping SAV Domain Team App(s)

Slide 38

Slide 38 text

orga Comment découper ? Comment découper ? Il nous faut de meilleures questions: - Quels critères ? - Quelles contraintes ?

Slide 39

Slide 39 text

orga Critère découpage: la taille "Miller's Law": 7 ± 2 - George A. Miller

Slide 40

Slide 40 text

orga Critère découpage: la taille "Pizza rule": 5 - 8 ppl - Jeff Bezos

Slide 41

Slide 41 text

orga Critère découpage: besoin de communication & synchro

Slide 42

Slide 42 text

orga Critère découpage: besoin de communication & synchro

Slide 43

Slide 43 text

orga Critère découpage: besoin de communication & synchro

Slide 44

Slide 44 text

orga Critères de découpage: Criticité métier / différenciateur

Slide 45

Slide 45 text

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 identiﬁés → plus facile de trouver des interlocuteurs Confusion aux frontières des domaines (au début) Transverse technique “oublié” Difﬁcile de bien dimensionner les équipes (scope & roadmap)

Slide 46

Slide 46 text

30 devs 2 métiers 👫😓 2 supports 👬

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

orga Equipe type pluridisciplinaire 1 PO 1 Lead tech 4/ 6 devs (1 ops) 1 QA

Slide 49

Slide 49 text

orga Recrutement: Takeaways Internaliser les devs historiques en position de lead dev Pas de coût / difﬁculté pour monter en compétence Un bon dev ne fait pas forcément un bon lead dev / manager Recrutement PO externes Difﬁcile de monter en compétence sur l’existant Organisation “ateliers métier” chaque semaine 1h pour focus sur une partie de l’appli

Slide 50

Slide 50 text

Télescopage & régressions inter- équipes

Slide 51

Slide 51 text

archi Couplage inter équipes Évolutions d’une équipe → crée des régressions dans une autre équipe Frontières ﬂoues: 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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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)

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Modulariser ne pas dupliquer

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

archi Convention over conﬁguration 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

Slide 58

Slide 58 text

Baisse de la qualité: augmentation des bugs

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Contraintes de sécurité: limiter l’accès au code

Slide 62

Slide 62 text

archi Monorepo: SOS porte ouverte Tout le monde voit tout Tout le monde peut tout modiﬁer Toute la CI / CD est basée sur ce monorepo (release train) Github Code Owners Création de nouveaux repos Extraction des commons (identiﬁer couplages cachées) Changement du mode de release Souplesse cycle de déploiement Matrice de versions compatibles & limiter nb de version

Slide 63

Slide 63 text

7 nouveaux projets à lancer !

Slide 64

Slide 64 text

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)

Slide 65

Slide 65 text

orga Comment prioriser ? Comment avancer à la fois sur la modularisation et les nouveaux sujets ? Prioriser Cost of Delay

Slide 66

Slide 66 text

Fin

Slide 67

Slide 67 text

Fin Suite au prochain épisode !

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

Takeaways

Slide 70

Slide 70 text

orga Equipe pluridisciplinaire <10

Slide 71

Slide 71 text

orga ops Démarche cloud : infra as cloud, abstraction Kube Equipe pluridisciplinaire <10

Slide 72

Slide 72 text

orga ops métier Démarche cloud : infra as cloud, abstraction Kube Equipe pluridisciplinaire <10 Privilégier vos critères différenciateurs

Slide 73

Slide 73 text

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)

Slide 74

Slide 74 text

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)