Cinq raisons de rapatrier les données depuis le cloud
Cet article passe en revue les principaux facteurs motivant un rapatriement depuis le cloud : coût, conformité, problèmes de latence et de gravité des données, retour en arrière en cas de migration mal préparée vers le cloud et défaillance du fournisseur.
La transition vers le cloud computing n’est pas toujours le long fleuve tranquille que l’on s’imagine. Si le cloud attire une part toujours plus importante des budgets des entreprises (une tendance qui, selon les analystes du secteur, devrait se poursuivre), il n’est pas pour autant la panacée. Des entreprises se sont vues contraintes de faire machine arrière : rapatrier sur site des applications et des données qu’elles avaient transférées dans le cloud. Pour l’heure, ces cas restent une minorité, mais le processus de rapatriement doit être pris en compte dans toute stratégie cloud.
La notion de rapatriement des données sur site est inhérente à certains usages, comme la sauvegarde et la restauration. Cette opération peut aussi être dictée par des considérations financières, pratiques, voire réglementaires. Examinons les cinq principales raisons de rapatrier les données depuis le cloud.
1- Réduire des coûts
Le cloud computing n’est pas toujours moins cher que les solutions sur site. Et les coûts peuvent évoluer, parce que les fournisseurs augmentent leurs prix, parce que les besoins changent ou, souvent, parce que l’entreprise a sous-estimé les coûts induits par le fonctionnement dans le cloud. Dans le cas d’un service à la demande ou à l’utilisation, plus vous utilisez le cloud (sous la forme de ressources de stockage ou de traitement), plus la facture est élevée. Les entreprises risquent de voir leurs besoins de stockage dépasser rapidement leur budget. Avec les systèmes sur site, une fois le matériel acheté ou loué, la plupart des coûts ne varient pas en fonction de l’utilisation.
Avec le cloud, plus le service est utilisé, plus il coûte cher. C’est le cas pour le stockage de données en général, ainsi que pour des aspects particuliers comme la lecture des données depuis l’extérieur du cloud (ne serait-ce que depuis les bureaux de l’entreprise), l’emploi de ressources connexes comme les outils de sécurité et d’administration, ou encore les écritures dans les bases de données.
Autre éventualité, le fournisseur de cloud est susceptible d’augmenter ses tarifs. Selon le contrat, les entreprises peuvent rapidement subir des hausses de coûts, parfois au point qu’une solution sur site s’avère finalement plus économique.
2- Se conformer aux stratégies de sécurité ou à la réglementation
Les obligations réglementaires ne devraient pas être un motif pour rapatrier les données depuis le cloud, ou alors cela signifie que la migration initiale en cloud n’avait pas été correctement planifiée. Par ailleurs, rien ne permet d’affirmer qu’un déploiement en cloud public est moins sûr qu’une architecture sur site, surtout si des règles de sécurité adéquates sont appliquées et si les systèmes sont correctement configurés.
Néanmoins. Bien que les failles de sécurité soient rares chez les fournisseurs de cloud public, il arrive fréquemment que les clients configurent mal leur infrastructure cloud. En cas de perte ou de violation de données, l’entreprise peut décider de rapatrier ses données sur site, ne serait-ce que pour minimiser l’impact sur sa réputation.
Sur le plan de la réglementation, les fournisseurs de cloud public, y compris les hyperscalers, ont pris des mesures pour répondre aux exigences des gouvernements et du secteur. Des services cloud spécifiques sont disponibles pour les données confidentielles, par exemple les informations conformes à la loi HIPAA ou à la norme PCI-DSS.
Toutefois, le principal problème est souvent la localisation des données. Si les grands fournisseurs de cloud proposent désormais un stockage dans des zones géographiques spécifiques, une entreprise peut tout de même décider, ou être obligée de décider, que la meilleure solution est de relocaliser les données dans un système sur site ou un datacenter local.
« Il est faux de penser que la réglementation crée des obstacles importants à la migration des applications vers le cloud », estime Adam Stringer, expert en résilience des entreprises au cabinet PA Consulting. « Les organismes de régulation exigent effectivement de la rigueur, tout comme pour d’autres dispositifs externalisés, mais il existe de nombreux exemples probants d’entreprises soumises à une réglementation très stricte qui ont migré vers le cloud. Le secret réside dans une planification minutieuse. »
En revanche, les enquêtes viennent compliquer la donne. Si un organisme de régulation, un service de police ou un tribunal exige une analyse approfondie des données, l’opération peut s’avérer impossible, ou du moins très coûteuse, dans le cloud. Il faut alors rapatrier les données en interne.
3- Réduire la latence et l’inertie des données
Bien que le cloud offre une capacité de stockage presque illimitée, son fonctionnement dépend des connexions Internet, ce qui entraîne de la latence. Certaines applications (sauvegarde et restauration, messagerie et bureautique, et progiciels à la demande) ne sont pas particulièrement sensibles à la latence. La qualité de la connectivité en entreprise est désormais suffisante pour que les utilisateurs ne remarquent pas de lenteurs.
Mais pour certaines applications, dont les analyses en temps réel, les bases de données, les outils de sécurité et ceux liés aux capteurs ou autres objets connectés, la sensibilité à la latence peut être plus critique. Les architectes système doivent tenir compte de la latence entre la source des données, les ressources de stockage ou de traitement et l’utilisateur, ainsi que de la latence entre des services cloud eux-mêmes.
Des technologies comme la mise en cache, l’optimisation réseau, ou encore des équipements de proximité (informatique dite de Edge) permettent de réduire la latence. Mais, parfois, la solution la plus simple consiste à rapatrier les données en interne. Ainsi, les liaisons sont raccourcies et l’équipe informatique peut paramétrer avec précision le stockage, le traitement et la mise en réseau en fonction des besoins applicatifs.
Pour éviter les problèmes de latence, il convient de réfléchir à la localisation des données, afin de résoudre les problèmes d’inertie. Si la plupart des données se trouvent dans le cloud et que leur traitement s’effectue dans le cloud, l’inertie des données ne constitue pas un obstacle. En revanche, si les données circulent constamment entre plusieurs clouds et des ressources de stockage ou de traitement sur site, il y a un problème.
4- Résoudre des migrations en cloud mal conçues
Il arrive que des entreprises rapatrient les données simplement parce que le passage au cloud ne répond pas à leurs attentes. Dans ce cas, elles cherchent à « sauver la face », selon l’analyste Naveen Chhabra de Forrester. « Elles ont essayé d’adapter une application au cloud alors que, du point de vue de l’architecture, ce n’était pas justifié », explique-t-il.
Adam StringerExpert en résilience des entreprises, cabinet PA Consulting
Peut-être que la charge de travail n’était pas conçue pour le cloud, ou que la migration a été mal planifiée ou exécutée. « Si l’architecture des données que vous déplacez dans le cloud est anarchique, vous ne ferez que reproduire cette anarchie dans le cloud », estime Adam Stringer de PA. « Un transfert vers le cloud ne résoudra pas, en soi, les problèmes de conception informatique. »
Et lorsque les entreprises souhaitent utiliser le cloud (que ce soit dans le cadre d’un redéploiement ou d’un projet entièrement nouveau), elles doivent appliquer des normes de conception identiques ou supérieures à celles qu’elles mettent en œuvre sur site. « La rigueur architecturale est aussi importante pour les déploiements dans le cloud que sur site », fait observer Adam Stringer. « Si elles ne s’y prennent pas bien, les entreprises finiront par devoir rapatrier une partie de leurs actifs. »
Cela ne signifie pas que le rapatriement sera facile, ni même qu’il réglera le problème. Mais au moins, l’équipe informatique aura la possibilité de tout remettre à plat, d’analyser ce qui n’a pas fonctionné et de repenser les moyens d’utiliser le cloud plus efficacement à l’avenir.
5- Parer aux défaillances de l’hébergeur
La défaillance du fournisseur de cloud constitue une raison majeure de rapatrier les données. Le client n’aura sans doute pas le choix. Dans l’idéal, le fournisseur donnera aux entreprises un préavis et un délai réaliste pour récupérer leurs données ou les transférer chez un autre fournisseur de cloud. Mais il est possible qu’un fournisseur fasse faillite sans préavis, ou que des problèmes techniques ou environnementaux l’obligent à cesser ses activités du jour au lendemain. Les entreprises devront alors compter sur des copies de secours de leurs données, sur site ou chez un autre fournisseur.
Heureusement, la défaillance totale d’un fournisseur est rare. Cependant, l’expérience acquise lors de récentes pannes de services cloud montre que les entreprises doivent au minimum élaborer un plan pour sécuriser et récupérer leurs données en cas de problème. Et la technologie sur site est susceptible de jouer un rôle central dans tout plan de reprise, ne serait-ce qu’en attendant que l’entreprise trouve de nouvelles ressources dans le cloud.
« La question à se poser avant de transférer une application vers le cloud est de savoir si cette opération permet d’accroître la résilience du client ou du service proposé sur le marché », explique Adam Stringer de PA. « Si la migration ne vise qu’à réduire les coûts, les frais susceptibles d’être engagés pour rétablir la résilience par la suite, pourraient en annuler tous les avantages. »