Exploiter la gravité des données :décisions stratégiques en matière d'architecture cloud

Si vous travaillez dans le domaine des infrastructures, vous avez ressenti la gravité des données en action. Vous planifiez et construisez une architecture idyllique, vierge et flexible et prenez du recul pour l'émerveiller brièvement. Ensuite, vous ajoutez des données – et ensuite les données augmentent ! Soudainement, les charges de travail se regroupent autour, les services sont déployés là où les données se trouvent et vos décisions d'architecture sont discrètement dictées par les emplacements de stockage plutôt que par les priorités de l'entreprise.

Au début, c’est subtil, quelques millisecondes supplémentaires de latence par-ci, une petite facture de sortie par-là. Mais avancez rapidement et vous gérez un système dans lequel le déplacement des charges de travail n’est pas un choix stratégique, mais un effort herculéen. C’est le vrai danger. Non pas que vous ne puissiez pas bouger, mais cela devient si coûteux, perturbateur et politiquement difficile que vous ne le ferez tout simplement pas.

Le kicker ? L'attraction gravitationnelle ne se soucie pas de savoir si l'environnement dans lequel vous êtes coincé est toujours le bon pour vous.

Qu'est-ce que la gravité des données ?

Vous connaissez l’analogie :la masse attire la masse. En technologie, les ensembles de données constituent la masse. Plus ils grossissent, plus leur attraction est forte. Les modèles de calcul, d'applications, d'analyse et d'IA migrent vers les données pour réduire la latence et simplifier l'accès.

Cette attraction peut être utile à court terme. Garder tout à proximité réduit le mouvement des données, améliore les performances et minimise la complexité – du moins au début. Mais avec le temps, cela devient une contrainte. Plus l'ensemble de données et les services environnants sont volumineux et étroitement liés, plus il devient difficile de les déplacer sans perturbation majeure.

Voir aussi : Automatisation de la gouvernance des données :exploitez l'IA comme portier numérique

L'impact réel sur la stratégie cloud

1. Les défis de la migration

Les migrations à l’échelle du pétaoctet ne sont pas « lift-and-shift ». Il s'agit d'opérations progressives avec des fenêtres de basculement, des stratégies de synchronisation delta, une validation des données et une gestion des risques intégrées. Même avec la meilleure planification, vous pourriez être confronté à :

• Des frais de sortie qui semblent conçus pour décourager les départs
• Limitation de la bande passante du côté du fournisseur
• Interruption opérationnelle ou service dégradé lors des basculements
• Audits de conformité pouvant arrêter une migration en cours de route
•  

Conseil pratique : N’attendez pas de déménager pour penser à la portabilité. Intégrez-le à votre architecture dès le départ, grâce à des normes ouvertes, des charges de travail conteneurisées et des abstractions qui réduisent la dépendance à l'égard des services propriétaires.

2. Pénalités de performance

Vous savez déjà que la proximité compte. Mais dans une configuration multirégion ou multicloud, il est étonnamment facile que les données et les calculs s'écartent au fil du temps.

Lorsque cela se produit, vous payez deux fois :une fois en latence (affectant l'expérience utilisateur, les SLA d'analyse et les temps de traitement par lots) et une autre fois en coûts de transfert interrégionaux ou inter-cloud.

Conseil pratique : Surveillez en permanence le placement de la charge de travail par rapport à l'emplacement des données, et pas seulement au moment du déploiement. Utilisez des outils ou des politiques qui synchronisent automatiquement le calcul et le stockage, sauf s'il existe une raison délibérée de les séparer.

3. Verrouillage du fournisseur par défaut

Le verrouillage se produit rarement lors d’une seule décision importante. Cela se produit lentement – ​​une API par-ci, une base de données gérée par-là – jusqu’à ce que vos charges de travail soient profondément liées aux services d’un seul fournisseur. D’ici là, la « migration » s’apparente plus à une réécriture qu’à une délocalisation.

Conseil pratique : Suivez les dépendances spécifiques au fournisseur dans votre architecture comme vous le feriez pour une dette technique. Organisez un examen trimestriel pour décider lesquels vous tolérerez (car ils offrent une valeur unique) et lesquels vous commencerez à dérouler avant qu'ils ne deviennent un chemin critique.

Voir aussi : L'emplacement, l'emplacement et l'emplacement comptent aussi avec les données

Atténuer la gravité des données

Voici comment éviter que cette attraction ne devienne un piège :

Adopter l'hybride et le multi-cloud par défaut

Ne considérez pas l’hybride comme une stratégie « ultérieure ». C'est le point de départ. Placez les charges de travail là où elles fonctionnent le mieux, et non là où votre fournisseur principal a de la capacité. Gardez plusieurs fournisseurs en jeu pour maintenir le levier de négociation et la flexibilité de déploiement.

Pousser le calcul vers la périphérie

Pour les charges de travail sensibles à la latence – inférence IA, télémétrie industrielle, streaming vidéo – traitez les données à la source ou à proximité. Transférez uniquement les données affinées ou agrégées vers l'infrastructure principale pour réduire les mouvements et les coûts.

Soyez agressif en matière de gestion du cycle de vie des données

Toutes les données ne méritent pas un stockage premium ou un accès immédiat. La hiérarchisation chaud/chaud/froid devrait être une pratique standard. Archivez de manière agressive. Supprimez ce qui n’a aucune valeur opérationnelle, commerciale, juridique ou de conformité. Chaque téraoctet que vous coupez réduit l'attraction gravitationnelle.

Regard vers l'avenir

La technologie émergente commence à changer la donne. Le stockage décentralisé, l’orchestration basée sur l’IA et les structures de données indépendantes du fournisseur peuvent contribuer à faire de la mobilité une véritable option. Mais ce ne sont pas des solutions miracles. Sans architecture intentionnelle, ces outils ne font qu'ajouter une autre couche de complexité autour d'une masse déjà immobile.

La gravité des données est inévitable. L’erreur est de le traiter comme un problème purement technique alors qu’il est aussi financier et stratégique. L’emplacement de vos données dictera bien plus que la latence. Il définira votre structure de coûts, votre flexibilité et la rapidité avec laquelle vous pouvez réagir lorsque des opportunités ou des menaces émergent.

L'hyperscaler avec lequel vous démarrez peut être le bon choix pour certaines charges de travail, mais ne présumez jamais que c'est le bon choix pour toutes, pour toujours.

Actions à démarrer maintenant :

• Inventairez vos emplacements de données et vos charges de travail :identifiez ceux qui sont « liés par gravité » à un seul fournisseur.
• Modélisez les coûts de migration avant d'en avoir besoin :connaissez votre vitesse de fuite en dollars, en temps et en risques.
• Construire pour la portabilité :normes ouvertes, conteneurisation et dépendances propriétaires minimales.
• Examinez l'emplacement tous les trimestres :veillez à ce que le calcul et le stockage soient alignés autant que possible.
• Entretenir des relations avec plusieurs fournisseurs, même si l'un d'entre eux est dominant aujourd'hui.
•  

Dans le cloud, la mobilité n’est pas un avantage; c’est votre police d’assurance contre la hausse des coûts, les baisses de performances et les ralentissements de l’innovation. Construisez votre architecture comme vous prévoyez de déménager, et vous aurez la liberté de rester uniquement lorsque cela a vraiment du sens.