Les 5 erreurs du cloud d'avant à ne pas reproduire dans le cloud d'après


Publié le: 12 juin 2020 par Atos

Google Cloud, AWS et Azure affichent malgré la crise des croissances jusqu’à 52% sur le premier trimestre 2020. Depuis la mi-mars, le cloud public a séduit les entreprises pour apporter de la souplesse et des garanties de service en période de pandémie.  A présent que nombre d’entre elles vont être à la recherche de solutions pour amortir l’impact économique du confinement, c’est la promesse de réaliser des économies substantielles qui pourrait continuer d’accroître la demande. Mais pour que celle-ci se réalise, encore faut-il se garder de quelques faux-pas courants et éviter ainsi de rejoindre le camp des déçus du cloud.

 

La conversion sans conviction

Nombre de DSI n’ont pas tant choisi le cloud que répondu à la volonté de modernisation de leur direction générale ou à la prolifération de « l’informatique grise » (Shadow IT) développée à leur insu par les utilisateurs. Purement défensive et dénuée de conviction, la démarche se traduit alors par des plans de transformation timides, incomplets et/ou trop lents. On n’ose pas basculer complètement et réduire la taille de ses data centers, ou les fermer. On entretient deux infrastructures en parallèle, ce qui alourdit naturellement les coûts au lieu de les réduire. Et l’on est de moins en moins capable de susciter autour du cloud l’adhésion et la dynamique qui sont indispensables à sa généralisation. Cette conversion trop lente a fait nombre de malheureux pendant le confinement, obligeant parfois les employés à adapter leur rythme de travail à celui des ressources disponibles dans le datacenter, alors qu’on s’attend à ce que ce soit l’inverse qui prime.

Le retour de la vengeance du data center

Même chez ceux qui sont persuadés du bien-fondé du cloud public, les réflexes ont la vie dure. Toute leur carrière, les responsables d’infrastructures ont bâti des data centers avec la crainte de se tromper. Dans une installation prévue pour un minimum de dix ans, qui accueillera des applications critiques, exigeantes en termes de capacités et de sécurité, ils savent que tout doit être au top dès le départ. Et ils reproduisent trop souvent ce schéma dans le cloud, dont ils surdimensionnent d’emblée l'ossature. Précaution aussi superflue que coûteuse puisque le cloud permet de grandir, de s’adapter progressivement aux besoins et même – ô joie ! – de se tromper. Aux grands plans à long terme, on privilégiera donc une croissance organique et itérative de l’infrastructure cloud en utilisant au maximum les outils natifs des opérateurs que l’on renforcera le cas échéant.

L’open bar pour les développeurs

Ce qui ne veut pas dire qu’il ne faut pas de cadre ! Les développeurs sont friands d’innovations, et ne pas leur poser de limites reviendrait à prendre le risque que chacun pioche à sa guise dans le catalogue de services prolifique des cloud providers. Il en résulterait un environnement que son hétérogénéité et sa complexité rendraient inexploitable. Même si une partie de la tâche est dévolue aux opérateurs du cloud, standardisation, rationalisation et mutualisation sont toujours de rigueur. Pour fixer ce cadre, le plus simple et le plus économique est l’approche dite du « lift & shift », qui consiste à transposer telles quelles dans le cloud les applications existantes. Les coûts peuvent alors diminuer de 10 % à 30 %. Le refactoring, qui consiste à redévelopper une application pour qu’elle tire mieux parti de l’élasticité du cloud, offre des bénéfices supérieurs – de 40 % à 60 % à terme –, mais son coût (redéveloppement, duplication de l’infrastructure le temps du projet…) n’est pas négligeable. Mieux vaut donc migrer, en recueillir les fruits (fermeture des salles, licences de sauvegarde…), et redévelopper ensuite si cela se justifie.

Un oubli nommé FinOps

À l’opposé du pilotage financier traditionnel, proactif et fondé sur des prévisions et des budgets, le cloud demande d’être réactif : pour optimiser les coûts, il faut en permanence s’ajuster aux besoins réels. Ceci exige d’établir une collaboration étroite entre la finance et la technique pour établir des règles de gestion dynamiques, pragmatiques et réactualisées au gré de l’évolution des usages. C’est le rôle des FinOps d’instaurer ce dialogue, notamment via l’analyse des consommations et la tenue de comités réguliers. Or, la mise en place de ce rouage essentiel, pourtant simple, est souvent différée. La consommation n’étant pas surveillée dès le départ, les dérives s’accumulent et, au bout de quelques mois, des centaines d’instances « zombies », qui tournent sans que l’on sache ce qu’elles font, ni pourquoi, peuvent dévorer tous les gains escomptés. Une stratégie de relance post confinement ferait donc bien d’intégrer cette dimension d’emblée car il est ensuite très difficile de revenir en arrière ! On choisira pour ça une personne issue de la technique avec une bonne compréhension des modes de facturation des fournisseurs de cloud qui fera un parfait interlocuteur pour les achats et les métiers.

Une transformation incomplète

En atomisant les ressources, le cloud change la structure même du système d’information, donc la façon dont chacun interagit avec lui. Cependant, rares sont les entreprises où les fonctions non techniques ont été sensibilisées à cette révolution. Il y aurait pourtant beaucoup à gagner à ce que la finance sache intégrer la variabilité des coûts du cloud, à ce que les achats puissent gérer ses modèles d’abonnement, et à ce que les métiers prennent conscience des économies considérables qu’ils peuvent désormais réaliser, par exemple en éteignant les machines superflues le soir et le week-end (jusqu’à 60 %) ou en optant pour une disponibilité de 99 % plutôt que 99,9 % pour leurs applications non critiques (-60 % également). Pour porter pleinement ses fruits, toute stratégie cloud implique donc une connaissance précise de ses besoins et de sa propre culture d’entreprise.

Partager


Qui est Atos

Partenaire de Confiance de votre Transformation Digitale


Suivre ou contacter Groupe