Ce que l'interface web de Proxmox fait bien, et où vous finissez par ouvrir un deuxième écran

Cela vaut la peine de le dire clairement, parce qu'on suppose souvent le contraire : l'interface web de Proxmox est bonne. Elle expose presque tout ce que le système sait faire, elle ne cache pas l'état derrière des résumés aimables, et elle ne vous ment pas. Beaucoup de gens font tourner des infrastructures sérieuses sans rien d'autre, et ils ne se contentent pas d'un pis-aller.

Être juste là-dessus n'est pas de la politesse. Si vous ne savez pas dire ce qu'un outil fait bien, vous ne saurez probablement pas dire précisément où il est inconfortable, et c'est la seconde phrase qui sert.

Ce qu'elle fait bien

Elle est complète. Presque chaque capacité a sa place dans l'interface. Il n'y a pas un grand ensemble de choses qui ne passent que par l'édition d'un fichier, ce qui est plus rare qu'il n'y paraît dans cette catégorie.

Elle ne fait pas semblant. Quand une valeur est inconnue, elle a l'air inconnue. Quand une tâche échoue, l'échec est visible avec sa sortie. Les interfaces qui lissent tout cela sont agréables jusqu'au moment où vous avez besoin de la vérité.

Elle épouse de près le système en dessous. Ce que vous voyez correspond à des objets réels, donc ce que vous apprenez dans l'interface se transfère vers la ligne de commande et inversement. Les outils qui inventent leur propre abstraction vous apprennent l'outil au lieu du système.

Elle est rapide et toujours là. Aucun agent à installer, aucun service supplémentaire à maintenir en vie, rien de second qui puisse casser.

Où se trouve vraiment la friction

Pas sur un écran donné. Dans les questions dont la réponse est répartie sur plusieurs.

Demandez : « si ce disque lâche cette nuit, quelles machines tombent ? » L'interface sait répondre. Vous ouvrez le stockage, notez ce qu'il porte, ouvrez chaque machine, vérifiez ses disques, et gardez le résultat intermédiaire en tête. Quatre écrans et une jointure mentale, et vous recommencez la fois suivante.

Demandez : « par quel pont cette machine atteint-elle réellement l'extérieur ? » Même forme. Machine, pont, port physique, et la jointure se fait dans votre mémoire.

Demandez : « qu'est-ce que cette modification va toucher avant que je l'applique ? » Ici l'interface ne peut aider qu'en partie, car la réponse n'est stockée nulle part : il faut la dériver en parcourant les relations vers l'avant.

Ce ne sont pas des manques de fonctionnalités. Chaque fait nécessaire est présent et correct. Le coût est dans l'assemblage, et il se paie chaque fois que la question est posée, pas une fois pour toutes.

Pourquoi ce coût est invisible, jusqu'à ce qu'il ne le soit plus

Un après-midi tranquille, ouvrir quatre écrans n'est pas un fardeau. Cela ressemble à de l'administration normale, parce que c'en est.

Cela devient cher dans exactement deux situations. Pendant un incident, quand la jointure se fait sous pression et qu'une mauvaise jointure produit une réponse fausse et assurée. Et sur un système inconnu, où vous ne savez pas encore quelles relations existent, donc vous ignorez ce que vous avez omis de vérifier.

C'est pourquoi ceux qui exploitent un serveur depuis des années ne rapportent souvent aucune friction, et ceux qui en ont hérité d'un la semaine dernière en rapportent beaucoup. Les deux décrivent la même interface avec exactitude.

Ce qu'une seconde couche ne doit pas faire

Elle ne doit pas remplacer la première. L'interface native reste la référence de ce que le système pense réellement. Tout ce qui la contredit est faux par définition, et une seconde couche qui vous encourage à ne plus y regarder est un risque.

Elle ne doit pas inventer son propre modèle. Si une seconde couche vous enseigne des concepts qui n'existent pas dans Proxmox, vous entretenez désormais une traduction dans votre tête, et les traductions dérivent.

Elle ne doit pas masquer les échecs. Une couche qui annonce le succès plus volontiers que le système en dessous est pire que pas de couche du tout.

La façon honnête de décider

Ne demandez pas quelle interface est meilleure. Demandez quelles questions vous posez le plus souvent, et si leurs réponses vivent sur un écran ou sur quatre.

Si vos questions régulières portent sur un seul objet, démarrer cette machine, agrandir ce disque, vérifier cette sauvegarde, l'interface native y répond directement et une seconde couche ajoute une étape pour rien.

Si vos questions régulières sont des questions de relations, de quoi cela dépend-il, qu'est-ce que cela va toucher, où cela tourne-t-il vraiment, ce sont celles qui vous coûtent à chaque fois, et c'est la seule raison honnête d'ajouter quoi que ce soit.

Ce que fait Atlas

Atlas tourne à côté de l'interface Proxmox, pas à sa place, et vise exactement les questions de relations ci-dessus.

La chaîne de ressources est dessinée d'une machine jusqu'au disque physique, et la chaîne réseau d'une machine jusqu'au port physique, si bien que la jointure qui se faisait dans votre tête se fait à l'écran. C'est toute la différence : mêmes faits, assemblés une fois et gardés assemblés.

Avant qu'une modification ne s'exécute, les ressources qu'elle touchera sont listées, ce qui transforme la troisième question en quelque chose qui se lit au lieu de se déduire.

Et il reflète Proxmox au lieu de remplacer son modèle : utilisateurs, rôles, groupes et jetons d'API sont ceux de Proxmox, les permissions sont demandées à Proxmox à la connexion, et Atlas ne construit aucun concept parallèle à garder synchronisé. Ce que vous apprenez ici reste vrai là-bas.