Migration · Rapatriement cloud
Rapatriement cloud
Le rapatriement transfère les charges de travail du cloud public vers la colocation. C'est rentable quand la charge est régulière, lourde et prévisible — le profil où vous louez de l'élasticité que vous n'utilisez jamais. Le seuil de rentabilité est généralement 12 à 24 mois une fois que le matériel, la colocation, la main-d'œuvre de migration et l'équipe d'exploitation que vous gérez maintenant sont intégrés au modèle. Les charges de travail qui échouent ce test sont les charges intermittentes, et elles devraient rester où elles sont.
Vérification des signaux
Le rapatriement est une décision charge de travail par charge de travail, non au niveau global de l'infrastructure. Évaluez chaque candidat par rapport aux deux colonnes : une charge qui se situe principalement à gauche mérite d'être modélisée, et une charge qui se situe principalement à droite coûtera plus cher en dehors du cloud peu importe comment la feuille de calcul est organisée.
| Rapatrier | Conserver en cloud |
|---|---|
| Utilisation régulière supérieure à ~60 % en permanence | Charge intermittente, saisonnière ou déclenchée par des événements |
| Volumes de sortie de données volumineux et prévisibles | Trafic dominé par des pics imprévisibles |
| Gravité des données — l'ensemble de données est volumineux et principalement statique | Données qui doivent rester près de services cloud gérés |
| Conformité ou souveraineté imposant une localisation connue | Une base d'utilisateurs véritablement mondiale nécessitant plusieurs régions |
| Charge de formation GPU soutenue facturée à l'heure | Travaux expérimentaux avec des semaines d'arrêt entre les exécutions |
| Une équipe d'infrastructure existante disposant de capacités | Une équipe déjà saturée, sans équipe d'astreinte pour la plateforme |
Modéliser le seuil de rentabilité
La comparaison décisive est la dépense annuelle en cloud pour la charge de travail par rapport au coût annuel de possession, avec chaque ligne de la deuxième colonne remplie honnêtement. Quatre lignes manquent régulièrement dans les modèles commerciaux de rapatriement, et chacune d'elles est importante.
| Ligne | Souvent oublié car |
|---|---|
| Personnel d'exploitation de plateforme | Le cloud l'intègre dans la facture, donc cela n'est jamais apparu comme un élément distinct auparavant. Les correctifs, la capacité, le firmware, les défaillances matérielles et la réponse en dehors des heures normales deviennent votre responsabilité. |
| Frais de sortie des données | Une charge unique, mais pour un grand ensemble de données, elle peut atteindre plusieurs centaines de milliers — et elle est facturée par le fournisseur que vous quittez. |
| Cycle de remplacement du matériel | Les dépenses en capital de la première année semblent déterminantes jusqu'à ce que vous amortissiez sur quatre à cinq ans de manière réaliste et que vous ajoutiez le renouvellement qui s'ensuit. |
| Capacité excédentaire à provisionner d'avance | Le cloud vous permet de dimensionner pour aujourd'hui. L'infrastructure que vous possédez doit être dimensionnée pour le pic attendu, et cette capacité supplémentaire est payée dès le premier jour. |
La calculatrice TCO de colocation modélise le côté colocation, et le guide TCO colocation vs cloud détaille la comparaison complète avec des chiffres concrets.
Comment la migration diffère
La méthode en six phases s'applique, mais trois phases prennent une forme différente. La découverte est plus difficile : les environnements cloud dérivent, et les ressources dans la console ne correspondent que rarement à l'architecture documentée — la couverture d'étiquetage est généralement le premier problème à résoudre. Il n'y a pas de phase logistique ; à sa place se trouve l'approvisionnement en matériel, qui entraîne ses propres délais. Le basculement est une redirection de trafic plutôt qu'un déménagement physique, ce qui rend l'annulation véritablement peu coûteuse cette fois : laissez l'environnement cloud en fonctionnement jusqu'à ce que la validation soit approuvée, et la restauration n'est qu'un changement DNS plutôt qu'un week-end.
Une chose qui ne change pas est la construction du réseau. Les circuits vers la colocation et la connectivité vers ce qui reste dans le cloud fonctionnent selon les mêmes délais de fournisseur de 60 à 120 jours que toute autre migration. Commandez-les la semaine où le contrat est signé.
Où l'implanter
- Indice des prix — le coût du marché cible par kW par mois, publié ouvertement
- Catalogue des installations — 202 installations avec puissance, densité et opérateur
- Répertoire des certifications — filtrer selon la conformité requise par votre charge
- Matrice de latence — aller-retour vers les régions où ce qui reste dans le cloud se trouve
- Suivi des prix GPU — si la charge en cours de rapatriement est un entraînement ou une inférence
Questions fréquemment posées
Qu'est-ce que le rapatriement cloud ?
Déplacer les charges de travail du cloud public vers l'infrastructure que vous possédez ou louez — généralement via colocation, parfois en local. C'est rarement du tout ou rien : le modèle courant est de rapatrier une charge de travail stable, prévisible et volumineuse tout en laissant les services à charge variable et non essentiels dans le cloud.
Quand le rapatriement fait-il véritablement économiser de l'argent ?
Lorsque l'utilisation est élevée et stable, que les frais de sortie sont importants et que la charge de travail est suffisamment grande pour remplir efficacement une empreinte de colocation. L'infrastructure que vous possédez est peu coûteuse par unité et coûteuse par heure d'inactivité ; le cloud est l'inverse. Une charge de travail tournant à 70%+ en permanence est la candidate classique, et une qui fonctionne quatre heures par jour ne l'est pas.
Quelle est la période de rentabilité ?
En général, 12 à 24 mois une fois que les capex matériels, la colocation, la main-d'œuvre de migration et l'effectif opérationnel que vous devez maintenir sont tous comptabilisés. Une durée plus courte signifie généralement que le modèle a omis le coût de la main-d'œuvre ou de l'exploitation de la plateforme vous-même ; une durée plus longue signifie que la charge de travail devrait probablement rester au cloud.
Qu'est-ce qui devrait rester en cloud public ?
Les charges par pics et saisonnières, tout ce qui est véritablement global et qui nécessiterait autrement plusieurs sites, les produits en phase initiale dont la forme change encore, la capacité de reprise après sinistre que vous ne voulez payer que lorsqu'elle s'exécute, et les services gérés que vous devriez reconstruire et exploiter. Le rapatriement est une décision de coût concernant la charge stable, pas une position philosophique sur le cloud.
Quel est le coût caché majeur du rapatriement ?
Le personnel. Le cloud intègre les opérations de plateforme à la facture ; la colocation ne le fait pas. Les correctifs, la planification de capacité, les défaillances matérielles, le micrologiciel, la surveillance et la réponse en dehors des heures de bureau deviennent autant de postes dans votre effectif. Les modèles de rapatriement qui battent le cloud sur le papier et perdent en pratique ont presque toujours sous-estimé ce coût.
En quoi le rapatriement diffère-t-il d'une migration de centre de données classique ?
Il n'y a pas de déplacement physique — aucun matériel n'est chargé sur un camion. En échange, vous devez gérer les délais de mise en œuvre des achats de matériel, une décision de dimensionnement que le cloud faisait autrefois élastiquement pour vous, et les frais de sortie de données qui peuvent atteindre six chiffres pour une grande infrastructure. La structure des phases reste la même ; la découverte est plus difficile, car les parcs informatiques cloud dérivent et l'inventaire dans la console ne correspond que rarement au diagramme d'architecture.
Modéliser un rapatriement ?
Décrivez le profil de la charge de travail et les marchés que vous envisagez. Nous reviendrons avec les centres de données conformes à vos besoins en puissance et conformité, ainsi que les tarifs de référence, afin que votre modèle d'infrastructure interne utilise des chiffres réels plutôt que des prix catalogue.