TOP 5 des erreurs d’une migration vers le Cloud

Chez SoftwareOne, de nombreux clients sont actuellement en train de faire la transition vers le Cloud au sein de leurs organisations. Chaque semaine, j'échange avec des responsables informatiques seniors qui peaufinent leurs stratégies, et je repère cinq erreurs fréquentes lors de l'adoption du Cloud public.

1. Le passage au Cloud est souvent considéré comme un substitut au centre de données

Certains dirigeants avec lesquels je discute ont une vision trop centrée sur l'infrastructure lorsqu'il s'agit du Cloud. Dans ces cas, l'approche consiste souvent à migrer rapidement. Cependant, cela implique d'ignorer les problèmes liés aux migrations Cloud non optimisées et aux projets qui n'apportent que peu ou pas de valeur commerciale.

Un ensemble d'applications a été transféré en justifiant cela par le fait que "nous avons déjà payé". Bien que les applications restent généralement inchangées, le scénario optimal, après plusieurs mois d'investissement dans le Cloud, serait que les applications migrées fonctionnent exactement comme avant. Cependant, peu des avantages vantés du Cloud se concrétisent, et les applications demeurent essentiellement les mêmes qu'à l'origine.

2. Prioriser la technologie plutôt que les performances commerciales

Certains clients privilégient la migration d'applications en se basant sur des considérations techniques plutôt que sur l'impact commercial maximal. Bien que cette approche simplifie le processus et confère davantage d'agilité au département informatique lors de la transition, elle risque de ne pas pleinement répondre aux attentes de l’organisation.

Les dirigeants nourrissent de grandes attentes quant aux bénéfices que le Cloud peut offrir, souvent influencés par le marketing des hyperscalers. Toutefois, se tourner vers le Cloud et maintenir une expérience similaire à des coûts comparables pourrait ne pas suffire. Ceci devient particulièrement critique si le processus de migration mobilise de nombreuses ressources informatiques, affecte les services habituels ou entraîne le report d'autres projets stratégiques.

3. Évitez les hypothèses non vérifiées

De nombreuses organisations se basent sur des hypothèses internes concernant la faisabilité technique, la cohérence architecturale, la qualité du code, et les capacités de refactoring. Après tout, qui souhaite abandonner un code qui fonctionne ? Cependant, faire des hypothèses dès le début de la planification peut parfois entraîner des surprises. Il est étonnant de voir que de nombreuses migrations vers le Cloud sont planifiées sans une compréhension claire des changements nécessaires pour les applications ou de la faisabilité du refactoring pour certaines d'entre elles.

Même lorsqu'il s'agit de refactoring, les efforts peuvent varier. Refactoriser une application pour la faire fonctionner sur une plateforme en tant que service (PaaS) ou pour résoudre des problèmes de sécurité n'est pas la même chose que la repenser entièrement en utilisant des approches basées sur les microservices. Pour bien comprendre ce que vous avez et les défis de la migration, la meilleure approche est d'utiliser des outils automatisés de découverte et d'inspection, en plus des méthodes standards de l'industrie.

4. Stratégies Cloud déconnectées entre le développement et l'exploitation

Lorsqu'on passe au Cloud, les responsables informatiques se concentrent sur le remplacement des centres de données et les économies d'infrastructure, tandis que les équipes de développement se penchent sur la productivité et les nouvelles capacités des applications. Il est crucial que ces groupes collaborent pour surmonter les défis souvent négligés de l'adoption du Cloud, comme le fonctionnement des sauvegardes, l'extension de la sécurité au Cloud et le choix d'un bon modèle de gouvernance.

5. Une approche traditionnelle des coûts

Lorsque nous assistons nos clients dans l'élaboration d'arguments commerciaux liés au Cloud et comparons les workloads sur le Cloud et sur site, nous constatons souvent un manque d'expertise FinOps pour gérer des scénarios de coûts dans un environnement multicloud.

Par exemple, si vous envisagez d'acquérir une licence de base de données ou tout autre logiciel spécifique, vous pouvez le faire soit directement sur les places de marché Cloud, soit via des contrats logiciels traditionnels avec des droits hybrides pour une utilisation sur site et dans le Cloud. Cependant, fonder votre argument commercial sur l'idée que le logiciel sera obtenu dans le Cloud sous forme d'une solution SaaS (ce qui peut sembler raisonnable pour un architecte) est tout simplement une façon peu judicieuse d'estimer les coûts. En réalité, nous avons souvent constaté que l'argument commercial ne tient pas dans le Cloud, car les coûts logiciels sont fréquemment surestimés ou mal optimisés. Cette situation se reproduit également dans l'infrastructure Cloud, où les contrats à long terme améliorent régulièrement les coûts unitaires.