Vous êtes un tout nouveau DSI. Il est 9h00 un mercredi et vous êtes en situation d’urgence lors d’une réunion Zoom avec les responsables des opérations informatiques. Les visages à l’écran sont sombres, et on comprend pourquoi lorsqu’ils expliquent le but de la réunion.
Il semble que toutes les opérations informatiques, qui étaient initialement budgétées à 10 millions de dollars pour cet exercice, sont jetons maintenant un coup d’œil à un dépassement de 4 millions de dollars dû aux dépenses inattendues en personnel d’exploitation et en outils nécessaires pour exécuter le tout nouveau lot d’applications et de bases de données qui ont simplement été transférées vers un cloud public.
Que s’est-il passé ? Il est fort probable qu’ils se soient heurtés à un « mur de cloudops », suggérant que le coût des systèmes d’exploitation dans le cloud a été ignoré de 20 % à 30 %. Ils ont supposé que, dans la majorité des cas, le coût d’exploitation des mêmes systèmes dans le cloud serait de 10 % de plus que sur site. Le marché leur a dit que les coûts d’exploitation seraient probablement réduits.
La vérité est que certaines choses se produisent aujourd’hui.
Au départ, la pandémie a fait pression beaucoup d’entreprises à déplacer leur prochaine tranche de systèmes vers le cloud – des systèmes empêchés au début étant donné qu’ils étaient plus complexes et pas trop développés. De plus, ces systèmes s’engagent dans de nouvelles méthodes, telles qu’une base de données basée sur le cloud prenant désormais en charge les données d’un centre d’information conventionnel plutôt que celles résidant exactement dans le même centre de données.
Deuxièmement, étant donné qu’il existe un « besoin de rapidité » dans la délocalisation vers le cloud, de nombreuses actions pragmatiques ont été compressées ou ignorées. La refactorisation des applications pour tirer parti des services natifs du cloud ou la conteneurisation de quelques-uns des systèmes mobiles a en fait été repoussée, optant pour des procédures de levage et de déplacement moins chères et beaucoup plus rapides qui sont sous-optimisées.
Enfin, et essentiel, personne dans l’entreprise n’a encore fait de cloudops pour ce type de systèmes. Par exemple, le déplacement de systèmes basés sur un mainframe vers un cloud public est très différent du déplacement de piles LAMP (Linux, Apache, MySQL et PHP), qui sont plus modernes. Ce manque de capacités transforme une grande partie de la planification en incertitude. Cette fois, ils se sont trompés de 20% à 30%.
Il existe plusieurs méthodes pour réparer le mur cloudops que les entreprises frappent actuellement.
Premièrement, il faut se concentrer davantage sur la refactorisation ou la réparation des systèmes lors de leur migration vers le cloud. Je dis souvent : « La merde dans les locaux déplacés vers le cloud est juste de la merde dans le cloud ». Les systèmes dont l’exploitation est de plus en plus compliquée et coûteuse dans le cloud doivent être réparés ou améliorés au fur et à mesure que vous les déplacez.
C’est un calcul simple pour moi. Si vous ignorez l’amélioration des systèmes, vous devez alors prévoir davantage pour les cloudops. Ou améliorez les systèmes au fur et à mesure qu’ils migrent, comme la refactorisation vers des services cloud natifs, et bénéficiez d’améliorations cloudops et ainsi de réduire les dépenses. C’est un compromis clair.
Deuxièmement, profitez des outils cloudops idéaux pour vous assurer que toutes les opérations pouvant être automatisées sont automatisées. La majorité de ceux qui ont atteint un mur cloudops ont sous-optimisé l’automatisation des opérations. Ils poursuivent leurs pratiques opérationnelles sur site vers le cloud et finissent par adapter des procédures et des outils actuellement inefficaces à des systèmes qui sont devenus plus complexes.
Le problème avec le mur cloudops est que les entreprises ne comprennent pas pourquoi ils le frappent. Il ne s’agit pas de systèmes dans le cloud plus coûteux à exploiter qu’on ne le pensait à l’origine. Cela est dû à un manque de planification et à une absence de détermination à améliorer les systèmes avant de passer au cloud. Il s’agit également de comprendre comment tirer parti des outils cloudops appropriés de la bonne manière.
C’est peut-être un autre exemple de paiement immédiat par rapport à un paiement beaucoup plus élevé plus tard. J’ai trouvé que le premier est toujours une meilleure option sur la planète du cloud computing.
Toute l’actualité en temps réel, est sur L’Entrepreneur
