Une simple défaillance logicielle peut coûter beaucoup d’argent à une organisation, mais il est possible de l’éviter en modifiant facilement l’architecture et la conception. Cette nouvelle édition de « Release It » a été publiée en janvier 2018. Elle illustre comment concevoir des systèmes qui fonctionnent plus longtemps en limitant les défaillances et en reprenant le contrôle lorsque les choses tournent mal. Ce livre est un guide indispensable pour l’ingénierie des systèmes de production.
COMMENT CE LIVRE NOUS A-T-IL AIDÉS ?
Ce livre nous a aidés à éviter des risques qui coûtent cher aux entreprises en termes de temps d’arrêt et de réputation. Quatre-vingt pour cent du coût du cycle de vie d’un produit se situe au niveau de la production.
LE LIVRE EXPLIQUÉ EN MOINS DE 60 SECONDES
La version actualisée de Release it ! Design and Deploy Production-Ready Software traite de la production de systèmes modernes – des systèmes volumineux, complexes et fortement virtualisés. Elle comprend un aperçu de l’ingénierie du chaos, de la discipline de mise en œuvre des mises à jour sans temps d’arrêt et de la livraison continue, ainsi que de la robustesse des logiciels natifs dans le nuage. Analysez les approches de l’architecture, de la conception et de la création de systèmes distribués à dominante logicielle.
TROIS CITATIONS PRINCIPALES
- « La conception de logiciels telle qu’elle est enseignée aujourd’hui est terriblement incomplète. Elle ne parle que de ce que les systèmes doivent faire. Elle n’aborde pas l’inverse, c’est-à-dire ce que les systèmes ne doivent pas faire. Ils ne doivent pas tomber en panne, se bloquer, perdre des données, violer la vie privée, perdre de l’argent, détruire votre entreprise ou tuer vos clients ».
- « La plupart des testeurs que j’ai connus sont suffisamment pervers pour que, si vous leur indiquez le « chemin heureux » à travers l’application, c’est la dernière chose qu’ils feront. Il devrait en être de même pour les tests de charge ».
- « Concevez avec scepticisme et vous obtiendrez la résilience.
RÉSUMÉS ET NOTES DE LECTURE
Premier chapitre : Créer la stabilité
Lorsque votre logiciel ou votre base de données tombe en panne, changez de fenêtre et essayez quelque chose de nouveau. Vous pouvez faire appel à un ingénieur local pour vous aider à mettre en œuvre le changement. Si vous changez de base de données, essayez de passer à un meilleur fournisseur de services. Vous pouvez commencer par déplacer vos informations et vos données de l’ancienne base de données 1 vers la nouvelle base de données 2, puis mettre à jour la base de données 1. Après avoir vérifié la base de données mise à jour, déplacez vos informations et vos données vers la base de données 1.
Une mauvaise stabilité entraîne des coûts réels élevés. Le prix apparent est une perte de revenus. Une bonne stabilité ne coûte pas si cher. Lors de l’élaboration de l’architecture, de la conception et de la mise en œuvre de systèmes mineurs, de nombreux points de décision ont une grande influence sur la stabilité du système. La mise en œuvre d’un logiciel très stable coûte généralement le même prix que celle d’un logiciel instable. Pour parler de stabilité, vous devez connaître les transactions. Une transaction est une unité abstraite de travail traitée par le système. Une transaction s’étend sur de nombreuses pages et implique généralement des intégrations externes telles que la vérification des cartes de crédit. Les transactions sont la raison d’être d’un système. Un système peut traiter un seul type de transaction et le rendre entièrement dédié.
Les principales incertitudes qui pèsent sur la durée de vie de votre système sont les fuites de données et de mémoire. Ces deux dangers peuvent tuer votre système en production et sont rarement détectés lors des tests. Les tests permettent de visualiser les problèmes afin que vous puissiez les résoudre. Les problèmes qui surviennent lorsque votre logiciel est terminé sont ceux que vous n’avez pas testés. Par conséquent, ces pannes se produiront si vous ne testez pas les erreurs de mémoire dans l’application.
Citation préférée du chapitre : « Concevez avec scepticisme et vous obtiendrez la résilience. . »
Chapitre deux : Conception pour la production
Les opérations vous amènent à concevoir pour des considérations de production en examinant les fondements physiques du système : les machines et les câbles sur lesquels tout repose. Résolvez certains problèmes concernant les réseaux, les noms d’hôtes et les adresses IP. Chaque déploiement a son propre ensemble de préoccupations que les conceptions logicielles doivent prendre en compte.
- Opérations – Sécurité, capacité, état, communication, disponibilité
- Plan de contrôle – Déploiement, détection des anomalies, fonctionnalités, surveillance des systèmes
- Interconnexion-Routage, basculement, gestion du trafic, équilibrage des charges
- Instances – Services, composants, processus, surveillance des instances
- Fondation – Matériel, machines virtuelles, réseau physique, adresses IP
La mise en réseau au sein du centre de données et du nuage ne se limite pas à l’ouverture d’une prise de courant. Ces réseaux absorbent généralement plus de redondance et de sécurité que les réseaux de bureau. Lorsque vous ajoutez une ou deux couches de virtualisation, les applications et les services se comportent de manière plus distincte que dans les limites sûres de l’IDE. Ils nécessiteront un travail important pour se comporter correctement dans cet environnement.
Une instance est une installation sur une seule machine (virtuelle ou physique) à partir d’un réseau à charge équilibrée du même exécutable. Les instances individuelles assurent la transparence, gèrent correctement la configuration, acceptent le contrôle et gèrent les connexions. Chaque machine nécessite le code, la configuration et les liens réseau corrects. Les développeurs prêtent généralement attention au comportement de leur code. C’est pourquoi ils disposent d’excellents outils pour construire, héberger et déployer le code. Les développeurs doivent être capables de construire un système, d’effectuer des tests et de mettre en œuvre au moins une partie du système localement.
Les couches d’interconnexion couvrent tous les mécanismes qui combinent un ensemble d’instances en un système cohérent, y compris la gestion du trafic, la découverte et l’équilibrage de la charge. C’est grâce aux couches d’interconnexion qu’il est possible de créer une haute disponibilité. Envisagez la solution la mieux adaptée à votre organisation lorsque vous passez à l’interconnexion, au panneau de contrôle et à l’exploitation. Peu de techniques de découverte et d’innovation de services dépendent généralement de logiciels supplémentaires. Une équipe étendue avec des milliers de petits services est performante lorsqu’elle utilise Consul ou tout autre service dynamique. De plus, le coût d’exploitation de Consul est rapidement amorti. Pour les petites équipes, le choix idéal dans une infrastructure à évolution lente est le DNS. Cela implique des machines physiques engagées et des machines virtuelles dédiées à longue durée de vie. Les adresses IP restent généralement stables pour que le DNS soit pratique.
Citation préférée du chapitre : « L’équilibrage des charges, le routage, le délestage et la découverte de services sont quelques-unes des questions clés à prendre en compte lors de la construction des couches.
Chapitre trois : Livrer votre système
Vous ne devez pas prévoir un seul ou quelques déploiements pour les productions, mais plusieurs. Après avoir écrit, compressé et envoyé votre logiciel pour le déployer dans les opérations, ajoutez des notes de mise à jour pour chaque nouvelle option de configuration qu’ils doivent définir. Les opérations fixeront un « temps d’arrêt planifié » pour l’exécution de la version. La plupart du temps, vous concevez l’état du système après une mise en production. Le problème est que cela suppose que l’ensemble du système peut être modifié par un saut quantique instantané.
Le code est une responsabilité évidente entre le moment où vous l’exécutez dans le référentiel et le moment où il s’exécute en production. Le code non déployé est généralement un inventaire. Il comporte des bogues non divulgués et provoque des arrêts de production. Il peut s’agir d’une implémentation idéale d’une fonctionnalité dont personne ne veut. Le déploiement continu minimise le délai entre l’exécution et la production du code et la responsabilité du code non déployé.
Les bases de données sont la principale raison des « arrêts planifiés », principalement les changements de schéma dans les bases de données relationnelles. Au lieu d’implémenter des scripts SQL bruts à l’aide d’une CLI d’administration, vous pouvez avoir un contrôle programmatique pour faire avancer la version de votre schéma. Un cadre de migration tel que Liquibase peut vous aider à mettre en œuvre les changements de schéma. Cependant, il ne rend pas automatiquement ces changements compatibles avec les versions antérieures et postérieures.
Lorsque vous ajoutez des fonctionnalités à votre application, veillez à ne pas consommer les applications. Les différents consommateurs de votre service ont d’autres objectifs et d’autres besoins. Chaque application consommatrice a son équipe de développement qui travaille selon son propre calendrier. Vous ne pouvez pas forcer les consommateurs à suivre votre calendrier de publication. Pour apporter des modifications compatibles à l’API, réfléchissez à ce qui constitue une modification incompatible.
Citation préférée du chapitre : « En même temps, j’éprouvais un profond sentiment de perte : tout ce temps passé dans l’armée de déploiement. Tout ce potentiel gaspillé. L’humanité gaspillée ! Utiliser les gens comme s’ils étaient des robots. Perturber des vies, des familles, des rythmes de sommeil… c’était un tel gâchis. »
Chapitre quatre : Résoudre les problèmes systémiques
Le test de charge est généralement un processus non interventionniste. Vous définissez un plan de test, générez quelques scripts, configurez les générateurs de charge et le répartiteur de test, et lancez une série de tests pendant la nuit. Une fois le test terminé, analysez les données collectées pendant le test. Examinez les résultats, modifiez la configuration et programmez le prochain test. Le test de charge est à la fois un art et une science. Il est inimaginable de reproduire le trafic de production réel. Utilisez donc l’analyse du trafic et votre intuition pour parvenir à une simulation aussi proche que possible de la réalité.
Le changement est garanti, mais la survie ne l’est pas. Le développement agile permet d’accepter le changement en réaction à la situation de l’entreprise. Cependant, la flèche est susceptible de pointer dans l’autre direction. Le changement de logiciel peut générer de nouveaux produits et de nouveaux marchés. Il peut créer un espace pour de nouvelles alliances et une nouvelle concurrence, en augmentant la surface entre des entreprises qui appartenaient auparavant à des secteurs différents. Tous les logiciels n’ont pas besoin d’être modifiés quotidiennement. Certains logiciels n’ont pas de potentiel de changement et d’adaptation rapide. Dans certains secteurs, le changement de logiciel passe par une certification longue et coûteuse. Les coûts de transaction sont élevés si vous voulez envoyer des astronautes dans l’espace avec un tournevis et une pince à découper les puces.
Pour mettre en œuvre un changement, votre entreprise doit passer par un cycle de décision. Quelqu’un doit sentir qu’un besoin existe, quelqu’un d’autre doit décider que ce changement répondra parfaitement à ce besoin et qu’il vaut la peine d’être mis en œuvre. Ensuite, quelqu’un doit agir, concevoir la fonctionnalité et la mettre sur le marché, et enfin, quelqu’un doit voir si le changement a eu l’effet escompté. Dans les petites entreprises, le processus peut impliquer deux ou trois personnes. La communication est assez rapide.
L’ingénierie du chaos concerne les systèmes distribués, généralement à grande échelle. Les environnements d’essai ou d’assurance qualité ne sont pas idéaux pour le comportement à grande échelle des systèmes de production. Différents ratios d’instances entraînent des comportements de sortie qualitativement différents, ce qui est également le cas pour le trafic. Les réseaux encombrés se comportent de manière qualitativement différente des réseaux non encombrés.
Citation préférée du chapitre : « La plupart des testeurs que j’ai connus sont suffisamment pervers pour que, si vous leur indiquez le « chemin heureux » à travers l’application, c’est la dernière chose qu’ils feront. Il devrait en être de même pour les tests de charge. »
COMMENT CE LIVRE PEUT AIDER LES DÉVELOPPEURS DE LOGICIELS
« Release It ! » de Michael T. Nygard est un guide pratique qui aide les développeurs de logiciels à concevoir, développer et déployer des logiciels prêts pour la production. Le livre fournit des exemples concrets et des études de cas, mettant en évidence les pièges les plus courants et proposant des solutions pour les éviter. Il propose des conseils et des techniques pour identifier et résoudre les problèmes avant le déploiement, y compris la gestion des dépendances, les tests et la surveillance. Il couvre des sujets tels que l’optimisation des performances, l’évolutivité, la tolérance aux pannes, la surveillance et la journalisation, en se concentrant sur la construction de logiciels qui peuvent survivre aux rigueurs de la production. En suivant les lignes directrices du livre, les développeurs de logiciels peuvent créer des systèmes fiables et résilients qui répondent aux exigences de leurs utilisateurs et de leurs clients. Dans l’ensemble, ce livre est une ressource essentielle pour les développeurs qui cherchent à améliorer la qualité et les performances de leurs logiciels dans l’environnement de production.
