Fly.io का Postgres क्लस्टर 3 दिनों तक डाउन रहा, और उसके बारे में कोई सूचना नहीं मिली।

 (community.fly.io)
2 पॉइंट द्वारा GN⁺ 2023-07-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जुलाई 2023 में Fly.io होस्ट पर emergency maintenance के दौरान कई users की machines "stopped" और zombie state में अटक गईं, जिससे restart, removal और redeploy सब असंभव हो गए
  • dashboard पर सिर्फ "Service Interruption" banner दिखा, लेकिन status page पर संबंधित जानकारी नहीं थी, इसलिए कारण और recovery ETA समझना संभव नहीं था
  • fly machine command "could not get machine" error के साथ fail हुई, और machine list में creation date "1970-01-01" दिखने जैसे abnormal data मिले
  • कुछ लोगों ने fly scale से नया VM चलाकर अस्थायी recovery की, लेकिन खराब VM delete नहीं हो सका और billing जारी रहने की चिंता बनी रही
  • 12~15 घंटे से ज्यादा समय तक official response या status update न होने से platform reliability पर भरोसा कम हुआ

outage और शुरुआती लक्षण

  • सुबह app के health checks fail होने लगे, और machine "stopped" state में दिखी
  • dashboard पर सिर्फ "We are performing emergency maintenance on a host some of your apps instances are running on" नाम का Service Interruption banner दिखा, इसके अलावा कोई जानकारी नहीं
  • status page पर यह outage नहीं दिखा, इसलिए resolution process या ETA नहीं मिल सका
  • रुकी हुई machine instance को restart या remove करने की कोशिश करने पर timeout हुआ
  • redeploy के समय unmanaged machine से जुड़ी error आई
    • fly deploy केवल उन machines को update करता है जिनके metadata में fly_platform_version=v2 होता है, इसलिए fly machine update --metadata fly_platform_version=v2 <machine id> से हर machine को manually update करना पड़ता है

zombie machine state और workaround

  • कुछ machines "zombie mode" में चली गईं और सभी fly machine commands पर "Error: could not get machine" response देने लगीं
  • fly scale से additional VM allocate करके app availability restore की गई, लेकिन खराब VM अनिश्चित state में पड़ा रहा और उसे remove करना या account delete करना संभव नहीं रहा
  • fly machine list ने creation date "1970-01-01T00:00:00Z" जैसा गलत data दिखाया
  • एक और user ने भी इसी तरह scale up करके नई machine बनाकर workaround किया, लेकिन original machine "connection refused" error के कारण remove नहीं हो सकी
    • चिंता रही कि cleanup न हुए zombie VM और नए बनाए गए अतिरिक्त VM, दोनों के लिए billing होगी
  • staging environment भी इसी state में था

database container पर प्रभाव

  • एक user लगभग 14 घंटे पहले से यही समस्या झेल रहा था, और target database container था, इसलिए केवल scale up से recovery संभव नहीं थी
  • paid plan पर होने के बावजूद कुछ घंटे पहले support को email किया था, लेकिन कोई response नहीं मिला
  • संबंधित app syd region में hosted था, इसलिए संभावना जताई गई कि वहां के एक-दो hosts में समस्या हो सकती है

व्यापक प्रभाव और temporary recovery

  • कल तक app + Postgres (staging और production) की 4 machines चल रही थीं, लेकिन databases सहित 3 अभी भी down थीं
  • संबंधित app कंपनी का external API app था, इसलिए सभी integrations रुक गए
  • operations जारी रखने के लिए Fly पर नया project बनाकर instance चलाया गया, और environment variables व settings backfill करने में कुछ घंटे लगे
    • अनजाने में DR (disaster recovery) capability test बन गया
  • db machine से data लाने का कोई तरीका नहीं था, लेकिन यह main production db नहीं था, इसलिए जरूरी चीजों को reverse-engineer करके restore किया गया

platform reliability को लेकर चिंता

  • 12 घंटे बीत जाने के बाद भी official response न होने पर हैरानी जताई गई
  • यह दूसरी बार था जब वही समस्या हुई; service down होने पर भी Fly उसे normal report करता रहा और information या response न होने से सिर्फ इंतजार करना पड़ा
  • Heroku से तुलना: host unstable होने पर dyno automatically migrate हो जाता था, इसलिए ऐसी चिंता नहीं होती थी
  • छोटे standard Rails + Postgres app में भी हुई इस समस्या को लेकर चिंता जताई गई कि अगर app ज्यादा complex होता तो response देना और मुश्किल होता
  • कहा गया कि इस तरह की समस्याएं platform पर भरोसे को पूरी तरह तोड़ देती हैं

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

1 टिप्पणियां

 
GN⁺ 2023-07-21
Hacker News टिप्पणियाँ

  • Fly ने support thread में जवाब दिया: उनका कहना है कि वे फ़ोरम को नियमित रूप से देखते हैं, लेकिन यह पोस्ट छूट गई, और syd region में single host failure लंबे समय तक जारी रहा
    host restart के बाद सामान्य रूप से वापस नहीं आया और service discovery से भी कनेक्ट नहीं हो पाया, इसलिए manual recovery की ज़रूरत पड़ी
    कई instances पर चल रहे apps में केवल कुछ instances प्रभावित हुए, लेकिन single instance apps outage के दौरान inaccessible रहे, और Fly कई instances की configuration को ज़ोरदार तरीके से recommend करता है
    global/region outages को status.fly.io पर पोस्ट किया जाता है, और single host issues को dashboard के status tab में दिखाया जाता रहा है, लेकिन इस बार जैसी लंबी single host outage के लिए communication के तरीके की वे फिर से समीक्षा कर रहे हैं
    https://community.fly.io/t/service-interruption-cant-destroy...

    • मैं भी ऐसी ही बातों की वजह से Fly छोड़कर चला गया। पहले Fly machine पर चल रहा web app नए production PostgreSQL machine से बीच-बीच में connect नहीं कर पा रहा था, और बाद में PostgreSQL machine पूरी तरह मर गई और सारा data खो गया
      restart से भी recovery नहीं हुई, इसलिए एक पुराना backup RDS पर restore किया, और लगा कि migrate करना सही फैसला था
    • अगर यह सच में बस छूट गया था, तो समझ नहीं आता कि वह thread सिर्फ logged-in users के लिए private क्यों कर दिया गया
    • आजकल एक single host का खो जाना इतना बड़ा मामला क्यों होना चाहिए, यह समझ नहीं आता। instance failures तो होना स्वाभाविक है, और भले ही customer सिर्फ single instance चला रहा हो, खासकर Fly.io जैसे container-centric प्लेटफ़ॉर्म पर, उम्मीद होती है कि वह अपने-आप reschedule हो जाएगा
      ऊपर से यह सिर्फ user container नहीं बल्कि managed PostgreSQL service जैसा लग रहा है, इसलिए host failure के खिलाफ resilience की उम्मीद करना और भी जायज़ लगता है
    • यह अजीब लगा कि platform outage support ऐसे फ़ोरम पर निर्भर है जिसे कर्मचारी देखें भी या नहीं। docs[1] के मुताबिक email support पाने के लिए paid plan, कम से कम $29/माह चाहिए, इसलिए हो सकता है कि आप resource costs दे रहे हों फिर भी support न मिले
      मैं शायद $5~10/माह दे सकता हूँ, लेकिन 3 दिन का outage नहीं चाहता, इसलिए side project पर इसका इस्तेमाल नहीं करूँगा
      [1] https://fly.io/docs/about/support/
    • विडंबना और दुख की बात यह है कि जितनी कम entry barrier वाली service आप बनाते हैं, उतना ही ज़्यादा नीचे की friction-heavy low-level layer को संभालने के लिए experts की ज़रूरत पड़ती है
      अगर outage कुछ घंटों तक चला, तो मेरा मानना है कि Ansible या कुछ और इस्तेमाल करके नई machine खड़ी कर देनी चाहिए थी। चाहे hardware हो या AWS/GCP virtual machine, यह किया जा सकता था

  • ऐसा लगा कि Fly इस समस्या को दबाने की कोशिश कर रहा था, क्योंकि उसने thread[1] को बिना login वाले लोगों के लिए private कर दिया
    thread में ऐसे उदाहरण थे जहाँ service down थी लेकिन Fly status सामान्य दिखा रहा था, कोई जानकारी नहीं थी, और इंतज़ार करने के अलावा कुछ करने को नहीं था
    एक दूसरे user ने कहा कि app और staging/production PostgreSQL समेत चार में से तीन machines अब भी down थीं, और external API app टूट जाने से सारी integrations खराब हो गई थीं
    नया Fly project बनाकर temporary instance खड़ा करने में कई घंटे लग गए, और DB machine से data निकालने का कोई तरीका नहीं मिल रहा था
    यह प्रतिक्रिया भी थी कि organization status page पर “कोई outage नहीं” दिखना, जबकि उसी page पर app को maintenance में और inaccessible दिखाया जा रहा हो, अपमान जैसा लगता है
    17 घंटे तक status page update या notification लगभग नहीं थे, और सिर्फ Better Stack alerts मिले, ऐसी पोस्ट भी थी
    पूरा thread backup: https://pastebin.com/ebmCSZkC
    Fly CEO को भेजा गया tweet: https://twitter.com/SouthPawNZ/status/1682181533673857024
    [1] https://community.fly.io/t/service-interruption-cant-destroy...

  • Fly की सबसे खराब बात यह है कि जब कुछ गलत होता है, तो सिर्फ एक चीज़ नहीं टूटती बल्कि कई चीज़ें एक साथ टूटती हैं, और status page पूरी तरह हरी दिखती है
    आम तौर पर प्रतिक्रिया भी या तो चुप्पी होती है या “शुक्रवार को deploy करोगे तो ऐसा ही होगा” जैसी बहुत हल्की-फुल्की बात
    प्रोडक्ट देखने में शानदार लगता है, लेकिन मुझे यह उन hosting services में सबसे अस्थिर सेवा का खूबसूरती से पैक किया हुआ रूप लगता है जिन्हें मैंने इस्तेमाल किया है
    हर हफ्ते लोगों का काम बिगाड़कर, उन्हें weekend night में recovery में समय खर्च करने पर मजबूर करके, आखिर में “हम इससे बेहतर कर सकते थे” कहकर बात खत्म नहीं की जा सकती। यह अपवाद के लिए बहाना हो सकता है, बार-बार दोहराए जाने वाले पैटर्न के लिए नहीं

    • service outage के समय AWS-style status page संचालन की नकल करना, काफ़ी साहसी है

  • इस HN thread में काफ़ी शोर है, लेकिन मुझे लगता है कि मुख्य बात यह है: कर्मचारियों ने शायद ग्राहकों के नोटिस करने से पहले ही समस्या देख ली थी, paid support को email भेजने के बाद भी जवाब आने में कई घंटे लगे, और डाउन host के बारे में update लगभग 20 घंटे बाद ही आया
    प्रभावित users को host failure या recovery के तरीकों के बारे में ठीक से नहीं बताया गया, और dashboard पर emergency maintenance दिखाते हुए भी status page पर सब कुछ normal दिखाया गया
    plan और architecture की प्रकृति के कारण ऐसा downtime सुनिश्चित और आम बात है, यह मैं समझता हूँ, लेकिन अगर communication इतना खराब हो तो ग्राहक चले जाते हैं
    अगर दूसरे providers की तरह मेरे app जिस host पर चल रहा है उसमें थोड़ी भी गड़बड़ी हो तो मुझे email भेज दिया जाए, तो कम से कम मैं अपने app के लिए तुरंत कुछ कर सकता हूँ

    • मेरी नज़र में यह अच्छा summary नहीं है। free tier support forum activity नोटिस करने पर निर्भर था, और वह छूट गया; outage झेलने वाले लोगों ने high availability न होने वाली configuration में deploy करने का परिणाम देखा
      हालाँकि, इस बात पर मतभेद है कि क्या वे खुद पर्याप्त रूप से जानते थे कि उनकी स्थिति ऐसी थी
      एक खास server पर असामान्य रूप से लंबा outage हुआ, और इन बातों के मिल जाने से कई लोगों को बिना किसी explanation के लंबा outage झेलना पड़ा
      dashboard सिर्फ region/service outages दिखाता है, individual server outages नहीं, और लोग यह नहीं जानते थे, इसलिए उन्हें यह झूठ जैसा लगा
      Discourse tag settings के अजीब व्यवहार की वजह से ऐसा लगा जैसे समस्या छिपाने की कोशिश की जा रही हो
      संक्षेप में, किस्मत खराब थी, customer management के नज़रिए से process खराब था, documentation भी कुछ जगह कमज़ोर हो सकती थी, लेकिन मुझे यह आग से ज़्यादा धुआँ वाला incident लगता है
    • Fly.io के कर्मचारी के रूप में स्पष्ट कर दूँ: इस single host के डाउन होने के 30 मिनट के भीतर हमने प्रभावित सभी ग्राहकों की personalized status page[1] पर सूचना दे दी थी, और लगभग 47 घंटे बाद समस्या हल होने पर status page पर उसे resolved भी दिखाया गया
      timeline UTC के अनुसार यह थी: 2023-07-17 16:19 host down, 16:49 personalized status page post, 2023-07-19 15:00 host recovery, 15:17 status page resolved
      [1] https://community.fly.io/t/new-status-page/11398
    • ज़रा कल्पना करें कि अगर AWS को हर बार किसी region में एक single host डाउन होने पर global status page update करनी पड़े तो वह कैसा दिखेगा
      Fly.io, Heroku clone नहीं बनना चाहता था, लेकिन marketing और अच्छी तरह तराशे गए user experience की वजह से आखिरकार वैसा ही दिखा
      नतीजतन, उसे Heroku-style user base से भी निपटना पड़ा, जो single host outage पर भी brand को बड़ा नुकसान पहुँचा सकता है
    • मैंने personal project में Fly इस्तेमाल करते हुए यही चीज़ झेली है। प्रोजेक्ट डाउन था, लेकिन status page पर सब कुछ normal दिख रहा था
      मज़े के लिए किए जा रहे personal project के लिए तो ठीक था, लेकिन किसी ज़्यादा गंभीर उपयोग के लिए यह कितना उपयुक्त है, पता नहीं
    • अगर कोई गलत जानकारी है, तो ऐसी सामान्य बातें करने के बजाय उसी पोस्ट पर सीधे जवाब देना बेहतर होगा
      और 20 घंटे के downtime को “सुनिश्चित और सामान्य” कहने लायक इतने cloud providers हैं, यह मानना मुश्किल है
      दुर्भाग्य से, Fly.io से जुड़ी HN threads में मैंने काफ़ी passive-aggressive रवैया महसूस किया है

  • मैं सच में Fly.io को पसंद करना चाहता था। इसे configure करना और इस्तेमाल करना बहुत आसान है, लेकिन ईमानदारी से कहूँ तो mission-critical applications को इस service पर नहीं चलाना चाहिए
    आखिरकार सब कुछ AWS पर migrate कर दिया, जबकि मैं सच में ऐसा नहीं करना चाहता था
    machines अक्सर काम नहीं करती थीं, random outages होते थे, builds fail होते थे, और support के लिए higher tier का भुगतान करने के बाद भी support धीमा था और सवाल ठीक से पढ़ता भी नहीं था
    sidecar जोड़ नहीं सकते, external monitoring के साथ integrate करना मुश्किल है, और docs happy path पर तो ठीक हैं लेकिन edge cases में बहुत कमज़ोर हैं
    hobby projects के लिए यह ठीक है, और आज भी मैंने कई personal projects इस पर चलाए हुए हैं, लेकिन company infrastructure के लिए समय और frustration की लागत बहुत बढ़ गई थी, इसलिए migrate करना पड़ा
    यह Heroku का मानसिक उत्तराधिकारी जैसा लगता था, इसलिए उम्मीदें बड़ी थीं, लेकिन मुझे नहीं लगता कि यह अभी उस स्तर पर है

    • मेरा अनुभव भी यही था। हाल की एक hobby project में भी मैं लगातार दो दिन कुछ भी build नहीं कर सका, इसलिए मैंने इसका इस्तेमाल बंद कर दिया
      पिछले हफ्ते यह build हो रहा था, local में भी ठीक चल रहा था, बाद में Fly पर फिर से चलने लगा, लेकिन यह बिना किसी कारण बताए और बिना support जवाब के समझ से बाहर downtime था
      free tier बहुत उदार है, इसलिए billing limit के भीतर भी बहुत कुछ किया जा सकता है, लेकिन मेरे पास खाली समय कम है, और उस समय में मैं बस अपना project build करना चाहता हूँ
      वह सिर्फ Node से build होने वाली एक छोटी static site थी, फिर भी ऐसा हुआ
      tooling खुद शानदार है, इसलिए अगर वे infrastructure को stable कर लें तो मैं फिर से इसे आज़माना चाहूँगा
    • service इस्तेमाल करने के लिए ज़रूरी अहम जानकारी का आधा हिस्सा किसी forum thread में दबा पड़ा है जिसे कर्मचारियों ने पोस्ट किया था
      अगर उतनी ही मेहनत से वह जानकारी docs में नहीं डाली जा सकती, तो पता नहीं documentation pipeline कितनी खराब होगी
      इस्तेमाल से जुड़े forum सवालों के जवाब “यह docs में है, नहीं है तो अभी जोड़ दिया” और “अगर भ्रम है तो बताइए, docs update कर देंगे” होने चाहिए
    • मेरा भी यही अनुभव रहा। Fly dashboard पर सब कुछ normal दिख रहा था, लेकिन requests timeout हो रही थीं
      मुझे खुद fly logs में जाकर देखना पड़ा कि proxy server तक पहुँच नहीं पा रहा था, और इसे ठीक करने का मेरे पास कोई तरीका नहीं था
      कुछ घंटे बाद मैंने forum पर issue डाला, लेकिन न कोई जवाब आया न पढ़े जाने का कोई संकेत मिला, और थोड़ी देर बाद वह जादू की तरह ठीक हो गया
      मैं चाहता हूँ कि यह सफल हो, लेकिन इस communication की कमी और कुछ भी न कर पाने वाली बेबसी की वजह से कुछ समय तक मैं fly.io इस्तेमाल नहीं करूँगा
    • क्या आपने Render इस्तेमाल किया है? आपके हिसाब से Heroku का उत्तराधिकारी क्या है?
    • मेरा अनुभव भी कुछ निराशाजनक था। मैंने अपने toy project को आखिरकार Hetzner VM + Dokku पर migrate कर दिया, क्योंकि PostgreSQL database node बिना किसी सूचना के रुक गया था और जब तक मैंने उसे manually revive नहीं किया, वह वापस नहीं आया

  • यह शायद बहुत संतोषजनक जवाब नहीं होगा, लेकिन मैं निजी तौर पर बस इतना ही कह सकता हूँ: हमारी community site पर यह thread सूची से क्यों गायब हुआ, मुझे बिल्कुल नहीं पता।
    मैं admin UI देख रहा हूँ, और पोस्ट के बगल में एक छोटा ताला दिख रहा है, लेकिन “unlist story” विकल्प अब भी क्लिक करने योग्य है।
    मैं सबसे अच्छा यही कह सकता हूँ कि मुझे काफी यक़ीन है कि इस thread को छिपाने के लिए ऊपर से कोई निर्देश नहीं आया था। साइट public है और कोई भी account बनाकर thread देख सकता है।
    आप हमारे बारे में जो कहना चाहें कह सकते हैं, लेकिन ऐसी चीज़ें छिपाना हमारी कमियों में से एक नहीं है।
    Sydney server समस्या के बारे में मुझे अभी पर्याप्त जानकारी नहीं है, इसलिए वहाँ instance चला रहे लोगों के लिए उपयोगी जवाब नहीं दे सकता। मैं बाहर से लौटकर अभी-अभी स्थिति समझना शुरू कर रहा हूँ।
    अब देख रहा हूँ कि app-not-working category की सभी पोस्ट “private” जैसी दिख रही हैं, और शायद यह category setting की वजह से है। यहाँ private का मतलब है कि उसे देखने के लिए Discourse account से signup करना होगा।

    • अगर ईमानदार सलाह दूँ, तो यह शायद Kurt पर ज़्यादा लागू होती है, लेकिन कंपनी को बेहतर process, accountability, communication की ज़रूरत है।
      इस जवाब का tone और fly.io की दूसरी communications यह संकेत देती हैं कि fly.io के बारे में लोगों की राय को देखते हुए इन चीज़ों की कमी है।
      60 से ज़्यादा कर्मचारी हों और समस्याएँ इतनी हों, तो यह इंसानी और अपनापन भरा tone नहीं बल्कि ऐसे business का संकेत लगता है जो scale नहीं कर पा रहा।
      किसी बढ़ते हुए B2B business को सफल होने के लिए process और oversight जैसी चीज़ें चाहिए, लेकिन दूसरी प्रतिक्रियाएँ देखकर लगता है कि आप लोग उन्हें नहीं चाहते, और यह अच्छा संकेत नहीं है।
      एक बार टूटे तो incident, दो बार टूटे तो bad luck, लेकिन तीन बार टूटे तो process टूटा हुआ है। यहाँ comments देखकर लगता है कि Fly.io में यह तीन बार से कहीं ज़्यादा होता है।
    • इस जवाब को देखकर मेरा निष्कर्ष यह है कि अगर मैंने काम पर Fly.io चुना होता, तो शायद मुझे नौकरी से निकाल दिया जाता।
      outage की वजह से नहीं, बल्कि इसलिए कि support मिलने में कई दिन लग सकते हैं।
      अगली बार support बेहतर होगा, इसका community को आप क्या भरोसा दे सकते हैं?
    • शायद इसलिए क्योंकि यह SYD region में hosted है।
    • मुझे नहीं पता कि app-not-working category क्यों effectively threads को सूची से हटा रही थी, लेकिन वजह पता चलने तक मैंने उसे फिलहाल हटा दिया है, इसलिए यह thread फिर से public हो गया है।
    • मुझे Thomas जो कर रहे हैं वह सचमुच बहुत पसंद है, और मुझे लगता है कि यह approach सही है। संदर्भ के लिए, https://fly.io/blog/carving-the-scheduler-out-of-our-orchest... Fly blog पर मेरी पसंदीदा पोस्टों में से एक है।
      हम अप्रैल 2022 से https://changelog.com को Fly.io पर चला रहे हैं, और मौजूदा architecture यहाँ है: https://github.com/thechangelog/changelog.com/blob/master/IN...
      15 महीनों में हमने Fly.io पर Phoenix + PostgreSQL app के साथ 10 करोड़ से अधिक requests संभाली हैं, और फिर भी शिकायत करने की वजह ढूँढना मुश्किल है।
      कुछ deployments फेल हुए थे जिन्हें pipeline दोबारा चलाकर ठीक किया गया, जुलाई 2023 की शुरुआत में Frankfurt में 9 हज़ार requests ने 10 सेकंड तक 503 लौटाया था, और machines experiment के दौरान एक volume जो delete नहीं हो रहा था, वह अगले दिन गायब हो गया।
      हम Kaizen podcast में अक्सर Fly.io के अनुभव के बारे में बात करते हैं: https://changelog.com/topic/kaizen
      migration announcement episode: https://changelog.com/shipit/50
      संबंधित PR: https://github.com/thechangelog/changelog.com/pull/407
      apps v1(Nomad) से apps v2(flyd) migration plan के बारे में भी हमने हाल ही में बात की थी: https://changelog.com/friends/2#transcript-138
      यह दुखद है कि बहुत से लोगों का अनुभव अच्छा नहीं रहा, लेकिन मुझे लगता है Fly.io आगे भी बेहतर होता रहेगा। उम्मीद है कि कभी न कभी यह कठिन दौर एक अच्छी कहानी बन जाएगा।
      उम्मीद देने वाली पोस्ट: https://community.fly.io/t/reliability-its-not-great/11253

  • मुझे fly.io बहुत पसंद है और मैं चाहता हूँ कि यह सफल हो। वे मुश्किल काम कर रहे हैं, इसलिए चीज़ें टूट सकती हैं।
    लेकिन communication की कमी निराशाजनक है, खासकर इसलिए कि मार्च में CEO ने community में reliability पर जो बड़ी पोस्ट लिखी थी, उसमें उन्होंने खुद इसे सुधारने वाली चीज़ के रूप में बताया था।
    https://community.fly.io/t/reliability-its-not-great/11253#s...

    • “हमसे गड़बड़ हुई, लेकिन हम इसे ठीक करेंगे” वाला कार्ड एक बार खेलने के बाद भी अगर आप उसे लगातार ठीक नहीं कर पाते, तो स्थिति कठिन हो जाती है।
    • मैं इस ईमानदार feedback की कद्र करता हूँ। इस समस्या के बारे में communication हम बेहतर कर सकते थे।
      प्रभावित users के dashboard पर हम single-host failures दिखाते रहे हैं, और platform/region समस्याओं को status page पर दर्शाते रहे हैं, लेकिन साफ़ तौर पर एक बीच का क्षेत्र है जहाँ हमारी बताई गई स्थिति और users का वास्तविक अनुभव मेल नहीं खाते।
      हाल में capacity समस्याओं से बचने के लिए हमने बहुत सारा hardware जोड़ा है, और जैसा अपेक्षित था, कुल outages की संभावना कम हुई है, लेकिन hardware के रूप में failures की मात्रा बढ़ी है।
      users को ऐसी समस्याओं से बचने में मदद करना, recovery की गति बढ़ाना, और जब वे प्रभावित हों तब उन्हें बेहतर ढंग से सूचित करना — इन सबमें हम और बेहतर कर सकते हैं।
      communication में हमसे गलती हो जाए, तब भी हम ऐसा feedback सुन रहे हैं।

  • बड़ा खतरे का संकेत यह लगता है कि Fly के पास खराब सर्वर से स्वस्थ सर्वर पर वर्कलोड को जल्दी ले जाने का कोई automated तरीका नहीं दिखता
    जबकि containers और orchestrators ने attach/detach होने वाले data volumes की concept को abstract कर दिया है
    बेशक, इसे उपलब्ध कराने के लिए बड़े तकनीकी निवेश की ज़रूरत होती है, और मेरा मानना है कि यही उन वजहों में से एक है जिनसे big 3 cloud providers में storage महंगा है। फिर भी, अगर आप data persistence service दे रहे हैं, तो यह क्षमता अनिवार्य है
    Fly जो देना चाहता है और बाज़ार उससे जो उम्मीद करता है, उनके बीच mismatch है
    Fly कई data centers में apps चलाने की innovation देना चाहता था, लेकिन सही data persistence service के बिना यह सुविधा ज़्यादातर लोगों के लिए उपयोगी नहीं है
    लगता है कि वह SQLite replication से persistence की समस्या सुलझाना चाहता है, लेकिन तब ज़्यादातर developers को Fly platform के हिसाब से app development का तरीका बदलना पड़ेगा
    Fly को यह चुनना होगा कि वह स्थिर और सस्ता Heroku alternative बनेगा, या दुनिया भर के users को सबसे अच्छा performance देने वाला अपना अलग app development model पेश करेगा
    App Engine एक दिलचस्प उदाहरण है। वह अपने समय से आगे था और बहुत ऊँचे traffic तक scale होने वाला development model बताता था, लेकिन लोग उसके हिसाब से अपना development तरीका बदलना नहीं चाहते थे

    • क्या उसने पहले ही एक बार दिशा नहीं बदली थी? मौजूदा आकार और 100 million dollar से अधिक funding को देखते हुए, मुझे नहीं लगता कि वह फिर ऐसा आसानी से कर पाएगा
      अभी तो ऐसा लगता है कि एक आग बुझाते ही दूसरी लग जाती है, इसलिए उसके technical roadmap पर भरोसा नहीं होता
      क्या कई लोग Fly.io को पहले से ही लगभग 2 साल से “बाद में फिर देखेंगे” वाली सूची में नहीं डाल चुके हैं?
      जब लोग किसी चीज़ को unstable मानने लगते हैं, तो reputation वापस पाना बहुत मुश्किल होता है, खासकर IT में
    • Fly के पास remote-attached storage नहीं है, सब कुछ node-local LVM-based volumes पर है
      data persistence, 24-hour या manually created LVM snapshots को S3 में export करने के तरीके पर निर्भर है
      मेरे हिसाब से यह persistent workloads चलाने की जगह बिल्कुल नहीं है। अगर आप वहाँ PostgreSQL चला रहे हैं, तो आपको data को नए instance में hot-load करने या backup से restore करने की तैयारी रखनी चाहिए

  • इसी वजह से मैं पहले भी HN पर Fly का इस्तेमाल न करने की सलाह देता रहा हूँ: https://news.ycombinator.com/item?id=31394179
    account delete करने का अनुरोध करने के बाद, बिना किसी communication के मेरा account एक तरह के shadow ban की स्थिति में चला गया
    मैंने email भी भेजा था, लेकिन आज तक कोई जवाब नहीं मिला, और उसके बाद मैं सब कुछ Railway apps और Google Cloud Run पर ले गया

    • क्या आपका मतलब है कि account delete करने के बाद आपने उसी deleted email address से फिर से sign up करने की कोशिश की?
      सिर्फ harmless सवाल पूछने पर कोई company shadow ban क्यों करेगी?

  • दिलचस्प बात यह है कि Fly.io में इतिहास अपने-आप को दोहराता हुआ लगता है। पहली बार Heroku से मिलने जैसा एहसास होता है
    शुरुआती Fly.io वैसा ही ताज़ा और रोमांचक लगा था जैसा Heroku पहली बार आने पर लगा था, और उसकी simplicity तथा ease of use ने प्रभावित किया था
    लेकिन समय के साथ छोटी-छोटी समस्या के संकेत दिखने लगे, downtime बढ़ने लगा, और जो deploys पहले तेज़ और smooth थे वे परेशान करने वाली तरह से धीमे हो गए
    यह वैसा déjà vu लगता है जैसा Heroku की खूबियाँ फीकी पड़ने लगने पर लगा था
    जितने ज़्यादा लोग platform पर आते हैं, performance उतना गिरता है, और जितनी ज़्यादा लोकप्रियता मिलती है, उतना कम reliable दिखने का जो रास्ता है, Fly.io भी शायद उसी पर चल रहा है, यह अफ़सोस की बात है
    यह एक चेतावनी भरी कहानी जैसा लगता है कि promising platforms भी कैसे गिर सकते हैं, और उम्मीद है कि Fly.io इस चक्र से निकलकर Heroku के सबसे निचले दौर जैसा बेकार बनने से पहले खुद को संभाल लेगा

    • उस समय Fly काफी resources मुफ्त में दे रहा था, और documentation में भी उसे लगभग एक feature की तरह subtly recommend किया जाता था, यह देखकर मैं थोड़ा असहज था
      लगा कि शायद मैंने industry की ethical sense को ज़्यादा आँक लिया था, और अगर यह Heroku की तरह व्यापक रूप से जाना जाने लगे, तो पैसे न देने वाले लोग टूट पड़ेंगे, यह तो तय था
      इतना उदार free offering फिर से आज़माने के लिए या तो एक मज़बूत और महँगी abuse-prevention team चाहिए, या फिर इतने गहरे pockets कि शुरुआती अनुपस्थिति को झेलने लायक hardware पर बेहिसाब खर्च किया जा सके
      Fly इनमें से किसी भी मोर्चे पर मज़बूत नहीं दिखता। इसी वजह से उसका एक पहलू मुझे पसंद भी है। ऐसी चीज़ें अक्सर बड़ी कंपनियों वाले दिखावटी काम जैसी लगती हैं, और Fly में वह गंध कम है
      लेकिन अगर Fly engineers अपना ज़्यादातर समय long-term infrastructure reliability या developer experience के बजाय, free-riding crypto miners, scammers और abusers से निपटने, resource allocation तथा automatic throttling को optimize करने में लगा रहे हों, तो मुझे हैरानी नहीं होगी
    • मुझे भी ऐसा ही लगता है
      सोचता हूँ कि क्या इसका संबंध scale से है। जब तक company इतने paying customers हासिल करती है कि profitability या investability दिखने लगे, क्या तब तक साथ ही इतनी समस्याएँ भी जमा हो जाती हैं कि वह अपने शुरुआती ताज़ा और रोमांचक रूप से बदलकर उसी पुराने competitor जैसी बन जाती है जिसे वह replace करना चाहती थी?
      मेरा अनुभव भी कुछ ऐसा ही रहा है। जब कोई company “कुछ pizzas मँगाने” के स्तर से बढ़कर “venue book कर लिया” वाले स्तर तक पहुँचती है, तो entropy घुसने लगती है, और Conway's Law या Brooks's Law जैसी कहावतें और साफ़ दिखने लगती हैं