Mythes et réalités du cloud ou comment démythifier sept idées fausses sur le cloud

Il est très facile de se focaliser sur le remplacement des activités informatiques clés, à l’accès à l’infrastructure à la demande, aux services de calcul, de stockage et de base de données fournis, etc., en oubliant que la migration vers le cloud a un

impact plus large sur la transformation du modèle d’exploitation informatique complet et, surtout, sur l’entreprise. Par conséquent, lorsqu’ils entreprennent de rédiger un dossier commercial, les décideurs passent des mois à analyser les coûts sur site par rapport aux coûts du cloud et consacrent beaucoup moins de temps au principal moteur de valeur du cloud : les bénéfices commerciaux. La réalité est que l’agrégation des avantages commerciaux peut largement justifier les coûts informatiques dans le cloud.

L’économie du cloud est l’une des questions actuelles les plus controversées dans le domaine de l’informatique d’entreprise. La réalité est complexe, car le coût dépend fortement du point de départ de l’entreprise - et de sa capacité à gérer et à optimiser la consommation du cloud. Une grande compagnie d’assurance a constaté que, grâce à une combinaison de réorientation et d’approvisionnement, elle a pu améliorer la rentabilité des coûts unitaires dans son environnement privé, rendant ainsi une migration vers le cloud moins attrayante.

Les autres différences au départ constatées par les experts de McKinsey sont la maturité des entreprises en ce qui concerne le cycle de vie sur site, les engagements en matière de licences et les types de charges de travail. Les entreprises confrontées à d’importantes mises à niveau de leurs centres de données, par exemple, trouveront l’adoption du cloud attrayante comme moyen d’éviter d’importantes dépenses en capital pour des actifs qu’elles pourraient ne pas utiliser pleinement pendant des années et qui risquent d’être dépréciés plus rapidement que par le passé.

Par conséquent, la question essentielle pour l’économie du cloud est de savoir si la réduction du coût d’exploitation du cloud justifie le coût initial de la remédiation, en supposant que toute la configuration et la gouvernance soient faites correctement.

Historiquement, les dirigeants ont cité la sécurité de l’infrastructure du cloud public comme l’une de leurs principales préoccupations et un obstacle à l’adoption du cloud. Cependant, ces dernières années, tous les grands CSP ont réalisé des investissements importants dans leurs capacités de sécurité sous-jacentes. Leur modèle économique dépend de la sécurité, et chacun a investi des milliards dans la sécurité du cloud et a engagé des milliers de cyberexperts de haut niveau. Ils ont développé une série de nouveaux outils et de nouvelles méthodes pour sécuriser le cloud. Ceci est particulièrement important, car les violations du cloud public ont presque toutes été provoquées par des configurations non sécurisées des entreprises clientes. En fait, Gartner prévoit que, jusqu’en 2025, 99 % des défaillances de sécurité dans le cloud seront imputables au client et non au fournisseur du service.

La latence est souvent due au fait que le département informatique tente de faire transiter ses données par des centres de données internes. Le backhauling, ou le routage du trafic à travers les réseaux internes crée une latence plus élevée, une complexité supplémentaire et une mauvaise expérience utilisateur. Les services informatiques qui choisissent de faire du backhaul manquent généralement d’expérience ou de confiance dans la sécurité du cloud (pensant qu’ils auront un meilleur contrôle grâce au backhaul), ou doivent accéder à des données ou des applications critiques qui se trouvent dans des centres de données sur site.

L’idée de l’infrastructure en tant que service (IaaS), selon laquelle un fournisseur externe gère votre réseau, votre matériel et vos ressources sous-jacents, est une proposition intéressante pour de nombreux dirigeants d’organisations. L’idée fausse surgit cependant lorsque les dirigeants interprètent l’IaaS comme un remplacement complet de leur infrastructure interne. Si le cloud modifie radicalement les activités, les talents et le modèle d’exploitation requis dans un groupe d’infrastructure interne, et au-delà, il ne remplace pas totalement la nécessité de gérer sa propre infrastructure.

On pense souvent à tort qu’une organisation doit opter pour l’un de ces deux extrêmes pour réussir sa transition vers le cloud. Dans l’approche application par application, les organisations sont confrontées à une dynamique d’échelle peu attrayante. Elles continueront à payer pour les centres de données et l’assistance informatique sur site, tout en payant simultanément les CSP pour l’hébergement d’un sous-ensemble d’applications.

Le déplacement d’un sous-ensemble d’applications n’entraîne pas non plus de bénéfices commerciaux si ces applications ne constituent qu’une partie du portefeuille d’un domaine d’activité. Par exemple, si une entreprise déplace un ensemble d’applications du domaine d’accueil des clients vers le cloud, mais laisse derrière elle l’application qui génère et stocke les profils des utilisateurs, les avantages du cloud en termes de délai de commercialisation ne peuvent pas être pleinement réalisés. D’autre part, les entreprises qui déplacent un centre de données entier vers le cloud peuvent être confrontées à un investissement initial et à des risques importants. Parmi les centaines d’applications présentes dans un centre de données, beaucoup n’ont probablement pas été conçues pour fonctionner dans le cloud. Les entreprises devront donc investir dans diverses formes de remédiation, qui peuvent devenir coûteuses et risquées lorsqu’elles sont exécutées d’un seul coup.

Lorsque les entreprises s’engagent à passer au cloud, elles sont souvent confrontées à la pression d’agir rapidement, de minimiser les coûts et de maximiser les bénéfices commerciaux. En conséquence, les dirigeants estiment qu’ils doivent choisir entre une stratégie de transition plus rapide et moins coûteuse (pour aller plus vite et réduire les coûts) et une stratégie de remaniement longue et coûteuse (pour profiter des avantages commerciaux).

Bien que le fait d’agir rapidement, c’est-à-dire de virtualiser l’application et de la mettre dans le cloud tel quel, puisse être un moyen plus rapide et plus rentable de déplacer de nombreuses applications dans le cloud, il ne permet pas d’exploiter la majorité des avantages du cloud. En effet, l’architecture de l’application n’est pas modifiée et n’est souvent pas optimisée pour le cloud, ce qui fait qu’elle ne bénéficie pas de fonctions telles que la mise à l’échelle automatique, la gestion automatisée des performances, etc. En outre, l’application non native sera probablement à l’origine d’une latence plus élevée ou à d’autres problèmes de performances, et ses problèmes préexistants se situeront désormais simplement dans le centre de données d’un CSP plutôt que dans celui de l’entreprise.

D’autre part, une refonte complète de l’application et de son architecture pour l’optimiser pour le cloud prend beaucoup de temps, de compétences et d’argent. Elle permet d’obtenir des avantages, mais si lentement et à un coût si élevé que l’équilibre est souvent impossible. Cela augmente également le risque d’erreur lors de la transition lors du recodage, de la configuration et de l’intégration complexes. De nombreuses entreprises trouvent qu’il est préférable d’appliquer la stratégie du « meilleur des deux mondes », qui tire parti de techniques spécifiques telles que l’automatisation, l’abstraction et la conteneurisation.