Je discutais avec un ami consultant il y a quelques semaines. Son rôle principal actuellement est de travailler sur des projets de migration de bases de données SQL Server vers le cloud (AWS et Azure) et en masse. Son histoire me rappelle les projets il y a des années sur des projets P2V où la mémoire physique et les cœurs pourraient simplement être mappés à la mémoire virtuelle et aux cœurs virtuels, puis donner à l'administrateur VMWare la tâche de revoir cela en fonction de la consommation, sinon les avantages de la virtualisation étaient annulés.
Eh bien, avec les migrations vers le cloud, la même méthodologie est encore trop souvent appliquée pour la simplicité et la rapidité, mais le choc survient lorsque les factures d'abonnement au cloud arrivent. Cela peut à nouveau être un gaspillage d'argent évitable, dans ce cas, opex par opposition à capex .
Pour une raison quelconque, les propriétaires de projet hésitent souvent à examiner à l'avance l'utilisation, la consommation et les performances actuelles et à prévoir avec précision le dimensionnement requis pour la migration vers le cloud. Le problème avec la résolution du problème après la migration est qu'il y a plus de risques, plus de lutte contre les incendies et à quelle vitesse pouvez-vous le faire alors que les factures continuent d'arriver chaque mois.
J'ai donc hâte d'entendre ce que Denis O'Sullivan et Peter O'Connell ont à dire le 14 avril avec leur webémission en direct :Dimensionnement et mise à l'échelle précis de votre base de données cloud.
