Le cluster Postgres de Fly.io est en panne depuis 3 jours, sans aucune communication à ce sujet.

 (community.fly.io)
2 points par GN⁺ 2023-07-21 | 1 commentaires | Partager sur WhatsApp
  • Lors d'une maintenance d'urgence (emergency maintenance) sur des hôtes Fly.io en juillet 2023, des machines de plusieurs utilisateurs se sont retrouvées bloquées à l'état "stopped" ou en état zombie, rendant impossibles le redémarrage, la suppression et le redéploiement
  • Le tableau de bord n'affiche qu'une bannière "Service Interruption", tandis que la status page ne contient aucune information connexe, ce qui empêche de connaître la cause ou une ETA de rétablissement
  • Les commandes fly machine échouent avec l'erreur "could not get machine", et des données anormales apparaissent, comme une date de création affichée à "1970-01-01" dans la liste des machines
  • Certains ont pu rétablir temporairement le service en lançant de nouvelles VM avec fly scale, mais les VM défectueuses restent impossibles à supprimer, avec la crainte d'une facturation continue
  • Après plus de 12 à 15 heures sans réponse officielle ni mise à jour d'état, la confiance dans la plateforme s'en trouve dégradée

Survenue de l'incident et premiers symptômes

  • Le matin, les health checks de l'application ont commencé à échouer, et les machines apparaissaient à l'état "stopped"
  • Le tableau de bord n'affichait qu'une bannière Service Interruption indiquant : "We are performing emergency maintenance on a host some of your apps instances are running on", sans autre information
  • L'incident n'apparaissait pas sur la status page, rendant introuvables la procédure de résolution ou une ETA
  • Toute tentative de redémarrer ou supprimer une instance de machine arrêtée entraînait un timeout
  • Lors d'un redéploiement, une erreur liée aux machines unmanaged survenait
    • fly deploy ne met à jour que les machines dont les métadonnées contiennent fly_platform_version=v2, il fallait donc mettre à jour chaque machine manuellement avec fly machine update --metadata fly_platform_version=v2 <machine id>

État des machines zombies et solutions de contournement

  • Certaines machines sont passées en "zombie mode" et toutes les commandes fly machine répondaient par "Error: could not get machine"
  • En allouant des VM supplémentaires avec fly scale, il a été possible de rétablir la disponibilité de l'application, mais les VM défectueuses sont restées dans un état indéterminé, empêchant leur suppression ainsi que la suppression du compte
  • fly machine list affichait des données erronées, comme une date de création "1970-01-01T00:00:00Z"
  • Un autre utilisateur a lui aussi contourné le problème en créant de nouvelles machines via un scale-up, mais les machines d'origine restaient impossibles à supprimer à cause d'une erreur "connection refused"
    • Il s'inquiétait d'être facturé à la fois pour les VM zombies non nettoyées et pour les VM supplémentaires créées
  • L'environnement de staging était dans le même état

Impact sur les conteneurs de base de données

  • Un utilisateur subissait le même problème depuis environ 14 heures, et comme la cible était un conteneur de base de données, un simple scale-up ne permettait pas de rétablir le service
  • Il avait envoyé un e-mail au support plusieurs heures plus tôt via une offre payante, sans obtenir de réponse
  • L'application concernée étant hébergée dans la région syd, il a été évoqué qu'un ou deux hôtes de cette zone pouvaient être en cause

Impact étendu et rétablissement temporaire

  • Jusqu'à la veille, l'application et Postgres fonctionnaient avec 4 machines (staging et production), mais 3 restaient toujours en panne, dont les deux bases de données
  • Comme il s'agissait de l'application d'API externe de l'entreprise, toutes les intégrations étaient interrompues
  • Pour maintenir l'exploitation, un nouveau projet a été créé sur Fly afin d'y lancer des instances, et il a fallu quelques heures pour reconstituer les variables d'environnement et la configuration
    • Cela s'est transformé, malgré eux, en test des capacités de DR (reprise après sinistre)
  • Il n'y avait aucun moyen de récupérer les données depuis la machine de base de données, mais comme ce n'était pas la base de production principale, le nécessaire a pu être reconstitué par rétro-ingénierie

Inquiétudes sur la fiabilité de la plateforme

  • De la surprise est exprimée face à l'absence de réponse officielle après 12 heures
  • C'était la deuxième fois qu'ils subissaient le même problème : même quand le service est indisponible, Fly continue d'indiquer que tout va bien, sans information ni action possible autre que d'attendre
  • Comparaison avec Heroku : lorsqu'un hôte devenait instable, les dynos étaient automatiquement déplacés, ce qui évitait ce type d'inquiétude
  • Le problème est survenu sur une petite application standard Rails + Postgres, ce qui alimente la crainte qu'une application plus complexe serait encore plus difficile à gérer
  • Ces incidents sont décrits comme détruisant complètement la confiance dans la plateforme

À lire aussi

1 commentaires

 
GN⁺ 2023-07-21
Avis sur Hacker News

  • Fly a répondu dans le fil de support : l’entreprise explique qu’elle consulte régulièrement le forum, mais qu’elle a manqué ce message, et qu’une panne d’un seul hôte dans la région syd s’est prolongée
    L’hôte n’est pas revenu à la normale après un redémarrage et ne s’est pas non plus reconnecté au service discovery, ce qui a nécessité une restauration manuelle
    Les applications exécutées sur plusieurs instances n’ont vu qu’une partie de leurs instances touchées, mais les applications à instance unique étaient inaccessibles pendant la panne, et Fly recommande fortement une configuration à plusieurs instances
    Les incidents globaux ou régionaux sont publiés sur status.fly.io, et les problèmes touchant un seul hôte étaient jusqu’ici affichés dans l’onglet d’état du tableau de bord, mais Fly dit réexaminer sa manière de communiquer lors d’une panne prolongée d’un seul hôte comme celle-ci
    https://community.fly.io/t/service-interruption-cant-destroy...

    • Moi aussi, j’ai quitté Fly à cause de ce genre de problème. Au début, l’application web sur une machine Fly n’arrivait que par intermittence à se connecter à une nouvelle machine PostgreSQL de production, puis la machine PostgreSQL est complètement morte et j’ai perdu toutes les données
      Comme le redémarrage ne l’a pas rétablie, j’ai restauré une ancienne sauvegarde sur RDS, et je me suis dit que j’avais bien fait de migrer
    • Si le fil a vraiment été manqué, je ne comprends pas pourquoi il est devenu privé, visible uniquement par les utilisateurs connectés
    • Je me demande si perdre un seul hôte devrait vraiment être un si gros problème aujourd’hui. Les pannes d’instance arrivent forcément, et même si un client ne fait tourner qu’une seule instance, on s’attendrait à ce qu’elle soit automatiquement replacée, surtout chez un service centré sur les conteneurs comme Fly.io
      En plus, cela ressemble non pas à un simple conteneur utilisateur, mais à un service PostgreSQL managé ; il semble donc encore plus légitime d’attendre une résilience face à la panne d’un hôte
    • J’ai trouvé étrange que le support en cas d’incident de plateforme repose sur un forum que les employés peuvent voir ou non. D’après la documentation[1], il faut une offre payante, au minimum 29 $ par mois, pour obtenir du support par e-mail ; on peut donc payer les ressources sans forcément avoir de support
      Je pourrais payer autour de 5 à 10 $ par mois, mais je n’utiliserai pas ce service pour un side project pour lequel je ne veux pas subir une panne de 3 jours
      [1] https://fly.io/docs/about/support/
    • C’est à la fois ironique et tragique : plus on rend un service facile d’accès, plus on a besoin d’experts capables de gérer les couches bas niveau, beaucoup plus frictionnelles, qui se trouvent dessous
      Si la panne durait depuis plusieurs heures, ils auraient dû lancer une nouvelle machine avec Ansible ou autre. Cela aurait dû être possible, que ce soit sur du matériel physique ou sur une machine virtuelle AWS/GCP

  • Fly a rendu le fil[1] privé pour les personnes non connectées, comme si l’entreprise cherchait à étouffer le problème
    Dans ce fil, certains expliquaient que le service était hors ligne alors que l’état de Fly indiquait un fonctionnement normal, sans aucune information disponible ni autre option que d’attendre
    Un autre utilisateur disait que trois machines sur quatre — son application ainsi que les PostgreSQL de staging et de production — étaient toujours hors ligne, et que son application d’API externe était cassée, ce qui faisait échouer toutes les intégrations
    Il disait avoir mis plusieurs heures à créer un nouveau projet Fly et à lancer une instance temporaire, sans trouver comment récupérer les données depuis la machine de base de données
    D’autres réactions estimaient insultant que la page d’état de l’organisation affiche « aucun incident » alors que, sur cette même page, l’application était indiquée en maintenance et inaccessible
    Certains messages indiquaient aussi qu’en 17 heures, il n’y avait eu quasiment aucune mise à jour sur la page d’état ni notification, seulement des alertes Better Stack
    Sauvegarde complète du fil : https://pastebin.com/ebmCSZkC
    Tweet envoyé au CEO de Fly : https://twitter.com/SouthPawNZ/status/1682181533673857024
    [1] https://community.fly.io/t/service-interruption-cant-destroy...

  • Le pire avec Fly, c’est que quand quelque chose déraille, ce n’est pas une seule chose qui casse, mais plusieurs en même temps, tandis que la page de statut reste entièrement au vert.
    En général, la réaction est soit le silence, soit une attitude beaucoup trop légère du genre « voilà ce qui arrive quand on déploie un vendredi ».
    Le produit a l’air sympa, mais j’ai l’impression que c’est le service d’hébergement le plus instable que j’aie utilisé, joliment emballé.
    On ne peut pas casser le travail des gens toutes les semaines, les obliger à passer leurs soirées de week-end à réparer, puis conclure par « on aurait pu faire mieux ». Ça peut excuser une exception, pas un schéma qui se répète.

    • Copier la gestion des pages de statut à la AWS pendant les incidents de service, c’est audacieux.

  • Il y a beaucoup de bruit dans ce fil HN, mais l’essentiel me semble être ceci : les employés semblaient voir le problème avant même que les clients ne s’en rendent compte, plusieurs heures se sont écoulées avant une réponse même après un e-mail au support payant, et une mise à jour sur l’hôte en panne n’est arrivée qu’au bout d’environ 20 heures.
    Les utilisateurs touchés n’ont pas été correctement informés de la panne de l’hôte ni de la méthode de récupération, et le tableau de bord affichait une maintenance urgente tandis que la page de statut indiquait que tout était normal.
    Je comprends qu’avec les caractéristiques du plan et de l’architecture, ce type d’indisponibilité soit garanti et courant, mais avec une communication aussi mauvaise, on perd des clients.
    Si, comme chez d’autres fournisseurs, je recevais un e-mail dès que l’hôte sur lequel je suis présente le moindre souci, je pourrais au moins agir tout de suite sur mon application.

    • De mon point de vue, ce n’est pas un bon résumé. Le support de l’offre gratuite reposait sur le fait de remarquer l’activité sur le forum, ce qui a été manqué, et les personnes touchées ont vu les conséquences d’un déploiement dans une configuration non hautement disponible.
      En revanche, les avis divergent sur le fait qu’elles savaient suffisamment qu’elles étaient dans cet état.
      Un serveur précis a subi une panne anormalement longue, et l’ensemble de ces éléments a fait que beaucoup de gens ont connu une longue interruption sans explication.
      Le tableau de bord ne montre que les pannes de région/service, pas les pannes de serveurs individuels, et les gens l’ignoraient, ce qui leur a donné l’impression d’un mensonge.
      Un comportement étrange dans la configuration des tags Discourse a donné l’impression qu’on cherchait à cacher le problème.
      En résumé, je vois surtout un cas de malchance, de mauvaises procédures côté gestion client, et peut-être une documentation en partie insuffisante ; il y avait plus de fumée que de feu.
    • Pour clarifier en tant qu’employé de Fly.io : dans les 30 minutes suivant la chute de cet hôte unique, nous avons informé tous les clients concernés via leur page de statut personnalisée[1], puis, environ 47 heures plus tard, une fois le problème résolu, la page de statut l’a aussi indiqué comme résolu.
      La chronologie, en UTC, était la suivante : 2023-07-17 16:19, hôte hors service ; 16:49, publication sur la page de statut personnalisée ; 2023-07-19 15:00, hôte rétabli ; 15:17, page de statut marquée comme résolue.
      [1] https://community.fly.io/t/new-status-page/11398
    • Imaginez à quoi ressemblerait AWS s’il devait mettre à jour sa page de statut globale à chaque fois qu’un seul hôte tombait dans une région.
      Fly.io ne voulait pas devenir un clone de Heroku, mais à cause de son marketing et de son expérience utilisateur très soignée, c’est finalement l’image qu’il donnait.
      Résultat : il doit aussi composer avec une base d’utilisateurs à la Heroku, capable de porter un gros coup à la marque à chaque panne d’un hôte unique.
    • J’ai vécu la même chose en utilisant Fly pour un projet personnel. Le projet était hors ligne, mais la page de statut indiquait que tout était normal.
      Pour un projet perso fait pour le fun, ce n’était pas grave, mais je ne suis pas sûr que je l’utiliserais pour quelque chose de plus sérieux.
    • S’il y a de mauvaises informations, je pense qu’il vaut mieux répondre directement au message concerné plutôt que de faire ce genre de généralisation.
      Et j’ai du mal à croire qu’il existe beaucoup de fournisseurs cloud pour lesquels 20 heures d’indisponibilité seraient qualifiées de « garanties et normales ».
      Malheureusement, dans les fils HN liés à Fly.io, j’ai souvent ressenti pas mal de passif-agressif.

  • J’avais vraiment envie d’aimer Fly.io. La configuration et l’utilisation sont très simples, mais honnêtement, je ne pense pas qu’il faille y faire tourner des applications critiques.
    J’ai fini par tout migrer vers AWS, et ce n’était vraiment pas ce que je voulais.
    Les machines ne fonctionnaient souvent pas, il y avait des pannes aléatoires, les builds échouaient, et même après avoir payé une offre supérieure pour le support, celui-ci répondait lentement et ne lisait pas correctement les questions.
    Impossible d’ajouter un sidecar, difficile de l’intégrer à de la supervision externe, et la documentation est correcte pour le chemin nominal mais très insuffisante sur les cas limites.
    Pour des projets hobby, c’est très bien, et j’y héberge encore beaucoup de projets personnels, mais pour l’infrastructure de l’entreprise, le coût en temps et en frustration est devenu trop élevé et nous avons dû partir.
    Ça ressemblait au successeur spirituel de Heroku, donc j’avais de grandes attentes, mais à mon avis ce n’est pas encore à ce niveau.

    • J’ai eu la même expérience. Même sur un projet hobby récent, je n’ai rien pu builder pendant deux jours d’affilée, donc j’ai arrêté de l’utiliser.
      La semaine précédente, ça buildait, en local ça marchait bien, et plus tard ça a aussi remarché sur Fly, mais c’était une indisponibilité incompréhensible, sans explication de la cause ni réponse du support.
      L’offre gratuite est très généreuse, on peut faire beaucoup de choses en restant sous le seuil de facturation, mais j’ai peu de temps libre et, pendant ce temps-là, je veux juste builder mon projet.
      Ce n’était pourtant qu’un petit site statique buildé avec Node.
      L’outil lui-même est excellent, donc j’aimerais le réessayer s’ils stabilisent l’infrastructure.
    • La moitié des informations importantes nécessaires pour utiliser le service sont enfouies dans un fil quelconque posté par un employé sur le forum.
      Si, avec le même effort, ils n’arrivent pas à mettre ces informations dans la documentation, je ne sais pas à quel point leur pipeline de documentation est mauvais.
      Les réponses aux questions d’utilisation sur le forum devraient être « c’est dans la doc ; si ce n’était pas le cas, on vient de l’ajouter » et « si ce n’est pas clair, dites-le-nous, on mettra la doc à jour ».
    • J’ai eu la même expérience. Le tableau de bord Fly disait que tout était normal, mais les requêtes expiraient.
      J’ai dû fouiller moi-même dans les logs fly pour voir que le proxy n’arrivait pas à joindre le serveur, et je n’avais aucun moyen de corriger ça.
      Quelques heures plus tard, j’ai posté un problème sur le forum, mais je n’ai eu ni réponse ni signe que quelqu’un l’avait lu ; peu après, ça s’est réparé comme par magie.
      J’espère qu’ils réussiront, mais à cause de cette absence de communication et du sentiment d’impuissance de ne rien pouvoir faire, je n’utiliserai plus fly.io pour l’instant.
    • Je me demande si vous avez essayé Render. Quel est, selon vous, le successeur de Heroku ?
    • Mon expérience a aussi été plutôt décevante. J’ai finalement migré un projet jouet vers une VM Hetzner + Dokku : le nœud de base de données PostgreSQL s’était arrêté sans aucune notification et n’est pas revenu avant que je le relance manuellement.

  • Ce ne sera sans doute pas une réponse très satisfaisante, mais à titre personnel, c’est à peu près tout ce que je peux dire : je n’ai aucune idée de la raison pour laquelle ce fil de notre site communautaire a été retiré de la liste
    Je regarde l’interface d’administration : il y a un petit cadenas à côté du post, mais l’option « unlist story » reste cliquable
    Le mieux que je puisse dire, c’est que je suis assez convaincu qu’il n’y a pas eu de directive venue d’en haut demandant de masquer ce fil. Le site est public et n’importe qui peut créer un compte pour voir le fil
    Dites ce que vous voulez de nous, mais nous cacher dans ce genre de situation ne fait pas partie de nos défauts
    Pour le problème des serveurs de Sydney, je n’en sais pas encore assez pour donner une réponse utile aux personnes qui y faisaient tourner des instances. Je reviens de sortie et je commence tout juste à comprendre ce qui se passe
    Ah, apparemment tous les posts de la catégorie app-not-working semblent « private », et c’est probablement un réglage de catégorie. Ici, private signifie qu’il faut s’inscrire avec un compte Discourse pour les voir

    • Pour être franc, et ça s’adresse sans doute davantage à Kurt, l’entreprise a besoin de meilleurs processus, de responsabilité et de communication
      Le ton de cette réponse et des autres communications de fly.io me semblent indiquer, vu l’opinion publique sur fly.io, que ces éléments font défaut
      Avec plus de 60 employés et autant de problèmes, cela ressemble moins à un ton humain et attachant qu’au symptôme d’une entreprise qui n’arrive pas à passer à l’échelle
      Pour qu’une activité B2B en croissance réussisse, il faut des choses comme des processus et de la supervision ; or, à lire d’autres réponses, on dirait que vous n’en voulez pas, ce qui est mauvais signe
      Une fois, c’est un incident ; deux fois, c’est de la malchance ; trois fois, c’est un processus cassé. À lire les commentaires ici, chez Fly.io ça semble casser bien plus souvent que trois fois
    • La conclusion que je tire de cette réponse, c’est que si j’avais choisi Fly.io au travail, je pourrais me faire licencier
      Pas à cause de la panne elle-même, mais parce qu’il peut falloir plusieurs jours pour obtenir du support
      Quelle garantie pouvez-vous donner à la communauté que le support sera meilleur la prochaine fois ?
    • C’est probablement parce que c’est hébergé dans la région SYD
    • Je ne sais pas pourquoi la catégorie app-not-working revient de fait à retirer les fils de la liste, mais je l’ai supprimée pour l’instant en attendant d’en trouver la cause, et ce fil est donc de nouveau public
    • J’aime vraiment beaucoup le travail de Thomas, et je pense que cette approche est la bonne. À titre de référence, https://fly.io/blog/carving-the-scheduler-out-of-our-orchest... est l’un de mes articles préférés du blog de Fly
      Nous faisons tourner https://changelog.com sur Fly.io depuis avril 2022, et notre architecture actuelle se trouve ici : https://github.com/thechangelog/changelog.com/blob/master/IN...
      En 15 mois, nous avons traité plus de 100 millions de requêtes sur Fly.io avec une appli Phoenix + PostgreSQL, et il est difficile de trouver de quoi se plaindre
      Quelques déploiements ont échoué et ont été corrigés en relançant le pipeline ; début juillet 2023, à Francfort, 9 000 requêtes ont renvoyé des 503 pendant 10 secondes ; et un volume qui ne se supprimait pas pendant une expérimentation avec Machines a disparu le lendemain, à peu près tout ce qu’il y a eu
      Nous parlons souvent de notre expérience avec Fly.io dans le podcast Kaizen : https://changelog.com/topic/kaizen
      Épisode annonçant la migration : https://changelog.com/shipit/50
      PR liée : https://github.com/thechangelog/changelog.com/pull/407
      Nous avons aussi récemment parlé du plan de migration d’apps v1 (Nomad) vers apps v2 (flyd) : https://changelog.com/friends/2#transcript-138
      Je suis désolé que beaucoup de gens n’aient pas eu une bonne expérience, mais je pense que Fly.io continuera à s’améliorer. J’espère qu’un jour cette période difficile fera une bonne histoire à raconter
      Un post qui donne de l’espoir : https://community.fly.io/t/reliability-its-not-great/11253

  • J’aime beaucoup fly.io et j’espère qu’ils réussiront. Ils font quelque chose de difficile, donc ça peut casser
    Cela dit, le manque de communication est décevant, d’autant plus que c’est un point que le CEO avait lui-même identifié comme à corriger dans son grand post de mars sur la fiabilité adressé à la communauté
    https://community.fly.io/t/reliability-its-not-great/11253#s...

    • Quand on a déjà joué la carte « on a merdé, mais on va corriger le tir », ça devient compliqué si l’on n’arrive toujours pas à corriger le tir
    • Merci pour ce retour honnête. Nous aurions pu mieux communiquer sur le problème
      Nous affichons les pannes d’hôte unique dans le tableau de bord des utilisateurs touchés, et nous répercutons les problèmes de plateforme/région sur la page de statut, mais il existe clairement une zone intermédiaire où le statut que nous communiquons ne correspond pas à l’expérience réelle des utilisateurs
      Nous avons ajouté beaucoup de matériel pour éviter les récents problèmes de capacité et, comme prévu, la probabilité de panne globale a diminué, mais le volume de pannes sous forme matérielle a augmenté
      Nous pouvons encore faire davantage pour aider les utilisateurs à éviter ces problèmes, accélérer la récupération et mieux les informer lorsqu’ils sont touchés
      Même lorsque nous nous trompons dans notre communication, nous écoutons ce genre de retours

  • Le signal d’alerte le plus important est que Fly ne semble pas disposer de méthode automatisée pour déplacer rapidement les workloads d’un serveur en panne vers un serveur sain
    Et ce, alors même que les conteneurs et les orchestrateurs ont abstrait le concept de volumes de données attachables/détachables
    Bien sûr, fournir cela demande un gros investissement technique, et c’est à mon avis l’une des raisons pour lesquelles le stockage est cher chez les trois grands clouds. Mais si l’on propose un service de persistance des données, c’est une capacité indispensable
    Il y a un décalage entre ce que Fly veut proposer et ce que le marché attend
    Fly voulait innover en permettant d’exécuter des apps dans plusieurs datacenters, mais sans véritable service de persistance des données, cette fonctionnalité n’est pas utile pour la majorité des utilisateurs
    Ils semblent vouloir résoudre le problème de persistance avec la réplication SQLite, mais cela obligerait la plupart des développeurs à changer leur façon de développer des apps pour l’adapter à la plateforme Fly
    Fly doit choisir entre devenir une alternative stable et bon marché à Heroku, ou proposer une façon propre à elle de développer des apps offrant les meilleures performances aux utilisateurs du monde entier
    App Engine est un cas intéressant. Il était en avance sur son temps et prescrivait une façon de développer capable de monter en charge jusqu’à des trafics très élevés, mais les gens n’avaient pas envie de changer leur façon de développer pour s’y conformer

    • N’ont-ils pas déjà pivoté une fois ? Vu leur taille actuelle et plus de 100 millions de dollars levés, je pense que ce serait très difficile de le refaire
      En ce moment, ils donnent l’impression de courir partout, un incendie en chassant un autre, ce qui n’inspire pas confiance dans leur roadmap technique
      Cela ne fait-il pas déjà environ deux ans que beaucoup de gens ont mis Fly.io dans leur liste “à revoir plus tard” ?
      Quand les gens vous perçoivent comme instable, il est vraiment difficile de restaurer sa réputation, surtout dans l’IT
    • Fly n’a pas de stockage connecté à distance ; tout repose sur des volumes basés sur LVM locaux aux nœuds
      La persistance des données se fait via des snapshots LVM toutes les 24 heures, ou créés manuellement, exportés vers S3
      À mon avis, ce n’est vraiment pas un endroit où faire tourner des workloads persistants. Si vous y exécutez PostgreSQL, il faut être prêt à charger les données à chaud dans une nouvelle instance ou à restaurer depuis une sauvegarde

  • C’est pour la même raison que je déconseille depuis longtemps d’utiliser Fly sur HN : https://news.ycombinator.com/item?id=31394179
    Après avoir demandé la suppression de mon compte, celui-ci s’est retrouvé dans une sorte de shadow ban, sans aucune communication
    J’ai aussi envoyé des e-mails, mais je n’ai jamais reçu de réponse, et depuis j’ai tout migré vers des apps Railway et Google Cloud Run

    • Tu veux dire qu’après avoir supprimé ton compte, tu as essayé de te réinscrire avec l’adresse e-mail supprimée ?
      Pourquoi une entreprise te mettrait-elle en shadow ban simplement parce que tu as posé une question anodine ?

  • Ce qui est intéressant, c’est que j’ai l’impression que l’histoire se répète avec Fly.io. C’est similaire à ma première rencontre avec Heroku
    L’ancien Fly.io était frais et enthousiasmant, comme Heroku à ses débuts, et j’admirais sa simplicité et sa facilité d’utilisation
    Mais avec le temps, de petits signaux d’alerte sont apparus, les interruptions sont devenues plus fréquentes, et les déploiements qui étaient rapides et fluides sont devenus péniblement lents
    C’est comme un déjà-vu de l’époque où les atouts de Heroku commençaient à disparaître
    C’est dommage, car Fly.io semble suivre le même chemin : plus la plateforme attire de monde, plus les performances se dégradent, et plus elle devient populaire, moins elle paraît fiable
    Cela ressemble à un avertissement sur la manière dont une plateforme prometteuse peut chuter, et j’espère que Fly.io parviendra à sortir de ce cycle et à trouver sa place avant de devenir aussi inutile que Heroku à son plus bas

    • À l’époque, j’avais été un peu inquiet en voyant que Fly offrait gratuitement des ressources assez importantes et les présentait même implicitement comme une fonctionnalité dans sa documentation
      Je me suis demandé s’ils ne surestimaient pas la conscience professionnelle du secteur ; il était évident qu’une fois aussi connu que Heroku, cela attirerait des gens qui ne veulent pas payer
      Pour tenter à nouveau une offre gratuite généreuse, il faut soit une organisation anti-abus solide et coûteuse, soit des poches assez profondes pour déverser du matériel afin d’absorber l’absence initiale de contrôle
      Fly ne semble fort ni dans l’un ni dans l’autre. C’est aussi pour ça que je les apprécie. Ces choses-là ressemblent à des absurdités de grandes entreprises, et Fly dégage moins cette odeur
      Mais je ne serais pas surpris que les ingénieurs de Fly passent l’essentiel de leur temps à gérer des mineurs de cryptomonnaies opportunistes, des escrocs et des abuseurs, ainsi qu’à optimiser l’allocation des ressources et les limites automatiques, plutôt qu’à améliorer la fiabilité de l’infrastructure à long terme ou l’expérience développeur
    • J’ai le même sentiment
      Je me demande si c’est lié à l’échelle. Au moment où une entreprise obtient assez de clients payants pour devenir rentable ou finançable, n’accumule-t-elle pas en même temps assez de problèmes pour passer progressivement de cette impression initiale de fraîcheur et d’enthousiasme à quelque chose qui ressemble aux anciens concurrents qu’elle voulait remplacer ?
      C’est aussi ce que j’ai vécu. Quand une entreprise passe de la taille “quelques pizzas” à “on a réservé une salle pour l’événement”, l’entropie s’infiltre, et des adages comme la loi de Conway ou la loi de Brooks deviennent de plus en plus évidents