Les choix techniques sont effectués et assumés par la Feature Team.
La Feature Team doit agir de manière responsable afin d'identifier les choix qui l'impactent exclusivement et les choix qui impactent l'organisation.
Les choix qui dépassent le périmètre de la Feature Team (exemple : licence, langage de programmation peu répandu) doivent être soumis à validation par l'organisation ou par le processus de convergence des pairs.
Le bon outil pour le bon usage est une source d'économies.
Un mauvais outil imposé à tous est un risque. Le mauvais usage d'un bon outil peut avoir des conséquences très néfastes. Par exemple, les méthodes Agiles mal utilisées sont dangereuses.
Les outils doivent être remis en question.
Excel est souvent un choix rationnel mais ça n'est pas un outil à tout faire (CRM, ERP, Datamart, …)
Privilégiez le Build pour le coeur de métier.
Envisagez le Buy pour le reste, au cas par cas.
Plus un outil porte une fonctionnalité apportant un caractère différenciant pour l'organisation, plus il a vocation à être construit. Le coeur de métier doit permettre la spécificité et s'adapter souvent et rapidement. Certains progiciels sont parfois adaptés à ce besoin.
Pour le reste : SaaS, Open Source, Build ou Propriétaire sont à étudier au cas par cas.
Privilégiez l’Open Source.
Les choix alternatifs doivent être étayés.
Les solutions propriétaires sont un risque pour l'organisation qui doit être capable de reprendre la maintenance si besoin.
Rares sont les outils propriétaires qui n'ont pas d'alternatives Open Source.
L'organisation bénéficie de la Communauté Open Source et peut lui reverser ses contributions.
Développez des services autonomes et faiblement couplés.
Le couplage faible doit être la norme.
Chaque micro-service dispose d'une interface clairement définie.
Cette interface détermine le couplage entre les micro-services.
Le Domain Driven Design permet, notamment avec les Bounded Contexts, d'anticiper au mieux cette problématique.
Chaque service possède son propre système de stockage de données.
Un Data Store n'a vocation à être couplé qu'avec un seul micro-service.
L'accès aux données d'un micro-service à un autre est effectué exclusivement via son interface.
Ce design implique la cohérence à terme à l'échelle de la plateforme. Elle doit être appréhendée à tous les niveaux, y compris UX.
Chaque micro-service doit avoir un périmètre fonctionnel raisonnable, qui "loge dans la tête".
Un micro-service propose un nombre raisonnable de fonctionnalités.
N'hésitez pas à découper un micro-service lorsque celui-ci commence à grossir.
Un service de taille raisonnable permet d'envisager sereinement la réécriture, si le besoin se présente.
Le Reactive Manifesto ouvre la voie vers la conception d'architectures réactives.
La programmation réactive se concentre sur le flux de données et la propagation du changement. Elle s'appuie sur le pattern "Observer" contrairement à l'approche "Iterator", plus classique.
Le Reactive Manifesto fixe des axes fondamentaux : disponibilité et rapidité, résilience aux pannes, souplesse, élasticité et orientation messages.
Les processus asynchrones favorisent le découplage et la scalabilité au profit des performances.
Les échanges entre applications doivent être en premier lieu asynchrones.
Les échanges asynchrones permettent naturellement le couplage faible, l' isolation et le contrôle des flux (back-pressure).
La communication synchrone ne doit être envisagée que lorsque l'action l'impose.
Le système d'informations doit être orienté événements.
Les processus fonctionnels orientés "événements" sont naturellement implémentés de manière asynchrone.
L' orientation événements permet de favoriser la mise en place d'approches telles que Command Query Responsibility Segregation (CQRS) et Event Sourcing.
Privilégiez un message-broker simple , robuste et performant à un "tuyau intelligent".
Les ESB ont montré leurs limites : la maintenance évolutive est critique, aussi bien d'un point de vue technique qu'organisationnel.
Les messages brokers comme Kafka offrent une solution simple, durable et résiliente.
Des endpoints intelligents et des tuyaux simples est une architecture qui fonctionne à l'échelle : c'est Internet.
La synchronisation totale du système doit être pensée dès sa conception.
Si la synchronisation entre deux systèmes est assurée par un flux d'événements, la resynchronisation totale de ces systèmes doit être prévue dès la conception.
Un audit automatique de la synchronisation (exemple : par échantillons) permet de mesurer et détecter les éventuelles erreurs de synchronisation.
La configuration des services est centralisée, leur découverte est assurée par un annuaire.
La configuration des micro-services est centralisée pour l'ensemble des environnements.
Un annuaire centralisé permet d'assurer la découverte dynamique des micro-services.
La scalabilité globale du SI dépend de cet annuaire.
Les Feature Teams fournissent un environnement "bac à sable".
Les Feature Teams maintiennent un environnement "bac à sable" (version actuelle et version à venir) afin de permettre aux autres équipes de développer à l'échelle.
Dans certains cas non nominaux, des features peuvent être désactivées dans l'environnement de développement.
Votre système tombera en panne !
Concevez-le afin qu’il y soit tolérant.
Votre système tombera en panne, c'est inévitable. Il doit être conçu pour cela (Design For Failure).
Prévoir la redondance à tous les niveaux : matériel (réseau, disque, etc.), applicatifs (plusieurs instances des applications), zones géographiques, providers (exemple : AWS + OVH).
Fournissez des toolkits, n’imposez pas de cadres stricts.
Attention aux composants techniques maisons et transverses ! Ils sont contraignants, coûteux et difficiles à maintenir.
Des accélérateurs, toolkits, stacks techniques peuvent être mis en commun, au libre choix des Feature Teams, en évitant une approche dogmatique.
Public, privé ou hybride, le cloud (IaaS ou PaaS) est la norme pour la production.
Les services de type PaaS sont à privilégier, ils sont simples et passent rapidement à l'échelle.
Les services IaaS permettent d'adresser les cas demandant une plus grande souplesse , mais ils demandent plus de travail opérationnel.
Un cloud privé n'est pas un environnement de virtualisation traditionnel, il s'appuie sur du commodity hardware.
Les Feature Teams ne gèrent pas l'infrastructure, elle est fournie et maintenue par l'organisation.
Les problèmes d'infrastructure ne sont pas du ressort des Feature Teams. L'infrastructure doit leur être fournie et maintenue par un service transverse.
Les conteneurs offrent la souplesse nécessaire à un outillage hétérogène.
Les conteneurs offrent la souplesse nécessaire aux Feature Teams pour leur permettre un outillage hétérogène dans un contexte homogène.
L'utilisation de conteneurs permet de s'affranchir des problèmes d'environnements techniques.
Les conteneurs (exemple : Docker) permettent de s'affranchir des différences d'environnement.
Le processus de déploiement doit être agnostique à l'environnement.
Certains composants comme les bases de données ne doivent pas être déployés dans des conteneurs. Leur déploiement est malgré tout automatisé.
Les mesures doivent être centralisées et accessibles à tous.
Les métriques sont accessibles à tous avec différents niveaux de granularité : vue détaillée pour la Feature Team concernée, agrégations pour les autres membres de l'organisation.
L'accès aux métriques n'implique pas l'accès aux données unitaires, celui-ci doit être contrôlé pour préserver la confidentialité.
Tous les environnements sont concernés.
La qualité logicielle est un facteur clé.
Les revues de code sont systématiques. Elles sont effectuées par des membres de la Feature Team ou d'autres membres de l'organisation, dans le cadre de l'amélioration continue.
Ça n'est pas vous qu'on audite mais votre code : "You are not your code !".
La qualimétrie peut être en partie automatisée, mais rien ne vaut l'"oeil neuf".
Le testing automatisé est un prérequis non négociable au déploiement continu.
Le testing automatisé permet d'assurer la qualité du produit dans le temps.
Il est un prérequis au déploiement continu, il permet changements et déploiements fréquents.
Le déploiement en production devient un événement anecdotique !
Des tests à tous les niveaux : unitaires, intégration, fonctionnels, résilience, performance.
Les tests d'intégration et fonctionnels sont les plus importants, ce sont eux qui garantissent le bon fonctionnement du produit.
Les tests unitaires sont adaptés au développement.
Les tests de performance permettent de mesurer la performance dans le temps.
Les tests de résilience permettent d'anticiper les pannes.
La couverture est le principal indicateur objectif de qualité des tests.
La couverture de code par les tests est une bonne métrique de la qualité du code.
C'est une condition nécessaire mais pas suffisante, la couverture d'une mauvaise stratégie de tests peut être élevée sans être garante de la bonne qualité du code.
La sécurité est un processus, elle ne doit pas être traitée en réaction aux problèmes.
Des experts sécurité peuvent être intégrés directement aux Feature Teams si nécessaire.
Des experts sécurité sont disponibles dans l'organisation pour auditer, sensibiliser et transmettre.