Face à un changement déroutant : le virage de Fly.io vers Sprites

 (fly.io)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Malgré de solides résultats, l’identité de l’entreprise vacillant, Fly.io a levé des fonds supplémentaires, confié sa direction à Scott Johnston, ancien CEO de Docker, et fait de Sprites son activité centrale
  • Alors que l’IA permet à presque tout le monde de créer des logiciels sur mesure, il devient difficile de se différencier uniquement avec un cloud public déployé près des utilisateurs et une ergonomie centrée sur les développeurs humains
  • Sprites est constitué d’ordinateurs pour agents que l’on peut créer par centaines ou par milliers à la demande et conserver longtemps ; chacun offre un disque persistant de 100 Go et une facturation à l’usage qui s’arrête lorsqu’il est inactif
  • Les nouveaux Sprites ajoutent le Sprite Block Device, plus rapide et plus fiable, le fork de disques, ainsi que des Connectors permettant d’appeler des systèmes externes sans exposer d’identifiants
  • Fly.io ne cherche pas à poursuivre simultanément une plateforme applicative à fonctionnalités fixes conçue par des humains et un futur centré sur les agents : l’entreprise se concentre sur ce dernier, tout en continuant à maintenir Fly Machines et les fonctions PaaS existantes

Une crise d’identité révélée malgré de solides résultats

  • En évaluant le meilleur endroit pour héberger une nouvelle application en 2026, Theo Browne a parlé positivement de Fly.io, mais a estimé que, parmi les fournisseurs qu’il suivait, c’était celui dont il était le moins sûr qu’il existe encore à la fin de l’année
  • À ce moment-là, Fly.io enchaînait des résultats trimestriels solides, y compris les meilleurs résultats financiers de son histoire, mais la question de son identité — quoi construire et vers où aller — restait non résolue
  • Fly.io a levé une importante somme supplémentaire, lancé une nouvelle version de Sprites afin de concentrer les capacités de l’entreprise, et nommé Scott Johnston CEO

Les hypothèses de l’adéquation produit-marché existante ont changé

  • Fly.io est parti de deux principes
    • Les applications Internet sont plus rapides lorsqu’elles sont déployées au plus près des utilisateurs
    • Plutôt qu’une infrastructure cloud complexe, il faut offrir aux développeurs à la fois la flexibilité d’AWS et la facilité d’usage d’Heroku
  • Ces deux principes restent importants, mais avec la transformation du développement logiciel par l’IA, ils ne sont plus aussi décisifs qu’avant
  • Se contenter d’intégrer les agents de codage aux processus de développement existants, comme des compilateurs plus intelligents, ne suffit pas à saisir l’ampleur du changement
  • Avant l’apparition des tableurs, des tâches correspondant aujourd’hui à des documents Excel devaient elles aussi être des programmes écrits par des programmeurs ; les formules de tableur ont transformé d’innombrables professionnels en programmeurs
  • L’IA provoque une transformation encore plus vaste, en allant vers un monde où presque tout le monde peut créer presque n’importe quel type de programme
  • Les clouds publics existants sont conçus pour déployer auprès de millions de personnes des applications à fonctionnalités fixes, passées par des standards stricts et des procédures CI/CD
  • Des programmes destinés à des millions d’utilisateurs continueront d’exister, mais ils ne seront peut-être plus la forme la plus courante, tout comme les tableurs consultés par des millions de lecteurs ne le sont pas
  • Continuer à parier sur une conception du cloud public façon 2020 revient à parier contre la diffusion de logiciels personnalisés et adaptatifs
  • Fly.io choisit un monde où ses amis et sa famille peuvent faire directement avec leur ordinateur ce qu’ils veulent, sans attendre un développeur

Les besoins des agents plutôt que l’expérience des développeurs humains

  • Le fait que l’infrastructure cloud soit difficile pour les développeurs reste un problème, mais à mesure que les agents prennent en charge le travail, l’importance d’une expérience développeur soigneusement conçue pour les humains diminue
  • Pour les agents, qui fonctionnent mieux dans des environnements explicites, des valeurs par défaut très prescriptives et une expérience développeur trop sélectionnée peuvent même être défavorables
  • Les gens commencent à confier les tâches aux agents au lieu de lire la documentation et d’apprendre une nouvelle CLI par tâtonnements
  • Un agent peut traiter d’un seul coup une demande consistant à déployer sur Fly.io un site créé localement, mais il peut aussi gérer un déploiement AWS d’un seul coup, ce qui rend difficile la différenciation par la seule facilité d’usage existante
  • Après avoir constaté que ses clients à la croissance la plus rapide étaient des robots, Fly.io a cessé de simplement réinterpréter ses produits existants pour les agents et a commencé à chercher l’environnement que les agents veulent réellement

L’ordinateur que veulent les agents

  • Les agents de codage sont fondamentalement conçus pour s’exécuter sur le poste de travail d’un développeur
  • Même dans une sandbox fiable, si l’agent s’exécute sur un ordinateur portable physique, son travail s’arrête dès que l’on ferme le capot ; les utilisateurs finissent donc par déplacer leurs sandboxes d’agents vers le cloud
  • Les serveurs de cloud public existants exigent un engagement trop important pour les tâches des agents
    • Ils doivent être plus éphémères que les serveurs traditionnels de type « animal de compagnie » ou « bétail »
    • Ils doivent pouvoir être créés au moment voulu, conservés uniquement le temps nécessaire et fonctionner à faible coût
  • Sprites est un ordinateur semi-jetable conçu pour ces besoins
    • Il est possible d’en créer rapidement des centaines ou des milliers
    • Chaque Sprite dispose d’un disque persistant de 100 Go
    • La facturation dépend de l’usage, mais le comptage s’arrête lorsqu’il ne fait rien, et il détermine lui-même son état d’inactivité
    • Il peut héberger des applications et les partager avec des collègues via Internet
  • Le secteur se concentre sur les sandboxes, mais ce dont les agents ont besoin n’est pas une sandbox : c’est un ordinateur doté de persistance et d’utilité
  • Il est possible de créer immédiatement des Sprites et de les utiliser directement

Faire de Sprites le centre de l’entreprise

  • Les premiers Sprites étaient un projet créé par une petite équipe informelle au sein de Fly.io, et ils n’étaient même pas hébergés sur le site web principal de Fly.io
  • Désormais, les ordinateurs pour agents (Computers for Agents) deviennent le cœur de l’entreprise, et Sprites n’est plus un projet porté par seulement quelques personnes
  • Fly Machines et les fonctionnalités existantes de plateforme en tant que service (PaaS) ne sont pas abandonnés et continueront d’être proposés
  • Les nouveaux Sprites améliorent le passage à l’échelle et l’orchestration, et introduisent deux sous-systèmes majeurs qui complètent l’ensemble de fonctionnalités visé

Sprite Block Device et fork de disques

  • L’ancienne pile de stockage était construite sur JuiceFS, avec Litestream raccordé dessus
  • Le Sprite Block Device (SBD), que Ben Johnson et Tim Newsham ont reconstruit depuis les fondations, est plus rapide et plus fiable que l’ancien système, tout en conservant les fonctions de checkpoint et de restauration instantanés
  • Avec le fork de disque, extension clé de SBD, il est possible de créer un Sprite modèle puis de le répliquer efficacement des millions de fois

Des Connectors pour éviter l’exposition des identifiants

  • Les Connectors reposent sur les tokens tokenisés développés pour protéger la plateforme centrale de Fly.io
  • Ils sont conçus pour permettre à un Sprite d’envoyer des requêtes authentifiées à d’autres systèmes sans fournir directement à l’agent des identifiants susceptibles de fuiter
  • Ils sont plus pratiques à utiliser que la gestion manuelle de comptes et de clés API
  • Les capacités de réplication de SBD et les Connectors sont les fonctionnalités les plus demandées par les clients, et expliquent aussi pourquoi de nombreuses entreprises d’agents ont continué à utiliser Fly Machines même après le lancement de produits dédiés aux agents
  • Sauf apparition d’un changement technologique encore plus déroutant que les modèles Transformer, Fly.io estime que Sprites convient à ses futurs clients ainsi qu’à une grande partie de ses clients existants, et propose donc une nouvelle bêta

Le départ du CEO fondateur

  • Pendant les huit premières années suivant sa création, Fly.io a fonctionné comme une organisation d’expérimentation à la recherche de l’adéquation produit-marché
    • Elle a essayé des dizaines de choses, dont Postgres non managé, un CDN mondial et WireGuard en mode utilisateur
    • Elle a construit une organisation d’ingénierie ascendante, évité les feuilles de route produit, et constitué une équipe entièrement remote travaillant dans plus d’une douzaine de pays
  • Certaines expériences ont porté leurs fruits et d’autres ont servi d’occasions d’apprentissage, mais Fly.io n’a plus besoin, à ce stade, de ce type de projets scientifiques
  • Le fondateur a estimé avoir épuisé l’essentiel de ce qu’il pouvait apporter comme CEO et a quitté son poste

Scott Johnston devient CEO

  • Depuis 2025, Fly.io discutait depuis plusieurs mois de l’idée de confier ses décisions à Scott Johnston
  • Lorsqu’il était CEO de Docker, Scott a traversé une période difficile née d’une crise d’identité entre marché entreprise et marché développeur, puis a fortement développé l’activité
  • Le fondateur, actionnaire de Fly.io et alors CEO, a jugé qu’à l’étape actuelle de l’entreprise, le mode opératoire de Scott convenait mieux que le sien, et l’a convaincu avec le conseil d’administration
  • Le fondateur reste conseiller et membre du conseil d’administration, participe aux discussions sur la conception produit, tandis que Scott prend en charge l’exploitation et l’exécution de l’activité

Des fonds supplémentaires pour la nouvelle stratégie

  • Fly.io n’avait pas annoncé de nouvelle levée de fonds depuis plusieurs années, mais avait précédemment levé un montant important et fonctionnait à un niveau où, selon le plan existant, elle n’aurait pas eu besoin de lever à nouveau
  • L’IA ayant changé ce plan, l’entreprise a levé des fonds supplémentaires pour mener sa nouvelle stratégie, sans en dévoiler le montant ni les conditions
  • Scott Johnston abordera séparément les futures informations relatives au financement

Choisir entre deux futurs

  • Fly.io prévoit que, dans quelques années, les agents détermineront la façon dont presque tous les logiciels seront construits et déployés
  • Les logiciels deviendront plus personnalisés, viseront des publics plus restreints, et leurs formes seront plus flexibles et plus fluides
  • Ce changement suscite de l’espoir tout en mettant mal à l’aise les professionnels du secteur
  • L’entreprise avait deux options
    • Continuer à étendre et améliorer une plateforme d’applications full-stack à fonctionnalités fixes conçue par des humains
    • Finaliser avec précision des produits adaptés à un futur proche centré sur les agents
  • Lorsqu’une startup poursuit simultanément deux directions, il lui est difficile de se concentrer suffisamment sur l’une ou l’autre ; Fly.io a donc choisi les produits centrés sur les agents
  • Sprites a résolu des décisions de priorisation repoussées depuis des mois, et Scott Johnston est chargé d’en faire l’activité centrale de Fly.io

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis Hacker News

  • L’abstraction de Sprites est élégante, mais en 30 ans de carrière dans le développement, c’est le produit d’infrastructure le plus bogué que j’aie jamais vu
    Les données disparaissaient sans arrêt et le système se retrouvait dans un état zombie impossible à joindre ; la moitié du système disait que le Sprite allait bien, l’autre moitié qu’il était mort, au point de ne même pas pouvoir recharger un snapshot
    Entre le déjeuner et le soir, parfois même pendant que je travaillais, les résultats disparaissaient ; j’ai abandonné au bout de deux semaines et j’ai dû fouiller l’historique du terminal pour recopier mon travail depuis un Sprite mort et le sauver
    Il semble que plus de la moitié des Sprites que j’ai lancés aient eu des problèmes ; le concept est excellent, donc j’espère qu’ils assureront la fiabilité

    • J’exploite une application qui orchestre l’exécution de code sur plusieurs Sprites, et il y a encore quelques mois c’était assez instable pour que le service casse complètement ou que des données disparaissent, nécessitant une restauration par le support
      Cela dit, depuis environ deux mois, ça semble devenu bien plus stable
      Il y a quelques années, Fly.io aussi avait trop de bugs pour être utilisable sérieusement, mais aujourd’hui j’y fais tourner plusieurs workloads de production de façon très stable, donc je pensais que Sprites suivrait le même chemin, et c’est apparemment en train d’arriver
    • Ce n’est pas seulement un problème de Sprite, c’est le résultat du fait que toute la plateforme Fly.io a laissé traîner des problèmes connus pendant des années
      Vu à quel point le CEO a mal géré les choses, sa démission est peut-être même préférable
    • J’ai vu un client enterprise étudier l’adoption de Sprites pour accélérer le développement, mais il a finalement abandonné Fly.io pour une autre entreprise proposant le même concept
      La raison : de graves bugs d’interface, des pertes de données et un support médiocre
      Cela dit, pendant la période d’essai ils n’ont pas utilisé leur vrai domaine d’entreprise ni indiqué qu’il s’agissait d’une société du Fortune 200, donc cela a peut-être influé sur la qualité du support

  • En tant que développeur Elixir, j’espérais la réussite de Fly.io, mais faute d’avoir trouvé l’équilibre entre une ingénierie brillante et la stabilité opérationnelle, j’ai dû partir à deux reprises
    Pendant un temps, même lors de pannes mondiales, la page de statut affichait tout comme normal, et il fallait lire les messages sur le forum pour savoir qu’il y avait un incident ; l’entreprise répondait qu’elle était trop occupée à résoudre le problème pour mettre à jour la page de statut
    Ils ont ensuite commencé à la mettre à jour, mais après « panne dans une région spécifique », il n’y avait souvent plus aucune nouvelle pendant des heures
    Dès que le support payant est sorti, je m’y suis abonné, mais l’adresse e-mail censée garantir une réponse rapide n’était la plupart du temps surveillée par personne ; même en signalant une panne majeure, la réponse « quel est le problème ? » n’arrivait que le lendemain ou plusieurs jours plus tard
    Si cela avait été rare, ce n’aurait été qu’un problème de support client, mais à une époque nous subissions des incidents majeurs presque chaque mois ; puis cela semblait se stabiliser un peu avant de rechuter de manière répétée
    J’ai fini par repasser tous mes services en auto-hébergement ; c’est plus pénible, mais la disponibilité s’est nettement améliorée, et quand il y a une panne, je peux au moins en connaître moi-même la cause, ce qui est bien moins douloureux
    S’ils veulent continuer l’activité d’hébergement, ils doivent assumer leurs responsabilités et mettre du budget dans l’exploitation ; sinon, autant abandonner l’hébergement et devenir un autre HashiCorp

    • Le passage où la page de statut disait que tout allait bien alors qu’on n’apprenait la panne mondiale que sur le forum est presque impossible à distinguer entre AWS et Fly

  • Concentrer toute l’entreprise sur Sprites donne l’impression que Fly.io a choisi le suicide
    Les sandboxes IA sont déjà un marché très concurrentiel et pratiquement banalisé, et le nouveau CEO risque fort de privilégier les revenus au détriment d’une vision créative
    J’espère me tromper

    • En dehors de la facturation à l’usage, une sandbox IA peut être implémentée facilement sur n’importe quel service de machine virtuelle ou de conteneur, donc je ne comprends pas cette stratégie
      Les conteneurs sont jetables et les tâches faciles à relancer, donc la persistance des données y est moins importante ; on peut aussi laisser l’agent lancer directement son environnement sur du bare metal
      Les agents passent surtout leur temps à attendre le GPU, donc en appliquant la déduplication mémoire à des workloads similaires, on peut en faire tourner des centaines avec peu de matériel
      AWS est déjà le cloud des agents, et avec des agents et de l’infrastructure as code (IaC), la complexité d’AWS se réduit aussi fortement
      Désormais, la valeur ne se trouve plus dans l’orchestration ni dans quelques bp de marge matérielle sur la couche de model serving, mais dans la création d’outils qui aident les agents à prendre de meilleures décisions

  • Les progrès récents des LLM provoquent une crise d’identité non seulement chez les individus, mais aussi dans les entreprises et les organisations, et ce texte en est un bon exemple
    On peut se demander s’il vaut encore la peine de construire des produits ou des entreprises que l’IA peut produire d’un seul coup
    À l’inverse, cela a aussi pour effet intéressant de pousser à s’attaquer à des choses plus grandes et plus ambitieuses qu’auparavant
    J’espère que davantage de gens se tourneront vers des domaines comme l’énergie propre, où même des centaines de personnes travaillant sur la même chose continuent d’apporter un bénéfice net durable à l’humanité

  • Je me demande si cela veut vraiment dire que Docker a explosé sa croissance, ou si c’est plutôt au sens Boeing, avec des portes qui s’envolent

  • Sprites semble mieux convenir à une petite activité stable tenue par quelques amis qu’à une startup financée par des investisseurs
    Pour un développeur, Docker ou Podman suffisent déjà largement
    Le vaste nouveau marché où même les grands-parents créent des applications sera capté par des services comme Lovable, et il est peu probable que des non-développeurs utilisent Sprites
    Au final, cela ne peut attirer qu’une partie des développeurs existants

    • En théorie, je suis justement le client cible, parce que j’ai peur que les agents, en multipliant par 100 la productivité du développement logiciel, finissent aussi par ruiner mon ordinateur, mon réseau domestique et ma vie
      On voit tous les jours passer des nouvelles disant qu’OpenCode, Claude Code et autres sont des catastrophes de sécurité ; si l’isolation est si facile, pourquoi davantage de développeurs n’utilisent-ils pas de conteneurs, et pourquoi ces incidents continuent-ils à se produire ?
      J’évite l’agent coding parce que je n’ai pas envie d’ouvrir mon environnement domestique à des LLM d’entreprise distants juste pour écrire du code plus vite, mais à partir du moment où il faut analyser plusieurs fichiers source à la fois, je perds clairement au change

  • Partir juste après avoir réorienté toute l’entreprise vers Sprites paraît assez brutal
    Il faut au moins laisser au nouveau CEO la possibilité de définir lui-même la direction et de tenter sa chance

  • Je ne sais pas si Sprites mérite qu’on mise l’avenir de l’entreprise dessus, et le jugement final appartient au nouveau CEO
    À long terme, ce type d’environnement d’exécution isolé finira probablement intégré à Claude Code ou Codex, ou directement fourni par les entreprises de l’IA

    • Sprites ne sert pas seulement à fournir un environnement d’exécution à des outils comme Claude Code ; c’est aussi utile pour quiconque construit un produit ayant besoin d’exécuter du code non fiable à bas coût
    • Sprites est une abstraction vraiment excellente
      Git worktree résout un problème similaire, mais avec Sprites on peut lancer rapidement une instance, exécuter un service, puis la confier à un agent de code pour améliorer une fonctionnalité
      On peut faire tourner plusieurs agents en parallèle et choisir l’un des résultats, sans être limité par le nombre de ports ni par le CPU local
      Et comme le manque de RAM va probablement durer encore un moment, on peut faire tourner des centaines d’agents sur Sprites
    • Je n’ai pas envie de louer aussi l’environnement de déploiement au Claude qui m’a écrit le code ; j’aime l’idée de ne récupérer que le code, puis de mettre fin à la relation et de déployer ailleurs

  • Ce que Fly.io doit corriger et prioriser, c’est la fiabilité
    J’aimais bien le fait que l’application démarre dès qu’on lance un conteneur Docker, mais le service est tombé en panne à plusieurs reprises et c’était très cher
    Maintenant, j’utilise simplement un VPS