Quelqu’un a déjà changé de cloud en cours d’utilisation ?

Question et réponses sur HN demandant pourquoi et comment des gens ont migré entre des clouds comme AWS, Azure et Google

• J’ai migré l’environnement de mon client de AWS → Google, puis de Google → Hetzner, sans aucune interruption de service
  • La raison principale était le prix. Après avoir épuisé les crédits gratuits AWS/Google, nous sommes passés à Hetzner
  • Les économies réalisées grâce aux crédits ont représenté 20 fois le coût de la migration
  • La migration s’est faite en reliant le backend via des reverse proxies dans chaque environnement, puis en configurant un VPN entre les services avant de changer le DNS
  • La partie la plus délicate a été le failover de la base de données, et le fait de faire en sorte que les mises à jour soient retentées après la bascule du master
  • Grâce à cela, le client a obtenu une configuration indépendante du fournisseur cloud et a bien tiré parti des crédits gratuits dont il disposait
  • Détails techniques
    • reverse proxies comme haproxy et nginx + Hashicorp Consul + ngx_mruby
    • Mise en place d’un VPN entre les clouds pour que les reverse proxies puissent accéder aux backends des deux côtés
    • Réplication de la base de données vers le nouveau cloud
    • Permettre à l’application de choisir quelle base de données utiliser comme master (Consul)
    • Faire en sorte que l’application gère les erreurs de base de données de manière élégante. C’était la partie la plus difficile
    • Définir un DNS TTL faible
    • Connecter les nouveaux backends au reverse proxy et vérifier l’absence d’erreurs
    • Mettre à jour le DNS pour ajouter le nouveau reverse proxy à l’environnement
    • Promouvoir en master le réplica situé dans le nouveau cloud
    • Réduire progressivement les connexions sur les anciens backends
    • Retirer finalement l’ancien reverse proxy du DNS
    • Une fois tout vérifié, supprimer l’ancien environnement et rétablir le DNS TTL
• GitLab est passé de AWS à Azure, puis de nouveau à Google Cloud (il y a quelques années)
  • Au début, ils avaient démarré sur AWS comme tout le monde, mais cela coûtait énormément d’argent (ils parlaient littéralement de « brûler de l’argent »)
  • Ils ont vu que YC donnait des crédits Azure à ses membres, et après calcul cela semblait couvrir environ un an d’usage, donc ils ont migré
  • Mais la migration a été pénible, et pendant toute la période sur Azure, personne n’en a été satisfait. En plus, les crédits gratuits ont été consommés assez vite
  • Ils ne se souviennent pas exactement pourquoi ils ont ensuite migré vers GCP, mais cela a pris beaucoup de temps et a été un processus très difficile
  • L’expérience sur GCP a été bien meilleure, sans être parfaite pour autant
  • En particulier, GCP avait tendance à arrêter des VM de façon aléatoire sans raison claire
  • Parfois l’arrêt se passait proprement, mais dans d’autres cas cela finissait dans une sorte d’état intermédiaire, si bien que d’autres systèmes tentaient encore de s’y connecter et obtenaient des timeouts au lieu d’échouer immédiatement
  • D’après leurs souvenirs, cela s’est amélioré avec le temps, mais cela donnait une impression très Google du type « quelque chose est cassé, mais nous ne pouvons pas vous dire pourquoi »
  • Avec le recul, s’ils recréaient une entreprise aujourd’hui, ils resteraient probablement chez Hetzner ou chez un autre fournisseur bare metal bon marché
  • Les services cloud sont excellents si on les exploite au maximum de leurs possibilités, mais dans 90 % des cas on les utilise sans réel bénéfice tout en payant beaucoup plus cher
• Google Cloud → Digital Ocean → OVH
  • Faire tourner notre propre stack sur des serveurs performants est plus simple et pose moins de problèmes qu’on ne l’imagine
  • Déployer avec git push et builder des conteneurs relève presque du « set it and forget it »
  • Nous avons des données PostgreSQL de l’ordre du téraoctet, ce qui est extrêmement cher chez la plupart des clouds
  • Certains voient le cloud comme du pain déjà tranché, prêt à consommer, mais en pratique cela ne réduit pas vraiment le temps passé par les développeurs
  • Le cloud est plus cher et nettement plus lent que l’exploitation de serveurs. Pour des charges de travail de taille intermédiaire, il n’y a pas vraiment d’avantage à utiliser le cloud

Je n’ai retenu que les 3 réponses les plus votées. Il y a aussi, sous ces réponses, divers commentaires avec d’autres questions, avis et objections, donc cela vaut la peine d’y jeter un œil.

[kunggom]

Un article d’ITWorld a été publié pour critiquer précisément ce fil, en affirmant qu’un manque de compréhension du cloud reste encore très répandu.
Migration vers le cloud « éblouie par les crédits »… « la plus grande illusion »

[xguru]

Il faut lire l’article d’ITWorld en gardant à l’esprit que son auteur, Matt Asay, était encore récemment responsable du marketing développeur chez AWS.
https://www.linkedin.com/in/mjasay/details/experience/

[kunggom]

Oh, merci pour cette bonne information.

[superwoou]

Le cloud n’est pas une solution miracle. La dernière phrase de la 3e réponse me laisse un peu perplexe ; cela ne dépend-il pas surtout de la manière dont on l’utilise ?

[xguru]

C’était une question sur la migration entre clouds, mais beaucoup de gens recommandaient plutôt des services d’hébergement comme Hetzner que le cloud lui-même.
Le coût est sans doute la principale raison, mais je pense quand même qu’un bon usage du cloud présente pas mal d’avantages.
Et en réalité, si une petite entreprise dit « nous n’utilisons pas le cloud, nous faisons de l’hébergement ! », il devient aussi plus difficile de recruter des développeurs. (Si vous développez tout vous-même, bien sûr, ce n’est pas vraiment un problème.)

Au passage, je suis tout à fait d’accord sur le fait que Google Cloud avait tendance à arrêter des VM de manière aléatoire sans raison claire.
C’est d’ailleurs pour ça que, il y a quelques années, j’ai déplacé un petit serveur que j’exploitais chez Google vers AWS LightSail.
Il arrivait assez souvent qu’un jour, sans raison, le serveur tombe net ou devienne inaccessible. Peut-être que ça s’est amélioré depuis, mais… ce n’était pas une bonne expérience.