À proposExpertiseRéalisationsR&DBlogOutilsCommencerContact

Les trois décisions à prendre avant de partir vers Azure

La plupart des projets cloud n'échouent pas sur la technologie. Ils échouent parce qu'on a commencé à construire avant de décider trois choses.

pH7x Systems® · · 2 min de lecture

Aller vers Azure est facile. N'importe qui, avec une carte bancaire, y crée une machine virtuelle en dix minutes. C'est ainsi que beaucoup d'organisations y arrivent sans peine et se retrouvent, deux ans plus tard, avec une facture que personne ne sait expliquer et une architecture que personne ne peut changer.

Le problème n'est jamais Azure. C'est d'avoir commencé à construire avant d'avoir décidé trois choses.

1. L'identité, avant tout

L'identité n'est pas un détail de configuration. C'est la fondation. Tout ce qui vient ensuite (permissions, accès conditionnel, automatisation, coûts par équipe) repose sur la façon dont les identités ont été organisées le premier mois.

Repousser cette décision ne la fait pas disparaître. Elle est alors prise par défaut, par celui qui crée la ressource suivante. Et défaire une structure d'identité mal bâtie, deux ans plus tard, avec des systèmes de production posés dessus, est la tâche la plus ingrate qui soit.

2. Comment les coûts vont être lus

« Combien cela nous coûte-t-il ? » est la question que posera la direction financière, et elle la posera à la fin du premier trimestre.

Sans étiquettes, sans groupes de ressources porteurs de sens et sans convention de nommage, la réponse est un long tableau dans lequel personne ne distingue la production du test que quelqu'un a laissé tourner en novembre.

Cela se décide avant la création de la première ressource, car revenir ensuite étiqueter des centaines de ressources est un projet à part entière, et c'est un projet que personne n'approuve.

3. Ce qui n'ira pas dans le cloud

C'est la décision que l'on prend rarement de façon explicite, et c'est celle qui permet d'économiser le plus d'argent.

Tout n'a pas vocation à migrer. Certains systèmes sont en fin de vie : il faut les éteindre, non les déplacer. Certaines charges de travail ont un profil d'usage qui rend le cloud plus cher que le serveur déjà payé. Certaines données restent là où elles sont, pour des raisons réglementaires.

Une migration qui déplace tout sans discernement n'est pas une migration. C'est un déménagement où l'on emballe les ordures pour les emporter avec soi.

Le schéma qui se répète

Ces trois décisions ont un point commun : elles coûtent toutes moins cher à prendre qu'à corriger. Elles coûtent des semaines au début, et des années à la fin.

Nous l'avons appris dans des environnements réglementés, dans la banque et dans le secteur public, où une décision reportée se voit vite. Mais ce n'est pas une question de secteur : une décision reportée finit toujours par se voir.

De la méthode au départ. Pas des suppositions à l'arrivée.

Commentaires

Poursuivre la lecture