- Fly.io hat nach der Aufnahme von rund 25 Millionen Dollar ($25m) im Juli 2023 von A16Z und bestehenden Investoren wie Intel Capital und Dell unter der Führung von EQT Ventures zusätzlich rund 70 Millionen Dollar ($70m) gesichert
- Die Kernherausforderung besteht darin, dass Apps besser werden, wenn sie nahe an den Nutzern ausgeführt werden, gewöhnliche Entwickler aber innerhalb von 2 Stunden schwer nachvollziehen können, wie man Deployments über mehrere Städte hinweg umsetzt
- Fly.io betrachtet nicht nur globale Deployments, sondern auch On-Demand-VMs, Echtzeitfunktionen, Nutzer-Presence, Verschlüsselung und Secrets, Cluster-Datenbanken sowie hardwarebeschleunigte Inferenz als dasselbe 2-Stunden-Problem
- Das Kapital soll in die eigene Hardware-Flotte, mehr Regionen, Support und Stabilität sowie fortgeschrittene Storage- und Sicherheitsfunktionen und Experimente mit neuer Hardware fließen
- Fly.io hält an der Ausrichtung als entwicklerfreundliche Plattform fest, auf der man sich online anmeldet, schnell etwas ausprobieren und Apps allein mit ein oder zwei
flyctl-Befehlen plus Container-Paketierung ausführen kann
Die Finanzierung von Fly.io
- Fly.io nahm im Juli 2023 25 Millionen Dollar von Investoren auf, darunter A16Z sowie bestehende Investoren wie Intel Capital und Dell
- Danach sicherte sich das Unternehmen eine zusätzliche Investition von 70 Millionen Dollar unter der Führung von EQT Ventures
- Einer der praktischen Zwecke der Finanzierungsankündigung ist die Kundengewinnung
- Manche Kunden arbeiten problemlos mit dem kleinen Fly.io zusammen, andere fühlen sich erst mit einem Fly.io sicher, das zusätzliche 70 Millionen Dollar unter Führung von EQT Ventures erhalten hat
- Fly.io hat über Jahre hinweg in der Community mit Nutzern, Fans und Kritikern diskutiert und dabei die Plattformvision, die es aufbauen will, verfeinert
Das „2-Stunden-Problem“ und globale Deployments
- 2020 war die Grundüberzeugung von Fly.io, dass Apps umso besser funktionieren, je näher sie an den Nutzern laufen
- Apps wie Video oder Echtzeit-Presence werden als Kategorie gesehen, die sich ohne physische Nähe schwer umsetzen lässt
- Im frühen HN-Launch-Thread erwartete man, dass WebRTC, Edge-Caching und Game-Server die Hauptthemen sein würden, tatsächlich verlagerte sich das Interesse aber in Richtung Datenbanken
- Was Fly.io übersehen hatte, war die Annahme, dass nur bestimmte „Edge-artige“ Apps globale Deployments benötigen
- Tatsächlich möchten die meisten Apps ebenfalls am Edge laufen, versuchen es aber nur, wenn es einfach genug ist
- Bei Game-Servern ist Edge-Deployment unverzichtbar, daher treibt das Team das Problem so lange voran, bis es gelöst ist
- Bei CRUD-Apps wie einem Online-Buchladen wechselt man zu etwas anderem, wenn nach etwa 2 Stunden Versuch kein klarer Weg sichtbar wird
Grenzen heutiger Internet-Deployments
- Als Problem wird dargestellt, dass ein großer Teil der CRUD-Apps weltweit in der Nähe von Amazon
us-east-1in Ashburn, Virginia, gehostet wird - Viele Entwickler verstehen, dass es besser ist, näher an den Nutzern zu laufen, aber mit den üblichen Tools lässt sich innerhalb von 2 Stunden nur schwer erfassen, wie man Apps gleichzeitig in mehreren Städten betreibt
- Fly.io wettet darauf, dass mit der richtigen Plattform und Toolchain auch Apps wie Buchläden, Sandwich-Bewertungs-Apps, Musikempfehlungssysteme oder Mailinglisten-Manager für Kirchen weltweit schnell laufen können
- Zu den Zielregionen zählen nicht nur Gegenden rund um Ashburn, sondern auch Städte wie Chicago, Sydney, Singapur und São Paulo
- Die Fähigkeit, in mehreren Städten gleichzeitig schnell zu laufen, wird als wichtige Funktion zur Verbesserung der App-Qualität bewertet
Fly Machines und andere „2-Stunden-Funktionen“
- Sandboxing, Code-Editoren mit REPL und CI/CD-Anwendungen müssen alle nicht vertrauenswürdigen Kundencode ausführen
- Solche Systeme haben jeweils ihren eigenen Weg gefunden, bei Bedarf gesperrte Container zu starten
- On-Demand-VMs sind jedoch eine für viele Apps sehr wertvolle Funktion, deren Umsetzungsweg nach nur 2 Stunden Recherche nicht klar erkennbar ist
- Deshalb hat Fly.io Fly Machines entwickelt und will das Starten von VMs so einfach wie einen Funktionsaufruf machen
- Auch die nächsten Ziele folgen demselben Muster
- Echtzeitfunktionen und Nutzer-Presence
- Verschlüsselung und Speicherung von Secrets
- Cluster-Datenbanken
- Hardware-beschleunigte Inferenz
- Andere Unternehmen in den Bereichen verteilte Datenbanken, Daten-Locality, Storage, KI und App-Frameworks versuchen ebenfalls, das „2-Stunden-Fenster“-Problem der Entwickler zu lösen
- Wenn Fly.io wie beabsichtigt funktioniert, können solche Plattformen darauf neue Grundbausteine schaffen, neue Ideen schneller zu den Nutzern bringen und die Qualität von Apps steigern
Warum das Kapital nötig ist
- Fly.io ist der Ansicht, dass für den Aufbau einer solchen Plattform kapitalintensive Komponenten erforderlich sind
-
Eigene Hardware-Flotte
- Fly.io läuft schon immer auf eigener Hardware
- Statt auf einer generischen Cloud aufzubauen, steckt das Unternehmen die Hardware selbst in die Racks; dafür gibt es technische Gründe und Gründe der Kontrolle
- Der zentrale Grund ist die Wirtschaftlichkeit
- Wenn Menschen Apps auf der Plattform bauen sollen, muss das Unternehmen zeigen, dass es auch in 10 Jahren noch existieren könnte, und man ist überzeugt, dass Hardware die dafür nötigen Margen ermöglicht
-
Mehr Regionen
- Fly.io startete mit 19 Regionen und hielt das für ausreichend, wenn man nur einzelne App-Entwickler adressiert
- Das Unternehmen will aber, dass auch andere Plattformen wie Managed Databases und Entwickler-Tools auf Fly.io laufen
- Solche Unternehmen benötigen mehr Regionen
- Fly.io ist inzwischen auf 33 Regionen gewachsen, und das Tempo beim Aktivieren neuer Regionen nimmt weiter zu
-
Support und Stabilität
- Fly.io erkennt an, dass die Herausforderungen bei der Plattformstabilität groß sind
- Man sieht das nicht als Problem, das sich allein mit cleveren Tricks lösen lässt
- Zudem will das Unternehmen stärker auf fortgeschrittene Storage- und Sicherheitsfunktionen sowie neue Arten von Hardware setzen
Die unveränderte Plattformausrichtung
- Die Richtung, in die sich Fly.io als Plattformunternehmen entwickeln will, hat sich seit 2020 nicht verändert
- Ziel ist eine Plattform, die man innerhalb von 5 Minuten nach der Online-Anmeldung ausprobieren kann
- Das Gegenstück dazu sind Plattformen, bei denen sich nach der Online-Anmeldung ein Vertriebsmitarbeiter meldet, Preise nennt und eine Demo ansetzt
- Gewünscht ist eine Plattform, die man auch ohne Handbuch versteht
- Das Gegenstück dazu sind Plattformen, zu deren Bedienung konkurrierende Bücher erscheinen und für deren Nutzung beim Starten einer App eine Fachzertifizierung nötig ist
- Python-, Rust- und Julia-Code sollen sich auf natürliche Weise ausführen lassen
- Im Gegensatz zu Ansätzen, bei denen der Code erst in JavaScript zurückkompiliert werden muss
- Die Funktionen von Fly.io lassen sich meist mit ein oder zwei
flyctl-Befehlen nutzen, und jede als Container paketierbare App funktioniert - Wer bereits einen funktionierenden Docker-Container hat, kann ihn direkt auf Fly.io testen
- Selbst von Grund auf sollte sich eine App innerhalb weniger Minuten mit nur einer Ziffer auf Fly.io starten lassen
- Für die Ausführung auf allen Kontinenten dürften von dort aus nur noch etwa 1 bis 2 Minuten zusätzlich nötig sein
1 Kommentare
Hacker-News-Kommentare
Die Formulierung „viel Geld eingesammelt“ löst inzwischen selbst aus Kundensicht zuerst Sorge aus
Es wirkt, als laufe das Unternehmen nur mit Venture-Capital-Geld, als seien die Preise, die ich nutze oder bezahle, kein realistischer künftiger Preis und als wachse die Plattform unabhängig vom Umsatz einfach immer weiter
Als Kunde gibt mir die Aussage, dass der Betrieb und die zahlende Kundschaft profitabel sind, deutlich mehr Vertrauen in die Stabilität
Ich widerspreche dem Artikel an sich nicht, aber aus Kundensicht ist das für mich kein klar positives Signal mehr
Und dann ändern sie eines Tages die Preise völlig absurd mit der Begründung, ich würde doch eine großartige Plattform kostenlos nutzen
Das ist so, als würde ich jemanden fürs Rasenmähen engagieren und ein paar Jahre später kommt er mit drei Aufsitzmähern an und sagt, er müsse die Preise erhöhen, um die Kosten der erbrachten Leistung zu decken
Sie haben ihr Geschäft für Kunden mit 10-Acre-Rasenflächen ausgebaut und dann angenommen, ich bräuchte dasselbe Serviceniveau, aber am Ende verliere ich dadurch meine Rasenpflege
Als Investor würde man sich über VC-Abhängigkeit Sorgen machen, aber als Nutzer war es bei Diensten wie Hello Fresh nicht unbedingt schlecht, dank investitionssubventioniertem Essen günstig zu essen
Es wirkt wahrscheinlich, dass sie nicht allzu lange auf einen Exit hinarbeiten und verkauft werden, aber wenn sie die Leidensfähigkeit haben, als unabhängiges Unternehmen weiterzumachen, wäre das sehr zu begrüßen
Das Produkt ist validiert, scheint bessere Erfolgschancen als die Konkurrenz zu haben, wird wohl erst einmal nicht verschwinden, und ich erwarte auch schnellere Produktverbesserungen
Der Witz „Alle CRUD-Apps der Welt laufen in Loudoun County, Virginia, also Amazon us-east-1 in Ashburn, und dort gibt es so viele Rails-Apps, dass eine davon in den County Board of Supervisors gewählt wurde“ ist schmerzhaft treffend
Wenn man darüber nachdenkt, wirkt schon das ganze Paradigma von Regionen insgesamt ziemlich veraltet. AWS hat zwar ein paar Bewegungen in diese Richtung gemacht, bleibt am Ende aber etwa bei der Control Plane weiterhin an das Regionskonzept gebunden, dazu kommen die Seltsamkeiten von VPC, undurchsichtige Abrechnung, Verfügbarkeitsprobleme sowie allerlei Hacks, Stacks und Aufwand, um mehrere Regionen/AZs zu handhaben
Spätere Anbieter wie Fly oder Cloudflare scheinen den Cloud-Bereich zunehmend mit einem Ansatz zu dominieren, bei dem Rechenleistung ohne Regionskonzept am Edge ausgeführt wird, während der regionsbasierte AWS-Ansatz wohl für Legacy-Anwendungen bleibt, die darin gefangen sind
Der regionsbasierte Ansatz ist weniger „echte Cloud“ als vielmehr ein gehostetes elastisches Rechenzentrum. Echte Cloud müsste überall sein und gar nicht erst als Standortfrage in Betracht gezogen werden
Dadurch ist ihr Brand-Marketing makellos. Jeder Blogpost vermittelt eine klare, leicht spöttische Stimme
Wenn man ein bekannter Hacker werden will, sollte man in der Branche wohl auch ein einigermaßen bekannter Autor sein
Solche selbstreflexiven Kommentare wirken nur, wenn man sie selten einsetzt, und in diesem Artikel funktioniert das sehr gut
Er erkennt die opportunistischen Motive, die implizite Heuchelei und die Selbstdarstellung solcher Ankündigungen an, vermittelt aber trotzdem alle wichtigen Informationen und erklärt knapp das reale Problem, das die Plattform löst
Auch die legitimen Einsatzbereiche des Kapitals werden klar benannt, sodass die Fragen nach „warum“ und „wie viel“ beantwortet werden
Zur Frage „Warum schreiben Startups solche Ankündigungen?“: In Unternehmen, die mehrfach Finanzierungsrunden erlebt haben, war das zu 100 % ein Vorwand für Pressepräsenz
Solange es nicht heißt „Der CEO wurde gleichzeitig wegen Unterschlagung und Belästigung verhaftet“, bekommt man kostenlose Werbung, wenn man einen Anlass schafft, damit Tech-Medien darüber berichten
Noch besser, wenn die Zielkunden Tech-Medien lesen. Daran ist nichts verwerflich, aber es war überraschend, dass man zwar die opportunistischen Gründe anerkennt, den häufigsten Grund aber auslässt
Die Reporter kannten ihr Publikum gut und interpretierten das so, dass nur Artikel mit einer Investment-Meldung Klicks bringen
Deshalb blieben wir nach einer Finanzierung oft bis zu sechs Monate still und kündigten sie erst zusammen mit einer neuen Funktion oder einem Produktlaunch an
Wenn Tech-Artikel auch ohne Finanzierungsankündigung mehr geklickt würden, könnte sich dieser Kreislauf ändern, aber im Moment wirkt es wie eine Art Gefangenendilemma. Solche Artikel werden nicht geschrieben, nicht geklickt und deshalb wieder nicht geschrieben
Meist wegen opportunistischer Ziele, nämlich eine bestimmte Botschaft und einen bestimmten Eindruck zu hinterlassen, wie der Artikel erklärt
Natürlich geht es auch darum, den Firmennamen bekannt zu machen, und das könnte ein opportunistisches Motiv sein, das im Artikel weniger behandelt wurde
Soweit ich mich erinnere, war es technisch gesehen öffentliche Information. Als ich eine Firma gründete, wurde es mir so erklärt, aber das ist lange her
Wenn man es nicht selbst veröffentlicht, tun es andere, also ist es viel besser, zuerst selbst zu posten, damit die Leute den eigenen Text lesen und nicht den von jemand anderem
Wenn man 100 Millionen Dollar eingesammelt hat, muss man auf einen 1-Milliarde-Dollar-Exit zusteuern. Um das aktuelle Momentum zu halten, werden die F&E-Kosten enorm steigen
Den gesamten Stack selbst zu bauen und am Ende alles extrem robust machen zu müssen, ist eine gewaltige Engineering-Aufgabe
Fly kann auf dem Papier profitabel wirken, weil für Compute Gebühren anfallen und Hardware sowie Bandbreite günstig sind
Aber die tatsächlichen Kosten sind F&E, Marketing und aktienbasierte Vergütung, und diese Kosten können Profitabilität in jeder Größenordnung verhindern. Das sind keine Einmalkosten, sondern laufende Ausgaben; wenn man sie nicht tätigt, wandern die Kunden ab
Das ist nicht nur ein Heroku-spezifisches Beispiel, sondern die Tragödie von Plattform-/Infrastruktur-Startups
Es gibt einen Grund, warum man nicht viele kleine Cloud-Anbieter sieht: wirtschaftlich funktioniert es nur mit Größe
Fly scheint eine wirklich coole und moderne Sicht auf Software Engineering zu haben und wirkte wie ein guter Arbeitsplatz, aber ich spüre eine große Diskrepanz zwischen Marketing und Produkt
Marketing und Dokumentation konzentrieren sich darauf, weltweit verteilte App-Server sehr einfach hochzufahren, aber die Kunden, die tatsächlich weltweit verteilte App-Server brauchen, haben wahrscheinlich bereits eine reife Plattform mit ebenfalls weltweit verteiltem Datenspeicher und machen sich daher kaum Sorgen darum, App-Server hochzufahren
Deshalb habe ich das Gefühl, dass ich etwas Grundlegendes an der Architektur von Internetanwendungen missverstehe
Dass es in mehreren Regionen laufen kann, ist nützlich. Die Splatoon-Community sitzt nicht an einem Ort, sondern ist über die ganze Welt verteilt; wenn man nur in den USA hostet, ist es für Spieler in Japan langsam und umgekehrt
Selbst wenn das Projekt nichts wird, dürfte es später, nach der Schule, eine ziemlich nützliche Erfahrung sein
Derzeit läuft es an der US-Ostküste, in Amsterdam und in Tokyo für etwa 10 Dollar im Monat
Das Zielobjekt wechselt nur zwischen Kubernetes, Single-Page-Apps, GraphQL, Edge-Deployments und so weiter
Im Goldrausch verkauft man Schaufeln
Der Satz, es gebe „eine Plattformfirma, auf der Python-, Rust- und Julia-Code gut laufen kann, und eine Plattformfirma, die einen dazu bringt, einen Weg zu finden, das wieder nach JavaScript zu kompilieren“, wirkt wie ein spielerischer Seitenhieb auf Cloudflare und Deno
Es wäre interessant, wenn Fly zusätzlich zu Docker-Containern auch WASM-Container hosten würde
Der Seitenhieb auf Cloudflare war meiner Meinung nach der Teil mit dem „dafür sorgen, dass ein Vertriebsmitarbeiter anruft“
Mir gefiel die Stelle, an der zugegeben wurde, dass Fly zwar eigentlich für Games/Edge-Caching usw. gedacht schien, in der Praxis aber von allen wie ein neues Heroku zum Deployment von Rails+PostgreSQL-CRUD-Apps genutzt wird
Soweit ich es verstanden habe, ist das nächste Ziel, die Verlagerung von Rails+PostgreSQL-Apps an den Edge zu etwas Trivialem zu machen, also zu einem „Zwei-Stunden-Problem“
Ziemlich gewagt. Historisch brauchte man dafür meist eine anwendungs-/framework-/domänenspezifische Kopplung wie „Wie shardet man dieses Domainmodell am besten?“
Das über PaaS/IaaS zu lösen, kommt faktisch fast dem Schreiben und Betreiben eines verteilten Cloud SQL/Aurora gleich
Wenn es allerdings eher darum geht, etwas wie einen Aurora-Klon oder Neon nahtlos innerhalb des Stacks zu betreiben, dann scheint es machbar zu sein und hätte wohl auch erheblichen Produktwert
Wenn man bedenkt, dass die Margen bei Cloud-Angeboten für SMBs/Hobbyprojekte relativ niedrig sind, ist mir nicht klar, wie fly.io Profitabilität erreichen will
Man kann vielleicht die ganze Welt in den Free Tier packen, aber was passiert, wenn EQT aussteigen muss
Können sie genug Features bauen, damit Unternehmen sich ernsthaft dafür entscheiden. In den Firmen, in denen ich gearbeitet habe, wäre das schwer zu nutzen oder durchzusetzen, außer bei Teams mit weniger als 5 Leuten und überhaupt keinem Skalierungsbedarf
Unsere Unit Economics sind gut. Das riskanteste und beängstigendste, was wir getan haben, war, mit eigener Hardware zu starten
Bei entwicklerzentrierter Infrastruktur muss man viele Entwickler anziehen, sie dazu bringen, uns in ihre Jobs mitzunehmen, und dann ihren Arbeitgebern über lange Zeit helfen, etwas Besseres aufzubauen
In Unternehmen mit Beschaffungsprozessen ist das ein sehr langwieriger Weg, weil diese Prozesse darauf ausgelegt sind, keine Kerninfrastruktur von Startups zu kaufen
Auch wenn es noch nicht für alle passt, hat es für uns bisher funktioniert
[0] https://community.fly.io/t/funding-and-longevity/1957
Ich frage mich, worin sich fly.io davon unterscheidet oder besser ist, die gesamte App inklusive dynamischer Inhalte vor CloudFront oder ein anderes CDN zu setzen
Ein CDN ist näher am Client und kann daher SSL mit geringerer Latenz bereitstellen, und dieser Unterschied kann ziemlich groß sein
Das schiebt den App-Server zwar nicht an den Edge, aber selbst dann zahlt man immer noch die Latenzkosten dafür, auf eine Datenbank in einem Bunker in Virginia zuzugreifen
Viele Apps haben pro Web-Request mehrere Roundtrips zur Datenbank, also wirkt das eher noch schlimmer. Ich denke, es ist besser, die Latenzkosten beim Web-Request in Kauf zu nehmen und dafür dem App-Server schnellen Zugriff auf die Datenbank zu geben
Die Zielkunden von Fly scheinen größtenteils eher im Bereich statischer Inhalte zu liegen