"Premierement ne faites pas de mal" - Hippocrate
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). Il s'agit du quatrième d'une série d'articles qui ont évalué 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 cloud.
Dans les articles précédents, nous avons passé en revue certains des facteurs courants que les entreprises doivent prendre en compte lorsqu'elles décident si et comment intégrer des services cloud. Nous avons également abordé les avantages et les inconvénients des différentes stratégies, ainsi que la manière de les comparer les unes aux autres afin de déterminer la meilleure voie à suivre pour votre entreprise.
Dans les prochains articles de la série, nous analyserons certaines stratégies courantes de migration des données vers le cloud, dans le contexte de la manière de gérer (et de minimiser) les risques.
Avant de commencer, il est important de noter que certaines entreprises sont intrinsèquement plus tolérantes au risque que d'autres – et vous devez déterminer ce que votre entreprise considère comme acceptable ou inacceptable.
Ceci est influencé par la nature de votre entreprise et les facteurs associés, par exemple si vous avez ou non des délais réglementaires ou des informations personnelles protégées (IPP) qui doivent être protégées. Dans certains cas, les conséquences du non-respect des délais réglementaires ou d’une fuite d’IPP sont énormes.
Imaginez une compagnie d'assurance qui enfreint par inadvertance les lois HIPAA : les conséquences en aval peuvent entraîner des sanctions financières, des sanctions civiles, une publicité négative et éventuellement même des sanctions pénales. Les entreprises de la finance, de la santé, des assurances et d’autres entreprises fortement réglementées auront une tolérance au risque beaucoup plus faible en ce qui concerne les changements de systèmes, de logiciels et d’architecture, comparable à une migration vers le cloud.
La perspective du calcul et du stockage dans le cloud présente une énigme intéressante pour de nombreux administrateurs système d'entreprise : les pressions concurrentes liées à la nécessité de répondre aux besoins d'innovation de l'entreprise pour l'avenir et la nécessité de garantir que les services et flux de travail existants restent en ligne pour soutenir l'entreprise aujourd'hui.
Une stratégie réussie d’adoption du cloud nécessite un équilibre prudent : prendre des risques calculés pour adopter de nouvelles plates-formes et technologies porteuses de croissance et d’innovation, tout en gardant les lumières allumées et le bon fonctionnement de l’entreprise.
Des stratégies irréalistes
Avant de voir quoi faire, parlons de ce qu'il faut faire. ne sauraient faire. Premier d’entre eux : ne prenez pas de risques inutiles lorsqu’il s’agit des applications qui assurent le fonctionnement de votre entreprise.
Refactorisation de grandes applications
De nombreuses organisations envisageront au moins de refactoriser leurs charges de travail critiques basées sur des fichiers vers 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 certains 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 natifs spécifiques aux fournisseurs disponibles sur AWS et Azure, mais il y a quelques inconvénients importants à garder à l'esprit. aussi.
Le coût initial de cette stratégie est élevé. En fonction de sa taille et de sa complexité, le coût de conversion peut être compris entre 3 et 30 millions de dollars pour réécrire une seule application.
C'est vrai : plus de 30 millions de dollars pour une application. Et cela suppose que cela réussisse.
Ce qui nous amène au revers de la médaille : non seulement le risque d’une panne à grande échelle est très élevé, mais dans le pire des cas, cela peut arrêter toute votre entreprise le temps que le problème soit diagnostiqué et corrigé. Et ce n’est qu’un échec parmi d’autres : combien d’entre eux votre organisation peut-elle en tolérer au cours des deux années et plus qu’il faudra pour mener à bien le projet ?
Reconnaître le risque dans son contexte
Il existe des situations légitimes dans lesquelles le scénario ci-dessus pourrait en réalité être considéré comme un risque acceptable. Considérer ce qui suit:
Imaginez que l'une de vos applications critiques et dépendantes de fichiers ait été achetée par un nouveau fournisseur qui a annoncé qu'elle serait progressivement supprimée et qu'elle ne serait plus prise en charge à partir d'une certaine date. Soudain, vous vous trouvez dans une position où vous devez faire quelque chose, dont chacun pourrait aboutir à un échec et à une perturbation des activités.
Peut-être que votre organisation s'appuie sur une application tierce dont le fournisseur a annoncé que la prochaine version sera native du cloud ». Quoi que vous et votre organisation pensiez de cette annonce, le risque existe malgré tout, et il vous appartient de le minimiser et de l'atténuer plutôt que d'essayer de l'éviter.
Certaines transformations commerciales plus importantes peuvent également compenser le risque lié au passage au cloud. Si vous faites l'objet d'un changement de marque important ou d'un changement de modèle commercial, alors vous a) courez déjà un risque élevé d'autres échecs, mais b) pouvez peut-être récupérer certaines des données précédentes qui étaient historiquement conservées sur site en passant au cloud.
Dans ces cas-là, il existe suffisamment de facteurs externes qui l’emportent sur la question de savoir si la migration vers le cloud est considérée comme un risque acceptable à prendre.
Ceux d’entre vous qui sont assez vieux pour se souvenir du bug de l’an 2 ont un exemple parfait de facteurs externes qui modifient l’équation du « risque acceptable » : une équation dans laquelle le risque de ne rien faire était plus élevé que de prendre des mesures pour réorganiser, migrer ou même remplacer une mission. -applications héritées critiques.
Certes, les scénarios ci-dessus ne s’appliqueront probablement pas à la plupart d’entre vous. Lorsqu'il s'agit de refactoriser des applications critiques pour l'entreprise, de nombreuses organisations mettent en balance la faible probabilité de succès et le coût élevé de l'échec, et concluent à juste titre qu'il est plus logique de laisser l'application là où elle est et d'attendre que le cloud prenne le relais. en haut.
En faire trop
Une autre stratégie irréaliste lors de tout parcours vers le cloud consiste à essayer d’aller trop vite. Non seulement vous casserez l'application, mais vous serez mort dans l'eau jusqu'à ce que vous puissiez revenir à votre déploiement sur site ou le réparer dans le cloud.
Si vous ne ralentissez pas et ne prenez pas le temps nécessaire pour évaluer et tester minutieusement vos applications, vous risquez des problèmes de latence post-migration, des erreurs de données et des problèmes de débit. Au-delà d’un certain seuil, ces problèmes peuvent aboutir à un échec complet de la migration. Le risque que ces erreurs se produisent est considérablement réduit lorsque vous consacrez le temps et les efforts nécessaires à une transition en douceur du sur site vers le cloud.
Alors, quelles sont les stratégies réalistes pour déplacer les charges de travail vers le cloud ? Restez à l'écoute pour notre prochain épisode pour voir les approches que nous recommandons.
James Walkenhorst est l'ingénieur marketing technique principal de l'équipe produit de Qumulo. Il travaille sur et autour des plates-formes NAS et des environnements de démonstration pratiques depuis 15 ans, et a passé les 10 années précédentes dans les opérations informatiques en tant qu'ingénieur et gestionnaire.