author
Jodi Moran, co-fondatrice et CTO de la société Plumbee, spécialisée dans le développement de jeux sur le web (Jeux Facebook en particulier), a présenté lors de QCon Londres un retour d’expérience sur les pratiques de développement mises en oeuvre au sein de sa société, et qui ont permis de répondre à des contraintes de croissance fulgurante.
Jodi démarre la présentation avec la définition de la notion de “Une vitesse soutenable”:
- La vitesse est mesurée par le temps séparant l’expression du besoin à son changement effectif.
- La durabilité est mesurée par la capacité à garder cette vitesse dans le temps.
Maintenir un rythme soutenable permet d’avoir de la réactivité, ce qui est primordial pour garder son audience. Mais cela permet également d’avoir un meilleur rendement et des investissements plus faibles.
Pour arriver à délivrer rapidement de la valeur ajoutée aux clients, il est nécessaire de mettre en oeuvre différentes pratiques:
- Itérer et automatiser
- Agiliser le fonctionnement des équipes
- Mettre en place la livraison incrémentale
- Se focaliser sur les principes agiles, et non pas sur les pratiques : les procédés sont un moyen pour atteindre un but
Un concept important qui revient régulièrement dans les différentes sessions est le besoin de faire simple. Simple ne veut pas dire simpliste, il faut plutôt aller chercher la notion de simplicité dans les concepts, ou bien dans la maintenabilité applicative.
Il est, par exemple, important de traiter les changements de façon isolée. Ils doivent être faciles à identifier, et les changements impactant, sous-entendus risqués, doivent être appliqués sur différentes releases.
Il est peut être difficile d’avoir un backlog produit correctement ordonné. Pour résoudre ce problème, Jodi propose de se focaliser sur les fonctionnalités permettant d’obtenir un minimum viable. Pour être efficace, il minimuser autant que possible l’overhead de process et de technologies.
Une fois un projet démarré, il arrivera inévitablement un moment où il faudra adresser la dette technique. Afin de maîtriser ce problème, il est nécessaire de l’anticiper dès le début des développements en gardant une base de code minimaliste. Sachant qu’il n’est pas possible d’éviter la dette technique à long terme, il convient donc de la garder sous contrôle, et de la traiter de façon intentionnelle. C’est le principe de l’amélioration continue.
Au niveau des opérations, le besoin de simplicité se retrouve également. Jodi préconise la mise en place de procédures de déploiement et d’exécution des tests de type “pousse bouton”. La simplicité ne doit pas se retrouver uniquement dans le développement, mais également dans les procédures et dans l’architecture.
L’automatisation des tâches répétitives et les itérations rapides sont deux moyens de permettant de délivrer rapidement des fonctionnalités.
Les technologies utilisées doivent être, elles aussi, simples et communes. Il est donc essentiel de choisir des outils ayant une communauté importante. Il est préférable de choisir des produits open-source, d’encourager l’utilisation de composants, et de choisir des languages fortement répandus tels que : Java, JavaScript ou bien encore ActionScript (dans l’industrie du jeu sur Internet, l’ActionScript reste un langage prédominant).
Pour étayer ses propos, Jodi nous décrit son architecture: la plateforme d’exécution sélectionnée n’est autre qu’Amazon EC2. Ce choix de plateforme apporte de nombreux avantages tels que de la flexibilité et de l’agilité. La plateforme Amazon nécessite une équipe d’exploitation réduite, ce qui permet de réduire les coût de maintenance des environnements serveurs. A la différence de services PaaS tels que Google App Engine, la plateforme AWS n’impose pas de lock-in technologique, et de nombreux services, habituellement complexes à mettre en oeuvre, sont fournis out of the box.
La stack technique utilisée par l’équipe est composées de Spring, AspectJ, Mysql (RDS), ce qui reste assez classique. Le point intéressant provient de la façon dont les données sont traitées, puisque la structure de stockage est unique et très générique: les données sont représentées sous forme de tuples [userid[int], valueid[int], value[blob]], puis sont réparties sur de multiples instances de bases MySQL Amazon. Par exemple, un compte utilisateur est stocké sur une instance dont les données sont répliquées sur d’autres instances en mode “slave”. Les données sont ainsi affectés sur les différents serveurs via un simple “round-robin”, et le sharding est quant à lui traité via une librairie maison.
Ces choix techniques concernant la stack applicative ainsi que la structure de la base de donnée permettent:
- de faciliter la compréhension du système
- d’éviter les périodes de downtime lors de changements de schemas
- de monitorer et de tuner facilement les environnements serveurs
- de pouvoir scaler horizontalement sans difficultés majeures.
- d’avoir une plateforme hautement disponible, ainsi qu’un failover transparent.
Du point de vue de Jodi, il est bénéfique de collecter autant de données que possible, et de les stocker pour une période indéterminée. Des données sont collectées à chaque évènement, qu’elles soient de source applicative ou bien système. Cela permet d’effectuer du monitoring et de l’analyse de données.
La collecte systématique de données permet d’étudier l’impact d’un changement applicatif ou de paramétrage. Pour cela, les équipes de Plumbee ont recours à différentes méthodes dont le split testing qui consiste à expérimenter un changement sur un petit groupe d’utilisateurs afin d’en étudier l’impact sur l’utilisation de l’application.
Pour la suite, Jodi nous parle de l’organisation du travail au sein de la société: afin d’optimiser le fonctionnement des équipes, il est nécessaire de faire matcher les notions appliquées à l’architecture applicative avec l’organisation de la société. L’idée est de créer des “mini startups” à l’intérieur de la société qui s’occupent chacunes d’un périmètre précis de l’application et du fonctionnel. Les équipés, composées de compétences multiples, sont autonomes et responsables de leur périmètre. Elles peuvent ainsi avancer rapidement et cela a pour effet d’améliorer le sens du partage des responsabilités au sein des équipes.
Après cette digression organisationnelle, Jodi revient sur des aspects plus techniques et nous présente sa vision:
- Il faut privilégier la glue technique plutôt que de refaire.
- Les fonctionnalités sont des assets, alors que le code est un passif.
- Les développements et les outils sont hétérogènes, il ne faut pas essayer de les standardiser.
- Enfin, il n’y a pas de “Big Picture”, il faut savoir s’adapter et répondre au besoin.
Point plus étonnant, Jodi prône que le test est mort, et reprend les idées de la KeyNote d’Alberto Savoia au GTAC 2011: Les applications et les besoins évoluent trop vite pour dépenser de l’énergie et du temps dans les tests. De plus, les tests ont la fâcheuse tendance d’ancrer le code, plutôt que de lui permettre d’évoluer. Le test est censé permettre de valider une fonctionnalité, mais du point de vue de qui ? du développeur ? du product owner ? ou bien de l’utilisateur ? Selon Jodi, tester moins est moins risqué (Ouch!). Elle souligne cependant que cette idée est moins vraie pour les systèmes qui ont moins tendance à évoluer.
Le corollaire émanant du point précédent, est que les tests de charges sont morts : réaliser un test de charge est difficile, il vaut mieux avoir un bon design permettant le scaling horizontal. Afin prévoir la capacité pour de nouveaux utilisateurs, mieux vaut avoir un environnement basé sur un provider IaaS, un bon design, du monitoring, et une bonne capacité d’adaptation pour être en mesure de scaler Just In Time.
Afin de prévoir la capacité nécessaire à développer de nouvelles fonctionnalités, il faut investir dans des stratégies de dark launch, et de rollouts graduels. Et pour réussir ce tour de force, il faut le prévoir dans le système.
En point final, Jodi pense que les services d’exploitation et d’infra sont morts, et qu’il est nécessaire que les ingénieurs soient en mesure d’opérer avec le système sur lequel ils travaillent.
Certains points de vue sont un poil provocateurs ou même curieux, mais ce retour d’expérience est pour le moins pragmatique et pas uniquement théorique. Il faut donc y piocher des idées avec parcimonie et garder en tête les quatre éléments clés de la réussite: rapidité, simplicité, pragmatisme et maîtrise.
Enfin Jodi, finit la session sur ces mots : il faut avoir une culture de la rapidité, engager les meilleurs, les rendre passionnés de leurs produits, leur donner des responsabilités et de la liberté. Il est essentiel de leur faire confiance et de les laisser prendre des décisions, tout en les encourageant à prendre des risques (NDLR: mesurés ?)
Liens utiles:
- Slides de la présentation: Zero to ten million daily users in four weeks