11 हफ़्तों के Kubernetes माइग्रेशन के बाद कंपनी अपना अस्तित्व-कारण भूल गई (2020)

 (theolognion.com)
1 पॉइंट द्वारा GN⁺ 2024-03-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सिलिकॉन वैली startup Xenobroom Inc. ने 2020 के मई में महामारी के दौरान दैनिक उपयोग में तेज़ उछाल आने पर मौजूदा server infrastructure को Kubernetes पर माइग्रेट करने का फैसला किया
  • यह माइग्रेशन सिर्फ deployment सुधार तक सीमित न रहकर bash स्क्रिप्ट और VPS-आधारित configuration की फिर से समीक्षा और redesign वाले लंबे काम में बदल गया
  • dependency और library upgrade, PostgreSQL के कुछ हिस्सों को distributed KV storage में बदलना, और AWS की flexibility का लाभ उठाना—इन सबको साथ आगे बढ़ाया गया, जिससे scope लगातार बढ़ता गया
  • मौजूदा staging server और develop branch-आधारित daily deployment की जगह production-only CI workflow, dynamic routing, A/B testing, और regional dependency support वाला सेटअप ले आया
  • जब लगा कि माइग्रेशन पूरा हो गया है, तब तक टीम का कोई भी सदस्य प्रोडक्ट का उद्देश्य याद नहीं रख पाया था, और users व investors ने भी माना कि वे मूल प्रोडक्ट को समझते ही नहीं थे, इसलिए उसे बहाल करना लगभग असंभव हो गया

Kubernetes माइग्रेशन से बढ़ता गया काम का दायरा

  • Xenobroom Inc. ने 2020 के मई में server infrastructure upgrade शुरू किया
    • CEO की डायरी के अंशों और CTO के engineering notes के मुताबिक, महामारी के दौरान दैनिक उपयोग अचानक बहुत बढ़ गया था
    • इसके बाद मौजूदा infrastructure को Kubernetes पर माइग्रेट करने का निर्णय लिया गया
  • काम अपेक्षा से ज़्यादा लंबा खिंच गया
    • साधारण bash स्क्रिप्ट और VPS machines को फिर से बनाना, परखना और re-engineer करना पड़ा
    • कंपनी के भीतर इसे software dependency और library upgrade का मौका भी माना गया
  • infrastructure बदलाव ने बड़े architectural overhaul का रूप ले लिया
    • यह आकलन किया गया कि एक single machine पर चल रहे PostgreSQL database के बड़े हिस्से को distributed KV storage में बदला जा सकता है
    • इसके साथ AWS की flexibility का उपयोग करने का तर्क भी जुड़ गया
    • develop branch से रोज़ deploy होने वाला साधारण staging server हटा दिया गया
    • उसकी जगह dynamic routing के साथ production-only CI workflow लाया गया, जो A/B testing और regional dependency को सहज रूप से support करता था

प्रोडक्ट का उद्देश्य खोना और बाहरी मदद

  • जब माइग्रेशन प्रक्रिया पूरी होती हुई दिखी, तब कंपनी के भीतर किसी को भी प्रोडक्ट का उद्देश्य याद नहीं था
  • users और investors भी स्थिति को सुलझा नहीं पाए
    • दोनों समूहों ने सार्वजनिक रूप से स्वीकार किया कि उन्होंने शुरू से ही प्रोडक्ट को वास्तव में कभी समझा ही नहीं था
    • कई हफ़्तों के downtime के बाद प्रोडक्ट के अर्थ को बहाल करना लगभग असंभव हो गया
  • CEO ने Phutar Afrayughum नाम के एक आध्यात्मिक माध्यम और extrasensory perception विशेषज्ञ से मदद मांगी
    • उनका परिचय ऐसे व्यक्ति के रूप में दिया गया जिसने Google के messaging app market share को बढ़ाने में मदद की थी और Material Design framework के विकास में भी शामिल रहा था
    • हालांकि इस मदद को “allegedly” कहा गया है, इसलिए इसे तथ्य के रूप में निश्चित नहीं माना गया है

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

1 टिप्पणियां

 
GN⁺ 2024-03-02
Hacker News की राय

  • यह लेख और भी मज़ेदार है: 20% middle managers को निकालने के बाद dev productivity संयोग से 3 गुना बढ़ गई
    https://www.theolognion.com/p/company-accidentally-increased...

    • इसे satire कहना भी मुश्किल है

  • हमारे $dayjob में भी ऐसा migration चल रहा है; 2 साल पहले शुरू हुआ था, लेकिन अभी 30% भी पूरा नहीं हुआ
    पहले जो लोग सबसे ज़ोर से कहते थे “Kubernetes पर जाना चाहिए, monolith को खत्म करना चाहिए”, वे अब LLM से खेलते-खेलते Kubernetes को भूल चुके हैं
    कुछ लोगों को proof of concept और चमकदार नई चीज़ें सचमुच बहुत पसंद होती हैं, और लगता है उस भूमिका की अपनी उपयोगिता भी है

    • नई और चमकदार technology से job satisfaction पाने वाला ढांचा है
      इसलिए smart लोग unethical बड़ी tech companies, ad companies और surveillance companies में भी काफ़ी संतुष्ट होकर काम करते दिखते हैं
      कंपनी क्यों मौजूद है, या उनके computer के बाहर वह असल में क्या करती है, यह इतना मायने नहीं रखता; technology और नई चीज़ों का पीछा करने की आज़ादी मायने रखती है
      कंपनी उन्हें पैदा होने वाली productivity और उत्साह पसंद करती है, और अच्छा compensation भी देती है
      आम तौर पर ऐसे developers के पास भी conscience होता है, लेकिन वह conscience अक्सर corporate-friendly अच्छे social movement के रूप में absorb होकर प्रदर्शित किया जाता है
    • यह scope creep से ज़्यादा जानबूझकर किया गया resume-driven development लगता है
      कोई “मैंने X किया है” कहने के लिए checkboxes एक-एक करके tick कर रहा है
      छोटी team में यह तरीका productivity को सचमुच बहुत जल्दी रोक सकता है, और अक्सर इसे हर समस्या हल करने की इच्छा के रूप में पेश किया जाता है
      लेकिन नतीजा यह होता है कि कोई समस्या हल नहीं होती, बल्कि और भी नई समस्याएँ पैदा हो जाती हैं
    • FAANG-adjacent कंपनियों में promotion बहुत मुश्किल होता है, और level system की वजह से salary बढ़ाने का तरीका भी अक्सर सिर्फ promotion ही होता है
      promotion के लिए promotion packet चाहिए, और promotion packet के लिए बड़ा और भारी-भरकम project चाहिए
      अंत में जिस core problem को हल किया जा रहा होता है वह business need नहीं बल्कि promotion बन जाती है, और problems की तलाश में निकले विशाल projects पैदा होते हैं
    • कंपनी का पैसा जलाने में शायद काम आ सकता है
      आपने जो बताया वह proof of concept भी नहीं लगता। proof of concept की बुनियादी शर्त है कि वह कम से कम काम करे, लेकिन यह तो भीड़ के पीछे चलते हुए busy दिखने के लिए configuration बनाने जैसा है
      employee के नज़रिए से भी यह लंबे समय तक टिकने के लिए अच्छा environment नहीं लगता
    • लगता है ऐसे लोग ही उल्टा सबसे ज़्यादा promote होते होंगे। सचमुच टेढ़ा system है

  • उस blog में और भी मज़ेदार लेख बहुत हैं। खासकर यह मुझे पसंद आया:
    https://www.theolognion.com/p/dev-builds-perfect-note-taking...
    और यह भी है:
    https://www.theolognion.com/p/ai-solves-all-political-econom...

  • पता है कि यह मज़ाक है, लेकिन अगर postmortem किया जाए तो failure की वजह शायद यह होगी कि “कंपनी के कई लोगों ने सोचा कि इस मौके पर software dependencies और library upgrades भी साथ में कर लेते हैं। single machine पर चल रहे PostgreSQL database के बड़े हिस्से को भी AWS की जबरदस्त flexibility का इस्तेमाल करके distributed key-value store में बदला जा सकता है”
    scope बचाकर रखना चाहिए

    • यही इस joke के core के काफी करीब है
      दुनिया में बहुत लोग अपने बनाए product से ज़्यादा इस्तेमाल की जा रही technology पर ध्यान देते हैं
      product पर focus करने का मतलब है scope समझना, और बहुत जल्दी over-engineering न करना
      joke Kubernetes पर focus करता है, लेकिन यही बात server-side rendering, AI, $modernFrontendLib, $modernLanguage से भी बनाई जा सकती है
    • कंपनी का scope भी बचाकर रखना चाहिए
      अगर business cloud infrastructure बेचने का नहीं है, तो ready-made cloud provider इस्तेमाल कर लेना चाहिए
      अगर आप पहले से cloud provider को पैसे दे रहे हैं, तो खासकर Kubernetes न इस्तेमाल करना बेहतर है

  • असल दुनिया में 11 हफ्तों का Kubernetes migration तो बड़ी सफलता माना जाता

    • वास्तव में 11 महीने लगते, और अब “cloud native” जैसी हालत हो गई होती
      हाँ, database चलाना थोड़ा मुश्किल रहा होगा। क्योंकि Kubernetes storage settings ठीक से करना भूल गए होंगे, इसलिए pod अचानक move होने के बाद data गायब हो गया होगा
    • अगर पहले से Docker इस्तेमाल कर रहे हैं, तो इतना लंबा लगने की लगभग कोई वजह नहीं है
      अगर Docker भी इस्तेमाल नहीं कर रहे थे, तो ऐसे migration में समस्या Kubernetes खुद न होने की संभावना ज़्यादा है

  • systems चलाना आज जितना आसान और सस्ता है, पहले कभी नहीं था
    फिर भी engineers एक pizza deliver करने के लिए expedition team बनाना, Everest चढ़ना, summit पर pizza की photo लेना, फिर उसे plane से वापस घर लाना, Lamborghini किराए पर लेकर Mongol Rally दौड़ना, और 18 महीने बाद जाकर वह pizza deliver करना पसंद करते हैं
    जबकि इस बीच बस एक सस्ता scooter लेकर सड़क के नीचे चले जाएँ तो जीत जाते हैं

    • मैंने ऐसी जगह काम नहीं किया जहाँ engineers द्वारा डाली गई complexity, management द्वारा डाली गई complexity के बराबर रही हो

  • अगर technology complex है तो पहले उसे सीखना चाहिए। पहले किसी छोटी और गैर-महत्वपूर्ण service पर आज़माना चाहिए
    एक बार में एक ही चीज़ करें, और simple शुरुआत करें
    मैंने अपनी services को बिना problem Kubernetes पर migrate किया, लेकिन छोटी services को move करते हुए सीखने और experiment करने में 2 साल लगे
    कई approaches आज़माने के बाद हम सबसे उपयुक्त तरीके तक पहुँचे, जो internet पर तुरंत मिलने वाला तरीका नहीं था
    GitOps इस्तेमाल करते हैं, लेकिन automation नहीं करते; जिस चीज़ की ज़रूरत हो, उस पर बस kubectl apply -k चलाते हैं। क्योंकि उस समय हमने माना था कि शुरुआत करने के लिए flux अनावश्यक रूप से complex है
    अब services दर्जनों में हैं और समझ भी बन गई है, इसलिए flux अपनाने के बारे में सोच रहे हैं

  • 1977 में मैं घंटे के हिसाब से बिल करने वाली एक law firm में युवा trial lawyer के तौर पर काम करता था
    हर केस के लिए मैंने कौन-सा काम किया, यह कागज़ पर दर्ज करता था, और office staff पूरे हो चुके कागज़ से अलग की जा सकने वाली पट्टियाँ काटकर हर केस के paper folder के अंदरूनी board पर चिपका देते थे
    1979 में मैंने RadioShack Tandy I खरीदा, और जल्द ही घर पर DOS-based database program Foxbase में गहराई से डूब गया। बाद में यह FoxPro बना और 1990 के शुरुआती दशक में Microsoft ने इसे खरीद लिया
    1981 में मैंने अपनी law firm शुरू की, और उस समय office productivity में सबसे नया innovation fax और एक-line screen, memory, तथा forms store करने के लिए छोटी disk वाली electric typewriter थी। कंपनियाँ अभी personal computer इस्तेमाल नहीं करती थीं
    मेरी law firm जल्द ही करीब 10 वकीलों और 12 support staff तक बढ़ गई, और मैंने सभी secretaries के लिए Compaq computers खरीदे
    हाथ से पट्टियाँ चिपकाने की प्रक्रिया को बदलने के लिए time और billing program लिखने में मैंने बहुत समय लगाया, और network install करना भी सीखा और खुद install किया
    जिन दूसरी law firms को मैं जानता था, उनमें एक भी computer नहीं था, लेकिन हमारे पास support staff के लिए 10 से ज्यादा और clients को भेजने से पहले bills review करने के लिए वकीलों के लिए 4–5 “portable” Compaq थे
    उसी दौरान मैं अपने business को बर्बाद कर रहा था। जब दूसरों के पास एक भी computer नहीं था, तब हमारे पास world-class technology थी, लेकिन legal work या corporate clients की sales पर ध्यान देने के बजाय मैं दरवाज़ा बंद करके सिर्फ programming करता रहा
    आखिरकार 1994 में मैंने law firm बंद कर दी
    फिर भी वह रोमांचक समय था। जल्द ही सभी law firms के पास word processing के लिए computers आ गए, लेकिन commercial billing programs अभी नहीं थे
    करीब 24 महीनों तक जिन दूसरी law firms के वकीलों के साथ मैंने काम किया, वे सभी मेरा billing program चाहते थे
    लेकिन case work में डूबे होने के बावजूद मैं मज़ेदार programming में ही लगा रहा, और मेरा legal practice उस program के लिए एक perfect laboratory था। अफसोस, उसी programming ने मेरा business बर्बाद कर दिया

    • वह अलग की जाने वाली पट्टी वाला तरीका सचमुच दिलचस्प है। सोच रहा हूँ कि क्या उस समय time tracking के लिए यह common तरीका था
      अगर कोई photo बची हो तो देखना चाहूँगा

  • मेरे field में “Kubernetes” को GraphQL/React/Next से बदल दें, तो बात बिल्कुल वैसी ही बैठती है
    और यह एक perfectly working app को migrate करने की बात है, वह भी ऐसा app जो ज्यादातर CRUD है
    जबकि GraphQL या interactive frontend से मिलने वाले trade-offs की बिल्कुल जरूरत नहीं है, फिर भी ऐसा किया जाता है
    इस industry में जितना ज्यादा समय बिताता हूँ, उतना ही ज्यादा देखता हूँ कि जिम्मेदार पदों पर बैठे लोगों को अक्सर पता ही नहीं होता कि वे क्या कर रहे हैं

    • चीज़ों को लगातार ठीक से चलाए रखने के लिए लोगों को reward नहीं मिलता
      उन्हें बदलाव के लिए reward मिलता है, बस वह बदलाव results दे रहा हो या कम-से-कम ऐसा दिखाया जा सके कि कभी न कभी देगा

  • self-hosted MinIO से managed blob storage में 5 लाख blobs move करने के लिए 4 महीनों से दिन-रात जूझ रहा हूँ, लेकिन politics और bureaucracy हटाकर वास्तविक productive काम 1 हफ्ते से भी कम है
    इसलिए 11 हफ्ते का Kubernetes migration तो बड़ी success जैसा लगता है