asega
commented
1 year ago Ce qui était vrai hier ne l'est pas forcément aujourd'hui.
Je ne pense pas non plus qu'on puisse éviter la dette technique, y'en aura toujours, surtout si tu bosses sur un projet "greenfield".
Si t'en as pas, ton projet est sûrement pas si ambitieux que ça mais c'est pas le sujet.
Je ne pense pas non plus que la dette technique soit crée en ayant des ingénieurs qui n'ont pas le niveau ou par le manque d'architectes et spécialistes sécurité.
Parce qu'il y'aura toujours de la dette technique, le but c'est pas de l'éviter mais de la gérer: éviter qu'elle soit grosse, éviter qu'elle explose.
Aujourd'hui en 2023 nous avons des retours d'expérience; au niveau infrastructure comment bâtir dans le cloud; sur AWS cela nous donne par exemple le Well-Architected Framework. OpenStack et OpenShift ont les mêmes documentations léchées. Les suivre, permet de rester dans les clous. Après j'avoue, avoir de l’expérience permet d'en faire une meilleure interprétation. [1]
Pour des questions budgétaires beaucoup ne peuvent se payer à temps plein des architectes ou experts sécurité. Je dirais qu'un bon compromis aujourd'hui serait de lire ces documents, bâtir et avoir ces pros quelques jours par moi arranger le boulot.
Aujourd'hui nous avons aussi des frameworks qui permettent de re-factoriser un produit dans des temps corrects; dernièrement j'ai été dans un magasin, les mecs ont reconstruist en quelques semaines une appli vieillissante écrite en PHP (aucune critique) en maintenant les specs originales et en la rendant modulaire.
Donc non, je ne crois pas que ce soit lié au gens ou aux choix techniques. D'ailleurs qu'est-ce qu'un bon choix technique?
Hier on pouvait dire je maîtrise X donc je peux garantir que c'est un bon outil pour le produit. Personnellement, de nos jours, je trouve bien présomptueux les consultants qui disent je maîtrise X techno liées au cloud car elles sont super vaste et aujourd'hui tout avance très vite.
En 2015 c'était un pari insouciant de faire du kubernetes, aujourd'hui t'as vu le nombre d'applis cloud native (intègres à la fondation) qui tournent et qu'ont moins de deux ans de vie ? Un autre exemple: terraform pour moi a toujours été une connerie et tout le monde le sait, mais on avait que ça à l'époque. Aujourd'hui je partirai sur des choses comme pulumi ou le C.D.K d'AWS (impératif hein) ca plus de sens: la phase d'apprentissage est bien plus courte et créer des infrastructures ésotériques bien plus aisé. [2]
Dans la même veine:
- est ce que kubernetes est un bon choix ? Par le passé j'ai vu des équipes revenir vers des instances ou bouger vers ECS ou similaire
- aujourd'hui aussi les gens y réfléchissent à deux fois lorsqu'on parle de micro services, c'est plus la balle magique.
Pour moi la dette technique est crée lorsqu'un projet est mal géré, lorsque on ne suit pas les principes de base du DevOps. Rappelle toi, le handbook nous dit qu'il tourne autour de 3 axes: Flow, Feedback et Continuous Learning & Experimentation.
A mon avis si on ne prends pas le temps de remettre dans le produit ce qu'on a appris au cours de son exploitation et développement (i.e Feedback) , si on ne prends pas le temps d'améliorer le produit via les expériences annexes que nous faisons (aussi avoir du temps dédié pour en faire, ie 'Continuous Learning & Experimentation') , et bien on crée de la dette technique.
Je suis plutôt tiède au niveau des recommandations, tu peux avoir écrit des tests qui passent mais si la fonction ne se comporte pas comme elle devrait le faire, ça ne change rien. Tes recommandations permettent de recevoir du feedback/eviter la casse mais elles ne permettent pas de re-investir dans le produit ou réellement éviter la dette (a part la doc et usine a gaz).
[1] Oui, avoir de l'expérience change les choses du tout au tout, je ne pense pas du tout que lire le WAF est la panacée et fait du lecteur un architecte cloud (quoique), l'expérience permet d'avoir une vision, de faire des choix cohérents en temps de crise et des Paris gagnants.
[2] Pour le lecteur: j'ai travaillé pour des compagnies, pour des raisons politiques, se devait de limiter certaines fonctionnalités, d'avoir une flotte d'instances agrandies ou limitées et bien qu'on parte d'une base commune c'était hardu de faire ça sous TF. Même avec la pattern des terra services, on l'a fait mais c'était sale.
stephrobert
Devops - Gestion de la dette technique de l'infra as code
Trop souvent mis de coté au nom de l'agilité, la gestion de la dette technique setraite dés le démarrage d'un projet.
https://blog.stephane-robert.info/post/devops-dette-technique/