Comment quantifier et qualifier les avantages de la migration vers le cloud

Il va de soi que l'avenir des entreprises repose sur le cloud. Cela est particulièrement vrai si l'on considère le rôle énorme que la migration vers le cloud a joué dans l'espace de l'entreprise au cours des dernières années :

Les dépenses consacrées au cloud computing ont augmenté à 4,5 fois le taux des dépenses informatiques depuis 2009 et devraient augmenter de plus de 6 fois jusqu'en 2020.

Tour d'horizon de l'informatique en nuage de Forbes

Ceci est corroboré par les dernières données d'Oracle, dont la deuxième prévision pour 2019 était que 80 % de toutes les charges de travail de l'entreprise, y compris celles considérées comme « critiques à la mission », migreront vers le cloud au cours des 12 prochains mois.

Malgré la quasi-omniprésence du cloud dans toute l'entreprise (et la familiarité croissante avec les technologies cloud pour les experts informatiques et les non-initiés), le déplacement des workflows dans le cloud n'est pas une tâche facile. Cela est particulièrement vrai lorsqu'il s'agit de gérer les attentes et d'apporter des améliorations, qu'elles soient liées aux coûts ou aux performances, une fois la migration terminée.

Pour s'assurer que les équipes ne font pas des promesses qu'elles ne peuvent pas tenir, elles ont besoin de visibilité à chaque étape de leur migration vers le cloud. Après tout, « vous ne pouvez pas gérer ce que vous ne pouvez pas mesurer, », dit le vieux mantra, et les équipes informatiques doivent donc avoir une visibilité à chaque étape de la migration afin de définir des attentes précises et de garder une longueur d'avance sur les problèmes avant qu'ils ne fassent dérailler toute l'entreprise.

Définir des objectifs de performances acceptables

Pour commencer, les équipes doivent comprendre parfaitement quelles applications, infrastructure réseau ou processus tombent en panne le plus souvent. Le service informatique devra probablement procéder à des entretiens interfonctionnels pour obtenir des informations et l'adhésion de l'ensemble de l'organisation.

Il peut être facile de plaider en faveur de la migration vers le cloud lorsque le service informatique pense en termes de généralités. Bien sûr, se décharger de la maintenance du matériel réseau semblera attrayant pour les décideurs soucieux de leur budget, mais quel investissement initial est nécessaire avant que l'entreprise puisse réaliser ces économies ?

Le coût à lui seul ne suffira peut-être pas non plus à attirer tous les décideurs. Si la migration vers le cloud améliore les performances de plusieurs applications jugées critiques pour l'entreprise, cela se fera-t-il au détriment des outils utilisés ailleurs ? Les performances de l'application seront-elles affectées tout au long de la migration et pour combien de temps ? Une nouvelle formation est-elle requise pour les utilisateurs ?

Les équipes doivent maîtriser toutes ces questions avant de soumettre leurs propositions de migration à l'équipe de direction. Cela nécessitera que le service informatique réfléchisse sérieusement à l'état actuel du réseau afin de créer une base de référence des performances existantes. De cette façon, les équipes peuvent confirmer ou éclairer les opinions des décideurs sur les points à améliorer le plus et placer la solution dans le contexte du cloud.

Référence des performances avant la migration

L'expérience de l'utilisateur final est l'endroit où tout commence. Après tout, l'informatique ne réussira pas si l'expérience de l'utilisateur final des employés n'est pas améliorée - ou est en fait sensiblement pire - après la migration vers le cloud. Même les décideurs qui se concentrent uniquement sur le résultat net seront d'accord, car une mauvaise expérience utilisateur peut avoir un effet domino sur les performances de l'entreprise dans son ensemble. Le service informatique doit donc se concentrer sur « l'état actuel » du réseau (ainsi que la satisfaction des utilisateurs) avant de déraciner les architectures.

Pour les applications, cela nécessite des tests Web synthétiques qui donnent au service informatique une perspective locale sur ce que les utilisateurs vivent réellement dans les lieux où ils travaillent, ainsi qu'une visibilité claire sur l'ensemble du chemin de livraison. Avec ces informations à portée de main, le service informatique peut établir des « critères d'acceptation » auxquels il doit répondre pendant et après migration vers le cloud pour garantir la satisfaction des utilisateurs. Voici quelques exemples de critères :

• Le temps de réponse doit être inférieur à 5 % des niveaux avant la migration
• Les taux d'erreur de service doivent être égaux ou inférieurs aux niveaux avant la migration
• La disponibilité des applications doit être égale ou inférieure aux niveaux d'avant la migration
• Les coûts d'infrastructure doivent être réduits d'au moins X % au cours de la migration

Les équipes doivent donc vérifier la vitesse à laquelle les applications sont actuellement livrées aux utilisateurs, la latence entre les serveurs (internes et externes, DNS, etc.), les taux d'erreur, les types d'erreurs et les problèmes de performances spécifiques au navigateur. Ce n'est qu'avec toutes ces données que le service informatique peut comprendre l'état de la pré-migration du réseau.

Continuer la surveillance tout au long de la migration

Une fois que les équipes ont mis en place les bases de référence, il est important qu'elles continuent à surveiller leurs critères d'acceptation tout au long du processus de migration. Les équipes doivent être en mesure de créer des tableaux de bord et des alertes qui peuvent signaler lorsque le réseau ne répond pas aux critères, idéalement en utilisant les mêmes métriques, sinon la solution de surveillance, qu'elles ont référencées pour les performances de base.

• Temps de disponibilité - Pour les applications cloud, le service informatique doit s'attendre à ce que les temps d'arrêt soient limités à quelques minutes au cours d'une semaine donnée. La plupart des applications publiques visent 99,9 % ou plus (environ 7 minutes par semaine ouvrable).
• DNS - Pour les applications qui sont maintenant dans le cloud, le service informatique disposera probablement d'un serveur DNS local ou d'un service DNS public fournissant l'adresse IP. C'est quelque chose qui doit être surveillé activement car cela empêchera les connexions pour tous les utilisateurs à un endroit donné.
• Latence, RTT - Maintenant que les services sont à l'extérieur du centre de données ou à l'extérieur du bureau, il pourrait y avoir une différence significative dans le temps nécessaire au trafic pour se déplacer du client au serveur. Les pics ici peuvent être liés à des problèmes de réseau local, de FAI ou d'application.
• Capacité - Payer pour la bande passante d'un FAI est une chose, mais la capacité de bout en bout d'un réseau entre l'emplacement de l'utilisateur et le serveur d'applications aura probablement un goulot d'étranglement différent. Cette mesure permet au service informatique d'identifier quand la congestion affecte les vitesses de connexion.

Les pics et les sauts sont des indicateurs utiles de bogues liés à la migration qui doivent être résolus immédiatement, même avant de nouvelles demandes commerciales, pour arrêter les problèmes avant qu'ils ne prolifèrent. En résolvant les problèmes, les yeux du service informatique sont directement sur le problème, les équipes sont plus susceptibles de mettre en œuvre la solution la plus appropriée.

Exploiter la surveillance pour qualifier le succès

Le référencement effectué par les équipes avant la migration doit être refait pour comparaison une fois la nouvelle architecture réseau en place. La clé ici est d'utiliser les mêmes processus (utilisation, modèles, temps, etc.) qui ont été testés sur l'ancien réseau.

Avec toutes les migrations vers le cloud, il y a un certain niveau de contrôle qui est perdu. Que ce soit au niveau du bare metal, du système d'exploitation ou des niveaux d'accès, il est également important que les équipes utilisent des solutions de surveillance modernes qui peuvent offrir le même niveau de visibilité sur le nouveau réseau pris en charge par le cloud. Si l'infrastructure n'appartient plus au service informatique, le niveau de visibilité avec les anciens outils de surveillance sera altéré. Ceci est crucial, car de nombreuses solutions de surveillance ne peuvent pas offrir de visibilité dans les environnements cloud ou même en dehors des pare-feu informatiques.

Sans informations au-delà du pare-feu, il est difficile pour le service informatique d'identifier les problèmes qui proviennent d'un FAI ou d'une infrastructure tierce et de les résoudre rapidement. Cela peut à la fois retarder la migration pendant qu'elle est en cours et rendre les utilisateurs extérieurs à l'informatique nostalgiques des jours pré-cloud si les performances sont continuellement entravées.