- AWS से अपने सर्वर पर माइग्रेट करके मासिक infrastructure लागत को 10वें हिस्से तक घटाने वाले एक डेवलपर का अनुभव, जिसमें मासिक खर्च 1,400 डॉलर से घटकर 120 डॉलर रह गया और ज़्यादा ताकतवर server performance भी मिली
- Hetzner जैसे प्रदाताओं के bare-metal server 80 core के लिए लगभग 190 डॉलर प्रति माह पर मिलते हैं, जो AWS के समान स्पेक वाले instance की तुलना में 7 से 18 गुना सस्ते हैं
- cloud engineers के अपने सर्वर चलाने का विरोध करने के पीछे job security और complex infrastructure पर निर्भरता जैसे कारण हैं, जबकि असली लागत का बोझ नियोक्ता उठाता है
- ज़्यादातर छोटे business को high availability, multi-zone replication, automatic failover जैसी enterprise-grade सुविधाओं की ज़रूरत नहीं होती, और एक single server भी रोज़ाना लाखों requests संभाल सकता है
- शुरुआती setup के बाद server management स्थिर रहता है, और AI tools की मदद से Linux server चलाने की entry barrier अब तक के सबसे निचले स्तर पर है
cloud लागत बचत का मामला
- हाल ही में सभी projects को cloud से माइग्रेट करके मासिक AWS लागत में 10 गुना कटौती और हज़ारों डॉलर की बचत हासिल की
- मासिक AWS बिल लगभग 1,400 डॉलर से घटकर 120 डॉलर से कम हो गया
- कम लागत में ज़्यादा ताकतवर server infrastructure मिला
- performance 2 गुना बेहतर हुई और vendor lock-in से आज़ादी मिली
- यह ट्वीट वायरल होने पर दो बातें सामने आईं: बहुत से developers ने तरीका जानने में रुचि दिखाई, और कई लोगों ने इस विचार पर तीव्र नाराज़गी और टकरावपूर्ण रवैया दिखाया
- business के नज़रिये से 10 गुना लागत बचत, 2 गुना performance सुधार, और vendor lock-in से मुक्ति जैसे स्पष्ट फायदे हासिल हुए, फिर भी कड़ा विरोध झेलना पड़ा
cloud समर्थकों के हित
- विरोध करने वालों में ज़्यादातर के प्रोफ़ाइल में "devops", "cloud engineer", "serverless guy", "AWS certified" जैसे keywords थे
- ये लोग अपने प्रोजेक्ट खुद cloud पर नहीं चलाते और cloud की लागत भी अपनी जेब से नहीं भरते
- इन्हें employer के AWS bill से फर्क नहीं पड़ता, इसलिए हर महीने हज़ारों डॉलर की बर्बादी का दर्द महसूस नहीं होता
- AWS इनके लिए सुविधाजनक क्यों है
- यह तकनीकी रूप से जटिल दिखता है, जिससे दूसरे developers के सामने ये ज़्यादा स्मार्ट लगते हैं
- dependency और lock-in पैदा करता है, जिससे employee के रूप में ये आसानी से replace नहीं होते
- cloud इस्तेमाल करने से ऊँची salary सुनिश्चित होती है, इसलिए business के लिए efficient निर्णय लेने की प्रोत्साहना नहीं होती
- उल्टा, business infrastructure जितना जटिल और पेचीदा होगा, इनकी नौकरी उतनी सुरक्षित होगी
- ये इस सच को नहीं बताएँगे कि server असल में सस्ते होते हैं
सस्ते server rental विकल्प
- Hetzner पर माइग्रेट करना (कोई affiliation नहीं, बस सस्ते server देता है)
- 80-core bare-metal server 190 डॉलर प्रति माह से कम में किराए पर मिल सकता है
- AWS के C5-C6 series के समान स्पेक वाले instance की कीमत 2,500 से 3,500 डॉलर प्रति माह है, यानी 13 से 18 गुना महंगा
- reserved instance लेने पर भी लगभग 1,300 डॉलर प्रति माह पड़ता है, यानी अब भी 7 गुना महंगा, और 46,000 डॉलर upfront के साथ 3 साल का contract चाहिए
- VPS विकल्प भी आकर्षक हैं
- 48 vCPU machine 300 डॉलर प्रति माह में, बिना setup fee या long-term contract के, यानी पूरी flexibility
- 8-core, 32GB RAM machine 50 डॉलर प्रति माह में, और अगर रोज़ लाखों requests नहीं हैं तो सारे projects एक साथ चलाए जा सकते हैं
server खरीदना और datacenter का उपयोग
- लंबे समय में server खरीदना और भी सस्ता पड़ता है
- 44 CPU, 256GB RAM, 2TB NVMe SSD वाला rack-mount server 1,000 डॉलर से कम में खरीदा जा सकता है
- monthly cloud लागत से भी कम में apps को कई साल तक चलाया जा सकता है
- datacenter rack space किराए पर लेने का विकल्प
- बिजली, internet, cooling और security देने वाला datacenter cage या shared rack space किराए पर लिया जा सकता है
- DatacenterMap जैसी वेबसाइट से अपने क्षेत्र के datacenter खोजे जा सकते हैं
- छोटे developers के लिए यह बहुत जटिल है
- engineer hire करना, price negotiate करना जैसी झंझटें हैं
- यह मुख्यतः medium और large कंपनियों के लिए है, छोटे teams के लिए व्यावहारिक नहीं
- Hetzner जैसे प्रदाताओं से पहले से mounted server किराए पर लेना व्यावहारिक रूप से वही बात है, बस hardware management का बोझ कम हो जाता है
"क्या यह अब भी cloud नहीं है?" वाली आलोचना का जवाब
- सबसे आम आलोचना: "क्या यह भी cloud नहीं है?", "तुम cloud से बाहर नहीं निकले, बस cloud provider बदल लिया"
- यह आलोचना मुख्य बात को मिस करती है
- असली सवाल अपने server manage करना बनाम cloud को default मान लेना है
- अगर एक छोटा Linux machine चलाकर RDS जैसी महंगी managed services को बदला जाए, तो 10 से 100 गुना कम लागत आती है
- ज़्यादातर developers server से डरते हैं, जबकि उन्हें बस थोड़ी हिम्मत चाहिए कि वे सस्ते में अपना server setup कर सकते हैं
- वास्तविक दुनिया में लगभग किसी को भी cloud की महंगी managed services की ज़रूरत नहीं होती; कुछ Linux boxes पर सामान्य software से काम चल जाता है
- नामकरण की बहस असल मुद्दे को धुंधला करती है
- VPS, bare-metal, on-premise या colo हो, नाम मायने नहीं रखता
- server कहीं न कहीं तो रखना ही होगा; असली बात यह है कि पैसा आपकी जेब में ज़्यादा बचा या Amazon shareholders के पास चला गया
- इस तरह की बात करने वाले लोग मूलतः gatekeeper की भूमिका निभाते हैं
- "तुम सही तरीके से नहीं कर रहे, switch भी खुद खरीदो, rack भी खुद बनाओ, ethernet cable भी खुद लगाओ"
- यह ज़हरीली और आलसी दलील है, जो सतही बातों में उलझकर मुख्य मुद्दे से बचती है
cloud लागत मूल रूप से महंगी है
- cloud समर्थकों की gaslighting
- "तुम cloud गलत इस्तेमाल कर रहे हो", "महंगा इसलिए है क्योंकि तुम गलत कर रहे हो", "तुम्हें cloud इस्तेमाल करना आना चाहिए"
- इनमें से ज़्यादातर ने कभी विकल्प आज़माए ही नहीं, और अपने projects के लिए server manage करने का वास्तविक अनुभव नहीं है
- लेखक AWS से परिचित है और AWS certification की पढ़ाई भी की है
- यह भी जाँचा कि infrastructure over-provisioned तो नहीं
- यह भी देखा कि unused services के पैसे तो नहीं दिए जा रहे
- AWS cost optimization पर अनगिनत घंटे लगाए, और 5,000 डॉलर प्रति माह से ज़्यादा वाले AWS bill को आधे से भी कम करने में सफलता मिली
- serverless computing, reserved instances आदि सबकी जानकारी है
- reserved instances समस्या को और बढ़ाते हैं: वे vendor lock-in बढ़ाते हैं और 3 साल के contract में बाँध देते हैं
- जब आप cloud छोड़ने पर विचार कर रहे हों, तब 3 साल का contract सबसे खराब विकल्प है
- हर कोशिश के बाद निष्कर्ष यही: cloud बस बहुत महंगा है
विरोध की वजह
- इतने लोग लागत बचत की बात पर इतना ध्यान क्यों दे रहे हैं?
- दो मुख्य निष्कर्ष
- रोज़ी-रोटी दाँव पर है: अगर लेखक जैसे लोग पर्याप्त लोगों को मना लें, तो कुछ लोगों की नौकरियाँ जा सकती हैं
- डर से पैदा हुई अतार्किक बहस: पिछले 10 साल में cloud बनाना trend रहा, जिससे लाखों "devops" और "cloud engineers" भूमिकाएँ बनीं; अगर अब cloud छोड़ना trend बन गया तो कई cloud professionals का career खत्म हो सकता है
- बहुत से developers मन ही मन जानते हैं कि cloud उतना अच्छा नहीं जितना शुरुआत में वादा किया गया था
- वे देखते हैं कि employer का AWS खर्च उचित स्तर से 10 गुना ज़्यादा है, फिर भी "कोई बात नहीं" कहकर निकल जाते हैं
- वे manager को नाराज़ करने या ज़िम्मेदारी लेने का जोखिम नहीं लेना चाहते
- team में सबसे ज़ोर से बोलने वाले व्यक्ति से असहमति की political cost से डरते हैं
- AWS के पास मज़बूत cult-like following है
- certifications के ज़रिए लोगों को वास्तविक sales pages और product descriptions रटाए जाते हैं
- practical thinking की जगह evangelists हैं जो dogma फैलाते हैं
- बाहरी दुनिया का डर दिखाया जाता है (server ख़तरनाक हैं! scale नहीं होंगे!)
- "cloud engineer" को identity बना दिया जाता है; entry आसान, exit मुश्किल
- चूँकि जीविका दाँव पर है, AWS समर्थक अपने doctrine में फँसकर अतार्किक बहस दोहराते रहते हैं
- वे AWS sales landing page की दलीलें एक-एक करके दोहराते हैं, बिना यह सोचे कि उनकी सचमुच ज़रूरत है या नहीं
- यह एक belief system की बहस है, इसलिए लोग irrational हो जाते हैं
cloud का इतिहास
- पहले हर कोई अपने server चलाता था
- VPS, hosting services, datacenter के bare-metal, company के किसी अँधेरे कमरे में, या घर से
- हर कोई machine में SSH करना जानता था और उसमें सहज था
- 2010 के शुरुआती दशक में cloud marketing psyops campaign शुरू हुआ
- मकसद था enterprise tech को शुरुआती-stage startup को बेचना
- रणनीति थी कि जितना जल्दी हो सके उन्हें lock-in कर लिया जाए, ताकि funding मिलने पर उनसे कमाई की जा सके
- AWS की रणनीति
- startups के लिए credits देना शुरू किया
- startup accelerators के चक्कर लगाकर हर startup को onboard करने की कोशिश की
- चाल बहुत सरल थी: startup को infrastructure बनाते समय बहुत सस्ता (या free) दो, और जैसे ही वह बढ़े, सब कुछ बहुत महंगा कर दो, ताकि lock-in के कारण निकलना मुश्किल हो जाए
- IBM cloud ने भी ऐसी ही रणनीति अपनाई (2014 का एक event)
- उस समय सब कुछ Heroku पर चल रहा था और ठीक काम कर रहा था
- सवाल था: "यह सारा cloud क्या है और इसे कैसे इस्तेमाल किया जाता है?"
- ऐसा लगता था मानो कोई ऐसी चीज़ बेची जा रही हो जो उनके लिए बनी ही नहीं
- इन कंपनियों ने पिछले कई वर्षों में cloud प्रचार अभियानों पर लाखों डॉलर खर्च किए ताकि शुरुआती startups enterprise tech अपनाएँ
- पिछले 10 साल की zero interest rate स्थिति ने भी आज की हालत बनाने में योगदान दिया
- अब एक countercultural movement मौजूद है
- इसे मुख्यतः @dhh और Rails community आगे बढ़ा रही है
- यह धरती के ज़्यादातर software business की वास्तविकता के साथ मूल रूप से ताज़ा, सही और मेल खाता है
ज़्यादातर business को cloud की ज़रूरत नहीं
- कुछ लोगों की समझ इस बात से पूरी तरह कटी हुई है कि असली software business कैसा दिखता है
- वे Fortune 500 के नज़रिये से सोचते हैं और मानते हैं कि enterprise ही standard है
- उन्हें लगता है कि average business को high availability, multi-zone replication, automatic failover, distributed Kubernetes clusters जैसी cloud सुविधाओं की ज़रूरत है
- हक़ीक़त में बहुत कम software business को इसकी ज़रूरत होती है
- power law के मुताबिक ज़्यादातर business हमेशा छोटे ही रहेंगे
- अमेरिका में small business कुल business का 99.9% हैं
- यूरोपीय संघ में SME (250 से कम employees) कुल business का 99% हैं
- ज़्यादातर developers scaling requirements को बढ़ा-चढ़ाकर आँकते हैं
- "high traffic" की उनकी threshold बहुत कम होती है
- एक संदर्भ बिंदु: अभी 2-server setup के साथ रोज़ लाखों requests और लाखों monthly visitors संभाले जा रहे हैं
- @levelsio जैसे indie makers सब कुछ एक single server पर चलाते हैं
- ज़्यादातर developers ने कभी अपने किसी वास्तविक project को, जिसमें असली users और production traffic हो, single server पर चलाया ही नहीं
- technical requirements भी बढ़ा-चढ़ाकर आँकी जाती हैं
- बहुत कम software business को ऐसी सुविधाओं की ज़रूरत होती है, और आमतौर पर उनके पास इसके अच्छे तकनीकी कारण होते हैं
- Netflix को दुनिया भर के ग्राहकों तक भारी मात्रा में video transcode और stream करना पड़ता है, इसलिए उसे distributed systems, CDN और edge computing चाहिए
- लेकिन अगर 1,000 users वाला एक छोटा app सिर्फ JSON objects भेज रहा है, तो उसे इसकी बिल्कुल ज़रूरत नहीं
- कई developers अपने project को Netflix जैसा समझने की जादुई सोच रखते हैं
- यह wishful thinking है, समझ में आती है, लेकिन गलत तकनीकी फैसलों तक ले जाती है
- वे मानते हैं कि button tap करते समय कुछ milliseconds की देरी user पकड़ लेगा, इसलिए दुनिया भर में distributed servers चाहिए
server ठीक रहेंगे
- बहुत से लोग datacenter के काम करने के तरीके को लेकर जादुई धारणाएँ रखते हैं
- उन्हें लगता है कि datacenter के server नाज़ुक हैं, अस्थिर हैं और हवा में गायब हो सकते हैं
- कुछ लोग तो यह भी मानते हैं कि बिजली गिरने से पूरा datacenter खत्म हो सकता है
- आधुनिक datacenter पहले से इन सभी समस्याओं को ध्यान में रखकर चलते हैं और उनमें कई सुरक्षा उपाय होते हैं
- सिर्फ बिजली गिरने जैसी सामान्य बातों के लिए नहीं, बल्कि uptime को ख़तरे में डाल सकने वाली लगभग हर चीज़ के लिए
- redundant power, redundant cooling, redundant internet links, redundant fire suppression systems, redundant security systems और व्यापक physical security
- datacenter की हर चीज़ resilience और redundancy (कम से कम N+1, कभी-कभी 2N) को ध्यान में रखकर डिज़ाइन की जाती है ताकि uptime सुनिश्चित रहे
- यह ज़्यादातर डर-आधारित राय है, जो सफल cloud marketing और psyops campaign का परिणाम है
- AWS अपनी machines कहाँ रखता है? किसी इंद्रधनुष के नीचे जादुई जगह में?
- सिर्फ AWS की machines ही उन समस्याओं से जादुई रूप से सुरक्षित कैसे हो सकती हैं जो दूसरे datacenter में भी होती हैं?
- disaster हो सकता है (OVH 2021 fire), इसलिए recovery के लिए backups ज़रूरी हैं
- लेकिन लगभग 15 साल server चलाने के अनुभव में यह दुर्लभ है, और कुछ मिनट से ज़्यादा downtime कभी नहीं देखा
server management full-time काम नहीं है
- जिसने server लंबे समय तक manage किए हैं, वह जानता है कि ज़्यादातर समय शुरुआती setup में जाता है, उसके बाद server काफ़ी स्थिर रहते हैं
- hardware failures अपेक्षाकृत दुर्लभ होते हैं, और server once up होने के बाद आमतौर पर कई साल तक बिना बड़े हस्तक्षेप के ठीक चलते हैं
- अपने server चलाना full-time काम नहीं है
- 5 लोगों की devops team रखने की ज़रूरत नहीं
- अलग server admin hire करने की भी ज़रूरत नहीं: आप खुद कर सकते हैं, और यह इतना कठिन नहीं है
- Claude और ChatGPT को Linux systems और उनके management की अच्छी समझ है, उनसे मदद ली जा सकती है
- ट्वीट पोस्ट होने के बाद लोगों ने मान लिया कि यह लेखक का पहला server है और वह server चलाने के वास्तविक मतलब को लेकर ज़रूरत से ज़्यादा आशावादी है
- जबकि 2006 से server management का अनुभव है
- शुरुआत PHP scripts edit करके और FTP server पर upload करके की थी
- WordPress install करना सीखा, WP templates edit किए, और फिर बाकी सब उसके बाद आया
- यह अनुभव बहुत क़ीमती था और इसने बुनियाद सिखाई
- Linux क्या है और उसमें navigate कैसे करना है, यह सीखा
- 2007 तक Canonical से Ubuntu CD-ROM मंगवाकर डाक से पाया और parents के computer में partition बनाकर Linux सीखा
- इन शुरुआती अनुभवों ने web development की बुनियाद सिखाई, बाकी सब उसी पर बना
Linux सीखना क्यों महत्वपूर्ण है
- नई पीढ़ी के developers (Gen Z, Alpha) उस hardware से पूरी तरह कट चुके हैं जिस पर software चलता है
- उनके पास इस तरह का बुनियादी अनुभव नहीं है
- वे ऐसे समय में पैदा हुए हैं जब YouTube पर कोई random व्यक्ति किसी vendor का प्रचार करता है और किसी खास command से सारे infrastructure problems जादुई रूप से हल करने की बातें सिखाता है
- इसलिए server क्या है और कैसे काम करता है, इस बारे में उनकी जादुई धारणाएँ होना स्वाभाविक है
- वे दावा करते हैं कि "serverless" में काम कर सकते हैं, लेकिन यह नहीं समझते कि वे अपना code कई अलग-अलग boxes पर चला रहे हैं
- बेशक कई लोग Linux और servers के बारे में ज़्यादा सीखते हैं, लेकिन average bootcamp graduate के पास 20 साल पहले के FTP hackers जितना hands-on Linux अनुभव नहीं होता
- यह कोई नैतिक फैसला नहीं है; न अच्छा न बुरा — web development की वर्तमान स्थिति बस यही है
- नतीजा यह है कि Vercel जैसी कंपनियाँ ऐसे नए developers से पैसे कमा रही हैं जिन्हें ठीक से पता ही नहीं कि वे क्या कर रहे हैं और जिन्होंने जीवन में कभी server नहीं चलाया
- अज्ञानता की कीमत दोहरी है: अज्ञानता खुद, और उसका फायदा उठाने वालों को चुकाई गई कीमत
- चीज़ें कैसे काम करती हैं, यह न जानना सचमुच पैसे खर्च करवाता है
अभी server सीखने का सबसे अच्छा समय है
- अगर आपने कभी अपना server manage नहीं किया और backend जैसी हर चीज़ से डर लगता है, तब भी सब ठीक रहेगा
- सच में, server अच्छे से संभालने के लिए इससे बेहतर समय कभी नहीं रहा
- Claude और ChatGPT दोनों को Linux की बहुत अच्छी समझ है और वे तकनीकी इतिहास में अभूतपूर्व तरीके से step-by-step मार्गदर्शन दे सकते हैं
- सिर्फ setup कैसे करना है और यह कैसे काम करता है, इतना ही नहीं; जब बदलाव चाहिए हों, तब भी आप बिना किसी को hire किए सवाल पूछकर steps follow कर सकते हैं
- यह उतना डरावना नहीं है, और यह काम उतनी बार करना भी नहीं पड़ता
- AI के इस दौर में, जहाँ code generation standard होता जा रहा है और code commodity बन सकता है, उस code को सस्ते production server पर deploy करना और उसे असली end users के लिए उपयोगी बनाना जानना developer के लिए एक बड़ा differentiator हो सकता है
- security जैसी चीज़ों की चिंता करनी चाहिए, यह सही है
- लेकिन यह तर्क नज़रअंदाज़ किया जा सकता है कि अपना server चलाना AWS server चलाने से कम सुरक्षित है, मानो EC2 instances हैकर्स से जादुई रूप से सुरक्षित हों
- सही setup करना वास्तव में इतना मुश्किल नहीं है; guides और setup scripts देखना काफ़ी है
- बहुत से developers आपसे ज़्यादा experienced होते हुए भी, AI के साथ आप जितना अच्छा कर सकते हैं उससे भी बदतर production काम कर रहे हैं
- अगर आप ChatGPT से Linux server harden करने और security best practices (password authentication बंद रखना, सिर्फ strong SSH keys इस्तेमाल करना) पूछ लें, तो 90% काम हो जाता है
- Cloudflare एक अतिरिक्त protection layer दे सकता है
- Linux box को lock down करने के बाद उसके ऊपर Cloudflare चलाएँ
- अगर DNS में server IP को proxy करके छिपा दिया जाए, तो यह आदर्श है
- DDoS protection, edge caching, और top-tier DNS लगभग मुफ्त में मिल जाते हैं
24 टिप्पणियां
ऑन-प्रेमिस पर ज़रूरी infrastructure को सीधे बनाने में लगने वाले समय और मेहनत को देखें, तो cloud services इतनी महंगी नहीं लगतीं।
और cloud service का इस्तेमाल high availability के लिए किया जाता है, लागत के लिए नहीं।
मुझे यह IKEA या Daiso जैसी अवधारणा लगती है।
बहुत किफायती और व्यावहारिक cloud services भी ज़रूर होंगी।
लेकिन उन्हें इस्तेमाल करते-करते फिर साथ में कुछ ऐसी चीज़ें भी इस्तेमाल होने लगती हैं जो थोड़ी महंगी लगती हैं।
(बस एक मोटा-सा उदाहरण है) Lambda इस्तेमाल करें तो फिर API Gateway भी इस्तेमाल करने लगते हैं, और वह थोड़ा महंगा और असुविधाजनक है -_-^
कुछ ऐसा ही है।
वैसे जिस बात से मुझे बहुत सहमति है, वह यह है।
AWS इनके लिए सुविधाजनक होने की वजह
तकनीकी रूप से जटिल दिखता है, इसलिए दूसरे डेवलपर्स के सामने खुद को स्मार्ट दिखाया जा सकता है
यही पंक्ति है।
सच कहूँ तो, AWS services पुरानी हैं और evolve होते-होते उनमें कई ऐसे features भी रह गए हैं जिन्हें deprecate तक नहीं किया जा सका। इन चीज़ों को अच्छी तरह जानकर काम करना काफ़ी कूल लगता था, इसलिए मैंने भी SA लिया था lol.. पूरी तरह सहमत~~
क्लाउड, on-premise और IDC—हर एक के अपने फायदे और नुकसान हैं, इसलिए अंततः सबसे अहम बात यह है कि उपयोग के उद्देश्य और पैमाने के अनुसार सही विकल्प चुना जाए।
सबसे बड़ी धारणा यही है कि 'hardware failure लगभग नहीं होता'...
मेरे अनुभव में, जब कंपनी IDC में rack किराए पर लेकर server चलाती थी, तो लगभग हर तीन दिन में कोई न कोई disk मर जाती थी, और disk बदलने व RAID recovery करने के लिए भाग-दौड़ करनी पड़ती थी...
इसलिए, जब तक कोई बहुत खास वजह न हो, मैं बस cloud इस्तेमाल करने की ही सलाह देता हूँ. हार्डवेयर खराब होने पर सिर्फ 'क्लिक' करके सब कुछ फिर से ऊपर ले आ पाना कितनी बड़ी वैल्यू है.....
हर 3 दिन में एक बार डिस्क खराब हो जाना थोड़ा अजीब है...
मुझे नहीं लगता कि यह कोई सामान्य केस है।
यह 10 साल से भी पुरानी बात है, और शायद Seagate.. था।
Backblaze ने बताया कि पिछले साल 4372 ड्राइव फेल हुए, तो उस स्तर के स्केल पर लगभग हर 2 घंटे में एक ड्राइव फेल होना स्वाभाविक है...
यह बहुत बड़े scale पर होने वाली आवृत्ति है।
उम्, मैंने 42U Rack के 100 यूनिट वाले कंप्यूटर रूम में HPC, HCI, शुरुआती Hadoop से बने distributed file system, और तरह-तरह के storage वाले environment में काफ़ी लंबे समय तक काम किया है, लेकिन हर 3 दिन में एक बार disk fail होती हो, ऐसा मैंने कभी नहीं देखा।
Hacker News राय
मैं कई सालों से सीधे अपने सर्वर चलाता आ रहा हूँ, और इससे सादगी बनी रही है तथा बहुत समय और पैसे बचे हैं
मैं AWS या Azure से बचता हूँ क्योंकि उनकी configuration जटिल है और UI भी खास अच्छा नहीं है
असली बात यह है कि सर्वर को इस तरह मैनेज करना चाहिए कि उसे कभी भी सिर्फ configuration files से दोबारा बनाया जा सके। इसलिए Ansible जैसे tools ज़रूरी हैं
अगर cloud का इस्तेमाल करना ही हो, तो मैं DigitalOcean की सिफारिश करता हूँ। यह सरल और intuitive है, इसलिए मानसिक शांति के लिए बेहतर है
मैं DO का इस्तेमाल सिर्फ disaster recovery के तीसरे चरण के लिए करता हूँ, और Terraform व Ansible से cluster को अपने-आप configure करता हूँ
ज़्यादातर developer communities trends के पीछे भागती हैं, लेकिन मैं ऐसे माहौल में भी अपने physical server cluster पर JVM-आधारित Clojure monolith deploy करके स्थिर मुनाफ़ा कमा रहा हूँ
ulimitsettings, syn cookies performance issues, security updates, zero-day attacks का जवाब, email sending (IP warming, spam list management), GDPR compliance वगैरहइन सबकी ज़िम्मेदारी मेरी होती है, और cloud इस्तेमाल करने वाले लोग सिर्फ ‘बेवकूफ़ बने हुए’ लोग नहीं हैं
मुझे black-and-white logic पसंद नहीं है। ज़्यादातर startups अगर EC2 की जगह Hetzner, Linode, DigitalOcean जैसी सेवाओं पर जाएँ तो काफी पैसा बचा सकती हैं
लेकिन cloud के भी कई फ़ायदे हैं — backups, managed DB, multi-AZ जैसी सुविधाएँ कुछ clicks में मिल जाती हैं
शुरुआत में hardware पर कोई capital investment नहीं लगता, और अगर peak load बहुत ज़्यादा हो तो यह उल्टा सस्ता भी पड़ सकता है
लेकिन engineering time की क़ीमत बहुत अधिक होती है, इसलिए तेज़ी से बढ़ने वाले चरण में cloud तर्कसंगत हो सकता है
आख़िरकार cloud इसलिए महँगा नहीं है कि वह cloud है, बल्कि इसलिए कि आप ऐसी सुविधाओं के लिए भुगतान करते हैं जिनकी ज़रूरत नहीं होती
multi-cloud strategy ने कई बार disaster रोका भी है
VPS या dedicated server में भी शुरुआती लागत लगभग नहीं के बराबर होती है, और जब तक peak load बहुत चरम न हो, cloud ज़रूरी नहीं कि ज़्यादा सस्ता ही हो
managed DB सुविधाजनक है, लेकिन उसमें forced upgrades बहुत होती हैं, और अगर scale बहुत बड़ा न हो तो खुद मैनेज करना बेहतर हो सकता है
पहले hardware scale करना मुश्किल था, लेकिन अब एक single server भी पहले के पूरे rack जितना performance दे सकता है
अब मध्यम आकार के projects वे समस्याएँ खुद हल कर सकते हैं जिन्हें पहले cloud हल करता था
हाँ, बाहरी manpower support लेने के लिए cloud कहीं ज़्यादा आसान है, जबकि self-hosting के लिए support staff ढूँढना कठिन है
मैं व्यक्तिगत रूप से self-hosting पसंद करता हूँ, लेकिन जो लोग infra खुद छूना नहीं चाहते, उनके लिए cloud बेहतर है
पहले मैं एक hedge fund startup में IT संभालता था
हम dual Xeon server (512GB RAM) पर C++ analytics program चलाते थे, लेकिन lunch पर किसी ने boss से पूछ लिया, “आप AWS क्यों नहीं इस्तेमाल करते?” और वह घबरा गए
मैंने देखा कि ‘buzzword compliance’ को efficiency से भी ज़्यादा महत्व दिया जाता है
कई CTO इसी माहौल की वजह से अनावश्यक रूप से बड़े budget ख़र्च करते हैं, और efficient architecture इस दुनिया में उल्टा marketing की कमजोरी बन जाती है
“10x saving” वाली अभिव्यक्ति तार्किक रूप से ग़लत है। 10x का मतलब 10 गुना ज़्यादा होता है
सर्वर cost से ज़्यादा maintenance labor cost बड़ी होती है
भले ही आप 10 EC2 instances चला रहे हों, Systems Manager से auto-patching किया जा सकता है, इसलिए खुद automation stack बनाने की ज़रूरत नहीं पड़ती
cloud पर बहस black-and-white नहीं है
छोटे पैमाने पर Hetzner और AWS लगभग समान हो सकते हैं, और बड़े enterprises के लिए असली सवाल यह है कि क्या वे अपने tooling खुद बना सकते हैं
मध्यम आकार की कंपनियों (SME) का हिस्सा सबसे पेचीदा है। अगर हर customer के लिए पूरी तरह अलग system चाहिए, तो AWS फ़ायदेमंद है; अगर 24/7 स्थिर load है, तो अपने सर्वर बेहतर हैं
अगर आप cloud को सिर्फ VM hosting के लिए इस्तेमाल करते हैं, तो यह घाटे का सौदा है। अक्सर लोग cloud features का इस्तेमाल नहीं करते, सिर्फ cost भरते हैं
अपने सर्वर में पूरे महीने maximum capacity की कीमत चुकानी पड़ती है, जबकि cloud में सिर्फ ज़रूरत के कुछ दिनों का भुगतान करना पड़ता है
cloud MVP बनाने और market validation के लिए बेहद उपयोगी है
startup credits और free tier के साथ तेज़ी से experiment किया जा सकता है, और बाद में अगर cost समस्या बने तो migrate किया जा सकता है
लेकिन शुरुआत से ही server-independent architecture के साथ design करना चाहिए, और migration के लिए समय निकालना आसान नहीं होता
हमारी टीम Google Cloud इस्तेमाल करती है, लेकिन हमारा spend इतना कम है कि sales representative नाराज़ रहता है
clouds के बीच move कर सकने की संभावना negotiation power का काम करती है
इसके अलावा cloud में SLA या data protection regulations को संभालना आसान होता है, इसलिए enterprise customers का भरोसा जीतने में मदद मिलती है
मुझे जिज्ञासा है कि AWS ने शुरुआती दौर में इतनी विस्फोटक growth क्यों देखी
2010 के शुरुआती वर्षों में rack lease करना और सर्वर setup करना महँगा और धीमा था, और multi-region setup लगभग असंभव था
AWS ने इन समस्याओं को हल किया, लेकिन अब हालात बदल चुके हैं
Squarespace का वह किस्सा भी था जब Hurricane Sandy के दौरान उन्होंने खुद ईंधन ले जाकर सर्वर बचाए थे
Hetzner पर server order करने के 10 मिनट के भीतर Ubuntu install और Ansible config पूरा किया जा सकता है
fixed pricing, unlimited bandwidth, predictable performance — बिना अनावश्यक abstraction की सादगी ही इसका आकर्षण है
EC2 ने यह झंझट ख़त्म किया, और Lambda उससे भी आगे गया। अब bare-metal rental कहीं ज़्यादा सस्ता हो गया है
AWS की पुरानी free credits policy असल में lock-in strategy ही थी
अपने server को data center में रखना जितना लगता है उतना मुश्किल नहीं है
मुझे gaming server के लिए high-clock CPU चाहिए था, जो cloud में मिलना कठिन था, इसलिए मैंने खुद setup बनाया
installation fee सहित यह लगभग £15 प्रति माह में चलता था, और कई सालों तक अच्छी तरह चला। नतीजे में cost में बड़ी बचत हुई
Seattle data center में equipment रखा जाता था, और modem-based KVM से remote management किया जाता था
हम कुछ साल पहले Hetzner पर migrate हुए थे, और जो बचत हुई उसके बाद शायद अब फिर cloud पर नहीं लौटेंगे
अपवाद है Cloudflare Workers, जिसकी quality अच्छी है और free quota काफ़ी उदार है
AI की वजह से automation, deployment और backup scripts लिखना पहले से बहुत आसान हो गया है, इसलिए management भी सरल हुआ है
संदर्भ के लिए, Anthropic का Claude Code Pro/Max users को 18 नवंबर तक $250 free credits दे रहा है
संबंधित घोषणा इस ट्वीट में देखी जा सकती है
सिर्फ़ एक बार backup restore का अनुभव हो जाए, तो शायद इसकी वैल्यू समझ आ जाएगी, है न? On-premise में backup restore सबसे ज़्यादा सिरदर्द होता है।
खैर.. मैं इस बात से सौ फीसदी सहमत हूँ कि 'cloud की लागत ज़रूरत से ज़्यादा महंगी है' और 'ज़्यादातर मामलों में बड़े cloud की सुविधाओं की ज़रूरत नहीं होती', लेकिन लेख का लहजा ऐसा लगता है मानो वह यह कह रहा हो कि cloud services सबकी सब धोखा हैं, और यही बात पढ़ने में असहज बनाती है। यह कुछ वैसा सुनाई देता है जैसे कहना, 'insurance products सबके सब धोखा हैं।'
क्लाउड का इस्तेमाल तब किया जाता है जब आप सर्वर मैनेज नहीं करना चाहते हों, या मांग का अनुमान लगाना आसान न हो और तेज़ी से scale करने की ज़रूरत हो। इसके अलावा और किन use cases में इसका मतलब बनता है, मुझे समझ नहीं आता।
मैं कुल मिलाकर सहमत हूँ, लेकिन जब आप कई सालों तक सीधे सर्वर ऑपरेट करते हैं, तो यह खलता है कि इसमें security के नज़रिए से कोई चर्चा नहीं है।
मैं भी इस राय से सहमत हूँ।
सही कहा।
मैं इससे सौ प्रतिशत सहमत हूँ कि cloud महंगा है.
लेकिन अगर अभी 200 से ज़्यादा containers को bare metal पर Kubernetes खुद सेटअप करके इस्तेमाल करना पड़े,
ऐसी स्थिति में जहाँ 1 backend developer है और devops नहीं है, अगर यह सोचा जाए कि एक व्यक्ति की labor cost के चौथाई खर्च में server management और operations का बोझ कम हो जाता है, तो यह अपने-आप में बुरा विकल्प भी नहीं है.
अगर कोई व्यक्ति सिर्फ server infrastructure management ही करता हो, तो cloud से बाहर जाना निश्चित रूप से एक अच्छा विकल्प हो सकता है.
व्यक्तिगत तौर पर, क्लाउड को जितना हो सके उतना हटाकर सर्विस बनाकर देखने की कोशिश की, तो सच में दिमाग खराब हो गया।
मुझे container image registry चाहिए था, लेकिन उसे खुद सेटअप करने लगा तो local storage बोझिल लगा। बैकअप की सुविधा के लिए s3 compatible विकल्प देखने पड़े, बाहरी access रोकने के लिए vpn service भी चलानी पड़ी, reverse proxy पर https certificate management, और ci/cd security के लिए तरह-तरह की settings तक... self-hosting...
अगर क्लाउड में सिर्फ कुछ साधारण services ही इस्तेमाल करनी हों, तो bare metal सस्ता पड़ता है और वैसे इस्तेमाल करना सही भी होगा। लेकिन अगर दूसरी services के साथ integration चाहिए और तरह-तरह के झंझट कम करने हों, तो भले ही अभी server cost महंगी लगे, फिर भी ऐसी services को एक-एक करके खुद बनाने की जरूरत नहीं पड़ती — इस वजह से setup और management cost बचने का फायदा हो सकता है।
इमेज स्टोरेज के लिए कई open source विकल्प मौजूद हैं।
हाँ, बहुत हैं। मेरा मतलब उसे सीधे ऑपरेट करने के बोझ से था। मैं भी Nexus या Harbor इस्तेमाल करता हूँ।
मेरे निजी अनुभव में यह बोझ या समस्या नहीं थी।
हालांकि बोझ का मानदंड हर किसी के लिए अलग हो सकता है, इसलिए ऐसा सोचा जा सकता है।
आप कौन-सी service develop कर रहे हैं जिसके लिए आपको container image repository की ज़रूरत है?
मैं किसी भी service को develop करूँ, container deployment को prefer करता हूँ, इसलिए ऐसा है। मैं deployment भी जहाँ तक संभव हो direct ssh connection के बिना करना पसंद करता हूँ। अगर सिर्फ लागत के बारे में सोचें... तो registry के बिना direct deploy करने के तरीके भी शायद हो सकते हैं, लेकिन मैंने इसे सिर्फ एक उदाहरण के तौर पर सोचा था, और मैं email service जैसी चीज़ों में होने वाली कुछ असुविधाओं पर फोकस करना चाहता हूँ।