Der Postgres-Cluster von Fly.io war 3 Tage lang ausgefallen, ohne jegliche Meldung dazu

 (community.fly.io)
2 Punkte von GN⁺ 2023-07-21 | 1 Kommentare | Auf WhatsApp teilen
  • Im Juli 2023 kam es während einer Notfallwartung (emergency maintenance) eines Fly.io-Hosts zu einem Vorfall, bei dem Maschinen mehrerer Nutzer in einem „stopped“- bzw. Zombie-Zustand hängen blieben und weder neu gestartet, entfernt noch neu bereitgestellt werden konnten
  • Im Dashboard erschien lediglich ein Banner „Service Interruption“, während auf der Status Page keine zugehörigen Informationen standen; Ursache und ETA für die Wiederherstellung waren nicht nachvollziehbar
  • fly machine-Befehle schlugen mit dem Fehler „could not get machine“ fehl, und in der Machine-Liste wurden auffällige Daten wie das Erstellungsdatum „1970-01-01“ angezeigt
  • Einige stellten per fly scale neue VMs bereit und konnten so vorübergehend wiederherstellen; die defekten VMs ließen sich jedoch nicht löschen, mit der Sorge, dass die Abrechnung weiterläuft
  • Über mehr als 12 bis 15 Stunden gab es keine offizielle Antwort oder Status-Updates, was zu einem Verlust an Plattformvertrauen führte

Auftreten der Störung und erste Symptome

  • Am Morgen begannen die Health Checks der App fehlzuschlagen, und die Maschine wurde als „stopped“ angezeigt
  • Im Dashboard wurde lediglich ein Service-Interruption-Banner mit „We are performing emergency maintenance on a host some of your apps instances are running on“ angezeigt, sonst keine Informationen
  • Auf der Status Page wurde diese Störung nicht angezeigt, sodass kein Lösungsablauf oder ETA zu finden war
  • Beim Versuch, die gestoppte Maschineninstanz neu zu starten oder zu entfernen, traten Timeouts auf
  • Bei einem erneuten Deployment trat ein Fehler im Zusammenhang mit unmanaged Machines auf
    • Da fly deploy nur Maschinen aktualisiert, deren Metadaten fly_platform_version=v2 enthalten, müssen einzelne Maschinen mit fly machine update --metadata fly_platform_version=v2 <machine id> manuell aktualisiert werden

Zustand der Zombie-Machines und Workaround

  • Einige Maschinen gingen in den „zombie mode“ über und antworteten auf alle fly machine-Befehle mit „Error: could not get machine“
  • Durch das Hinzufügen weiterer VMs per fly scale wurde die Verfügbarkeit der App wiederhergestellt, die defekte VM blieb jedoch in einem unklaren Zustand und konnte weder entfernt noch das Konto gelöscht werden
  • fly machine list zeigte falsche Daten wie das Erstellungsdatum „1970-01-01T00:00:00Z“ an
  • Ein weiterer Nutzer umging das Problem ebenfalls durch Hochskalieren und Erstellen einer neuen Maschine, die ursprüngliche Maschine konnte jedoch wegen eines „connection refused“-Fehlers nicht entfernt werden
    • Es bestand die Sorge, dass sowohl für die nicht bereinigten Zombie-VMs als auch für die zusätzlich erstellten VMs Kosten anfallen
  • Die Staging-Umgebung befand sich im gleichen Zustand

Auswirkungen auf Datenbank-Container

  • Ein Nutzer hatte seit etwa 14 Stunden zuvor dasselbe Problem; da das Ziel ein Datenbank-Container war, war eine Wiederherstellung durch einfaches Hochskalieren nicht möglich
  • Trotz bezahltem Plan wurde vor mehreren Stunden eine E-Mail an den Support geschickt, aber es gab keine Antwort
  • Da die betreffende App in der Region syd gehostet wurde, wurde die Möglichkeit erwähnt, dass dort ein oder zwei Hosts Probleme haben könnten

Breite Auswirkungen und provisorische Wiederherstellung

  • Bis zum Vortag wurden App + Postgres (Staging und Produktion) auf 4 Maschinen betrieben, doch 3 davon, darunter zwei Datenbanken, waren weiterhin down
  • Da die betreffende App die externe API-App des Unternehmens war, wurden alle Integrationen unterbrochen
  • Um den Betrieb aufrechtzuerhalten, wurde auf Fly ein neues Projekt erstellt und eine Instanz gestartet; das Backfilling von Umgebungsvariablen und Konfiguration dauerte einige Stunden
    • Unbeabsichtigt wurde daraus ein Test der DR-Fähigkeiten (Disaster Recovery)
  • Es gab keine Möglichkeit, Daten von der DB-Maschine zu holen; da es sich jedoch nicht um die Haupt-Produktionsdatenbank handelte, wurden die benötigten Inhalte per Reverse Engineering wiederhergestellt

Sorgen um die Zuverlässigkeit der Plattform

  • Es wurde Verwunderung darüber geäußert, dass nach 12 Stunden keine offizielle Antwort vorlag
  • Es war bereits das zweite Mal, dass dasselbe Problem auftrat: Selbst wenn der Dienst down ist, meldet Fly alles als normal, und ohne Informationen oder Reaktion bleibt nur das Warten
  • Vergleich mit Heroku: Wenn ein Host instabil ist, wird das Dyno automatisch verschoben, sodass man sich darüber keine Sorgen machen musste
  • Da das Problem selbst bei einer kleinen, standardmäßigen Rails + Postgres-App auftrat, bestand die Sorge, dass die Reaktion bei komplexeren Apps noch schwieriger wäre
  • Es wurde formuliert, dass solche Probleme das Vertrauen in die Plattform vollständig zerstören

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-21
Hacker-News-Kommentare

  • Fly hat im Support-Thread geantwortet: Man prüfe das Forum regelmäßig, habe diesen Beitrag aber übersehen, und erklärte, dass es in der Region syd einen langanhaltenden Ausfall eines einzelnen Hosts gegeben habe
    Der Host sei nach dem Neustart nicht korrekt wieder hochgekommen und habe sich auch nicht erneut mit der Service-Discovery verbunden, weshalb eine manuelle Wiederherstellung nötig gewesen sei
    Apps, die mit mehreren Instanzen liefen, seien nur teilweise betroffen gewesen, aber Apps mit nur einer Instanz seien während des Ausfalls nicht erreichbar gewesen, und Fly empfehle nachdrücklich eine Konfiguration mit mehreren Instanzen
    Globale/regionale Ausfälle würden auf status.fly.io veröffentlicht, Probleme mit einzelnen Hosts bislang im Status-Tab des Dashboards angezeigt, aber man prüfe derzeit erneut, wie man bei langen Ausfällen eines einzelnen Hosts wie in diesem Fall kommunizieren solle
    https://community.fly.io/t/service-interruption-cant-destroy...

    • Ich habe Fly wegen solcher Dinge ebenfalls verlassen. Zuerst konnte die Web-App auf einer Fly-Maschine nur sporadisch eine Verbindung zu einer neuen Produktions-PostgreSQL-Maschine herstellen, danach starb die PostgreSQL-Maschine vollständig und alle Daten gingen verloren
      Auch ein Neustart half nicht bei der Wiederherstellung, daher wurde ein älteres Backup in RDS eingespielt, und im Nachhinein fühlte sich der Umzug richtig an
    • Wenn es wirklich nur übersehen wurde, verstehe ich nicht, warum der Thread dann privat nur für eingeloggte Nutzer sichtbar gemacht wurde
    • Heutzutage sollte der Verlust eines einzelnen Hosts doch eigentlich nicht so gravierend sein. Instanzausfälle kommen nun einmal vor, und selbst wenn Kunden nur eine einzelne Instanz betreiben, würde man besonders bei einer containerzentrierten Plattform wie Fly.io erwarten, dass automatisch neu platziert wird
      Außerdem klingt das nicht nach einem einzelnen Nutzer-Container, sondern nach einem Managed-PostgreSQL-Service, daher wirkt die Erwartung von Resilienz gegenüber Host-Ausfällen noch berechtigter
    • Es wirkte seltsam, dass der Support bei Plattformausfällen von einem Forum abhängt, das Mitarbeiter vielleicht sehen und vielleicht auch nicht. Laut Doku[1] braucht man für E-Mail-Support einen kostenpflichtigen Plan, mindestens 29 US-Dollar pro Monat, sodass man trotz Ressourcenverbrauch unter Umständen keinen Support bekommt
      5 bis 10 US-Dollar im Monat könnte ich zahlen, aber für ein Side-Project, das ich zwischendurch nicht anfassen möchte, würde ich keinen 3-tägigen Ausfall in Kauf nehmen
      [1] https://fly.io/docs/about/support/
    • Je mehr man Dienste mit niedriger Einstiegshürde baut, desto ironischer und tragischer ist es, dass man darunter Experten braucht, die sich um die friktionsreiche Low-Level-Schicht kümmern
      Wenn der Ausfall schon mehrere Stunden andauerte, hätte man meiner Meinung nach mit Ansible oder etwas Ähnlichem eine neue Maschine starten müssen. Das wäre sowohl mit Hardware als auch mit AWS-/GCP-VMs möglich gewesen

  • Fly scheint versucht zu haben, das Problem zu kaschieren, indem der Thread[1] für nicht eingeloggte Personen privat gemacht wurde
    Im Thread gab es Berichte, dass der Dienst ausgefallen war, der Fly-Status aber als normal angezeigt wurde, es keine Informationen gab und man nichts tun konnte außer zu warten
    Ein anderer Nutzer schrieb, dass drei von vier Maschinen weiterhin ausgefallen seien, darunter die App sowie staging/production PostgreSQL, und dass dadurch eine App mit externer API kaputtging und sämtliche Integrationen ausfielen
    Es habe mehrere Stunden gedauert, ein neues Fly-Projekt zu erstellen und eine temporäre Instanz hochzufahren, und man habe keinen Weg gefunden, die Daten von der DB-Maschine zu holen
    Es gab auch die Reaktion, dass es wie eine Beleidigung wirke, wenn die Statusseite der Organisation „keine Störung“ anzeigt, während auf derselben Seite Apps als in Wartung und nicht erreichbar markiert sind
    Ein weiterer Beitrag sagte, dass es 17 Stunden lang praktisch keine Updates oder Benachrichtigungen auf der Statusseite gegeben habe und nur Better-Stack-Benachrichtigungen eingingen
    Vollständiges Thread-Backup: https://pastebin.com/ebmCSZkC
    Tweet an den Fly-CEO: https://twitter.com/SouthPawNZ/status/1682181533673857024
    [1] https://community.fly.io/t/service-interruption-cant-destroy...

  • Das Schlimmste an Fly ist, dass, wenn etwas schiefläuft, nicht nur eine Sache kaputtgeht, sondern gleich mehrere gleichzeitig, und die Statusseite komplett grün aussieht.
    Die Reaktion ist meist Schweigen oder eine allzu lockere Haltung wie „So etwas passiert eben, wenn man am Freitag deployt“.
    Das Produkt sieht schick aus, aber es wirkt wie der am hübschesten verpackte instabile Hosting-Service, den ich je benutzt habe.
    Man kann nicht jede Woche die Arbeit der Leute kaputtmachen, sie ihre Wochenendabende mit der Wiederherstellung verbringen lassen und dann mit „Wir hätten das besser machen können“ abschließen. Das ist eine Entschuldigung für Ausnahmen, taugt aber nicht für ein wiederkehrendes Muster.

    • Bei einem Ausfall eine AWS-artige Statusseite als Vorbild zu nehmen, ist schon mutig.

  • In diesem HN-Thread gibt es viel Rauschen, aber der Kern ist aus meiner Sicht folgender: Die Mitarbeitenden schienen das Problem schon gesehen zu haben, bevor die Kunden es bemerkten, und selbst nach einer E-Mail an den bezahlten Support dauerte es mehrere Stunden bis zu einer Antwort, während ein Update zu dem ausgefallenen Host erst nach etwa 20 Stunden kam.
    Die betroffenen Nutzer wurden weder angemessen über den Host-Ausfall noch über Wiederherstellungsmöglichkeiten informiert, und obwohl das Dashboard eine Notfallwartung anzeigte, meldete die Statusseite überall Normalbetrieb.
    Ich verstehe, dass bei diesem Plan und dieser Architektur solche Downtimes gewissermaßen einkalkuliert und nicht ungewöhnlich sind, aber bei so schlechter Kommunikation verliert man Kunden.
    Wenn man mir wie andere Anbieter schon bei kleinsten Auffälligkeiten auf dem Host, auf dem ich liege, eine E-Mail schickt, kann ich wenigstens sofort etwas für meine App unternehmen.

    • Aus meiner Sicht ist das keine gute Zusammenfassung. Der Support für den Free Tier hing davon ab, Aktivität im Forum zu bemerken, und das wurde verpasst; die Betroffenen sahen letztlich die Folgen eines Deployments in einer nicht hochverfügbaren Konfiguration.
      Uneinigkeit besteht eher darüber, ob ihnen hinreichend klar war, dass genau das ihr Zustand war.
      Auf einem bestimmten Server gab es einen ungewöhnlich langen Ausfall, und in der Kombination führte das dazu, dass viele Leute ohne Erklärung von langen Störungen betroffen waren.
      Das Dashboard zeigt nur regionale bzw. serviceweite Ausfälle, aber keine Ausfälle einzelner Server; weil viele das nicht wussten, wirkte es wie eine Lüge.
      Ein seltsames Verhalten bei der Konfiguration von Discourse-Tags ließ es so aussehen, als wolle man das Problem verbergen.
      Kurz gesagt: viel Pech, schlechte Abläufe im Kundenumgang und möglicherweise teils mangelhafte Dokumentation, aber aus meiner Sicht war es eher viel Rauch als Feuer.
    • Als Fly.io-Mitarbeiter zur Klarstellung: Innerhalb von 30 Minuten nach dem Ausfall dieses einzelnen Hosts wurden alle betroffenen Kunden über ihre personalisierte Statusseite[1] informiert, und als das Problem nach etwa 47 Stunden behoben war, wurde die Statusseite ebenfalls als gelöst markiert.
      Die Zeitleiste in UTC war: Host-Ausfall am 2023-07-17 um 16:19, Eintrag auf der personalisierten Statusseite um 16:49, Host-Wiederherstellung am 2023-07-19 um 15:00, Statusseite um 15:17 auf gelöst gesetzt.
      [1] https://community.fly.io/t/new-status-page/11398
    • Man stelle sich vor, wie es aussähe, wenn AWS jedes Mal die globale Statusseite aktualisieren müsste, wenn in irgendeiner Region ein einzelner Host ausfällt.
      Fly.io wollte kein Heroku-Klon sein, wirkte durch Marketing und die polierte User Experience am Ende aber doch so.
      Dadurch musste man dann auch eine Heroku-artige Nutzerschaft bedienen, für die schon ein einzelner Host-Ausfall großen Markenschaden verursachen kann.
    • Ich nutze Fly für ein Privatprojekt und habe dasselbe erlebt. Das Projekt war down, aber die Statusseite meldete überall Normalbetrieb.
      Für ein Freizeitprojekt war das okay, aber für ernsthaftere Zwecke weiß ich nicht, ob ich es dafür nutzen würde.
    • Wenn da Fehlinformationen drinstehen, wäre es besser, direkt auf den betreffenden Beitrag zu antworten, statt solche Verallgemeinerungen zu ziehen.
      Und dass es viele Cloud-Anbieter geben soll, bei denen 20 Stunden Downtime als „garantiert und normal“ gelten, finde ich schwer nachvollziehbar.
      Leider habe ich in HN-Threads zu Fly.io immer wieder ziemlich viel passiv-aggressiven Ton wahrgenommen.

  • Ich wollte Fly.io wirklich mögen. Einrichtung und Nutzung sind sehr einfach, aber ehrlich gesagt finde ich nicht, dass man missionskritische Anwendungen auf diesem Dienst betreiben sollte.
    Am Ende habe ich alles zu AWS migriert, obwohl ich das wirklich nicht wollte.
    Maschinen liefen häufig nicht, es gab zufällige Ausfälle, Builds schlugen fehl, und obwohl ich wegen des Supports für einen höheren Tarif bezahlt habe, reagierte der Support langsam und las die Fragen nicht richtig.
    Man kann keine Sidecars hinzufügen, die Integration mit externem Monitoring ist schwierig, und die Dokumentation ist für den Happy Path okay, aber bei Edge Cases sehr lückenhaft.
    Für Hobbyprojekte ist es in Ordnung, und ich habe dort noch immer viele Privatprojekte laufen, aber für Firmeninfrastruktur wurden Zeit- und Frustkosten einfach zu hoch, sodass wir umziehen mussten.
    Es klang wie der geistige Nachfolger von Heroku, deshalb waren meine Erwartungen hoch, aber dieses Niveau erreicht es meiner Meinung nach noch nicht.

    • Meine Erfahrung war genauso. Selbst bei einem jüngsten Hobbyprojekt habe ich die Nutzung eingestellt, nachdem ich zwei Tage in Folge überhaupt nichts bauen konnte.
      In der Vorwoche funktionierte es, lokal lief es ebenfalls gut, und später ging es auch bei Fly wieder, aber es war eine unerklärliche Downtime ohne Erklärung der Ursache und ohne hilfreiche Support-Antwort.
      Der Free Tier ist sehr großzügig und erlaubt auch unterhalb der Abrechnungsgrenze eine ganze Menge, aber ich habe nur wenig freie Zeit und möchte in dieser Zeit einfach mein Projekt bauen.
      Es war nur eine kleine statische Site, die mit Node gebaut wurde.
      Das Tooling selbst ist großartig; wenn sie die Infrastruktur stabilisieren, würde ich es gerne wieder nutzen.
    • Die Hälfte der wichtigen Informationen, die man zur Nutzung des Dienstes braucht, ist in irgendeinem Thread vergraben, den ein Mitarbeiter im Forum gepostet hat.
      Wenn man es mit demselben Aufwand nicht in die Dokumentation schafft, weiß ich nicht, wie schlecht die Dokumentations-Pipeline sein muss.
      Die Antwort auf Nutzungsfragen im Forum sollte lauten: „Steht in der Doku, und falls nicht, haben wir es gerade ergänzt“ oder „Wenn etwas unklar ist, sagt uns Bescheid, dann aktualisieren wir die Doku“.
    • Ich hatte dieselbe Erfahrung. Das Fly-Dashboard sagte, alles sei in Ordnung, aber Requests liefen in Timeouts.
      Ich musste selbst in die Fly-Logs eintauchen, um zu sehen, dass der Proxy den Server nicht erreichen konnte, und ich hatte keine Möglichkeit, das selbst zu beheben.
      Einige Stunden später habe ich das Problem im Forum gepostet, aber es gab weder eine Antwort noch irgendein Zeichen, dass es gelesen worden war, und kurz darauf war es auf magische Weise behoben.
      Ich wünsche ihnen Erfolg, aber wegen dieses Mangels an Kommunikation und des Gefühls völliger Ohnmacht werde ich fly.io vorerst nicht mehr nutzen.
    • Hast du Render ausprobiert? Was würdest du als Nachfolger von Heroku ansehen?
    • Meine Erfahrung war ebenfalls eher enttäuschend. Ich habe mein Spielzeugprojekt am Ende auf eine Hetzner-VM + Dokku umgezogen, nachdem der PostgreSQL-Datenbankknoten ohne jede Benachrichtigung stehenblieb und nicht wieder hochkam, bis ich ihn manuell wiederbelebt habe.

  • Das ist wahrscheinlich keine besonders zufriedenstellende Antwort, aber persönlich kann ich nur so viel sagen: Ich habe keine Ahnung, warum dieser Thread auf unserer Community-Seite aus der Liste verschwunden ist
    Ich schaue gerade in die Admin-UI, und neben dem Beitrag ist zwar ein kleines Schloss, aber die Option „unlist story“ ist weiterhin anklickbar
    Das Beste, was ich sagen kann, ist, dass ich ziemlich sicher bin, dass es keine Anweisung von oben gab, diesen Thread zu verstecken. Die Seite ist öffentlich, und jeder kann ein Konto anlegen und den Thread sehen
    Man kann über uns sagen, was man will, aber so etwas zu verbergen gehört nicht zu unseren Schwächen
    Über das Problem mit dem Sydney-Server weiß ich noch nicht genug, um Leuten, die dort Instanzen betrieben haben, eine hilfreiche Antwort zu geben. Ich bin gerade erst von unterwegs zurück und verschaffe mir jetzt einen Überblick
    Ich sehe gerade, dass alle Beiträge in der Kategorie app-not-working als „private“ erscheinen, vermutlich wegen einer Kategorieeinstellung. Private bedeutet hier, dass man sich mit einem Discourse-Konto anmelden muss, um sie zu sehen

    • Wenn ich ehrlich raten soll, dann gilt das wohl eher Kurt, aber das Unternehmen braucht bessere Prozesse, Verantwortlichkeit und Kommunikation
      Der Ton dieser Antwort und andere Kommunikation von fly.io wirken angesichts der öffentlichen Meinung über fly.io wie ein Zeichen dafür, dass genau das fehlt
      Bei mehr als 60 Mitarbeitenden und so vielen Problemen wirkt das nicht wie ein menschlich sympathischer Ton, sondern wie ein Zeichen eines Unternehmens, das nicht skalieren kann
      Damit ein wachsendes B2B-Geschäft erfolgreich sein kann, braucht es Dinge wie Prozesse und Aufsicht; wenn man sich andere Antworten ansieht, scheint man das nicht zu wollen, und das ist kein gutes Signal
      Wenn etwas einmal kaputtgeht, ist es ein Vorfall, zweimal ist Pech, aber beim dritten Mal ist der Prozess kaputt. Den Kommentaren hier nach zu urteilen, geht bei Fly.io viel öfter als dreimal etwas kaputt
    • Mein Fazit nach dieser Antwort ist, dass ich vielleicht gefeuert werden könnte, wenn ich Fly.io auf der Arbeit ausgewählt hätte
      Nicht wegen der Störung selbst, sondern weil es Tage dauern kann, bis man Support bekommt
      Welche Zusicherung könnt ihr der Community geben, dass der Support beim nächsten Mal besser sein wird?
    • Wahrscheinlich, weil es in der Region SYD gehostet wird
    • Ich weiß nicht, warum die Kategorie app-not-working Threads faktisch aus der Liste entfernt, aber ich habe sie erst einmal entfernt, bis wir die Ursache finden, und dieser Thread ist jetzt wieder öffentlich
    • Ich mag wirklich, was Thomas macht, und halte diesen Ansatz für richtig. Nebenbei ist https://fly.io/blog/carving-the-scheduler-out-of-our-orchest... einer meiner Lieblingsbeiträge im Fly-Blog
      Wir betreiben https://changelog.com seit April 2022 auf Fly.io, und die aktuelle Architektur steht unter https://github.com/thechangelog/changelog.com/blob/master/IN...
      In 15 Monaten haben wir mit einer Phoenix- + PostgreSQL-App auf Fly.io mehr als 100 Millionen Requests verarbeitet, und ich finde kaum einen Grund zur Beschwerde
      Einige Deployments sind fehlgeschlagen und wurden durch erneutes Ausführen der Pipeline behoben, Anfang Juli 2023 lieferten in Frankfurt 9.000 Requests zehn Sekunden lang 503 zurück, und während des Machine-Experiments gab es ein Volume, das sich nicht löschen ließ und am nächsten Tag verschwunden war
      Im Kaizen-Podcast sprechen wir oft über unsere Erfahrungen mit Fly.io: https://changelog.com/topic/kaizen
      Die Episode zur Migrationsankündigung: https://changelog.com/shipit/50
      Zugehöriger PR: https://github.com/thechangelog/changelog.com/pull/407
      Kürzlich haben wir auch über den Migrationsplan von apps v1 (Nomad) zu apps v2 (flyd) gesprochen: https://changelog.com/friends/2#transcript-138
      Es tut mir leid, dass viele Leute keine guten Erfahrungen gemacht haben, aber ich glaube, Fly.io wird sich weiter verbessern. Hoffentlich wird diese schwierige Zeit irgendwann eine gute Geschichte
      Ein Beitrag, der Hoffnung macht: https://community.fly.io/t/reliability-its-not-great/11253

  • Ich mag fly.io sehr und wünsche ihnen Erfolg. Sie machen etwas Schwieriges, da kann etwas kaputtgehen
    Aber der Mangel an Kommunikation ist enttäuschend, besonders weil der CEO das in dem großen Zuverlässigkeitsbeitrag, den er im März in der Community gepostet hat, selbst als etwas benannt hat, das er verbessern möchte
    https://community.fly.io/t/reliability-its-not-great/11253#s...

    • Es wird schwierig, wenn man die Karte „wir haben es vermasselt, aber wir werden es in Ordnung bringen“ schon gespielt hat und es dann trotzdem nicht in Ordnung bringt
    • Ich bin dankbar für ehrliches Feedback. Wir hätten die Kommunikation über das Problem besser machen können
      Wir haben in den Dashboards betroffener Nutzer einzelne Host-Ausfälle angezeigt und Plattform-/Regionsprobleme auf der Statusseite abgebildet, aber es gibt eindeutig einen Zwischenbereich, in dem der kommunizierte Status und die tatsächliche Nutzererfahrung nicht übereinstimmen
      In letzter Zeit haben wir viel Hardware hinzugefügt, um Kapazitätsprobleme zu vermeiden, und wie erwartet ist dadurch die Wahrscheinlichkeit vollständiger Ausfälle gesunken, aber die Zahl hardwarebedingter Störungen gestiegen
      Wir können mehr tun, um Nutzern zu helfen, solche Probleme zu vermeiden, die Wiederherstellung zu beschleunigen und Betroffene besser zu informieren
      Auch wenn wir bei der Kommunikation Fehler machen, hören wir auf solches Feedback

  • Das größere Warnsignal ist, dass es bei Fly offenbar keinen automatisierten Weg gibt, Workloads schnell von einem ausgefallenen Server auf einen funktionierenden zu verschieben.
    Und das, obwohl Container und Orchestratoren das Konzept an- und abkoppelbarer Daten-Volumes abstrahiert haben.
    Natürlich erfordert so etwas große technische Investitionen, und ich denke, das ist auch einer der Gründe, warum Storage bei den Big 3 Clouds teuer ist. Trotzdem ist das eine zwingend notwendige Fähigkeit, wenn man einen Dienst für Datenpersistenz anbietet.
    Es gibt eine Diskrepanz zwischen dem, was Fly anbieten möchte, und dem, was der Markt erwartet.
    Fly wollte wohl die Innovation bieten, Apps über mehrere Rechenzentren hinweg ausführen zu können, aber ohne einen vernünftigen Datenpersistenzdienst ist diese Funktion für die meisten nicht nützlich.
    Es wirkt so, als wollten sie das Persistenzproblem mit SQLite-Replikation lösen, aber dann müssten die meisten Entwickler ihre Art, Apps zu bauen, an die Fly-Plattform anpassen.
    Fly muss sich entscheiden, ob es ein stabiles und günstiges Heroku-Ersatzangebot sein will oder eine eigenständige Art der App-Entwicklung anbieten will, die Nutzern weltweit die bestmögliche Performance liefert.
    App Engine ist hier ein interessanter Fall. Es war seiner Zeit voraus und schrieb eine Art der Entwicklung vor, die sich bis zu sehr hohem Traffic skalieren ließ, aber die Leute wollten ihre Entwicklungsweise nicht daran anpassen.

    • Haben sie nicht schon einmal einen Kurswechsel gemacht? In ihrer jetzigen Größe und mit über 100 Millionen Dollar an Finanzierung halte ich einen weiteren für sehr schwierig.
      Im Moment wirkt es, als würden sie hektisch einen Brand nach dem anderen löschen, und das schafft bei mir kein Vertrauen in die technische Roadmap.
      Haben nicht schon seit gut zwei Jahren viele Leute Fly.io auf ihre „später noch mal ansehen“-Liste gesetzt?
      Wenn Leute eine Plattform erst einmal als instabil wahrnehmen, ist es wirklich schwer, den Ruf wiederherzustellen, besonders in der IT.
    • Fly hat keinen Remote-attached Storage, alles sind node-lokale LVM-basierte Volumes.
      Die Datenpersistenz erfolgt über 24-Stunden- oder manuell erstellte LVM-Snapshots, die nach S3 exportiert werden.
      Ich halte das wirklich nicht für einen Ort für persistente Workloads. Wenn man dort PostgreSQL betreibt, sollte man darauf vorbereitet sein, die Daten in eine neue Instanz hot zu laden oder aus einem Backup wiederherzustellen.

  • Aus genau diesem Grund wurde auf HN schon seit Langem davor gewarnt, Fly zu benutzen: https://news.ycombinator.com/item?id=31394179
    Nachdem ich die Löschung meines Kontos beantragt hatte, wurde mein Konto ohne jede Kommunikation in eine Art Shadowban-Zustand versetzt.
    Ich habe auch E-Mails geschickt, aber bis heute nie eine Antwort erhalten, und danach alles zu Railway-Apps und Google Cloud Run migriert.

    • Meinst du, dass du nach dem Löschen deines Kontos versucht hast, dich mit der gelöschten E-Mail-Adresse erneut anzumelden?
      Warum sollte ein Unternehmen jemanden shadowbannen, nur weil er eine harmlose Frage gestellt hat?

  • Interessant ist, dass es sich bei Fly.io so anfühlt, als würde sich die Geschichte wiederholen. Es erinnert an meine erste Begegnung mit Heroku.
    Das frühere Fly.io war frisch und spannend, ähnlich wie Heroku bei seinem ersten Auftauchen, und ich war beeindruckt von der Einfachheit und leichten Bedienbarkeit.
    Doch mit der Zeit tauchten kleine Warnzeichen auf, die Downtimes wurden häufiger, und Deployments, die früher schnell und reibungslos liefen, wurden schmerzhaft langsam.
    Es fühlt sich an wie ein Déjà-vu aus der Zeit, als die Stärken von Heroku zu verschwinden begannen.
    Es ist schade zu sehen, dass Fly.io offenbar denselben Weg geht: Je mehr Leute auf die Plattform kommen, desto schlechter wird die Performance, und je populärer sie wird, desto weniger stabil wirkt sie.
    Es fühlt sich wie eine warnende Geschichte darüber an, wie selbst vielversprechende Plattformen abstürzen können, und ich hoffe, dass Fly.io diesen Kreislauf durchbrechen und seinen Platz finden kann, bevor es so nutzlos wird wie Heroku an seinem Tiefpunkt.

    • Ich war schon damals etwas nervös, als ich sah, dass Fly ziemlich viele Ressourcen kostenlos anbot und das in der Dokumentation sogar unterschwellig wie ein Feature empfahl.
      Ich hatte das Gefühl, ich hätte das Gewissen der Branche überschätzt, und es war doch klar, dass sich, sobald es wie Heroku allgemein bekannt würde, viele Leute darauf stürzen würden, die nicht zahlen wollen.
      Wenn man noch einmal versucht, großzügige kostenlose Kontingente anzubieten, braucht man entweder ein starkes und teures Anti-Missbrauchs-Team oder so tiefe Taschen, dass man die anfängliche Abwesenheit davon mit massiver Hardware ausgleichen kann.
      Fly wirkt in keiner der beiden Richtungen stark. Und das gefällt mir teilweise auch. Solche Dinge wirken oft wie sinnloser Großkonzern-Unsinn, und bei Fly riecht es weniger danach.
      Trotzdem würde es mich nicht überraschen, wenn die Fly-Ingenieure den Großteil ihrer Zeit nicht mit langfristiger Infrastrukturzuverlässigkeit oder Developer Experience verbringen, sondern damit, Trittbrettfahrer, Krypto-Miner, Betrüger und andere Missbraucher zu bekämpfen sowie Ressourcenallokation und automatisches Throttling zu optimieren.
    • Ich habe denselben Eindruck.
      Ich frage mich, ob das mit der Größe zusammenhängt. Ist es nicht so, dass ein Unternehmen genau dann, wenn es genug zahlende Kunden gewonnen hat, um profitabel oder investierbar zu wirken, gleichzeitig auch genug Probleme angesammelt hat, um sich allmählich wie der alte Wettbewerber zu verhalten, den es ursprünglich ersetzen wollte?
      So war jedenfalls meine Erfahrung. Sobald ein Unternehmen von der Größe „ein paar Pizzen bestellen“ zu „eine Event-Location reservieren“ wächst, schleicht sich Entropie ein, und Sprichwörter wie Conways Gesetz oder Brooks’ Gesetz werden immer offensichtlicher.