सबने कहा serverless अपनाओ। हमने वह Kubernetes क्लस्टर बनाए रखा जो ज़्यादातर समय खाली पड़ा रहता है

यह सलाह हर जगह है और यह स्पष्ट रूप से सही लगती है। आप ऐसे टेनेंट्स के लिए ऑथेंटिकेशन चलाते हैं जिनका ट्रैफ़िक ऊबड़-खाबड़ है। आप एक Kubernetes क्लस्टर के लिए चौबीसों घंटे पैसे देते हैं। Azure Container Apps आपको शून्य तक स्केल कर देगा और सिर्फ़ उतना ही बिल लेगा जितना आप इस्तेमाल करते हैं। खाली पड़े रहने के पैसे देना बंद करो।

हमने इसे गंभीरता से लिया। हमने Azure Container Apps पर माइग्रेट करने की लागत निकाली, ध्यान से देखा कि इससे हमें क्या मिलेगा, और AKS पर ही टिके रहे। यहाँ वह तर्क है, क्योंकि यह वह तर्क नहीं है जिसका अंदाज़ा आप क्लस्टर के उपयोग-ग्राफ़ से लगाते।

सलाह सही है, बस एक ऐसे वर्कलोड के लिए जो हमारे पास नहीं है

Serverless कंटेनर स्टेटलेस, झोंकेदार रिक्वेस्ट हैंडलिंग के लिए बेहतरीन फ़िट हैं: हर रिक्वेस्ट स्वतंत्र होती है, इंस्टेंस "मवेशी" की तरह हैं, और शून्य ट्रैफ़िक का मतलब शून्य बिल होना चाहिए। यह बहुत सारे वेब बैकएंड का वर्णन करता है।

यह किसी ऑथेंटिकेशन बैकप्लेन का वर्णन नहीं करता। हमारा उस तरह खाली नहीं पड़ा रहता जिस तरह कोई स्टेटलेस ऐप खाली पड़ा रहता है। यह क्लस्टर की लीडरशिप संभालता है और वह कोऑर्डिनेशन लेयर चलाता है जो तय करती है कि कौन-सा रेप्लिका सिंगलटन काम करे, जैसे रिटेंशन स्वीप और webhook पास। (अब हम उस leader को blob lease से चुनते हैं, gossip से नहीं, और वह अपने आप में एक अलग कहानी है।) क्लस्टर का शांत होना इसका मतलब नहीं कि उसके पास करने को कुछ नहीं है; इसका मतलब है कि वह अगले token को वैलिडेट करने और leader बने रहने के लिए तैयार बैठा है। शांत और खाली एक ही अवस्था नहीं हैं।

हमने जगह बदले बिना ही खाली पड़े रहने का बिल खत्म कर दिया

यहाँ वह हिस्सा है जिसने फ़ैसला किया: जिस लागत से हम बचना चाह रहे थे, उसका री-प्लेटफ़ॉर्म करने से कहीं सस्ता हल मौजूद था।

जो चीज़ पैसा सोख रही थी, वह थे ऐसे नोड्स जो 24/7 चलते थे जबकि ट्रैफ़िक काम के घंटों में सिमटा रहता था। तो हमने डेव क्लस्टर को ऐसा बना दिया कि जब कोई इस्तेमाल न करे तो वह संसाधन छोड़ दे (deallocate) (रात भर और सप्ताहांत में बंद, माँग पर वापस चालू) और नोड पूल को एक सस्ती SKU पर बदल दिया। इसने उस ज़्यादातर खाली-खर्च को निकाल बाहर किया जिसे हटाने का वादा serverless कर रहा था, और इसमें हमें एक माइग्रेशन के बजाय बस एक कॉन्फ़िगरेशन बदलाव की कीमत लगी। जब आप जो बचत चाहते हैं वह जगह पर ही हासिल की जा सकती है, तो उसी आँकड़े के पीछे भागने के लिए री-प्लेटफ़ॉर्म करना एक ऐसे अंतर के लिए बहुत बड़ा जोखिम है जिसे आप पहले ही पकड़ चुके हैं।

सबक का सामान्यीकरण हो जाता है: री-प्लेटफ़ॉर्म की कीमत आँकने से पहले हल की कीमत आँकें। "खाली पड़े रहने के पैसे देना बंद करो" एक लक्ष्य है, आर्किटेक्चर नहीं, और उस तक पहुँचने का सबसे सस्ता रास्ता अक्सर एक शेड्यूलर और एक SKU होता है, नया रनटाइम नहीं।

Scale-to-zero एक ऐसे बैकप्लेन से लड़ता है जिसे एक lease पकड़े रखना होता है

लागत को एक तरफ़ रख दें तब भी, scale-to-zero इस वर्कलोड के लिए दो तरह से सक्रिय रूप से गलत है।

पहला, कोल्ड स्टार्ट सबसे ख़राब संभव रास्ते पर आ गिरते हैं। जो रिक्वेस्ट कोल्ड-स्टार्ट का "कर" चुकाती है वह किसी ऐसे व्यक्ति की है जो लॉग इन करने की कोशिश कर रहा है, और "आपका साइन-इन धीमा था क्योंकि हमारी ऑथेंटिकेशन सेवा सो रही थी" ऐसा वाक्य नहीं है जिसे आप भेजना चाहेंगे।

दूसरा, लीडरशिप और scale-to-zero सीधे टकराव में हैं। आप एक ऐसे इंस्टेंस से lease नहीं पकड़े रह सकते जिसे स्केल करके हटा दिया गया है। एक ऐसा बैकप्लेन जिसका पूरा काम हमेशा ठीक एक जीवित leader रखना है, उसे ऐसा रनटाइम नहीं चाहिए जिसका पूरा काम इंस्टेंस को तब हटाना है जब वे शांत दिखें। हम अपने व्यवहार को बचाने के लिए प्लेटफ़ॉर्म के मूल व्यवहार से ही लड़ रहे होते।

वह रनटाइम तीन चीज़ें छीन लेता जिनका हम इस्तेमाल करते हैं

माइग्रेट करना मुफ़्त नहीं है, वहाँ भी नहीं जहाँ यह काम करता है; आपको मैनेज्ड रनटाइम का सैंडबॉक्स विरासत में मिलता है, और हमारा उन चीज़ों को रोकता है जिन पर हम निर्भर हैं:

• Twingate. हम निजी संसाधनों तक एक Twingate कनेक्टर के ज़रिये पहुँचते हैं। मैनेज्ड कंटेनर सैंडबॉक्स इसे नहीं चलाएगा, तो हमें वह निजी नेटवर्क एक्सेस फिर से ईजाद करना पड़ता जो हमारे पास पहले से है।
• हमारा बिल्ड पथ। हमारी पाइपलाइन के हिस्से Docker-in-Docker और एक निजी रजिस्ट्री के विरुद्ध az acr build पर टिके हैं, जिन दोनों को सैंडबॉक्स मना करता है। यह एक पूरा बिल्ड सिस्टम है जिसे दोबारा बनाना पड़ेगा, सिर्फ़ बदलने के लिए एक डिप्लॉय लक्ष्य नहीं।
• क्रॉस-क्लाउड नियंत्रण। हम एक AWS स्टैंडबाय चलाते हैं जो Azure प्राइमरी द्वारा जारी किए गए token को फ़ेडरेटेड JWKS के ज़रिये वैलिडेट करता है, जिसमें Cloudflare फ़ेलओवर का मध्यस्थ है। इसके लिए नेटवर्किंग और प्लेसमेंट का वह नियंत्रण चाहिए जिसे एक मैनेज्ड रनटाइम जानबूझकर छिपा देता है।

इनमें से हर एक एक ऐसा जुगाड़ है जिसे हमें सिर्फ़ वहीं वापस पहुँचने के लिए लिखना पड़ता जहाँ हम पहले से खड़े हैं। माइग्रेशन की असली लागत कटओवर नहीं है; यह हर उस क्षमता को दोबारा कमाना है जिसे सैंडबॉक्स छीन लेता है।

लागत बचत की एक पूँछ होती है, और हमने वह चुकाई

टिके रहना भी परिणामों से मुक्त नहीं है, और यह कहना ही ईमानदारी है। रात में नोड्स deallocate करने ने हमें एक ऐसी विफलता दी जो हमें कभी किसी हमेशा-चालू क्लस्टर पर न दिखती: कोल्ड नोड्स पर पहली इमेज पुल के समय एक token रेस (वही AKS issue 4052 वाली) जो कभी-कभी क्लस्टर वापस चालू होने के बाद ऊपर आ रहे किसी pod को अटका देती थी। हमने इसे एक लंबे रोलआउट टाइमआउट से ठीक किया और, प्रोडक्शन में, उस तरह deallocate न करके जैसे डेव करता है।

यही है इस अदला-बदली का असली आकार। हर रास्ते की विफलता-मोड्स की एक पूँछ होती है; सवाल यह है कि क्या आप उन्हें देख और ठीक कर सकते हैं। AKS पर कोल्ड-नोड रेस को देखा और ठीक किया जा सकता था। जो किस्म की अजीबताएँ आप किसी मैनेज्ड रनटाइम की अंतड़ियों से विरासत में पाते हैं, वे उस तरह की हैं जिनके बारे में आप एक सपोर्ट टिकट खोलकर इंतज़ार करते हैं।

जो नियम हम साथ ले गए

दो बातें, हमसे परे भी दोबारा इस्तेमाल लायक। ऐसी लागत से बचने के लिए माइग्रेट मत कीजिए जिसे आप अपनी जगह पर ही मार सकते हैं; पहले अपनी जगह पर ही हल की कीमत आँकिए, क्योंकि एक शेड्यूलर और एक सस्ती SKU ज़्यादातर मौक़ों पर एक री-प्लेटफ़ॉर्म को हरा देते हैं। और रनटाइम को वर्कलोड के आकार से मिलाइए: serverless स्टेटलेस और झोंकेदार को इनाम देता है और स्टेटफुल और हमेशा-चालू को सज़ा देता है, और एक ऑथेंटिकेशन कोर जो आपकी साइनिंग कुंजियाँ और आपके क्लस्टर की लीडरशिप पकड़े रखता है, वह मज़बूती से दूसरी क़िस्म का है।

हम serverless के ख़िलाफ़ नहीं हैं। हमारी स्टेटलेस सतह का काफ़ी हिस्सा उस पर ठीक रहेगा। लेकिन वह हिस्सा जो आपकी कुंजियाँ पकड़े रखता है और तय करता है कि विध्वंसक काम कौन चलाए, वह उबाऊ, हमेशा-चालू, निरीक्षण-योग्य इन्फ़्रास्ट्रक्चर पर ही चलता रहेगा। कभी-कभी जो क्लस्टर खाली दिखता है वही सस्ता विकल्प होता है, एक बार जब आप वह सब गिन लें जिसे उसे छोड़ने के लिए आपको दोबारा बनाना पड़ता।

आपके लॉगिन के नीचे मौजूद हमेशा-चालू, निरीक्षण-योग्य इन्फ़्रास्ट्रक्चर एक फ़ीचर है, कोई चूक नहीं। जब आप backplane खुद चलाने के बजाय अपना ऑथेंटिकेशन Authagonal पर चलाते हैं, तो आप यही सौंपते हैं।