सर्वरलेस डरावनी कहानियाँ

• विभिन्न SaaS और सर्वरलेस सेवाओं में अप्रत्याशित रूप से बहुत बड़े बिल आने के मामले बार-बार सामने आते हैं, और यह पेज उन्हें अच्छी तरह संकलित करता है
• जो उपयोगकर्ता सामान्य रूप से मासिक subscription fee चुका रहे थे, उन्हें DoS attack या बेकाबू resource usage के कारण सिर्फ एक दिन में ही दसियों हज़ार से लेकर लाखों डॉलर तक के बिल थमा दिए गए
• कुछ सेवाओं में spending limit सेट करने के बावजूद अतिरिक्त शुल्क लग गया, जिससे सिस्टम की सीमाएँ उजागर हुईं
• डेवलपर कम्युनिटी में ऐसे अनुभव साझा किए जा रहे हैं, और अतार्किक billing structure तथा transparency की कमी को बड़ी समस्या बताया गया है
• सर्वरलेस और cloud environment में एक छोटी गलती या एक हमला भी भारी वित्तीय नुकसान कर सकता है, इसलिए सावधानी की ज़रूरत पर ज़ोर दिया गया है

---

सर्वरलेस और SaaS सेवाओं में अत्यधिक बिलिंग के मामलों का संग्रह

#1 Webflow में भारी बिलिंग

• $69 प्रति माह वाले प्लान का उपयोग करते समय, बिना किसी स्पष्ट कारण के एक महीने का बिल $1,189.42 आ गया

#2 WebGL गेम साइट पर DoS attack का मामला

• मध्यम आकार की WebGL गेम अपलोड साइट के ऑपरेटर को DoS attack के बाद Google Firebase से सिर्फ एक दिन में $100,000 से अधिक का बिल मिला

#3 Vercel Pro और spending limit पार होना

• Vercel Pro प्लान $20 प्रति माह पर उपयोग किया जा रहा था, और $120 की spending limit सेट होने के बावजूद अप्रत्याशित अतिरिक्त शुल्क आ गया

#4 प्रोजेक्ट बिलिंग और बेहद बड़ा चार्ज

• एक ऐसा प्रोजेक्ट जो हर महीने $50 देता था, उसे एक सुबह $70,000 तक का बिल मिला

#5 BigQuery उपयोग और public dataset बिलिंग issue

• Playground environment में BigQuery का उपयोग करते समय $22,000 से अधिक का भारी बिल आ गया

#6 कम visitors के बावजूद बहुत अधिक hosting charge

• मासिक visitors सिर्फ 9,000 होने के बावजूद $250 प्रति माह का बिल आया, यानी सालाना $3,000 खर्च की स्थिति

#7 Devin(AI) द्वारा codebase बदलने के बाद की समस्या

• AI Devin ने code changes किए, जिसके बाद अप्रत्याशित परिणाम देखने को मिले

#8 मुफ्त उपयोग के बाद अचानक बिलिंग

• कभी कोई भुगतान नहीं किया था, फिर भी एक दिन अचानक $530 का बिल आ गया

#9 documentation site और अन्य छोटे प्रोजेक्ट्स की बिलिंग

• एक साधारण documentation site पर भी लगभग $400 का बिल आ गया; यानी कम उपयोग वाली सेवाओं में भी भारी बिल के कई मामले हैं

#10 free tier का डर

• करीब $103 का बिल भी समस्या माना गया। खासकर free tier उपयोग के दौरान अचानक invoice आना चिंता का कारण है

#11 Cloudflare, AWS और अन्य issues

• Cloudflare में 24 घंटे के भीतर $120,000 चुकाने की सूचना के साथ सेवा बंद होने का मामला सामने आया
• AWS S3 में खाली, private bucket बनाने के बाद भी अप्रत्याशित शुल्क लग गया
• Netlify में $104,500 का unpaid invoice मिलने जैसे समान मामले अलग-अलग providers में दोहराए गए

#12 DoS attack, email और data loss

• DoS attack के दौरान email भेजने में $11,000 खर्च हो गए, और बाद में database भी खो गया

#13 Vercel में भारी बिलिंग, account और trial समस्या

• Vercel पर spam attack के कारण एक ही दिन में $23,000 का बिल आ गया, और 56,000 accounts तथा trial सक्रिय हो गए

#14 test/deployment के दौरान अप्रत्याशित बिलिंग

• test के उद्देश्य से Vercel आदि पर features deploy करते समय अप्रत्याशित राशि वसूल ली गई
• sitemap(sitemap.txt) ने सैकड़ों GB bandwidth इस्तेमाल की, जिससे भारी बिल बना

#15 Firebase, Cloud Run test cost

• Firebase और Cloud Run की केवल दो tests में $72,000 खर्च हो गए, और सेवा दिवालिया होने की कगार पर पहुँच गई

निष्कर्ष और संकेत

• सर्वरलेस और cloud environment में cost structure अस्पष्ट हो सकता है और यह हमलों या गलतियों के प्रति बहुत संवेदनशील है
• अप्रत्याशित बिलिंग के कई मामले सामने आए हैं, इसलिए सेवा संचालन के दौरान सावधानीपूर्वक monitoring, usage management और limit setting बेहद ज़रूरी हैं
• अगर automation और monitoring फीचर्स कमजोर हों, तो एक साधारण test या एक बाहरी हमला भी दसियों हज़ार डॉलर का अप्रत्याशित नुकसान करा सकता है
• डेवलपर्स, startups और अन्य SaaS उपयोगकर्ताओं के लिए cost management और risk awareness का महत्व बढ़ता जा रहा है

[ahwjdekf]

मैंने एक बड़ी कंपनी के अंदरूनी DW के लिए डेवलपमेंट किया था, और यह मौजूदा on-premise डेटा को AWS पर माइग्रेट करने का काम था। लेकिन कई महीनों की डेवलपमेंट और टेस्टिंग पूरी करने के बाद भी आखिरकार यह रद्द हो गया। वजह यह थी कि हर महीने बिल उम्मीद से कहीं ज़्यादा आने वाला था। बड़ी कंपनियों के लिए भी cloud खर्च आसान नहीं होता।

[regentag]

मैंने भी AWS सीखने के मकसद से अकाउंट बनाया था, लेकिन मुझसे भी थोड़ी-सी रकम चार्ज कर ली गई थी.
अकाउंट हैक हो गया था और किसी ने मेरे अकाउंट पर instance बनाकर चला दिया था... मैंने जल्दी ही उसे बंद कर दिया, इसलिए मामला छोटी रकम पर ही खत्म हो गया.
मैं management में समय नहीं दे सकता था, इसलिए आखिरकार अकाउंट ही बंद कर देना पड़ा.

[ifmkl]

मैं यह सुझाव देना चाहूंगा कि cloud से शुरुआत करने से पहले आजकल काफ़ी प्रचलित n100, n150-स्तर के mini server environment बनाकर थोड़ा testing या operations का अनुभव जमा लिया जाए.

[crawler]

प्रोजेक्ट बहुत छोटा हो तब भी, एक बार उसे platform पर डाल देने के बाद अगर कोई vulnerability हो और उससे सीधे पैसों का नुकसान होने लगे, तो वह सच में डरावना लगता है

मैंने अपने content के आगे Cloudflare लगाया था, लेकिन एक hacker ने ऐसे objects ढूंढ निकाले जो cache नहीं हुए थे और उन पर 10 करोड़ से ज़्यादा बार hit किया। मैंने उसे block किया तो उसने सीधे origin bucket का address भी ढूंढ लिया और उस पर attack किया

ऐसे मामले में भी क्या cost refund मिलती है, यह जानना चाहूँगा।

[GN⁺]

Hacker News राय

• जब मैं बूटकैंप में प्रोग्रामिंग सीख रहा था, तब मैंने एक मुफ्त elastic beanstalk instance बनाया था। पहचान सत्यापन के लिए credit card चाहिए था, और उस समय मुझे नहीं लगा कि यह कोई समस्या बनेगी। लेकिन बाद में मेरे server पर bot spam attack हुआ और Amazon ने मुझसे $100,000 चार्ज कर दिए। आखिरकार मुझे refund मिल गया, लेकिन उस दिन के बाद से मैं Amazon से नफरत करने लगा और अगर cloud computing इस्तेमाल करनी पड़ी तो किसी दूसरी service का इस्तेमाल करने की कसम खा ली। मुझे उनका जटिल dashboard और ऐसा ढांचा बिल्कुल पसंद नहीं आया जो ग्राहकों को भ्रमित करके उनसे पैसे गंवाता है। अगर वे credit card को सिर्फ verification के लिए इस्तेमाल करते और bots को रोकते, तो वही काफी होता। किराने की दुकान में credit card से आसानी से cookies खरीदने जैसी साधारण चीज़ों से तुलना करें तो लगता है कि fintech का सचमुच उपयोगी इस्तेमाल हो सकता था, लेकिन उन्होंने वैसा नहीं किया
  • यही cloud hosting के डरावने होने की एक वजह है। सिर्फ Amazon ही नहीं, Azure और Google Cloud भी "आमतौर पर" refund कर देते हैं। लेकिन अगर मेरा हफ्ते में 5 visitors वाला demo project अचानक DDoS का शिकार हो जाए और hosting company इस बार कहे कि यह "आमतौर पर" वाला मामला नहीं है, और payment मांग ले, तो मैं दिवालिया होने की कगार पर पहुंच सकता हूँ
  • इस समय मुझ पर $25,000 का bill आया हुआ है। मैंने पहले SQS के data plane auditing को चालू किया था और असल में real-time audit event feed भी जोड़ दी थी। नतीजा यह हुआ कि हर audit event पर logging event एक infinite loop की तरह पैदा होने लगा। लगभग 10 साल तक रोज़ औसतन $2 देने वाला account एक दिन अचानक $3,000 प्रतिदिन देने लगा, और AWS की तरफ से कोई warning या हस्तक्षेप नहीं आया
  • Amazon ने $100,000 refund कर दिए, फिर भी आप उसे नापसंद क्यों करते हैं, यह जानना चाहता हूँ। मेरे मामले में AWS ने हमेशा refund दिया है, भले ही महंगा bill पूरी तरह मेरी गलती से बना हो। अगर कोई “budget cross होते ही सब बंद” policy होती, तो शायद “DDoS के कारण AWS ने सारे EC2 बंद कर दिए और मेरा scratch storage data भी उड़ गया” जैसी दूसरी त्रासदियाँ भी बहुत सामने आतीं
  • “यह तो एक single-line if statement का मामला है—account limit पार होते ही instances बंद करो और service को static drive पर dump कर दो। यह बहुत आसान काम है। वे बस ऐसा करना नहीं चाहते थे—वे scale का इस्तेमाल करके customers से revenue maximize करना चाहते हैं। जिन्होंने cloud compute से सबको मुश्किल में डाला, वही अब AI cost से भी market capture के सहारे आर्थिक फायदा उठाना चाहते हैं। आज edge compute आसान इसलिए हुआ है क्योंकि crypto की वजह से लोगों ने hard drives में जरूरत से ज्यादा निवेश कर लिया था। आखिरकार market bubbles और bad behavior को बढ़ावा देता है, और trust बनाने के बजाय ताकत के दम पर market का दुरुपयोग करने वाले लोगों को खुली छूट देता है। ‘तुम बस इसे समझते नहीं हो! (वैसे market crash होने से पहले थोड़ा और पैसा दे दो)’ जैसी चालाकी भरी मुद्रा अपनाने वाले smart villains ही industry की सबसे बड़ी समस्या हैं। Taxi company भी destination तक न पहुँचने पर $1,000 नहीं वसूलती। Server में if statement भी नहीं डाल सकते, यह बात समझ से परे है। तो क्या Amazon taxi company से भी बदतर है? शायद हाँ। यही तो ‘Waymo’ शुरू होने की वजह है (शायद मज़ाक है)”
• मुझे लगा था कि hosting/development/debugging में serverless के दर्द की बात होगी, लेकिन यह तो price explosion की कहानी निकली। शायद bandwidth cost मुझे कभी इतना गंभीर नहीं लगा, इसलिए मैंने इस तरह के ज़्यादातर लेख सरसरी तौर पर पढ़े, लेकिन यह वाला दिलचस्प था—एक खाली S3 bucket कैसे AWS bill को विस्फोटक बना सकती है में बताया गया है कि किसी और के S3 पर unauthenticated API calls करके उसका bill बढ़ाया जा सकता है। मेरे लिए यह नई जानकारी थी
  • मेरा मानना है कि इस मुद्दे पर blog post वायरल होने के तुरंत बाद कार्रवाई हुई: Amazon S3, कुछ error codes पर अब charge नहीं लेगा
  • serverless environment की असली समस्याओं में से एक यह है कि platform खुद black box की तरह अपारदर्शी होता है (हालाँकि यही serverless की value proposition भी है)। हमें एक बड़ा Lambda backend विरासत में मिला, और platform के भीतर की समस्याएँ—जैसे secret extender से जुड़ते समय होने वाले intermittent socket disconnects—ट्रेस करना बेहद कठिन था। local test environment और असली deployment environment में इतना फर्क है कि यह और भी दर्दनाक हो जाता है। Google Cloud Functions को घर पर खिलौने की तरह चलाना तो ठीक है, लेकिन किसी असली project में मैं उससे बेहतर HTTP server/queue consumer को सीधे ECS जैसे containers पर चलाना पसंद करूँगा
  • बात यह है: ‘मान लीजिए मैंने अपनी पसंदीदा region में एक खाली private S3 bucket बनाई। संयोग से किसी लोकप्रिय open source tool की default setting S3 पर backups store करने की है, और उसमें placeholder के तौर पर उसी नाम का इस्तेमाल हो गया जो मेरी bucket का है।’ मैं सोचता हूँ कि ऐसा सच में कितनी बार होता होगा—naming collisions वास्तव में कितनी आम हैं, इसका मुझे अंदाज़ा नहीं
  • इसे देखकर तो लगता है कि competitors को खत्म करने के लिए भी इस तरीके का इस्तेमाल किया जा सकता है। यही वजह है कि मुझे AWS खास पसंद नहीं। छोटे ग्राहकों को अचानक आने वाले bill shocks से बचाने की उनकी तरफ से कोई गंभीर कोशिश नहीं दिखती। Azure भी बहुत बेहतर नहीं, लेकिन कम-से-कम कुछ सुरक्षा उपाय तो हैं
  • मैं भी serverless, Lambda, और DynamoDB से सब कुछ बाँध देने वाले उस cloud lock-in वाले उदाहरण की उम्मीद कर रहा था, जहाँ असल में $20 के VPS पर sqlite से काम चल सकता था, लेकिन आपको अनावश्यक रूप से कहीं बड़ा setup इस्तेमाल करने पर मजबूर किया जाता है। अफसोस कि बात वह नहीं निकली
• serverless में असली दर्द किसी एक घटना से बड़ा bill आना नहीं, बल्कि हर महीने थोड़ा-थोड़ा बढ़ता bill है। resources बनाना बहुत आसान है और फिर उन्हें यूँ ही छोड़ देना भी। हर एक-दो महीने में खर्च कुछ हज़ार डॉलर बढ़ता जाता है, फिर COO को पता चलता है, और पूरी company emergency mode में जाकर bill को $10,000 से नीचे लाती है। फिर वही चक्र दोहरता है। कुछ सालों में जोड़ें तो यह एक बार में पैसा डुबाने से भी ज्यादा बर्बादी बन जाता है
  • यही practically AWS का business model है। क्या आपने इसे कभी “Planet Fitness” model कहा है? sign-up करना और पैसे खर्च करना बहुत आसान, लेकिन payments बंद कराना बेहद झंझट भरा
  • लगता है organizations ऐसे महंगे billing periods से कुछ सीखती ही नहीं हैं। मैं जानना चाहता हूँ कि charges लगातार बढ़ते क्यों रहे और क्या इसे पहले रोका जा सकता था
  • ऐसी समस्या on-premise में भी अक्सर होती है। ऐसे servers (आमतौर पर VMs) पड़े रहते हैं जिन पर unused apps लगातार चलते रहते हैं। बेशक VM की लागत भी शून्य नहीं होती
• अक्सर जिम्मेदारी किसकी है, यह साफ नहीं होता। ग्राहक चाहते हैं कि hardware infrastructure को एक click में deploy कर देने वाले जादुई, frictionless tools मिलें। अगर कोई अनुभवहीन user गलत configuration कर दे और बहुत बड़ा bill बन जाए, तो cloud provider अगर वही पूरा bill वसूल ले तो उसकी reputation खराब होती है। लेकिन अगर वह पहले से users को चुन-छाँटकर सीमित करे, तो startup बनाने की कोशिश कर रहे छोटे developers के लिए दरवाज़ा बंद हो जाता है। ऐसे में अगर अचानक $10,000 का bill बन जाए, तो दार्शनिक रूप से हमेशा यह सवाल रहता है कि किसे कितना भुगतान करना चाहिए, और गलती से बने खर्च की जिम्मेदारी कहाँ तक होनी चाहिए। अगर मेरे code के कारण resources 10 गुना अधिक inefficient तरीके से इस्तेमाल हुए हों, तो क्या बस “गलत config तुम्हारी जिम्मेदारी” कह देना सही है? या ग्राहक के नज़रिए से यह मायने नहीं रखना चाहिए कि मैं जिस cloud का उपयोग कर रहा हूँ वह AWS जैसी बड़ी company है या कोई छोटा startup API service
  • budget overrun/circuit breaker (spending cap) जैसी systems क्यों न हों? यह कोई असंभव समस्या नहीं लगती
  • असली जवाब तो आसान है—budget limit होनी चाहिए
  • यही उन वजहों में से एक है कि लोग serverless की बजाय असली servers इस्तेमाल करते हैं
• Hetzner पर आपको 16TBx2 HDD, 1TBx2 SSD, 64GB RAM, और 20TB free traffic $70 प्रति माह में मिल सकता है। जबकि AWS micro instance पर मैंने 1TB traffic के लिए $150 चुकाए थे (जहाँ तक मुझे याद है)। इसकी कोई जरूरत नहीं है
• “मैंने अपने content के सामने Cloudflare लगाया था, लेकिन एक hacker ने uncached objects ढूँढ लिए और उन पर 100 million से ज़्यादा hits किए। जब मैंने उसे block किया, तो उसने origin bucket का address सीधे ढूँढ लिया और उस पर हमला कर दिया।” इस बात पर मुझे जिज्ञासा है कि क्या ऐसा किसी के साथ भी नहीं हो सकता? यह भी साफ नहीं कि uncached object का leak होना port 22 को कमजोर password के साथ खोलकर छोड़ देने जितनी गंभीर गलती है या नहीं, क्योंकि S3 resources—खासकर images—आमतौर पर तो ऐसे ही बनाए जाते हैं कि कोई भी उन्हें कितनी भी बार access कर सके, है ना?
  • बिल्कुल नहीं। S3 bucket को private होना चाहिए और security rules इस तरह होने चाहिए कि access सिर्फ CDN से ही हो सके। तभी यह सुनिश्चित होगा कि traffic हमेशा CDN से होकर जाए
  • यह कुछ वैसा लगता है जैसे कोई OWASP Top 10 vulnerabilities खुली छोड़ देने पर गर्व करे। access control की setting उतनी मुश्किल नहीं है जितनी लोग समझते हैं, और अगर कोई इतना basic हिस्सा भी गलत कर दे, तो मुमकिन है कि वह बाकी जगह भी ऐसे ही लापरवाह हो। ऐसे व्यक्ति के जिम्मे कोई system हो तो मुझसे उस पर भरोसा नहीं होगा
  • सबसे basic बात यह है कि S3 objects private रखे जाएँ और कम-से-कम cloudfront proxy सामने रखा जाए। images जैसी चीज़ें हमेशा cache के जरिए serve होनी चाहिए
• इसे serverless कहना भी अजीब है, क्योंकि असल में आप अब भी cloud infrastructure पर servers ही चला रहे होते हैं। मूल रूप से आप अब भी client-server model के हिसाब से software लिख रहे हैं, और users के इस्तेमाल के लिए server कहीं न कहीं चलना ही चाहिए। मेरी नज़र में असली ‘serverless’ वह होगा जहाँ user software एक बार download कर ले और उसके बाद internet के बिना भी चला सके। या अगर data server को भेजना पड़े, तो भी वह developer द्वारा चुनी गई किसी एक खास जगह पर निर्भर हुए बिना काम कर सके
  • ‘serverless’ शब्द का असली मतलब एक ऐसी managed system से है जहाँ load के अनुसार resources (servers) अपने-आप बढ़ते-घटते हैं। यही इसकी मूल बात है। load बढ़े तो servers बढ़ें, load घटे तो कम हों। जब आप पूरे code structure को इस environment के हिसाब से कुशलता से ढाल सकते हैं, तभी serverless अपनी असली कीमत दिखाता है। यानी यह architecture तभी इस्तेमाल होना चाहिए जब सचमुच उसकी जरूरत हो
  • आम तौर पर उसे ‘local’ software कहा जाता है। ‘serverless’ नाम अच्छा नहीं है, लेकिन वास्तव में यह किसी खास backend deployment structure की बात है। इसका मतलब backend रहित app नहीं है
  • ‘serverless’ कुछ वैसा है जैसे “बिना कर्मचारियों वाली company”। असल में सेवा देने वाले लोग होते हैं, बस सब contractor होते हैं
  • ‘server’ आम तौर पर एक single machine होता है जिस पर कोई खास OS और software की कई layers (monitoring tools सहित) चल रही होती हैं, और जो users को business logic तक पहुँच देती है। अगर आप खुद servers चलाते हैं, तो OS चुनना, support software install/update करना, failure recovery देखना—सब आपकी जिम्मेदारी होती है। serverless ‘function as a service’ model है, जहाँ आपको सिर्फ business logic यानी अपने code की चिंता करनी होती है। server पर OS install करने की जरूरत नहीं, http server जैसे basic software की भी चिंता नहीं, updates या maintenance भी नहीं। बस code upload करें, और invoke होने पर वह चल जाएगा। यानी server operations के तनाव से पूरी तरह मुक्ति। इसलिए इसका नाम ‘serverless’ है—server मौजूद हैं, लेकिन उन्हें चलाना आपको नहीं पड़ता
• “serverless” का मतलब सच में server न होना नहीं है, बल्कि यह है कि आपको server manage नहीं करना पड़ता या यह जानना नहीं पड़ता कि आपका code किस server पर चल रहा है। कुछ ऐसा: “लो, यह code है, इसे हर घंटे चला देना। कहाँ चलाते हो, मुझे फर्क नहीं पड़ता”
  • यह शब्द असहज लग सकता है, लेकिन भाषाई नज़रिए से देखें तो यह Orwellian समस्या नहीं है। 1984 में ‘Newspeak’ का मकसद अभिव्यक्ति की विविधता को घटाना था, जबकि ‘serverless’ एक नए category को नाम देने की कोशिश है। हाँ, यह server के अस्तित्व को धुंधला कर सकता है, लेकिन इसे ठीक-ठीक Orwellian कहना सही नहीं होगा। शायद “servelet” जैसा कोई शब्द, यानी ‘हल्का server’, ज्यादा सटीक लगता
  • “cloud जैसी कोई चीज़ नहीं होती, बस किसी और का computer होता है” जैसी self-deprecating कहावत भी खूब चलती है
  • ‘serverless’ आखिरकार पुराने ‘shared hosting’ का tech-bro version ही लगता है, जिसमें ‘10,000% margin’ और ‘per-request billing’ जोड़ दी गई है
  • “no-code” systems भी आखिर code से ही चलते हैं। PaaS हो या कुछ और, आखिर server मौजूद हैं—इस बात पर गुस्सा करना बहाना ढूँढने जैसा है
• मैंने AWS serverless इस्तेमाल किया है, और local testing लगभग नामुमकिन थी। serverless run के लिए AWS IAM role ज़रूरी था, इसलिए account-wide बहुत broad permissions खुले हुए थे। आखिरकार स्थिति यह हो गई कि लगभग हर test production में ही करना पड़ता था, जो बहुत बड़ी समस्या थी
  • मैंने भी कई साल serverless project पर काम किया है, और local पर लगभग कुछ भी न चला पाना सच में बहुत बड़ी hidden cost थी। debugging time भी बेहद खराब था। जो replacement tools आए, वे भी असली projects में लगभग बेकार निकले
  • अगर ~/.aws/credentials file ठीक से configure कर दी जाए, तो AWS security keys के साथ local testing की जा सकती है। makefile से Lambda deployment automate किया जा सकता है, और हर Lambda के लिए custom IAM role बनाकर security requirements को JSON files में manage किया जा सकता है। AWS की असली ताकत यह है कि सब कुछ एक ही API से handle किया जा सकता है। programmatically सब कुछ बनाना और manage करना संभव है
  • 1. stack में बाँधकर developers के अलग account में deploy करें (free staging environment), 2) official supported Docker runtime से local testing करें, 3) हमेशा की तरह unit tests लिखें, 4) localstack जैसे tools से machine पर staging environment को emulate करें—इतने सारे options मौजूद हैं कि इतनी बुरी experience क्यों हुई, यह समझ नहीं आता
  • यह दावा तथ्यों से काफ़ी दूर है
• मुझे लगता है ‘serverless’ नाम ही Orwellian है, क्योंकि यह मूलतः server-based systems को ही ढक-छिपाकर पेश करता है
• यह विश्वास करना मुश्किल है कि ये companies 1TB bandwidth के लिए $550 तक लेती हैं। अगर आप guaranteed 10Gb/s port वाला server किराए पर लें, तब भी अगर प्रति TB $3 से ज़्यादा पड़े तो मैं उसे ठगी मानूँगा। समझ नहीं आता कि serverless इस लागत को 150 गुना तक कैसे सही ठहरा सकता है। क्या सचमुच इतने लोग इस pricing को मान लेते हैं? सिर्फ $10 के VPS या GitHub Pages पर भी reading wiki/tech docs/blog जैसी चीज़ें बिना किसी समस्या के चल सकती हैं, और थोड़ी-सी ठीक setup हो तो 10,000 concurrent users भी आराम से संभाले जा सकते हैं

[benjamin]

अब जो लोग पहली बार development में उतर रहे हैं, वे जब AI के जरिए कुछ बनाते हैं, तो क्या ज़्यादातर लोग Vercel, Supabase जैसी चीज़ों पर ही अपनी service चलाते नहीं होंगे?

लेकिन जब service बड़ी होने लगती है, तब इन्हें चुकानी पड़ने वाली कीमत का लोग शायद ठीक से हिसाब नहीं लगाते।
सोचते हैं कि उस समय आने पर देख लेंगे।

Vercel या Supabase के founders शायद खिलखिलाकर यही कहते हुए हामी भरेंगे, “हाँ हाँ, तब सोच लेना!”

बिल्कुल, उस समय आने पर सोचा जा सकता है। अगर आपके पास जल्दी निकल आने की क्षमता हो, तो।
लेकिन computer science की समझ के बिना यह आसान नहीं होगा।
जो पैसे आपने अभी-अभी कमाने शुरू किए हैं, वे सब उनके हाथ में जाते हुए दिख सकते हैं।

असल में, अभी यही हो रहा है।
यानी… computer science के बारे में बिल्कुल कुछ न जानने वाले newbies के पैसे लेने वाला एक बड़ा business खुल रहा है।

यही वजह है कि computer science को गहराई से पढ़ते रहना चाहिए।
कोई व्यक्ति मुश्किल से revenue देना शुरू करने वाली service पर हर महीने 10 लाख won खर्च करता है, जबकि कोई दूसरा बिना एक पैसा दिए service चलाता है।
operating cost कम करना भी एक skill है। क्या यह बहुत बड़ा competitive advantage नहीं है?
AI से coding करके कुछ बनाना और उसमें मज़ा महसूस करना अच्छी बात है, लेकिन अगर आप और गहराई में जाने की कोशिश नहीं करेंगे, तो आखिरकार आप कोई फर्क पैदा नहीं कर पाएंगे।

https://jeho.page/essay/2025/09/08/sucker-developer.html