Les équipes informatiques d'aujourd'hui ont beaucoup à faire. Bien que les données non structurées augmentent de 35 % par an, les équipes informatiques responsables de ces données voient leurs effectifs, leurs budgets et leurs centres de données diminuer (ces centres de données ne diminuent peut-être pas réellement, mais ils ne s'agrandissent certainement pas). Cet article est le quatrième d'une série de billets qui évaluent les défis et les opportunités, ainsi que les avantages et les inconvénients, avec lesquels les stratèges, les gestionnaires et les administrateurs d'entreprise doivent jongler lorsqu'il s'agit de déplacer des charges de travail vers le nuage.
Dans les articles précédents, nous avons passé en revue certains des facteurs communs que les entreprises doivent prendre en compte lorsqu'elles décident d'intégrer ou non des services en nuage et de quelle manière. Nous avons également abordé les avantages et les inconvénients des différentes stratégies, ainsi que la manière de les comparer afin de déterminer la meilleure voie à suivre pour votre entreprise.
Dans les prochains billets de cette série, nous analyserons certaines stratégies courantes de migration des données vers le nuage, dans le contexte de la gestion (et de la minimisation) des risques.
Avant de commencer, il est important de noter que certaines entreprises sont par nature plus tolérantes au risque que d'autres - et vous devez déterminer ce que votre entreprise considère comme un risque acceptable par rapport à un risque inacceptable.
Cela dépend de la nature de votre activité et des facteurs associés, par exemple si vous avez ou non des échéances réglementaires ou des informations personnelles protégées (IPP) qui doivent être sauvegardées. Dans certains cas, les conséquences du non-respect des délais réglementaires ou de la fuite d'informations personnelles protégées sont considérables.
Imaginez une compagnie d'assurance qui enfreint par inadvertance les lois HIPAA : l'effet en aval peut se traduire par des pénalités financières, des sanctions civiles, une publicité négative, voire des sanctions pénales. Les entreprises des secteurs de la finance, de la santé, de l'assurance et d'autres secteurs fortement réglementés auront une tolérance au risque beaucoup plus faible en ce qui concerne les systèmes, les logiciels et les changements architecturaux, au même titre qu'une migration vers l'informatique dématérialisée.
La perspective de l'informatique et du stockage en nuage présente un dilemme intéressant pour de nombreux administrateurs de systèmes d'entreprise : les pressions concurrentes pour répondre au besoin d'innovation de l'entreprise pour l'avenir et la nécessité de s'assurer que les services et les flux de travail existants restent en ligne pour soutenir l'entreprise aujourd'hui.
Une stratégie réussie d'adoption de l'informatique dématérialisée nécessite un équilibre prudent : prendre des risques calculés pour adopter de nouvelles plates-formes et technologies qui favorisent la croissance et l'innovation, tout en continuant à faire fonctionner l'entreprise et à l'éclairer.
Stratégies irréalistes
Avant de voir ce qu'il faut faire, parlons de ce qu'il faut faire pas à faire. La première d'entre elles est de ne pas prendre de risques inutiles en ce qui concerne les applications qui permettent à votre entreprise de fonctionner.
Refonte de grandes applications
De nombreuses entreprises envisageront au moins de remanier leurs charges de travail critiques basées sur des fichiers pour les faire passer à une architecture "cloud-native". Cela implique de réécrire l'application pour exploiter le stockage d'objets plutôt que les données de fichiers. Cette approche présente certes des avantages à long terme, tels qu'une plus grande flexibilité dans les opérations cloud et une intégration plus étroite avec certains des services cloud-native spécifiques aux fournisseurs disponibles sur AWS et Azure, mais il y a également quelques inconvénients importants à garder à l'esprit.
Le coût initial de cette stratégie est élevé. Selon la taille et la complexité de l'application, la réécriture d'une seule application peut coûter entre 3 et 30 millions de dollars.
C'est exact : plus de 30 millions de dollars pour une seule application. Et cela en supposant qu'elle réussisse.
Ce qui nous amène au revers de la médaille : non seulement le risque d'une défaillance à grande échelle est très élevé, mais dans le pire des cas, il peut entraîner l'arrêt de toute votre activité pendant que le problème est diagnostiqué et corrigé. Et il ne s'agit là que d'une seule défaillance : combien de défaillances de ce type votre organisation peut-elle tolérer au cours des deux années ou plus que durera le projet ?
Reconnaître les risques dans leur contexte
Il existe des situations légitimes où le scénario ci-dessus peut être considéré comme un risque acceptable. Prenons l'exemple suivant :
Imaginez que l'une de vos applications critiques, dépendant de fichiers, ait été achetée par un nouveau fournisseur qui a annoncé qu'elle serait progressivement retirée et ne serait plus prise en charge à partir d'une certaine date. Vous vous retrouvez soudain dans une situation où vous devez faire ce qui suit quelque chose tout cela pourrait aboutir à un échec et à une interruption de l'activité.
Peut-être votre organisation s'appuie-t-elle sur une application tierce dont le fournisseur a annoncé que la prochaine version serait "cloud native". Quel que soit votre sentiment et celui de votre organisation à l'égard de cette annonce, le risque existe bel et bien et il vous incombe de le minimiser et de l'atténuer plutôt que d'essayer de l'éviter.
Certaines transformations importantes de l'entreprise peuvent également compenser le risque de passer à l'informatique dématérialisée. Si vous procédez à un changement de marque important ou si vous changez de modèle d'entreprise, a) vous êtes déjà exposé à un risque élevé d'autres défaillances, mais b) vous pouvez peut-être récupérer certaines des données antérieures qui étaient conservées sur site en passant à l'informatique dématérialisée.
Dans ces cas, il existe suffisamment de facteurs externes pour que la migration vers le nuage soit considérée comme un risque acceptable à prendre.
Ceux d'entre vous qui sont assez âgés pour se souvenir du bogue de l'an 2000 ont un exemple parfait de facteurs externes qui modifient l'équation du "risque acceptable" : le risque de ne rien faire était plus élevé que celui de prendre des mesures pour réarchitecturer, migrer ou remplacer les applications patrimoniales, même celles qui sont essentielles à la mission.
Il est vrai que les scénarios ci-dessus ne s'appliquent probablement pas à la plupart d'entre vous. Lorsqu'il s'agit de remanier des applications critiques, beaucoup d'entreprises comparent la faible probabilité de réussite au coût élevé de l'échec et concluent à juste titre qu'il est plus judicieux de laisser l'application en l'état et d'attendre que le nuage la rattrape.
L'exagération
Une autre stratégie irréaliste dans tout voyage vers le nuage est d'essayer d'aller trop vite. Non seulement vous casserez l'application, mais vous serez dans l'impasse jusqu'à ce que vous puissiez revenir à votre déploiement sur site ou le réparer dans le nuage.
Si vous ne ralentissez pas et ne prenez pas le temps nécessaire pour évaluer et tester vos applications de manière approfondie, vous risquez des problèmes de latence, des erreurs de données et des insuffisances de débit après la migration. Au-delà d'un certain seuil, ces problèmes peuvent entraîner l'échec total de la migration. Le risque de survenue de ces erreurs est considérablement réduit lorsque vous consacrez le temps et les efforts nécessaires à une transition en douceur de l'infrastructure sur site vers l'infrastructure en nuage.
Quelles sont donc les stratégies réalistes pour déplacer les charges de travail vers le nuage ? Restez à l'écoute de notre prochain article pour découvrir les approches que nous recommandons.