- Un compte qui partage les bizarreries vécues chaque jour sur Microsoft Azure. La série a désormais dépassé les 400 jours
- Jour 403 : le récent #Microsoft Cloud for Sustainability Technical Summit a eu lieu. Mais, en réalité, cela ressemblait davantage à un sommet #Copilot avec un léger accent sur la durabilité. (Cette capture d’écran ne provient que des trois premières sessions)
- Jour 402 : la nouvelle fonctionnalité #AI d’Azure CLI a parfaitement bien fonctionné jusqu’à présent (capture d’écran d’erreur)
- Jour 401 : image d’erreur de lien. Ce n’est qu’un des innombrables cas de liens de la documentation #Azure qui renvoient vers des sections qui n’existent même pas
...
1 commentaires
Commentaires sur Hacker News
À l’époque où je travaillais chez Mojang, lors du rachat par Microsoft, on a essayé de migrer d’AWS vers Azure.
Sur le papier, ça avait du sens, et alors qu’AWS nous coûtait un montant à six chiffres par mois, Azure pouvait être utilisé gratuitement.
Mais au bout d’environ un an, après d’innombrables heures passées par notre équipe et par les experts solutions affectés par l’organisation Azure, tout le monde a convenu qu’il fallait continuer à payer cette facture à six chiffres à l’un des grands concurrents de Microsoft.
Depuis, je n’ai plus considéré Azure comme un fournisseur cloud réellement exploitable en production, et il faudra peut-être le réévaluer un jour, mais ce ne serait peut-être pas la première fois que je me trompe.
Globalement, c’était correct, mais les problèmes ont commencé quand on s’est mis à utiliser CosmosDB, qui s’appelait alors DocumentDB.
Le DocumentDB des débuts était vraiment lamentable, les coûts étaient bien trop difficiles à prévoir, on se retrouvait avec des factures absurdes chaque week-end, et le SDK .NET fourni était aussi rempli de bugs que terrible.
Le pire, c’était que l’interface web semblait directement liée à une instance CosmosDB donnée.
Si on sous-dimensionnait les ressources de la base, elle ralentissait, et même l’interface web qu’il fallait utiliser pour augmenter les ressources devenait lente elle aussi.
On se retrouvait donc parfois à devoir couper toute l’application juste pour augmenter les ressources de Cosmos, et Microsoft donnait une impression de pur amateurisme.
Je crois comprendre que Cosmos est bien meilleur aujourd’hui, mais le souvenir est resté très amer.
S’il y avait des crédits gratuits, je pourrais éventuellement redonner sa chance à Azure, mais aujourd’hui je ne le recommanderais absolument pas.
Faire tourner le plus grand service d’e-mail au monde sur la stack Windows aurait été une énorme validation, mais il a fallu des années pour y parvenir.
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
Je suppose qu’il y avait peut-être des fonctionnalités spécifiques à AWS, comme leur manière de gérer le serverless, qui ne pouvaient pas être transférées directement sur Azure, mais j’aime toujours comprendre pourquoi une migration de X vers Y a échoué.
Le fait que les technologies côté jeu se soient davantage étoffées entre-temps a sans doute aidé.
Édition : AWS -> Azure :)
AWS ayant globalement une longueur d’avance, il y avait à l’époque un écart technologique, qui semble avoir ensuite été comblé.
Pas de souci, Microsoft va changer le nom la semaine prochaine et refaire complètement l’interface d’administration et l’API.
Ça s’appellera désormais Dynamics CoPilot OneAI 365 for Business OneCloud.
live.com, d’autres enoutlook.com, d’autres encore ensharepoint.com,msbinbows.comet ainsi de suite.Mais la documentation et toutes les autres références continueront bien sûr d’utiliser les anciens noms.
D’après mon expérience, j’ai vu des organisations utiliser aussi bien des racks de serveurs on-premise que Linode, AWS et Azure, et les plaintes sur l’infrastructure cloud étaient proportionnelles à l’usage des services managés.
Les équipes qui s’appuyaient surtout sur des machines virtuelles, avec au pire une base de données relationnelle managée, se plaignaient très peu.
Certes, il faut maintenir un peu plus de scripts, mais c’est un inconvénient mineur comparé aux problèmes et comportements bizarres des services managés.
Évidemment qu’une machine virtuelle classique est plus facile à maintenir qu’un service managé ; c’est justement pour éviter de le faire soi-même qu’on paie beaucoup plus cher au fournisseur cloud les services managés.
Est-ce que ça veut dire qu’au fond, cet effort n’a pas de sens ?
Comme beaucoup d’entreprises passent au cloud principalement pour les services managés, je ne pense pas qu’on puisse dire que ce point soit totalement consensuel.
Un client avait besoin d’un tunnel IPsec vers le VPC où se trouvaient ses serveurs de production, et comme on ne voulait pas maintenir nous-mêmes ce type de configuration juste pour un seul client, on a regardé les services proposés par AWS et il y avait une solution IPsec managée.
Puis le client nous a signalé que le tunnel était tombé, et la solution consistait à lui demander de redémarrer de son côté pour rétablir la connexion.
On peut activer la journalisation sur S3 pour essayer de comprendre pourquoi, mais selon AWS, tout était censé fonctionner normalement.
Même avec seulement EC2, il arrive des choses étranges.
Récemment, une instance EC2 a cessé de répondre, mais l’Auto Scaling Group ne l’a pas remplacée, et quelle que soit l’action tentée, une erreur indiquait que l’instance n’était pas en cours d’exécution alors que son statut disait qu’elle tournait.
Heureusement, mon responsable est d’accord, mais il n’a pas tous les pouvoirs.
Le verrouillage fournisseur et la compatibilité d’API avec l’open source, presque identique mais jamais tout à fait, m’inquiètent de plus en plus à mesure que davantage d’équipes adoptent ces services.
On nous dit : « Mais c’est plus simple ! » ; on verra bien.
Avant 2014 environ, AWS réduisait régulièrement les tarifs de ses services majeurs pour répercuter la baisse des coûts technologiques.
Azure n’aimait pas ça et s’est mis à s’aligner sur les prix d’AWS, en répliquant immédiatement les mêmes remises sur les mêmes services.
C’est une forme de prix prédateurs dont l’objectif est de tuer toute incitation à baisser les prix, puisqu’un concurrent ne peut plus gagner de parts de marché même en réduisant ses tarifs.
J’aurais vraiment voulu aimer Azure parce qu’il s’intègre bien aux outils, mais je me suis sans cesse heurté à des limitations de disponibilité des machines virtuelles et à des bizarreries d’UX
Sur AWS, je n’ai jamais eu à me demander si je pouvais obtenir une machine ni si ce que j’avais fait avait réellement été pris en compte
J’ai aussi envisagé plusieurs fois le FaaS d’Azure, mais aujourd’hui je suis clairement dans le camp du « n’utilisez pas ça, fuyez vite »
L’expérience autour d’Azure Functions est tellement étrange qu’on ne peut jamais s’y sentir à l’aise, et accéder aux logs ou aux autres artefacts binaires est extrêmement pénible
Il est tellement simple d’exécuter un build .NET autonome sur une machine virtuelle Windows/Linux vide qu’il n’y a aucune raison de s’encombrer de toute cette complexité supplémentaire
Et il y a aussi des comportements qui cassent l’automatisation, par exemple quand SQL Server envoie un callback indiquant qu’il est en cours d’exécution alors qu’en réalité il ne sera prêt que 20 minutes plus tard
Je suis à moitié convaincu que
terraform time_sleepn’a pas été créé spécialement pour contourner les problèmes d’AzureC’est de toute façon le même service qu’on finit par utiliser quand une function app a besoin de plus qu’une simple fonction, comme un temps d’exécution plus long ou l’absence de latence liée au cold start
App Services demande un temps d’adaptation, mais c’est un conteneur Win Server/IIS verrouillé avec FTPS intégré, endpoint de vérification d’état pour l’auto-réparation, déploiement avec stockage désigné, options d’auto-scaling et SLA à 99,95 %
Il y a quelques années, ce n’était pas terrible côté performances, mais les SKU Premium récents avec au moins 2 vCPU de CPU modernes ne posaient aucun problème
C’est plus cher qu’une machine virtuelle, mais gérer la sécurité et les mises à jour d’une VM de serveur web représente énormément de travail
J’ai racheté une entreprise hébergée sur Azure
Ils utilisaient Postgres managé et des services .NET sur Windows, et l’infrastructure était petite, autour de 200 à 300 cœurs et 1 To de mémoire
Tous les quelques jours, Microsoft arrêtait aléatoirement des instances pour maintenance et coupait le réseau pendant plus de 10 minutes
Le Postgres managé avait des performances catastrophiques, donc nous l’avons migré, mais un expert basé en Inde nous a conseillé d’utiliser un autre type de volume, puis après le redémarrage de l’instance, la base de données n’a pas pu remonter à cause de la latence I/O
Cet expert disait être occupé et a évité les réunions pendant 3 jours d’affilée, et la RCA a conclu, dans une documentation à moitié finie qui semblait probablement écrite par un LLM, que ce n’était sans doute pas leur faute, mais les graphiques racontaient une autre histoire
La seule chose dans laquelle ils battent GCP et AWS, c’est la vitesse de chargement du dashboard
Sauf que si on exécute en parallèle 2 opérations réseau similaires, ça échoue ou ça prend 10 fois plus de temps qu’en séquentiel, ce qui est triste
Fuyez, n’utilisez pas ça
Parmi tous les fournisseurs PaaS, Azure a les pires abstractions et services
En gros, tout le monde semble accepter de consommer ces services bizarres, et c’est triste de voir apparaître des emplois d’architecte cloud et d’expert pour ça
Il faut continuer à rendre les partenaires indispensables, donc on entretient des conceptions médiocres et des couplages lâches
C’est d’ailleurs ce que je pense de l’IT d’entreprise en général
J’ai hérité d’un chaos Azure dans une petite entreprise d’environ 30 développeurs, puis nous avons créé dans nos outils de développement des abstractions plus proches des standards du secteur pour les services dont nous avions besoin, avant de migrer sur Hetzner quelques années plus tard
Les développeurs ici ne voient pratiquement pas la différence
Nos outils gèrent le workflow et les abstractions de services, et ce sont des choses qui ne devraient pas changer selon le fournisseur
La facture mensuelle a été divisée par 10, et nous avons utilisé une partie de cet argent pour créer la meilleure expérience développeur imaginable
Je considère que c’était un excellent échange
Il n’y a selon moi que deux cas où un grand cloud se justifie
Soit à une échelle de MVP vraiment minuscule, soit dans un environnement gigantesque, mondialement distribué, qui a besoin d’élasticité
Rapporté à la plupart des entreprises, ces deux cas relèvent presque de l’exception
Je pense que n’importe quel utilisateur d’Azure pourrait dresser une liste de 100 raisons de ne pas utiliser Azure, et ce serait pareil pour la plupart des gros logiciels
Même avec peu d’exposition aux autres clouds, il était facile de voir que l’expérience utilisateur d’Azure est laissée à la traîne faute d’être correctement pilotée
Le nombre de pages où il faut cliquer sur « plus » pour que la barre de filtres fonctionne correctement devrait de toute évidence être de 0 aujourd’hui
C’est un pattern objectivement mauvais, présent depuis des années, qui « devrait » être facile à corriger, mais qui ne sera probablement jamais prioritaire
Au final, ce genre de problème n’est corrigé que si sa résolution fait partie des valeurs centrales de l’organisation ou si cela nuit clairement au chiffre d’affaires
Dans la communauté des utilisateurs, la publicité et la visibilité de ces problèmes restent toujours importantes
J’utilise à la fois AWS et Azure, et la seule chose que j’aime vraiment chez Azure, c’est le portail
Comme dans AWS 2.0, toute la miscellanée du cloud est abstraite, et il ne reste que les paramètres qu’il faut réellement manipuler et leurs relations
J’aime aussi AWS, mais chaque fois que j’arrive dans un environnement inconnu et que je dois rétroconcevoir toutes les connexions, j’ai besoin d’un verre à la fin
Les quelques jours où j’ai utilisé Azure, le portail était vraiment une souffrance
Chaque clic mettait 5 à 10 secondes à répondre, et pour de simples changements de configuration par défaut il m’est arrivé de regarder un spinner Ajax pendant plus de 2 minutes
Comment peut-on aimer travailler comme ça ?
On dirait que quelqu’un essaie délibérément de les rendre aussi confuses que possible, sans qu’on comprenne dans quel but
Je ne dis pas que ton avis est invalide ni que tu mens, mais même parmi les gens qui vivent chaque heure dans l’écosystème Azure, je n’ai jamais vu quelqu’un aimer le portail Azure
Si ce n’est pas le cas, c’est drôle
Je suis complètement à l’opposé, donc j’imagine que c’est juste une affaire de goût
J’ai pas mal utilisé les deux, et même si le dashboard Azure reste agaçant, en termes de facilité d’utilisation il est bien meilleur qu’AWS
Et en plus, Microsoft investit visiblement du temps et de l’argent dans sa documentation, alors que celle d’AWS a toujours été médiocre
Si c'est une petite entreprise et que vous n'exploitez pas de conteneurs, Cloudflare est un cloud largement sous-estimé
Je sais qu'il est critiqué pour d'autres raisons, mais si vous en avez assez des big 3 ou 4, l'expérience développeur y est vraiment excellente
[1]: https://blog.cloudflare.com/container-platform-preview/
J'aime bien pour un site Svelte, mais être limité par le langage et par des contraintes basées sur le modèle requête-réponse, c'est une énorme limite
Au minimum, il faudrait des conteneurs et des volumes persistants pour que ça m'intéresse
Je déteste vraiment Azure avec passion
Je fais partie d'une équipe qui construit des outils pour automatiser la création de projets/comptes/abonnements selon les fournisseurs cloud
Notre fournisseur principal est GCP, et l'implémentation a été plutôt simple
Il y avait quelques pièges, mais ils étaient faciles à contourner
Maintenant, on doit prendre en charge Azure dans une logique multicloud
Avant, on était sur AWS, mais on en est sortis à 95 % ; il reste encore quelques équipes, mais à part des modules Terraform, on ne développe presque plus d'outils
Mais les API Azure, l'API MS Graph, et leurs SDK Go réunis sont le plus gros tas d'ordures que j'aie jamais eu à manipuler
Tout est en pointeurs, et même les littéraux de chaîne doivent parfois devenir des pointeurs, sauf que parfois non
La documentation est inexacte, certaines API n'acceptent que des ID alors que d'autres exigent le chemin complet
Certaines choses sont documentées, mais beaucoup d'API indiquent un format erroné
Aucune API ne renvoie les ID des ressources associées, donc il faut tout rechercher, avec beaucoup trop de recherches par nom
On a même dû ajouter une couche de cache d'ID pour éviter d'interroger en boucle les mêmes ressources pendant leur création
Nous utilisons une machine à états pour la création et pouvons reprendre à partir d'un point intermédiaire, donc il faut beaucoup de code de vérification et de reprise
Globalement, c'est le pire fournisseur cloud en matière de conception et d'implémentation, et si j'avais le choix, je ne le recommanderais ni ne le choisirais jamais
Ce qui est écrit en interne en Go est généralement excellent
Nous en avons développé un en interne, mais les options tierces nous intéressent aussi
Cela dit, à cause de nos règles métier internes, il est peut-être plus logique de le construire nous-mêmes que de l'acheter