अजनबी बदलाव का सामना: Fly.io का Sprites की ओर बदलाव

 (fly.io)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मजबूत प्रदर्शन के बावजूद जब बिज़नेस की पहचान डगमगाने लगी, तब Fly.io ने अतिरिक्त फंड जुटाया, पूर्व Docker CEO Scott Johnston को नेतृत्व सौंपा, और Sprites को मुख्य व्यवसाय की दिशा में मोड़ दिया
  • AI के कारण अब लगभग कोई भी व्यक्ति कस्टम सॉफ़्टवेयर बना सकता है, इसलिए केवल यूज़र के नज़दीक डिप्लॉय होने वाला public cloud और मानव डेवलपर-केंद्रित सुविधा ही अलग पहचान बनाने के लिए पर्याप्त नहीं रह गई
  • Sprites ऐसे एजेंट्स के लिए computers हैं जिन्हें ज़रूरत पड़ने पर सैकड़ों या हज़ारों की संख्या में बनाया जा सकता है और लंबे समय तक बनाए रखा जा सकता है; हर एक में 100GB persistent disk मिलती है और idle रहने पर usage-based billing रुक जाती है
  • नए Sprites में तेज़ और अधिक स्थिर Sprite Block Device, disk forking, और credentials उजागर किए बिना बाहरी systems को कॉल करने वाले Connectors जोड़े गए हैं
  • Fly.io इंसानों द्वारा डिज़ाइन किए गए fixed-function application platform और agent-केंद्रित भविष्य—दोनों का एक साथ पीछा नहीं करेगा; वह दूसरे पर फोकस करेगा, लेकिन Fly Machines और मौजूदा PaaS features जारी रहेंगे

मजबूत प्रदर्शन के बीच पहचान का संकट सामने आया

  • Theo Browne ने 2026 में नई applications host करने के लिए सबसे अच्छी जगह का आकलन करते हुए Fly.io के बारे में सकारात्मक बात की, लेकिन जिन providers पर वह नज़र रखता है उनमें साल के अंत तक उसके टिके रहने को लेकर सबसे कम भरोसा भी जताया
  • उस समय Fly.io कंपनी के इतिहास के सर्वश्रेष्ठ financial results समेत मजबूत quarterly performance दे रहा था, लेकिन वह क्या बना रहा है और किस दिशा में जा रहा है, इस पहचान संबंधी सवाल का समाधान अभी नहीं हुआ था
  • Fly.io ने काफ़ी अतिरिक्त फंड जुटाया, Sprites का नया version जारी किया ताकि कंपनी की क्षमता उसी पर केंद्रित की जा सके, और Scott Johnston को CEO नियुक्त किया

मौजूदा product-market fit की आधारशिला बदल गई

  • Fly.io की शुरुआत दो सिद्धांतों से हुई थी
    • internet applications यूज़र के जितना करीब deploy होंगी, उतनी तेज़ होंगी
    • जटिल cloud infrastructure के बजाय डेवलपर्स को AWS की flexibility और Heroku की usability साथ में मिलनी चाहिए
  • ये दोनों सिद्धांत अब भी महत्वपूर्ण हैं, लेकिन AI के सॉफ़्टवेयर development को बदल देने से ये पहले जितने निर्णायक नहीं रहे
  • coding agents को सिर्फ़ अधिक स्मार्ट compiler की तरह मौजूदा development process में जोड़कर इस बदलाव के पैमाने को समझना मुश्किल है
  • spreadsheets आने से पहले आज के Excel documents जैसे काम भी programmers द्वारा बनाए गए programs से ही होते थे, लेकिन spreadsheet formulas ने अनगिनत knowledge workers को programmer बना दिया
  • AI इससे भी बड़ा बदलाव ला रहा है और दुनिया को उस दिशा में ले जा रहा है जहाँ लगभग कोई भी व्यक्ति लगभग किसी भी तरह का program बना सकेगा
  • मौजूदा public cloud को कठोर standards और CI/CD प्रक्रियाओं से गुज़रने वाली fixed-function applications को लाखों लोगों तक पहुँचाने के लिए डिज़ाइन किया गया था
  • आगे भी लाखों users के लिए programs मौजूद रहेंगे, लेकिन वे शायद उन spreadsheets की तरह सामान्य रूप नहीं होंगे जिन्हें लाखों लोग पढ़ते हैं
  • 2020-शैली के public cloud design पर दाँव लगाते रहना, personalized और adaptive software के प्रसार के उलट दिशा में दाँव लगाने जैसा है
  • Fly.io ने उस दुनिया को चुना है जहाँ दोस्त और परिवार डेवलपर का इंतज़ार किए बिना कंप्यूटर से अपना मनचाहा काम सीधे करवा सकें

मानव डेवलपर अनुभव से अधिक एजेंट की ज़रूरतें

  • cloud infrastructure का डेवलपर्स के लिए कठिन होना अब भी समस्या है, लेकिन जब agents काम अपने हाथ में लेने लगते हैं तो इंसानों के लिए बारीकी से डिज़ाइन किए गए developer experience का महत्व घट जाता है
  • जो agents explicit environments में बेहतर काम करते हैं, उनके लिए opinionated defaults और curated developer experience उलटे नुकसानदेह भी हो सकते हैं
  • लोग documentation पढ़ने और नई CLI को trial and error से सीखने के बजाय agents को काम सौंपने लगे हैं
  • agents local में बनाई गई site को Fly.io पर deploy करने का अनुरोध एक ही बार में पूरा कर सकते हैं, लेकिन AWS deployment भी एक ही बार में कर सकते हैं, इसलिए सिर्फ़ usability के आधार पर अलग दिखना कठिन है
  • सबसे तेज़ी से बढ़ते customers के robots होने के अवलोकन के बाद, Fly.io ने अपने मौजूदा products को agents के लिए दोबारा व्याख्यायित करने के बजाय यह खोजना शुरू किया कि agents वास्तव में किस तरह का environment चाहते हैं

एजेंट किस तरह का computer चाहते हैं

  • coding agents मूल रूप से developer workstations पर चलने के लिए बनाए गए थे
  • भरोसेमंद sandbox भी अगर भौतिक laptop पर चले, तो ढक्कन बंद करते ही काम रुक जाता है; इसलिए users अंततः agent sandboxes को cloud में ले जाते हैं
  • मौजूदा public cloud servers, agent workflows के लिए ज़रूरत से ज़्यादा बड़ी प्रतिबद्धता मांगते हैं
    • उन्हें पारंपरिक pet servers या cattle servers से भी अधिक ephemeral होना चाहिए
    • ज़रूरत के समय बनाए जा सकें, जितने समय की ज़रूरत हो उतना ही टिकें, और कम लागत पर चल सकें
  • Sprites इन ज़रूरतों के लिए बनाए गए semi-ephemeral computers हैं
    • सैकड़ों या हज़ारों को तेज़ी से बनाया जा सकता है
    • हर Sprite के साथ 100GB persistent disk मिलती है
    • billing usage के हिसाब से होती है, लेकिन जब कोई काम नहीं हो रहा होता तो metering रुक जाती है, और idle स्थिति का पता सिस्टम खुद लगाता है
    • applications host की जा सकती हैं और internet के ज़रिए सहकर्मियों के साथ share भी की जा सकती हैं
  • industry sandbox पर केंद्रित है, लेकिन agents को sandbox नहीं बल्कि persistence और utility वाला computer चाहिए
  • Sprites को तुरंत बनाकर सीधे इस्तेमाल किया जा सकता है

Sprites को कंपनी के केंद्र में लाना

  • शुरुआती Sprites, Fly.io के अंदर एक छोटे अनौपचारिक टीम का प्रोजेक्ट था, और इसे Fly.io की मुख्य website पर host भी नहीं किया गया था
  • आगे से एजेंट्स के लिए computers (Computers for Agents) कंपनी का मुख्य फोकस होंगे, और Sprites अब कुछ लोगों तक सीमित प्रोजेक्ट नहीं रहेगा
  • Fly Machines और मौजूदा platform-as-a-service (PaaS) features को बंद नहीं किया जाएगा; वे जारी रहेंगे
  • नए Sprites scaling और orchestration को बेहतर बनाते हैं और दो प्रमुख subsystems जोड़ते हैं, जिससे लक्षित feature set पूरा होता है

Sprite Block Device और disk forking

  • पुराना storage stack JuiceFS पर बनाया गया था और उसमें Litestream जोड़ा गया था
  • Ben Johnson और Tim Newsham द्वारा ground up से बनाया गया Sprite Block Device(SBD) पहले से तेज़ और अधिक स्थिर है, और instant checkpoint/restore functionality भी बनाए रखता है
  • SBD का मुख्य विस्तार drive forking है, जिसकी मदद से एक template Sprite बनाकर उसे दक्षता से लाखों बार कॉपी किया जा सकता है

credentials को उजागर होने से रोकने वाले Connectors

  • Connectors का आधार tokenized tokens हैं, जिन्हें Fly.io ने अपनी core platform की सुरक्षा के लिए विकसित किया था
  • इन्हें इस तरह डिज़ाइन किया गया है कि Sprite दूसरे systems को authenticated requests भेज सके, लेकिन agent को ऐसे credentials सीधे न दिए जाएँ जो लीक हो सकते हों
  • यह accounts और API keys को manually manage करने की तुलना में अधिक सुविधाजनक है
  • SBD की replication क्षमता और Connectors वे features हैं जिनकी customers ने सबसे अधिक माँग की थी; यही वजह है कि dedicated agent product लॉन्च होने के बाद भी कई agent कंपनियाँ Fly Machines का उपयोग करती रहीं
  • जब तक Transformer models से भी अधिक अजनबी तकनीकी बदलाव नहीं आता, Fly.io का मानना है कि Sprites उसके future customers और मौजूदा customers के बड़े हिस्से, दोनों के लिए उपयुक्त हैं; इसलिए उसने नई beta जारी की है

संस्थापक CEO का पद छोड़ना

  • शुरुआती 8 वर्षों तक Fly.io को product-market fit खोजने वाली एक प्रयोगधर्मी संस्था की तरह चलाया गया
    • unbundled Postgres, global CDN, user-mode WireGuard सहित दर्जनों चीज़ों पर काम किया गया
    • bottom-up engineering organization बनाई गई, product roadmap से परहेज़ किया गया, और 12 से अधिक देशों में काम करने वाली एक fully remote team तैयार की गई
  • कुछ प्रयोग सफल रहे और कुछ सीखने का अवसर बने, लेकिन Fly.io के मौजूदा चरण में इस तरह के science projects की अब ज़रूरत नहीं है
  • संस्थापक ने यह निष्कर्ष निकाला कि CEO के रूप में वह जो विशिष्ट ताकत दे सकता था, उसका अधिकांश उपयोग हो चुका है; इसलिए उसने पद छोड़ने का फैसला किया

Scott Johnston का CEO बनना

  • 2025 से कई महीनों तक Scott Johnston को Fly.io के decision-making की ज़िम्मेदारी देने पर चर्चा हुई
  • Scott ने Docker के CEO रहते हुए enterprise market और developer market के बीच पहचान संकट से शुरू हुए कठिन दौर का नेतृत्व किया था, और बाद में बिज़नेस को काफ़ी बढ़ाया
  • Fly.io के shareholder और उस समय के CEO रहे संस्थापक ने आंका कि कंपनी के इस चरण में Scott की operating style उसकी अपनी शैली से अधिक उपयुक्त है, और बोर्ड के साथ मिलकर उन्हें यह भूमिका स्वीकार करने के लिए राज़ी किया
  • संस्थापक advisor और board member के रूप में बने रहेंगे, product design discussions में भाग लेंगे, और Scott बिज़नेस संचालन व execution संभालेंगे

नई रणनीति के लिए अतिरिक्त फंड

  • Fly.io ने कई वर्षों से नए निवेश की घोषणा नहीं की थी, लेकिन उसने पहले इतना बड़ा फंड जुटा लिया था कि पुराने प्लान के हिसाब से अतिरिक्त फंडिंग की आवश्यकता नहीं पड़ती
  • AI के कारण पुराने प्लान बदल गए, इसलिए नई रणनीति को आगे बढ़ाने के लिए अतिरिक्त फंड जुटाया गया, हालांकि राशि और शर्तें सार्वजनिक नहीं की गईं
  • Scott Johnston भविष्य की fundraising पर अलग से बात करने वाले हैं

दो भविष्यों में से एक का चयन

  • Fly.io का मानना है कि कुछ वर्षों के भीतर agents लगभग हर तरह के सॉफ़्टवेयर के निर्माण और deployment के तरीके को तय करेंगे
  • सॉफ़्टवेयर अधिक personalized होगा, उसका target audience छोटा होगा, और उसका रूप अधिक flexible व fluid होगा
  • यह बदलाव उम्मीद भी जगाता है और industry के लोगों को असहज भी करता है
  • कंपनी के सामने दो विकल्प थे
    • इंसानों द्वारा डिज़ाइन किए गए fixed-function full-stack application platform का विस्तार और सुधार जारी रखना
    • agent-केंद्रित निकट भविष्य के लिए उपयुक्त product को तराशकर पूरा करना
  • अगर कोई startup दोनों दिशाओं का एक साथ पीछा करे, तो किसी भी दिशा में पर्याप्त फोकस रखना मुश्किल होता है; इसलिए Fly.io ने agent-केंद्रित product को चुना
  • कई महीनों से टल रहे priority decisions को Sprites ने सुलझाया, और Scott Johnston को इसे Fly.io के मुख्य व्यवसाय में बदलने की ज़िम्मेदारी सौंपी गई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • Sprites का abstraction सुंदर है, लेकिन 30 साल के development career में मैंने इससे ज़्यादा bug वाला infra product नहीं देखा
    डेटा बार-बार गायब हो जाता था और कनेक्ट न हो सकने वाली zombie state में चला जाता था; सिस्टम का आधा हिस्सा Sprite को ठीक बता रहा था और बाकी आधा उसे dead मान रहा था, इसलिए snapshot भी load नहीं हो पा रहे थे
    लंच के दौरान, रात भर में, यहाँ तक कि काम करते समय भी आउटपुट गायब हो जाते थे; 2 हफ्तों में हार माननी पड़ी, और terminal history खंगालकर dead Sprite से काम की चीज़ें copy करके बचानी पड़ीं
    लगता है चलाए गए Sprites में आधे से ज़्यादा में दिक्कत आई; concept शानदार है, इसलिए उम्मीद है कि वे stability हासिल करेंगे

    • मैं एक ऐसा app चला रहा हूँ जो कई Sprites पर code run कराने को orchestrate करता है; कुछ महीने पहले तक service इतनी unstable थी कि पूरी तरह टूट जाती थी या डेटा गायब हो जाता था और support team से recovery करानी पड़ती थी
      हालांकि पिछले करीब दो महीनों में यह काफी ज़्यादा stable होती दिख रही है
      कुछ साल पहले Fly.io भी इतने bug वाला था कि real use के लिए मुश्किल था, लेकिन अब मैं उस पर कुछ production workloads बहुत reliably चला रहा हूँ; इसलिए लगा था कि Sprites भी वही रास्ता अपनाएगा, और सच में वैसा होता दिख रहा है
    • यह सिर्फ Sprite की समस्या नहीं है, बल्कि पूरे Fly.io platform ने कई सालों तक known issues को अनदेखा किया है, उसका नतीजा है
      CEO ने इसे खराब तरीके से चलाया है, इस लिहाज़ से resignation बेहतर भी हो सकता है
    • मैंने एक enterprise customer को fast development के लिए Sprites अपनाने पर विचार करते देखा, लेकिन अंत में उन्होंने Fly.io छोड़ दिया और उसी concept वाली दूसरी company पर चले गए
      वजह भी गंभीर interface bugs, data loss, और खराब support थी
      हालांकि test period में उन्होंने actual company domain इस्तेमाल नहीं किया था और यह भी नहीं बताया था कि वे Fortune 200 company हैं, इसलिए हो सकता है support quality पर इसका असर पड़ा हो

  • Elixir developer के तौर पर मैं चाहता था कि Fly.io सफल हो, लेकिन शानदार engineering और operational stability के बीच balance न बना पाने के कारण मुझे दो बार छोड़ना पड़ा
    कुछ समय तक global outages होते रहे और status page सब कुछ normal दिखाता रहा; outage का पता forum posts से चलता था, और company का जवाब था कि वे issue fix करने में इतने busy थे कि status update नहीं कर पाए
    बाद में उन्होंने status page update करना शुरू किया, लेकिन “specific region outage” के बाद कई घंटों तक कोई खबर न आने की घटनाएँ बार-बार हुईं
    Paid support आते ही मैंने तुरंत subscribe किया, लेकिन fast response का वादा करने वाला email address अक्सर कोई check ही नहीं करता था; बड़े outage report करने पर भी अगले दिन या कई दिन बाद “क्या समस्या है?” जैसा जवाब आता था
    अगर ऐसा rare होता तो यह सिर्फ customer support issue होता, लेकिन एक समय लगभग हर महीने कोई गंभीर outage झेलना पड़ता था; थोड़ी देर stable लगता और फिर बार-बार टूट जाता था
    आखिरकार सभी services self-hosting पर वापस ले गया; झंझट तो है, लेकिन uptime काफी बेहतर हुआ, और outage हो तो कारण खुद जान सकता हूँ, इसलिए pain बहुत कम है
    Hosting business जारी रखना है तो responsibility स्वीकार करनी होगी और operations में budget लगाना होगा; वरना hosting बंद करके एक और HashiCorp बन जाना बेहतर है

    • Status page normal था, लेकिन global outage का पता सिर्फ forum से चला—यह हिस्सा AWS है या Fly, पहचानना मुश्किल बना देता है

  • पूरी company को Sprites पर focus करना ऐसा लगता है जैसे Fly.io ने आत्महत्या चुन ली हो
    AI sandbox में पहले से कड़ी competition है और यह practically commodity बन चुका है; नया CEO शायद creative vision की कीमत पर revenue पर focus करेगा
    उम्मीद है मेरा आकलन गलत हो

    • Usage-based billing को छोड़ दें तो AI sandbox किसी भी virtual machine या container service के ऊपर आसानी से बनाया जा सकता है, इसलिए यह strategy समझ नहीं आती
      Containers disposable होते हैं और tasks आसानी से फिर से run किए जा सकते हैं, इसलिए data preservation भी कम critical है; agent से सीधे bare metal पर environment spin up भी कराया जा सकता है
      Agents अक्सर GPU का इंतज़ार करते हैं, इसलिए similar workloads पर memory deduplication लगाकर कम hardware पर भी सैकड़ों run किए जा सकते हैं
      AWS पहले से agents के लिए cloud है, और agents व infrastructure as code (IaC) इस्तेमाल करने पर AWS की complexity भी काफी घट जाती है
      अब value orchestration या model serving layer के hardware margin में कुछ bp के लिए लड़ने में नहीं है, बल्कि ऐसे tools बनाने में है जो agents को बेहतर decisions लेने में मदद करें

  • हाल की LLM progress के कारण सिर्फ individuals ही नहीं, companies और organizations भी identity crisis से गुजर रहे हैं; यह लेख इसका अच्छा example है
    AI एक बार में जो product या company बना सकता है, उसे बनाते रहने का मूल्य है या नहीं, यह सवाल है
    उल्टा, इसका एक दिलचस्प नतीजा यह भी है कि यह लोगों पर पहले असंभव दिखने वाले बड़े और ambitious कामों को आज़माने का दबाव डालता है
    उम्मीद है कि clean energy जैसे क्षेत्रों में और लोग आएँ, जहाँ सैकड़ों लोग एक ही काम करें तब भी मानवता को लगातार net benefit मिलता है

  • सवाल है कि Docker ने वाकई business को explosively grow किया, या Boeing की तरह दरवाज़ा उड़ गया, उस अर्थ में कहा गया है

  • Sprites किसी funded startup से ज़्यादा दोस्तों के छोटे group द्वारा चलाए जाने वाले छोटे stable business के लिए suitable लगते हैं
    Developers के लिए Docker या Podman पहले से ही इसे काफी अच्छी तरह solve करते हैं
    दादी-दादा तक apps बनाएँगे, ऐसा विशाल नया market Lovable जैसी services ले जाएँगी, और non-developers के Sprites इस्तेमाल करने की संभावना कम है
    अंत में वे existing developers में से सिर्फ कुछ हिस्से को ही capture कर पाएँगे

    • Agents अगर software development productivity को 100x बढ़ाने की प्रक्रिया में मेरा computer, home network और जीवन तक बिगाड़ देंगे, इस डर से theoretically मैं ही target customer हूँ
      OpenCode या Claude Code आदि के security disaster होने की खबरें रोज़ आती हैं; अगर isolation इतना आसान है तो ज़्यादा developers containers क्यों नहीं इस्तेमाल करते और ऐसी घटनाएँ लगातार क्यों होती रहती हैं, यह सवाल है
      Code तेज़ी से लिखने के लिए मैं अपने घर का environment remote corporate LLM के लिए खोलना नहीं चाहता, इसलिए agent coding से बच रहा हूँ; लेकिन जब कई source files को एक साथ analyze करना पड़ता है, तभी से साफ़ तौर पर नुकसान हो रहा है

  • पूरी company की direction Sprites पर बदलते ही तुरंत चले जाना harsh लगता है
    कम से कम नए CEO को खुद direction तय करके दाँव खेलने का मौका तो देना चाहिए

  • Company का future Sprites पर लगाना ठीक है या नहीं, यह doubtful है, और final call नए CEO का है
    Long term में ऐसे isolated execution environments Claude Code या Codex में built-in हो सकते हैं, या AI companies खुद दे सकती हैं

    • Sprites सिर्फ Claude Code जैसे tools को code run करने का environment नहीं देते; यह उन सभी के लिए useful है जो ऐसा product बना रहे हैं जिसे untrusted code सस्ते में run करना होता है
    • Sprites बहुत शानदार abstraction है
      Git worktree भी similar problem solve करता है, लेकिन Sprites के साथ instance जल्दी spin up करके service run कर सकते हैं और फिर coding agent को देकर feature improve करा सकते हैं
      कई agents parallel में run करके results में से एक चुन सकते हैं, और port count या local CPU constraints भी नहीं रहते
      RAM shortage कुछ समय तक जारी रहेगी, यह देखते हुए Sprites पर सैकड़ों agents run किए जा सकते हैं
    • जिस Claude ने code लिखा है, उससे deployment environment भी उधार नहीं लेना चाहता; सिर्फ code लेकर रिश्ता खत्म कर सकना और कहीं और deploy कर सकना अच्छा है

  • Fly.io को जिसे fix करके focus करना चाहिए, वह reliability है
    Docker container spin up करते ही app run हो जाना मुझे पसंद था, लेकिन service कई बार बंद हुई और price भी बहुत ज़्यादा था
    अभी मैं बस VPS इस्तेमाल कर रहा हूँ