Nous vous proposons un retour d’expérience sur nos choix d’organisation axés autour de la productivité. Notre challenge : rendre une start-up adaptable au changement. Nos objectifs : être efficace pour développer des services, les mettre en production, les faire évoluer et recommencer. Cette présentation illustrera les moyens organisationnels et techniques qui permettent à chaque membre du projet d’être capable d’intervenir sur l’ensemble des services développés. Nous aborderons entre autres l’agilité, l’infra-as-code (Terraform, AWS), le JavaScript moderne (ES2017, typage statique avec Flow, react native), l’approche mono-repository et la sécurité. Nous expliquerons pourquoi nous avons fait ces choix et les difficultés que nous avons rencontrées.

2. Florent Le Gall
Développeur full-stack @ Fluo
@flornt
Thierry Abaléa
CTO @ Fluo
@ThierryAbalea
Arthur Sudre
Développeur full-stack @ Xebia
@ASudre

3. Produits d’assurance App mobile en B2C
Fluo, c’est ...
Multiples Intégrations en B2B

4. Fluo
Les enjeux de Fluo
→ Développer de nombreux services à
partir de composants métiers communs
→ Accroître la vélocité
→ Vaincre la spécialisation
→ Faciliter le recrutement
→ Garantir fiabilité et sécurité dans le
contexte bancaire / assurantiel
Mono-repo JS Moderne Infra As Code

5. → Développer de nombreux services à
partir de composants métiers communs
→ Accroître la vélocité
→ Vaincre la spécialisation
→ Faciliter le recrutement
→ Garantir fiabilité et sécurité dans le
contexte bancaire / assurantiel
Mono-repo

6. L’approche mono-repository
Mutualiser le code
→ Via les bibliothèques de code ?
→ Via des micro-services ?
On a toujours besoin de bibliothèques de code !

7. L’approche mono-repository
Mutualiser le code
Versionner chaque bibliothèque et chaque service dans son repository ?
Service B
Common Library
Service A
V1
Uses CommonLibrary@V1 Uses CommonLibrary@V1
V1V1

8. L’approche mono-repository
Mutualiser le code
Versionner chaque bibliothèque et chaque service dans son repository ?
Service B
Common Library
Service A
V2
Uses CommonLibrary@V2 Uses CommonLibrary@V1
V1V2
→ Qui modifie le service B ?

9. L’approche mono-repository
Mutualiser le code
Versionner toutes les bibliothèque et services dans un seul repository !
Service B
Common Library
Service A

10. L’approche mono-repository
Pas d’Intégration Continue avec un workflow à base de branches
→ Contraire à l’Intégration Continue
Martin Fowler: “ The whole idea is that nobody is working on a code base that deviates significantly from
anyone else’s. ”
→ Refactorisations transverses extrêmement compliquées
→ Travail des développeurs en silo

11. L’approche mono-repository
Trunk Based Development

12. L’approche mono-repository
Trunk Based Development
→ Comment s’assurer qu’on peut releaser à tout le moment ?
→ Grâce au feature toggles !
→ Les features toggles doivent être testées !

13. L’approche mono-repository
Difficultés de l’approche monorepo
→ Upgrade global & atomique des versions des dépendances extérieures
→ Exige une équipe polyvalente et un travail d’équipe
→ Codes Review plus difficiles avec les outils standards

14. L’approche mono-repository
Disclaimer
Un monorepo n’implique pas une application monolithique
L’approche micro-services n’implique pas un repository par service

15. L’approche mono-repository
Conclusion
→ Apport majeur: l’Intégration Continue
→ Approche Trunk Based Development déstabilisante pour les nouveaux
→ Pré-requis : une équipe “mature” et une dette technique maîtrisée

16. → Développer de nombreux services à
partir de composants métiers communs
→ Accroître la vélocité
→ Vaincre la spécialisation
→ Faciliter le recrutement
→ Garantir fiabilité et sécurité dans le
contexte bancaire / assurantiel
JS Moderne

17. Le JS moderne chez Fluo
JavaScript un choix évident pour Fluo ?
→ Fluo sur mobile → Fluo sur le web
Début 2016

18. Le JS moderne chez Fluo
JavaScript un choix évident pour Fluo ?
“One language to rule them all”

19. Le JS moderne chez Fluo
JavaScript un choix évident pour Fluo ?
“One language to rule them all”
→ Typé statiquement par défaut
→ Très approprié pour les backends
→ Plutôt exotique sur les frontends

20. Le JS moderne chez Fluo
JavaScript un choix évident pour Fluo ?
“One language to rule them all”
→ Typé dynamiquement par défaut
→ Approprié pour les backends
→ Très approprié pour les frontends

21. Le JS moderne chez Fluo
1- Décomposition (spreading)
Quelques fonctionnalités fournies par ES2015, ES2016 et ES2017

22. Le JS moderne chez Fluo
2 - Affectation par décomposition (destructuring assignment)
contractDetails.js
Quelques fonctionnalités fournies par ES2015, ES2016 et ES2017

23. Le JS moderne chez Fluo
Quelques fonctionnalités fournies par ES2015, ES2016 et ES2017
3 - Modules (import / export)
…
file.js

24. Le JS moderne chez Fluo
4 - Async / Await
Quelques fonctionnalités fournies par ES2015, ES2016 et ES2017

25. Le JS moderne chez Fluo
Le JavaScript typé statiquement
Pourquoi ?
→ Un filet de sécurité
→ Aider au développement
→ Faciliter les changements dans le code
→ Garantir la cohérence dans le code

26. Le JS moderne chez Fluo
Le JavaScript typé statiquement
TypeScript ou Flow ?

27. Le JS moderne chez Fluo
Flow
Comment typer ?
AFTER

28. Le JS moderne chez Fluo
Flow
Bénéficier de la complétion
AFTER

29. Le JS moderne chez Fluo
Flow
Typer les payloads des APIs REST
AFTER
Client Serveur

30. Le JS moderne chez Fluo
Flow
Typer les propriétés des composants React

31. Choix de Node.js en backend
Le JS moderne chez Fluo
→ Transpilation
→ Async / Await
→ Même langage entre le frontend et le backend

32. React.js pour les frontends
Le JS moderne chez Fluo
→ Simple et facile
→ Expérience développeur au top !

33. React Native pour le mobile
Le JS moderne chez Fluo
→ Expérience développeur aussi bonne que sur le web
→ Pas de spécialisation Android / iOS

34. Les limites du tout JavaScript
Le JS moderne chez Fluo
→ Faible maturité des APIs
→ Investissement en tooling nécessaire

35. → Développer de nombreux services à
partir de composants métiers communs
→ Accroître la vélocité
→ Vaincre la spécialisation
→ Faciliter le recrutement
→ Garantir fiabilité et sécurité dans le
contexte bancaire / assurantiel
Infra As Code

36. Historique - Des moyens rudimentaires
Infra As Code chez Fluo
→ Installation / Mise à jour des “middlewares”: apt-get
→ Déploiement des applications Fluo: tar, scp & ssh
→ OVH VPS (Virtual Private Server)

37. Historique - Problèmes
Infra As Code chez Fluo
→ État (state) d’un serveur peu prédictible (non immutable)
→ Peur de mettre à jour les packages (Apache, Tomcat, ...)
→ Déploiements fastidieux et sujets aux erreurs

38. La transition
Infra As Code chez Fluo
Infra As Code
Cloud

39. La transition
Infra As Code chez Fluo
Infra As Code

40. Infra As Code
Infra As Code chez Fluo

41. Infra As Code
Infra As Code chez Fluo

42. Le principe de docker
Infra As Code chez Fluo

43. Pourquoi le choix de docker ?
Infra As Code chez Fluo
→ facilité de déploiement
→ portabilité
→ légèreté (mémoire disque et RAM)
→ orientation micro-services

44. Avantages de Docker sur Puppet/Chef/Ansible
Infra As Code chez Fluo
→ Testé et validé une fois pour toute depuis la CI
→ Déploiement atomique: pas de dérive de la configuration
→ Même livrable partout

45. Immutable
Infra As Code chez Fluo
→ Changement nécessaire ⇒ nouvelle image
→ Une image n’est pas modifiable

46. Et le reste ?
Infra As Code chez Fluo
→ Tout élément d’infra n’est pas basé sur une image :
- DNS
- Bucket S3
- VPC
- RDS
- Règles Firewall
- ...

47. Outils pour le provisioning et la configuration des ressources
AWS
Infra As Code chez Fluo
→ Outil de gestion de configuration :
- Puppet
- Ansible
- Chef
→ Outils d’orchestration :
- AWS Cloudformation
- HashiCorp Terraform
→ AWS SDK

48. Terraform
Infra As Code chez Fluo
→ particulièrement adapté à Docker
→ déclaratif : on décrit l’état attendu

49. Terraform
Infra As Code chez Fluo
→ Ressources AWS gérées : EC2, ALB, RDS, IAM, VPC, ...
→ 70 providers : AWS, Google Cloud, Microsoft Azure, ...

50. Accompagnement
Infra As Code chez Fluo
Gruntwork
https://gruntwork.io

51. Infra As Code chez Fluo

52. Conclusion
Infra As Code chez Fluo
→ Approche immutable convaincante
→ Courbe d’apprentissage assez élevée pour des développeurs
→ Le pragmatisme paye

53. Pour conclure
Enjeux
→ Développer de nombreux services à partir de composants métiers communs
→ Accroître la vélocité
→ Vaincre la spécialisation
→ Faciliter le recrutement
→ Garantir fiabilité et sécurité dans le contexte bancaire / assurantiel

56. React Native Web
Le JS moderne chez Fluo
→ Un composant React
Native dans le
Back-office Fluo (React
JS)

57. Qu’est-ce que le JS moderne pour Fluo ?
Utiliser les fonctionnalités fournies par ES2015 et ES2017
Classes
Before After

58. Paradigme fonctionnel
Qu’est-ce que le JS moderne pour Fluo ?
→ Immutabilité
→ Fonctions pures
→ Fonctions d’ordre supérieur
Notions utilisées
Fonctions classiques
→ map
→ filter
→ reduce
Exemple

59. Multi comptes AWS
Infra As Code chez Fluo
<schéma des comptes>

60. Multi comptes AWS
Infra As Code chez Fluo
→ Le multi comptes a un léger surcoût mais le ROI est clair
→ Meilleur isolation entre comptes en terme de:
● sécurité (IAM perfectible)
● auditabilité
● coût: visibilité par environment

61. Pourquoi le choix de terraform comme infra-as-code ?
Infra As Code chez Fluo
Tableau tiré de https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c
Chef Puppet Ansible SaltStack CloudFormation Terraform
Code Open source Open source Open source Open source Closed source Open source
Cloud All All All All AWS only All
Type Config Mgmt Config Mgmt Config Mgmt Config Mgmt Orchestration Orchestration
Infrastructure Mutable Mutable Mutable Mutable Immutable Immutable
Language Procedural Declarative Procedural Declarative Declarative Declarative
Architecture Client/Server Client/Server Client-Only Client/Server Client-Only Client-Only

62. Exemple de l’usage de terraform
Infra As Code chez Fluo
example.tf
→ Télécharge les “providers” : provider.aws
…
…
…
→ Planifie les changements

63. Exemple de l’usage de terraform
Infra As Code chez Fluo
→ Exécute le plan
…
→ Création des services
→ Sauvegarde d’un état
● terraform.tfstate
● terraform.tfstate.backup

64. Infra As Code chez Fluo
→ Exécute
example.tf
Exemple de l’usage de terraform
→ Mise à jour du service et sauvegarde de l’état

65. Exemple de l’usage de terraform
Infra As Code chez Fluo
→ Planifie la destruction
→ Supprime l’instance
… → Sauvegarde du nouvel état
● terraform.tfstate
● terraform.tfstate.backup
→ Suppression des services

66. Exemple de l’usage de Docker
Infra As Code chez Fluo
Image de base : node:7.10
Création du dossier de
l’application
Téléchargement des modules
Copie du mono-repo
Remplacement des données
sensibles grâces aux clés AWS
Compilation de l’application
Commande d’exécution de l’imageDockerfile

67. Exemple de l’usage de Packer
Infra As Code chez Fluo
example.json
→ Valider le fichier
…
→ Exécuter

68. L’approche mono-repository
Trunk Based Development
→ Les “release branches”

69. Le JS moderne chez Fluo
Utiliser les fonctionnalités fournies par ES2015 et ES2017
1- Fat Arrow
Before After

70. Le JS moderne chez Fluo
4 - Async / Await
Avant Après
Quelques fonctionnalités fournies par ES2015, ES2016 et ES2017