- Fly.io ने जुलाई 2023 में A16Z और मौजूदा निवेशकों Intel Capital, Dell आदि से लगभग 2.5 करोड़ डॉलर ($25m) जुटाने के बाद, EQT Ventures के नेतृत्व में अतिरिक्त लगभग 7 करोड़ डॉलर ($70m) हासिल किए
- मुख्य चुनौती यह है कि ऐप को उपयोगकर्ताओं के करीब चलाने से वह बेहतर होता है, लेकिन सामान्य डेवलपर के लिए कई शहरों में deployment को 2 घंटे के भीतर समझ पाना मुश्किल है
- Fly.io वैश्विक deployment के साथ-साथ on-demand VM, real-time फीचर, user presence, encryption और secrets, clustered databases, hardware-accelerated inference को भी उसी 2 घंटे की समस्या के रूप में देखता है
- निवेश राशि का उपयोग अपनी hardware fleet, ज्यादा regions, support और reliability, advanced storage, security features, और नए hardware experiments में किया जाएगा
- Fly.io online sign-up के बाद जल्दी trial करने, और
flyctlके एक-दो commands व container packaging भर से ऐप चलाने वाले developer-friendly platform की दिशा बनाए रखेगा
Fly.io का निवेश जुटाना
- Fly.io ने जुलाई 2023 में A16Z और मौजूदा निवेशकों Intel Capital, Dell आदि सहित निवेशकों से 2.5 करोड़ डॉलर जुटाए
- इसके बाद EQT Ventures के नेतृत्व में अतिरिक्त 7 करोड़ डॉलर का निवेश हासिल किया
- निवेश घोषणा का एक व्यावहारिक उद्देश्य customers हासिल करना भी है
- कुछ customers छोटे Fly.io के साथ deal करने में सहज होते हैं, लेकिन कुछ customers तभी आश्वस्त होते हैं जब Fly.io ने EQT Ventures के नेतृत्व में 7 करोड़ डॉलर का अतिरिक्त निवेश उठाया हो
- Fly.io ने कई वर्षों तक community में users, fans और critics के साथ चर्चा करते हुए जिस platform vision को बनाना चाहता है, उसे refine किया है
“2 घंटे की समस्या” और global deployment
- 2020 में Fly.io का मूल विश्वास था कि apps जितना users के करीब चलेंगी, उतना बेहतर काम करेंगी
- video या real-time presence जैसी apps को उन प्रकारों में गिना गया जिन्हें physical proximity के बिना बनाना मुश्किल है
- शुरुआती HN launch thread में WebRTC, edge caching और game servers मुख्य चर्चा बनेंगे, ऐसी उम्मीद थी, लेकिन असल रुचि databases की ओर चली गई
- Fly.io से जो बात छूट गई, वह यह थी कि उसने माना था कि सिर्फ खास “edge-type” apps को ही global deployment चाहिए
- वास्तविकता में अधिकांश apps भी edge पर चलना चाहती हैं, लेकिन वे ऐसा तभी आजमाती हैं जब यह पर्याप्त आसान हो
- game servers के लिए edge deployment जरूरी होता है, इसलिए teams समस्या सुलझने तक लगातार आगे बढ़ती रहती हैं
- online bookstore जैसी CRUD app अगर लगभग 2 घंटे कोशिश करने के बाद भी साफ रास्ता न दिखे, तो दूसरी चीजों पर आगे बढ़ जाती है
मौजूदा internet deployment तरीके की सीमाएं
- दुनिया भर की बहुत-सी CRUD apps का Amazon
us-east-1वाले Ashburn, Virginia के पास host होना एक समस्या के रूप में पेश किया गया है - कई developers समझते हैं कि users के करीब चलाना बेहतर है, लेकिन सामान्य tools से कई शहरों में एक साथ app चलाने का तरीका 2 घंटे के भीतर समझ पाना मुश्किल है
- Fly.io की bet यह है कि सही platform और toolchain हो तो bookstore, sandwich rating app, music recommender, church mailing list manager जैसी apps भी दुनिया भर में तेज़ी से चलाई जा सकती हैं
- target regions Ashburn के आसपास तक सीमित नहीं हैं, बल्कि Chicago, Sydney, Singapore, São Paulo जैसे शहरों तक शामिल हैं
- कई शहरों में एक साथ तेज़ी से चलने की क्षमता को app quality बढ़ाने वाला अहम feature माना गया है
Fly Machines और अन्य “2 घंटे वाले features”
- sandboxing, code editors और REPL, CI/CD applications—इन सबको untrusted customer code चलाना पड़ता है
- ऐसे systems ने जरूरत पड़ने पर locked-down containers शुरू करने का तरीका अपने-अपने ढंग से सुलझाया है
- लेकिन on-demand VM कई तरह की apps के लिए बहुत valuable feature होने के बावजूद, 2 घंटे की research भर से implementation path साफ नहीं होता
- इसलिए Fly.io ने Fly Machines बनाया, और VM शुरू करने को function call जितना सरल बनाना चाहता है
- आगे के targets भी इसी pattern में आते हैं
- real-time features और user presence
- encryption और secrets storage
- clustered databases
- hardware-accelerated inference
- distributed databases, data locality, storage, AI और app frameworks के क्षेत्रों की दूसरी कंपनियां भी developers की “2 घंटे की window” समस्या हल करने की कोशिश कर रही हैं
- अगर Fly.io अपनी मंशा के मुताबिक काम करता है, तो ऐसे platforms उसके ऊपर नए primitives बना सकेंगे, users तक नए ideas ज्यादा तेज़ी से पहुंचा सकेंगे, और app quality बढ़ा सकेंगे
निवेश राशि की जरूरत क्यों है
- Fly.io मानता है कि ऐसा platform बनाने के लिए capital-intensive elements की जरूरत है
-
अपनी hardware fleet
- Fly.io हमेशा अपने hardware पर चलता आया है
- general-purpose cloud के ऊपर build करने के बजाय hardware को खुद rack में लगाने के पीछे तकनीकी कारण और control से जुड़े कारण हैं
- मुख्य कारण economics है
- अगर लोगों से platform पर apps बनवानी हैं, तो यह दिखाना होगा कि उसके 10 साल बाद भी मौजूद रहने की संभावना है, और Fly.io के अनुसार hardware जरूरी margins संभव बनाता है
-
ज्यादा regions
- Fly.io ने 19 regions के साथ शुरुआत की थी, और अगर लक्ष्य सिर्फ individual application developers हों तो यह पर्याप्त संख्या मानी गई
- लेकिन Fly.io चाहता है कि managed databases और developer tools जैसे दूसरे platforms भी Fly.io के ऊपर चलें
- ऐसी कंपनियों को ज्यादा regions की जरूरत होती है
- Fly.io अब 33 regions तक बढ़ चुका है, और नए regions चालू करने की गति भी और तेज हो रही है
-
support और reliability
- Fly.io मानता है कि platform reliability की challenge बड़ी है
- वह इसे ऐसी समस्या नहीं मानता जिसे सिर्फ चतुर तरीकों से हल किया जा सके
- वह advanced storage, security features और नए तरह के hardware पर भी ज्यादा bets लगाना चाहता है
platform की दिशा नहीं बदलेगी
- Fly.io जिस तरह की platform company बनना चाहता है, उसकी दिशा 2020 के बाद से नहीं बदली है
- लक्ष्य ऐसा platform है जिसे online sign-up के बाद 5 मिनट के भीतर आजमाया जा सके
- दूसरी तरफ वे platforms हैं जहां online sign-up के बाद sales representative संपर्क करता है, price बताता है और demo schedule करता है
- वह ऐसा platform चाहता है जिसे manual पढ़े बिना समझा जा सके
- दूसरी तरफ वे platforms हैं जिनके इस्तेमाल पर किताबें प्रतिस्पर्धा में छपती हैं, और app launch करने के लिए professional certification चाहिए होता है
- Python, Rust, Julia code सहज रूप से चल पाना चाहिए
- यह उस तरीके के उलट है जिसमें code को JavaScript में फिर से compile करना पड़ता है
- Fly.io features आम तौर पर
flyctlके एक-दो commands से इस्तेमाल किए जा सकते हैं, और अगर app container में package की जा सकती है तो वह काम करती है - अगर आपके पास पहले से काम कर रहा Docker container है, तो Fly.io पर तुरंत test कर सकते हैं
- शुरुआत शून्य से भी करें, तो single-digit minutes में Fly.io पर चल पाना चाहिए
- सभी continents में चलाने में उसके बाद करीब 1–2 मिनट और लग सकते हैं
1 टिप्पणियां
Hacker News की राय
“बहुत पैसा जुटाया” जैसी अभिव्यक्ति अब किसी सेवा के ग्राहक के नज़रिए से पहले चिंता पैदा करती है
ऐसा लगता है कि वह कंपनी सिर्फ venture capital के पैसे पर चल रही है, मैं जो इस्तेमाल करता हूँ या जिसके लिए भुगतान करता हूँ उसकी कीमत भविष्य की वास्तविक लागत नहीं है, और राजस्व से अलग प्लेटफ़ॉर्म बस बढ़ता ही जा रहा है
ग्राहक के तौर पर, यह सुनना कि संचालन और paid customer base के आधार पर मुनाफ़ा है, स्थिरता के लिए ज़्यादा भरोसेमंद लगता है
मैं लेख से असहमत नहीं हूँ, लेकिन अब इसे ग्राहक के नज़रिए से सकारात्मक संकेत मानना मुश्किल है
फिर एक दिन वे कहते हैं कि मैं तो एक शानदार प्लेटफ़ॉर्म मुफ्त में इस्तेमाल कर रहा हूँ, और कीमत बेहिसाब बदल देते हैं
यह वैसा है जैसे आपने किसी को घास काटने के लिए रखा हो, और कुछ साल बाद वह 3 ride-on lawnmower लेकर आए और कहे कि दी जा रही सेवा की लागत निकालने के लिए दाम बढ़ाने पड़ेंगे
उन्होंने 10-acre लॉन वाले ग्राहक के लिए अपना बिज़नेस बढ़ाया और मान लिया कि मुझे भी उसी स्तर की सेवा चाहिए, लेकिन आख़िर में लॉन की देखभाल मैं ही खो देता हूँ
अगर मैं investor होता तो venture capital पर निर्भरता चिंता की बात होती, लेकिन user के तौर पर Hello Fresh जैसी सेवा में investment subsidy की वजह से सस्ता खाना मिलना बुरा नहीं था
लगता है बहुत देर नहीं लगेगी कि exit के लिए बेच दिए जाएँ, लेकिन अगर उनमें independent company बने रहने का दर्द झेलने की ताकत है तो यह बहुत स्वागतयोग्य होगा
लगता है कि product validate हो चुका है, competitors की तुलना में सफल होने की संभावना ज़्यादा है, कुछ समय तक गायब नहीं होगा, और product improvement भी तेज़ होगी
यह मज़ाक कि “दुनिया के CRUD apps Loudoun County, VA, यानी Amazon us-east-1 के Ashburn पर चल रहे हैं, और उस शहर में Rails apps इतने ज़्यादा हैं कि उनमें से एक county board of supervisors के लिए चुन लिया गया” इतना सटीक है कि चुभता है
सोचें तो region वाला paradigm ही अब कुल मिलाकर काफ़ी पुराना लगता है। AWS ने कुछ हलचल ज़रूर दिखाई है, लेकिन आखिरकार control plane जैसी चीज़ों में अब भी region की अवधारणा से बंधा है, और साथ में VPC की अजीबता, जटिल billing, availability की समस्याएँ, और कई regions/AZs संभालने के लिए तरह-तरह के hacks, stacks और मेहनत जुड़ी रहती है
Fly और Cloudflare जैसे बाद में आए खिलाड़ी region की अवधारणा के बिना edge पर computation करने वाले approach से धीरे-धीरे cloud क्षेत्र पर हावी होते दिखते हैं, और AWS का region-based approach शायद उसके भीतर फँसी legacy applications के लिए बचा रह जाएगा
region-based approach “real cloud” से ज़्यादा hosted elastic datacenter जैसा है। असली cloud तो ऐसा होना चाहिए जो हर जगह हो और जिसे अलग से सोचने की ज़रूरत ही न पड़े
नतीजा यह है कि उनकी brand marketing में खोट निकालना मुश्किल है। ब्लॉग की हर पोस्ट साफ़ और हल्की व्यंग्यात्मक आवाज़ में लिखी होती है
अगर मशहूर hacker बनना है, तो industry में थोड़ा-बहुत मशहूर writer होना भी पड़ता है
ऐसी self-aware commentary कम ही इस्तेमाल करनी चाहिए तभी असर करती है, और इस बार यह बहुत अच्छे से काम करती है
यह ऐसी घोषणाओं के भाड़े के सैनिक जैसे मकसद, छिपे हुए पाखंड और आत्म-प्रदर्शन को मानते हुए भी सारी ज़रूरी जानकारी दे देती है, और प्लेटफ़ॉर्म किस असली समस्या को हल करता है, यह भी संक्षेप में समझाती है
investment money का वैध इस्तेमाल भी साफ़ बताती है, इसलिए “क्यों” और “कितना” जैसे सवालों का जवाब मिल जाता है
“startup ऐसी घोषणाएँ क्यों लिखते हैं?” इस सवाल पर, जिन कंपनियों को मैंने कई बार funding उठाते देखा है वहाँ यह 100% media exposure का बहाना था
जब तक “CEO को गबन और harassment, दोनों मामलों में एक साथ गिरफ़्तार कर लिया गया” जैसी बात न हो, अगर tech media में लेख छपवाने का बहाना मिल जाए तो मुफ्त विज्ञापन मिल जाता है
अगर target customers tech media पढ़ते हों तो और भी अच्छा। इसमें कुछ ग़लत नहीं, लेकिन इस भाड़े के मकसद को मानते हुए सबसे आम वजह को छोड़ देना थोड़ा हैरान करने वाला था
पत्रकार अपने पाठकों को अच्छी तरह जानते हैं, और उनका मतलब यही था कि funding announcement वाले लेखों पर ही clicks आते हैं
इसलिए हम पैसा जुटाने के बाद कभी-कभी 6 महीने तक चुप रहते थे और फिर किसी नए feature या product launch के साथ उसका एलान करते थे
अगर funding announcement के बिना tech articles पर भी ज़्यादा clicks आने लगें तो यह चक्र बदल सकता है, लेकिन अभी यह किसी prisoner’s dilemma जैसा लगता है। ऐसे लेख लिखे नहीं जाते, clicks नहीं आते, इसलिए फिर लिखे भी नहीं जाते
आम तौर पर, जैसा लेख में बताया गया है, किसी खास message और impression को छोड़ने के भाड़े के मकसद से
बेशक कंपनी का नाम फैलाना भी मकसद होता है, और लेख में उसी भाड़े वाली प्रेरणा पर कम बात हुई हो सकती है
याद पड़ता है कि तकनीकी रूप से यह public information थी। जब मैंने कंपनी शुरू की थी तब मुझे ऐसा ही समझाया गया था, लेकिन वह काफ़ी पहले की बात है
अगर आप खुद announce नहीं करेंगे तो दूसरे कर देंगे, इसलिए बेहतर है कि पहले आप पोस्ट करें ताकि लोग उनका लेख नहीं, आपका लेख पढ़ें
अगर 100 मिलियन डॉलर जुटाए हैं, तो 1 बिलियन डॉलर एग्ज़िट की ओर बढ़ना होगा। मौजूदा momentum बनाए रखने के लिए R&D लागत बहुत ज़्यादा बढ़ेगी
पूरा stack खुद बनाना होगा, और अंततः सब कुछ बहुत मज़बूत बनाना होगा, इसलिए यह बहुत बड़ा engineering काम है
Fly compute के लिए शुल्क लेता है और hardware व bandwidth सस्ते हैं, इसलिए ledger पर यह लाभदायक दिख सकता है
लेकिन असली लागत R&D, marketing, और stock-based compensation है, और ये लागतें किसी भी scale पर profitability को रोक सकती हैं। ये one-time लागतें नहीं हैं, इन्हें लगातार खर्च करना पड़ता है, और अगर खर्च न करें तो ग्राहक छोड़ देंगे
यह सिर्फ Heroku का मामला नहीं, बल्कि platform/infrastructure startup की त्रासदी है
छोटे cloud provider बहुत ज़्यादा दिखाई नहीं देते, इसकी वजह है; economics सिर्फ scale पर काम करती है
Fly के पास software engineering को लेकर सच में काफ़ी शानदार और आधुनिक नज़रिया लगता है, और यह काम करने के लिए अच्छी जगह भी दिखती है, लेकिन marketing और product के बीच बड़ा mismatch महसूस होता है
marketing और docs दुनिया भर में distributed app server बहुत आसानी से खड़े करने पर केंद्रित हैं, लेकिन जिन ग्राहकों को वास्तव में globally distributed app server चाहिए, उनके पास शायद पहले से globally distributed data store वाला mature platform होगा, इसलिए वे app server खड़ा करने की चिंता नहीं कर रहे होंगे
इसलिए मुझे लगता है कि शायद मैं internet application architecture के बारे में कुछ बुनियादी बात ग़लत समझ रहा हूँ
कई regions में चलाना उपयोगी है। Splatoon community एक जगह नहीं है, बल्कि दुनिया भर में फैली हुई है, इसलिए अगर सिर्फ अमेरिका में host करें तो जापानी players के लिए धीमा होगा, और उल्टा भी यही
प्रोजेक्ट सफल न भी हो, तब भी बाद में स्कूल से बाहर आने के बाद यह काफ़ी उपयोगी अनुभव लगेगा
अभी इसे US East, Amsterdam, Tokyo में लगभग 10 डॉलर प्रति माह पर चला रहा हूँ
बस उसका रूप Kubernetes, single-page apps, GraphQL, edge deployment वगैरह में बदलता रहता है
gold rush में फावड़े बेचना ही काफ़ी है
यह वाक्य कि “कुछ platform कंपनियाँ हैं जो Python, Rust, Julia code अच्छी तरह चला सकती हैं, और कुछ platform कंपनियाँ हैं जो आपको उसे फिर से JavaScript में compile करने का तरीका ढूँढ़ने पर मजबूर करती हैं” Cloudflare और Deno पर हल्का-फुल्का तंज लगता है
अगर Fly Docker containers के साथ WASM containers hosting भी करने लगे, तो यह दिलचस्प होगा
Cloudflare पर तंज शायद “salesperson को फ़ोन करवाने” वाले हिस्से में था
यह अच्छा लगा कि Fly ने स्वीकार किया कि लोग इसे games/edge caching वगैरह के लिए इस्तेमाल करेंगे, ऐसा सोचने के बावजूद, वास्तव में सब इसे नए Heroku की तरह Rails+PostgreSQL CRUD apps deploy करने के लिए इस्तेमाल कर रहे हैं
मेरी समझ के अनुसार अगला लक्ष्य Rails+PostgreSQL apps को edge पर ले जाना इतना आसान बनाना है कि वह “दो घंटे की समस्या” भर रह जाए
यह काफ़ी साहसिक है। ऐतिहासिक रूप से “इस domain model को shard करने का सबसे अच्छा तरीका क्या है” जैसी application/framework/domain-specific coupling की ज़रूरत रही है
इसे PaaS/IaaS से हल करने का मतलब व्यवहार में distributed Cloud SQL/Aurora लिखना और चलाना होने के काफ़ी क़रीब है
हालाँकि अगर बात सिर्फ Aurora clone या Neon जैसी किसी चीज़ को stack के भीतर smoothly चलाने तक है, तो यह संभव लगता है, और product value भी काफ़ी बड़ी हो सकती है
SMB/hobby cloud के margins तुलनात्मक रूप से कम होने को देखते हुए, मुझे साफ़ नहीं है कि fly.io profitability कैसे हासिल करेगा
दुनिया भर को free tier पर चढ़ाया जा सकता है, लेकिन जब EQT को वसूली करनी होगी, तब क्या होगा
क्या वे इतने features बना पाएँगे कि कंपनियाँ इसे गंभीरता से चुनें। जिन कंपनियों में मैं रहा हूँ, उनमें अगर टीम 5 से कम लोगों की न हो और scaling की बिल्कुल ज़रूरत न हो, तो इसे इस्तेमाल करना या आगे बढ़ाना मुश्किल लगता
हमारी unit economics अच्छी है। हमने जो सबसे risky और डरावना काम किया, वह अपना hardware लेकर शुरुआत करना था
developer-focused infrastructure में आपको बहुत से developers को आकर्षित करना होता है, फिर उन्हें अपनी नौकरी में हमें लेकर आने देना होता है, और उसके बाद उनके employers को लंबे समय तक कुछ बेहतर बनाने में मदद करनी होती है
जिन कंपनियों में formal purchasing process होती है, वे startup से core infrastructure न खरीदें, इसी तरह डिज़ाइन की जाती हैं, इसलिए इसमें बहुत समय लगता है
अभी भले ही यह सबके लिए सही न हो, लेकिन अब तक हमारे लिए यह काम कर रहा है
[0] https://community.fly.io/t/funding-and-longevity/1957
मुझे जिज्ञासा है कि fly.io ऐप के पूरे हिस्से, dynamic content समेत, को CloudFront या किसी और CDN के आगे रखने के तरीके से कैसे अलग है, या उससे बेहतर कैसे है
CDN client के क़रीब होता है, इसलिए वह कम latency वाला SSL setup देता है, और यह फ़र्क काफ़ी बड़ा हो सकता है
यह app server को edge तक नहीं धकेलता, लेकिन ऐसा करने पर भी Virginia के bunker में बैठे database तक जाने की latency लागत फिर भी देनी पड़ती है
बहुत-सी apps एक web request में database के कई round-trip करती हैं, इसलिए यह और भी ख़राब लगता है। मेरा मानना है कि web request पर latency cost झेलने से बेहतर है कि app server database तक तेज़ी से पहुँचे
Fly के target customers ज़्यादातर static content वाली तरफ़ के लगते हैं