Je devrais savoir mieux que de me tourner vers la foule de Hacker News pour obtenir de la sagesse. Récemment, quelqu'un sur HN a posé une question intéressante : « Avez-vous déjà changé ? » Étant HN, les réponses n'étaient pas aussi intéressantes. En fait, relativement peu de personnes ont répondu à la question, préférant plutôt défendre l'exécution de leurs applications dans des centres de données privés. D'autres ont offert des conseils adaptés aux petits magasins et non aux grandes entreprises. Pourtant, malgré le bruit, il *y avait* un petit signal dans le fil. Si vous souhaitez tirer le meilleur parti d'un cloud particulier, vous devrez acheter ses services, ce qui, bien sûr, complique la migration. Oh, et si vous pensez que vous pouvez créer un meilleur cloud que les hyperscalers, vous passez peut-être à côté de l'essentiel. == Montrez-moi les crédits == Une fois que les entreprises ont choisi de s'appuyer sur un cloud particulier, qu'est-ce qui les incite à bouger ? En lisant les réponses de HN, les « crédits » sont un facteur de motivation primordial. On ne sait pas dans quelle mesure un tel pot de miel attire les grandes entreprises, mais pour un certain groupe démographique, la migration peut être motivée par « suffisamment de crédits Google Cloud [ou Azure ou AWS] pour rendre un changement valable ». .â Malheureusement, ce type simpliste d'analyse coûts/avantages néglige tous les coûts cachés de l'exécution dans le cloud, comme l'a détaillé David Linthicum. Comme GitLab l'a apparemment découvert, les crédits peuvent encourager la migration mais ils ne la paient pas nécessairement. Comme décrit dans le commentaire HN, « Chez GitLab, nous sommes passés d'AWS à Azure, puis à Google Cloud. » Pourquoi quitter AWS en premier lieu ? L'argent était un problème, mais pas parce qu'AWS était intrinsèquement plus cher. C'était plutôt un problème de configuration : « Comme la plupart des entreprises, très peu d'attention a été accordée aux coûts, à la configuration, etc. [lors du démarrage avec AWS]. Le résultat était que nous mettions essentiellement de l'argent en feu. Une offre de crédits Azure gratuits qui nous permettrait d'économiser quelque chose comme un an en factures ( pas mal d'argent à l'époque Ça sonne bien, non ? âÂÂLe déplacement a été assez douloureux et ⦠nous avons brélé les crédits gratuits *très* rapidement.¢Â L'entreprise a alors décidé de passer à Google Cloud (pour des raisons inexpliquées), et a constaté que la migration était, encore une fois, un "processus difficile". Qu'est-ce que le commentateur a appris de cette expérience ? « Avec le recul, si je devais créer une entreprise, je m'en tiendrais probablement à quelque chose comme Hetzner ou un autre fournisseur de bare metal abordable. Les services cloud sont excellents * si * vous utilisez leurs services dans toute la mesure du possible, mais je soupçonne que dans 90% des cas, cela finit par être un facteur de coût énorme sans que les avantages en valent la peine. Pour moi, c'est exactement la mauvaise leçon. == Je ne comprends toujours pas le cloud == Si vous lisez l'intégralité du fil de discussion, vous trouverez de nombreuses affirmations sûres d'elles-mêmes selon lesquelles le cloud à faire soi-même (sur Hetzner ou d'autres hébergeurs de serveurs dédiés) est la voie à suivre. (Ici et ici et ici.) Comme on dit, le cloud public est "plus lent et plus cher que votre propre serveur par une énorme marge". Sauf que ce n'est pas le cas . Cette idée que les professionnels de l'informatique peuvent facilement "out-cloud the cloud"est fausse et hors de propos. Le cloud n'a jamais vraiment été une question d'économie d'argent. Il s'agit de maximiser la flexibilité et la productivité. Comme le souligne un commentateur de HN, « Je travaille dans une très petite équipe. Nous avons quelques développeurs qui font également office d'ops. Aucun d'entre nous n'est ou ne veut être administrateur système. Dans notre cas, ECS [Elastic Container Service] d'Amazon est un énorme gain de temps et d'argent. Comment ? En supprimant les fonctions d'administration système, l'équipe devait auparavant remplir. âÂÂOui, la plupart des problèmes que nous avions avant auraient pu être résolus par un administrateur système compétent, mais c'est précisément le but âÂÂembaucher un bon administrateur système est beaucoup plus cher pour nous que de payer un peu plus à Amazon et de leur dire simplement "veuillez exécuter ces conteneurs avec cette configuration". Il fait bien le cloud. D'autres suggèrent qu'en passant aux options sans serveur, ils réduisent davantage le besoin d'administrateurs système. Oui, plus vous explorez des services propres à un cloud particulier, moins il est facile de migrer, quel que soit le nombre de crédits qu'un fournisseur vous accorde. Mais, sans doute, moins vous aurez envie de migrer si vos développeurs sont nettement plus productifs, car ils ne réinventent pas tout le temps les roues de l'infrastructure. Une entreprise a explicitement essayé d'éviter de se verrouiller sur un cloud particulier. âÂÂNous avons développé notre produit dès le début pour être déployé sur 3AWS, Azure, IBM.â Comment cela ? En s'en tenant au plus petit dénominateur commun qui était FaaS/IaaS ([AWS] Lambda, [Amazon] S3, [Amazon] API [Gateway], Kubernetes Cela semble simple, n'est-ce pas ? n'était certainement pas facile. Nous avons également ignoré les outils qui auraient pu nous aider grandement [si nous étions restés avec] un seul cloud pour être multicloud. âÂÂSe déplacer entre des fonctionnalités partageées données est possible, mais ce n'est certainement pas en quelques clics ou en quelques travaux Jenkins. Se déplacer entre les deux est un travail à temps plein. , maintenant dans Azure, prendra du temps et de l'apprentissage. Et passer de l'autorisation AWS IAM à Azure [Active Directory] ? Du temps, du temps et du temps. En d'autres termes, le multicloud n'est pas facile à mettre en place, et la migration non plus. Cela signifie-t-il que ni l'un ni l'autre n'en vaut la peine? Pas nécessairement. Comme le décrit Miles Ward, CTO de SADA (un partenaire clé de Google Cloud), il peut y avoir des raisons impérieuses de passer à un autre cloud. Pour beaucoup, c'est juste la facilité d'utilisation et l'efficacité pour faire avancer les choses ; pour d'autres, c'est l'attention et le partenariat ; pour une troisième cohorte, c'est des avantages de coût absurdes ; et un quatrième, c'est la performance et la fiabilité. En tant que tel, lorsque "les clients voient des lacunes dans un ou plusieurs de ces quatre domaines", ils se déplacent .â Ward a probablement raison : il *peut y avoir* des raisons impérieuses de migrer. Assurez-vous simplement de faire une analyse complète du coût total de possession du déménagement, qui doit aller bien au-delà de â¢ÂÂcloud X m'offre 50 000 $ en crédits. De plus, avant que vous décidez de déployer votre propre cloud, cela vaut la peine de prendre en compte les coûts associés à la gestion de toute votre propre infrastructure.