Contrairement à ce que tu penses, cela m’intéresse de comprendre pourquoi on a arrive à des architectures logicielles compliquées pour des résultats catastrophiques sans que personne ne se remette en question (d'où les quelques exemples cités).
Peut-être parce que l'informatique ce n'est pas qu'une unique question de logiciels justement ? Mais d'infrastructure, d'organisation, etc. - et que c'est l'architecture globale autour d'un besoin et du possible qui importe.
Un exemple qui me vient : la mise en place d'un bastion d'administration (je pense par exemple aux contraintes des normes voulues dans les OIV... mais ça semble se généraliser grâce à l'action de l'ANSSI) dans une "vieille" architecture, figée et difficile à bouger, comme on en trouve beaucoup dans les PME françaises : l'éditeur peut ne plus exister ; les sources non-documentées ; les personnes qui ont pensé certaines parties ou certaines organisations des traitements ne sont plus là: ce qu'elles ont pu faire avait peut-être du sens à leur époque, ...
Face au décideur, bon courage si tu penses seulement "logiciel" comme un tout unique et cohérent dans ta réponse, qui évolue forcément bien et uniformément.
Car il y a le logiciel, mais aussi le réseau à gérer. Les traitements métiers, qui ont pu évolué, qui peuvent être en partie analogiques voire physiques. Du SCADA. Certains applicatifs ne supportent pas tel ou tel protocole (pas de TLS/SSL, etc.). Il faut des proxy partout, des routes à ne plus en finir, être capable de faire dialoguer des choses qui n'ont pas été forcément prévues pour communiquer vers l'extérieur.
Rajouter les contraintes de redondance, de sécurité, logger pour motifs légaux. C'est une réalité. Pas juste un discours de "marketeux". Et avant de parler de la seule performance, on parle de viabilité, d'intérêts, de conditions préalables.
Bref tu te retrouves avec une évolution "organique" d'un logiciel ou d'un ensemble applicatif, qui peut être monolithique ou pas, avec des blocs qui ont été faits à des périodes différentes, des besoins différents - dont un contexte qui évolue.
Tu pars du principe que forcément personne ne remet en question une "mauvaise" architecture. Je ne crois pas que ça soit blanc ou noir. Tu peux être conscient d'une situation et devoir gérer une basse réalité qui soit complexe à gérer et faire évoluer.
ça augmente la complexité de ton application, elle fait pleins de choses différentes ça multiplie les droits que tu va devoir lui donner et rends son observation plus compliquée
+1 : un "cache" (amélioré) peut servir aussi à vérifier les droits, servir d'intermédiation au sens large, accélérer un accès, etc. Ou comme indiqué juste avant, servir d'agent nécessaire pour la mise en place d'un bastion d'administration qui ceinture un applicatif pas nécessaire sûr ou éditable, pour faire remonter des informations sur le fonctionnement de l'ensemble.
tu peux vouloir que ton cache survive à un redémarrage de ton applicatif
Voire dans certains cas, c'est même plus ou moins lui qui sera le co-pilote, si tu as du batch processing qui peut planter, se séquencer sans lien entre les opérations, etc. Le cache devient la clé de voûte, évolue et sert à maintenir des connexions à des bases de données, à alerter sur une situation anormale autant qu'à faire réellement du cache de requêtes.
Est ce que qu'on parle toujours informatique avec quelque chose d'aussi flou que :
"pleins de contexte différents qui amènent à des solutions différentes et donc des solutions différentes"
[^] # Re: Formatage automatique
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 1.
Peut-être parce que l'informatique ce n'est pas qu'une unique question de logiciels justement ? Mais d'infrastructure, d'organisation, etc. - et que c'est l'architecture globale autour d'un besoin et du possible qui importe.
Un exemple qui me vient : la mise en place d'un bastion d'administration (je pense par exemple aux contraintes des normes voulues dans les OIV... mais ça semble se généraliser grâce à l'action de l'ANSSI) dans une "vieille" architecture, figée et difficile à bouger, comme on en trouve beaucoup dans les PME françaises : l'éditeur peut ne plus exister ; les sources non-documentées ; les personnes qui ont pensé certaines parties ou certaines organisations des traitements ne sont plus là: ce qu'elles ont pu faire avait peut-être du sens à leur époque, ...
Face au décideur, bon courage si tu penses seulement "logiciel" comme un tout unique et cohérent dans ta réponse, qui évolue forcément bien et uniformément.
Car il y a le logiciel, mais aussi le réseau à gérer. Les traitements métiers, qui ont pu évolué, qui peuvent être en partie analogiques voire physiques. Du SCADA. Certains applicatifs ne supportent pas tel ou tel protocole (pas de TLS/SSL, etc.). Il faut des proxy partout, des routes à ne plus en finir, être capable de faire dialoguer des choses qui n'ont pas été forcément prévues pour communiquer vers l'extérieur.
Rajouter les contraintes de redondance, de sécurité, logger pour motifs légaux. C'est une réalité. Pas juste un discours de "marketeux". Et avant de parler de la seule performance, on parle de viabilité, d'intérêts, de conditions préalables.
Bref tu te retrouves avec une évolution "organique" d'un logiciel ou d'un ensemble applicatif, qui peut être monolithique ou pas, avec des blocs qui ont été faits à des périodes différentes, des besoins différents - dont un contexte qui évolue.
Tu pars du principe que forcément personne ne remet en question une "mauvaise" architecture. Je ne crois pas que ça soit blanc ou noir. Tu peux être conscient d'une situation et devoir gérer une basse réalité qui soit complexe à gérer et faire évoluer.
+1 : un "cache" (amélioré) peut servir aussi à vérifier les droits, servir d'intermédiation au sens large, accélérer un accès, etc. Ou comme indiqué juste avant, servir d'agent nécessaire pour la mise en place d'un bastion d'administration qui ceinture un applicatif pas nécessaire sûr ou éditable, pour faire remonter des informations sur le fonctionnement de l'ensemble.
Voire dans certains cas, c'est même plus ou moins lui qui sera le co-pilote, si tu as du batch processing qui peut planter, se séquencer sans lien entre les opérations, etc. Le cache devient la clé de voûte, évolue et sert à maintenir des connexions à des bases de données, à alerter sur une situation anormale autant qu'à faire réellement du cache de requêtes.
Oui, mille fois oui.