Amazon S3
वेब सर्वर की जगह
ऑब्जेक्ट स्टोरेज जो सीधे HTTP का जवाब देता है। बनी हुई साइट एक बकेट में कॉपी होती है और वहीं से परोसी जाती है। कुछ चलता नहीं; फ़ाइलें लौटा दी जाती हैं।
प्रति GB संग्रहण और प्रति अनुरोध बिल
केस स्टडीज़ तकनीकी
AWS सर्वरलेस आर्किटेक्चर, सबूत के साथ
सर्वरलेस की ज़्यादातर व्याख्याएँ आरेख पर ही रुक जाती हैं। यह व्याख्या उस तंत्र तक जाती है जिसे आप खुद टटोल सकते हैं: वही वेबसाइट जिस पर आप हैं। नीचे दिया हर आँकड़ा, हर सेवा और हर निर्णय वही है जो सचमुच प्रोडक्शन में है — वे हिस्से भी जो हमसे पहले ग़लत हुए।
01
सर्वरलेस असल में है क्या
सर्वर अब भी हैं। बस वे आपके नहीं हैं। जो बदलता है वह है वह इकाई जो आप किराए पर लेते हैं और जिसके बारे में सोचते हैं: पूरे महीने चलने वाली मशीन के बजाय, आप एक फ़ंक्शन के एक निष्पादन को किराए पर लेते हैं, और बिल उन्हीं मिलीसेकंडों का बनता है जितनी देर वह जागा रहा।
यह एक बदलाव अपने पीछे बहुत कुछ खींच लाता है। पैच करने के लिए कोई ऑपरेटिंग सिस्टम नहीं, क्योंकि आपके पास कोई है ही नहीं। क्षमता की योजना बनाने की ज़रूरत नहीं, क्योंकि कोई तय क्षमता है ही नहीं — एक हज़ार एक साथ आए अनुरोध एक हज़ार प्रतियाँ शुरू कर देते हैं। और ख़ाली बैठने का कोई ख़र्च नहीं, क्योंकि दो अनुरोधों के बीच आपका कुछ है ही नहीं।
आप क्या छोड़ते हैं
अच्छी बातों से पहले यह कहना ज़रूरी है। मशीन आपके हाथ से जाती है, इसलिए जो भी चीज़ लंबे समय चलने वाली प्रक्रिया, स्थानीय डिस्क या स्थिर IP चाहती है, उस पर दोबारा सोचना पड़ता है। शांत समय के बाद का पहला अनुरोध धीमा होता है। आपका आर्किटेक्चर दूसरे क्लाउड पर ले जाना कठिन हो जाता है। और डिबगिंग “ssh करके देख लो” से हटकर लॉग और ट्रेस पढ़ने में बदल जाती है, जो एक अलग कौशल है।
02
इसमें कौन-सी सेवाएँ लगती हैं
सर्वरलेस स्टैक इंस्टॉल नहीं किया जाता, जोड़ा जाता है। ये वे हिस्से हैं जो यह साइट इस्तेमाल करती है, हर एक किसकी जगह लेता है, और आप किसका भुगतान करते हैं।
AWS Lambda
एप्लिकेशन सर्वर की जगह
माँग पर एक फ़ंक्शन चलाता है, ऐसे कंटेनर में जिसे AWS शुरू करता और नष्ट करता है। आप कोड और मेमोरी का आकार देते हैं; उसके नीचे का सब कुछ AWS देता है।
प्रति मिलीसेकंड × मेमोरी बिल
Lambda Function URL
API गेटवे की जगह
एक HTTPS एंडपॉइंट, सीधे फ़ंक्शन से जुड़ा हुआ, अपनी CORS सेटिंग के साथ। एक अकेले एंडपॉइंट के लिए यह आरेख से एक पूरी सेवा हटा देता है।
कोई अतिरिक्त शुल्क नहीं
Amazon DynamoDB
डेटाबेस सर्वर की जगह
एक प्रबंधित की-वैल्यू स्टोर, जिसमें आकार तय करने के लिए कोई इंस्टेंस नहीं। किसी पंक्ति पर समय-सीमा लगाइए और वह अवधि पूरी होते ही खुद मिट जाती है।
प्रति रीड, राइट और GB बिल
Amazon SNS
मेल सर्वर की जगह
किसी विषय पर संदेश प्रकाशित कीजिए और उससे जुड़े सभी लोगों को सूचना मिल जाती है। पूछताछ की सूचना के लिए पूरी ज़रूरत बस इतनी ही है।
प्रति संदेश बिल
OIDC के साथ IAM
संग्रहीत क्रेडेंशियल की जगह
तैनाती पाइपलाइन GitHub से मिले अल्पकालिक टोकन से अपनी पहचान साबित करती है और एक भूमिका ले लेती है। लीक होने के लिए कोई AWS एक्सेस कुंजी है ही नहीं।
कोई शुल्क नहीं
यहाँ इस्तेमाल नहीं हुईं, पर इसी परिवार की हैं और जानने लायक़ हैं: API Gateway, जब कई रूट, प्राधिकरण या थ्रॉटलिंग चाहिए; Step Functions, जब काम कई फ़ंक्शनों में फैला हो; EventBridge, शेड्यूलिंग और फ़ैन-आउट के लिए; CloudFront, जब S3 के आगे CDN और अपना प्रमाणपत्र चाहिए।
03
एक अनुरोध, शुरू से अंत तक
इस साइट पर संपर्क फ़ॉर्म भरकर जब आप Send दबाते हैं, तब यह होता है।
-
पन्ने स्टोरेज से आते हैं
साइट स्टैटिक फ़ाइलों में बनती है और एक S3 बकेट में सिंक हो जाती है। S3 खुद अनुरोध का जवाब देता है। इसके आगे कोई प्रोसेस नहीं जिसकी मेमोरी ख़त्म हो, कोई कनेक्शन पूल नहीं, और ऐसा कुछ नहीं जो न्यूज़लेटर जाते ही गिर पड़े।
-
आप Send दबाते हैं
ब्राउज़र Function URL पर JSON भेजता है। इस क्षण तक दुनिया में कहीं भी हमारा कोई कंप्यूट नहीं चल रहा होता — न ख़ाली बैठा, न शून्य तक घटा हुआ, बस अनुपस्थित।
-
AWS एक कंटेनर शुरू करता है
वह फ़ंक्शन का कोड लाता है, एक रनटाइम शुरू करता है, और हैंडलर को बुलाता है। गर्म कंटेनर पर वह सीधे हैंडलर पर चला जाता है। दोनों ही हालत में फ़ंक्शन JavaScript की एक फ़ाइल है, जिसके नीचे कोई फ़्रेमवर्क नहीं।
-
फ़ंक्शन तय करता है कि यह कोई व्यक्ति है या नहीं
तीन सस्ती जाँचें, क्रम से: एक छिपा हुआ खाना जिसे केवल कोई स्वचालित फ़ॉर्म भरने वाला ही भरेगा, पन्ना बनने और फ़ॉर्म भेजे जाने के समय की तुलना, और उसी टेबल में रखी हर IP की गिनती। कोई भी बॉट इनमें से कम-से-कम एक में पकड़ा जाता है।
-
वह लिखता है, बताता है, और जवाब देता है
पूछताछ DynamoDB में जाती है, पंक्ति पर समाप्ति की मुहर लगी होती है, सूचना SNS को जाती है, और एक छोटा JSON जवाब ब्राउज़र को लौटता है, जो आपको धन्यवाद पन्ने पर भेज देता है। फिर कंटेनर जमा दिया जाता है, और थोड़ी देर बाद हटा दिया जाता है।
04
यह वेबसाइट, विस्तार से
ब्यौरा, ताकि आप दावों को मानने के बजाय परख सकें।
तीन चीज़ें जो हमसे पहले ग़लत हुईं
CORS दो जगह सेट किया गया
हमने CORS को Function URL पर कॉन्फ़िगर किया और साथ ही फ़ंक्शन से भी हेडर लौटाए। तब जवाब में access-control-allow-origin हेडर दो बार चला गया, ब्राउज़रों ने उसे ख़राब मानकर ठुकरा दिया, और फ़ॉर्म पर “Load failed” दिखा — जबकि पूछताछ सहेजी जा चुकी थी और ईमेल भी ठीक-ठाक भेजा जा चुका था। इसका हल है एक ही जगह चुनना। हम URL चुनते हैं।
एक सार्वजनिक एंडपॉइंट जो डरावना लगा
Function URL पन्ने के स्रोत में दिखता है, और आम तौर पर पहली चिंता यही होती है। वह जानबूझकर सार्वजनिक है: वह केवल एक फ़ॉर्म पोस्ट स्वीकार करता है और कुछ नहीं, उसके पास अपनी कोई क्रेडेंशियल नहीं, और उसकी IAM भूमिका ठीक एक टेबल में लिख सकती है और ठीक एक विषय पर प्रकाशित कर सकती है। राज़ पता नहीं है; राज़ यह है कि उस पते को करने की क्या अनुमति है।
एक CAPTCHA जिसकी ज़रूरत नहीं थी
पहली रचना में एक तीसरे पक्ष का CAPTCHA था। इसका मतलब था अनुरोध के रास्ते में एक और विक्रेता, एक और गोपनीयता घोषणा, और हर असली आगंतुक के लिए एक पहेली। हनीपॉट-और-घड़ी वाला तरीक़ा कुछ ख़र्च नहीं करता, किसी को कुछ नहीं बताता, और टिका हुआ है।
05
कोल्ड स्टार्ट, ईमानदारी से
जब कोई कंटेनर गर्म नहीं होता, तो आपका कोड चलने से पहले AWS को एक बनाना पड़ता है। यही कोल्ड स्टार्ट है, और सर्वरलेस पर यही सबसे ज़्यादा उठाई जाने वाली आपत्ति है। यह सच है, और आम तौर पर इसे वही लोग उद्धृत करते हैं जो आपके इस्तेमाल किए जा रहे रनटाइम से अलग किसी रनटाइम की बात कर रहे होते हैं।
असल में इसे तय क्या करता है: भाषा, तैनाती पैकेज का आकार, और क्या फ़ंक्शन को किसी निजी नेटवर्क तक पहुँचना है। बिना VPC जुड़ाव वाला छोटा JavaScript फ़ंक्शन तेज़ सिरे पर है। VPC के भीतर बड़ा Java एप्लिकेशन धीमे सिरे पर है, और इन दोनों की चर्चा अक्सर ऐसे होती है मानो वे एक ही चीज़ हों।
यह भी मायने रखता है कि कोल्ड स्टार्ट कहाँ आकर पड़ता है। इस साइट पर वह केवल फ़ॉर्म भेजे जाने पर ही पड़ सकता है, जब कोई व्यक्ति एक मिनट टाइप कर चुका होता है। अगर वह हर पन्ना खुलने पर पड़ता, तो जवाब अलग होता — और ठीक इसीलिए पन्ने S3 से आते हैं।
अगर आपके कामकाज के लिए कोल्ड स्टार्ट सचमुच मायने रखते हैं
पैकेज छोटा रखिए, ज़रूरत न हो तो VPC से बाहर रहिए, काम को मॉड्यूल स्कोप से हटाकर हैंडलर में लाइए, और अगर रास्ता सचमुच विलंब के प्रति संवेदनशील है, तो प्रोविज़न्ड कंकरेंसी इस्तेमाल कीजिए और गर्म कंटेनरों का भुगतान कीजिए। यह आख़िरी विकल्प एक डायल है, हार नहीं।
06
इसका ख़र्च
हम कोई मासिक आँकड़ा नहीं छापेंगे, क्योंकि आपका आँकड़ा अलग होगा और गढ़ा हुआ आँकड़ा किसी के काम का नहीं। काम की बात बिल की बनावट है।
किराए का सर्वर एक आयत है: हर महीने उतना ही, चाहे हज़ार लोग आए हों या कोई नहीं। सर्वरलेस एक सीढ़ी है जो ज़मीन से शुरू होती है। संपर्क फ़ॉर्म वाली किसी मार्केटिंग साइट के लिए उस सीढ़ी का कंप्यूट वाला हिस्सा ज़मीन से मुश्किल से उठता है, क्योंकि कंप्यूट तभी चलता है जब कोई आपको लिखता है।
ईमानदार जवाबी तर्क: लगातार ऊँचे आयतन पर, हमेशा व्यस्त रहने वाला फ़ंक्शन वही काम करने वाले हमेशा व्यस्त सर्वर से महँगा पड़ता है। एक बिंदु आता है जहाँ दोनों मिलते हैं। उससे नीचे आप ख़ाली बैठने का भुगतान कर रहे होते हैं; उससे ऊपर आप कुछ भी न चलाने की सुविधा का अतिरिक्त दे रहे होते हैं। आपका ट्रैफ़िक उस रेखा पर मोटे तौर पर कहाँ बैठता है, यह जान लेना ही अधिकांश निर्णय है।
07
इसे तैनात करना
मेन ब्रांच पर एक पुश से GitHub Actions का रन शुरू होता है। रन GitHub से एक अल्पकालिक पहचान टोकन माँगता है, उसे AWS को देता है, और AWS बदले में इसी एक काम तक सीमित भूमिका के लिए अस्थायी क्रेडेंशियल लौटाता है। फिर वह साइट बनाता है और नतीजा S3 पर सिंक कर देता है।
बीच के उस क़दम का मतलब यह है कि GitHub में कहीं भी कोई AWS एक्सेस कुंजी मौजूद नहीं है। घुमाने के लिए कोई गुप्त बात नहीं, लॉग में लीक होने के लिए कोई कुंजी नहीं, और रिपॉज़िटरी तक पढ़ने की पहुँच पाने वाले के लिए कुछ भी काम का नहीं।
08
सर्वरलेस कब ग़लत जवाब है
हम यह आपको अभी बताना पसंद करेंगे, माइग्रेशन के बीच में नहीं।
- स्थिर, भारी, पूर्वानुमेय भार। अगर काम कभी रुकता ही नहीं, तो आप उस लचीलेपन के लिए अतिरिक्त दे रहे हैं जिसका आप उपयोग ही नहीं कर रहे।
- लंबे चलने वाले काम। फ़ंक्शन की निष्पादन सीमा तय होती है। घंटों चलने वाला काम कंटेनर या बैच सेवा में होना चाहिए।
- एक अंक के मिलीसेकंड वाली विलंब सीमाएँ। ट्रेडिंग के रास्ते और वैसे ही तंत्र ऐसी गर्म प्रक्रिया चाहते हैं जो आपके नियंत्रण में हो।
- भारी, बार-बार बोलने वाला डेटाबेस काम। किसी पारंपरिक रिलेशनल डेटाबेस के सामने बहुत से अल्पजीवी फ़ंक्शनों को कनेक्शन पूलिंग चाहिए, जिसके बारे में आप वरना सोचते ही नहीं।
- ऐसा सॉफ़्टवेयर जो आपने नहीं लिखा। जो लाइसेंस वाला एप्लिकेशन एक होस्ट की अपेक्षा करता है, वह आपके चाहने भर से फ़ंक्शन नहीं बन जाएगा।
- पोर्टेबल बने रहने की सख़्त शर्त। सर्वरलेस आपको किसी प्रदाता की बुनियादी इकाइयों से कंटेनरों की तुलना में कहीं कसकर बाँधता है। यह सौदा स्वीकार्य हो सकता है — पर यह एक निर्णय होना चाहिए, कोई अचंभा नहीं।
अपने स्टैक के लिए यह सोच रहे हैं?
हम यह बैंकों, NBFC, वेल्थ मैनेजरों और फिनटेक के लिए बनाते और चलाते हैं — उन हिस्सों सहित जो सर्वरलेस हो ही नहीं सकते। बताइए आज आप क्या चला रहे हैं, और हम ईमानदारी से बताएँगे कि कौन-से हिस्से हटाने लायक़ हैं।