3.16 API गेटवे और सर्विस मेश

अवलोकन और उद्देश्य

जिस क्षण आप एक प्रोग्राम को कई सेवाओं में विभाजित करते हैं, एक नया प्रश्न सामने आता है: उनके बीच के ट्रैफ़िक और बाहर से आने वाले ट्रैफ़िक का प्रभारी कौन है? आप इस प्रश्न का बुरा उत्तर यह देकर दे सकते हैं कि समान सरोकारों (ऑथेंटिकेशन, रिट्राई, टाइमआउट, रेट लिमिट, लॉगिंग) को हर सेवा में मैन्युअल रूप से बिखेर दें, या आप इन सरोकारों को एक साझा लेयर में डालकर अच्छा उत्तर दे सकते हैं, जिसे हर सेवा मुफ़्त में विरासत में पाती है। यह अध्याय ऐसी ही दो लेयर के बारे में है। एक API गेटवे सामने वाले द्वार पर बैठता है और क्लाइंट से आने वाले ट्रैफ़िक का प्रबंधन करता है। एक सर्विस मेश आपकी सेवाओं के बीच बैठता है और उनके बीच बहने वाले ट्रैफ़िक का प्रबंधन करता है। ये संबंधित समस्याओं को अलग-अलग स्थानों पर हल करते हैं, और दोनों को भ्रमित करना एक सामान्य और महंगी गलती है।

उद्योग ट्रैफ़िक की इन दो दिशाओं को एक दिशा-सूचक (कम्पास) रूपक से नाम देता है। नॉर्थ-साउथ ट्रैफ़िक वह ट्रैफ़िक है जो आपके सिस्टम की सीमा को पार करता है: एक मोबाइल ऐप, एक ब्राउज़र, या कॉल करने वाला कोई पार्टनर। ईस्ट-वेस्ट ट्रैफ़िक वह ट्रैफ़िक है जो आपके सिस्टम के भीतर ही रहता है: एक अनुरोध को पूरा करने के लिए सेवा A, सेवा B को कॉल करती है और सेवा B, सेवा C को। एक API गेटवे नॉर्थ-साउथ के लिए विशेषज्ञ है। एक सर्विस मेश ईस्ट-वेस्ट के लिए विशेषज्ञ है। इस अंतर को स्पष्ट रखना इस अध्याय का सबसे उपयोगी विचार है, क्योंकि यह आपको बताता है कि कौन सा टूल किस नीति का स्वामी है, और यह आपको एक ही काम को दो बार करने से रोकता है।

बड़ी टीमों के लिए, ये लेयर वह तरीका हैं जिनसे आप किसी नीति को सौ बार के बजाय एक बार लागू करते हैं। जब ऑथेंटिकेशन, ट्रांज़िट में एन्क्रिप्शन, और रेट लिमिटिंग एक साझा लेयर में रहते हैं, तो एक सुरक्षा फिक्स उसी दिन हर सेवा तक पहुँच जाता है जिस दिन आप उस लेयर को डिप्लॉय करते हैं, बजाय इसके कि सौ बैकलॉग की प्रतीक्षा करनी पड़े। एंटरप्राइज़ और सरकारी परिवेशों में, यह केंद्रीकरण अक्सर मूल बिंदु होता है: ऑडिटर एक ऐसा एकल, सिद्ध किया जा सकने वाला स्थान चाहते हैं जहाँ एक्सेस की जाँच हो और ट्रैफ़िक एन्क्रिप्ट किया जाए, और एक साझा गेटवे या मेश उन्हें ठीक वही नीति प्रवर्तन बिंदु (policy enforcement point) देता है। यह अध्याय अध्याय 3.2 की आर्किटेक्चरल शैलियों, अध्याय 3.3 की वितरित-सिस्टम वास्तविकताओं, और अध्याय 3.13 की नेटवर्किंग बुनियादी बातों पर निर्मित है, और इन्हें इस बारे में ठोस मार्गदर्शन में बदलता है कि आपके ट्रैफ़िक को कौन संभालता है।

मुख्य सिद्धांत

• नॉर्थ-साउथ (गेटवे) को ईस्ट-वेस्ट (मेश) से अलग रखें; प्रत्येक को अपनी दिशा का स्वामी बनने दें।
• क्रॉस-कटिंग सरोकारों को एक साझा लेयर में डालें ताकि आप उन्हें प्रति सेवा नहीं, बल्कि एक बार लिखें।
• सर्विस मेश तभी अपनाएँ जब सेवाओं की संख्या के कारण प्रति-सेवा वायरिंग करना बड़ी लागत बन जाए।
• प्रत्येक सरोकार के लिए एक ही नीति प्रवर्तन बिंदु परिभाषित करें; कभी भी गेटवे और मेश दोनों को एक ही काम न करने दें।
• सेवाओं को पतला (thin) रखें: प्लेटफ़ॉर्म ट्रांसपोर्ट संभालता है, सेवा बिज़नेस लॉजिक संभालती है।
• नेटवर्क स्थान पर आधारित भरोसे के बजाय पहचान-आधारित, ज़ीरो-ट्रस्ट नेटवर्किंग को प्राथमिकता दें।
• मेश की परिचालन जटिलता को आँखें खुली रखकर स्वीकार करें, और मापें कि क्या यह लाभदायक है।

सिफ़ारिशें

समझें कि एक API गेटवे क्या करता है

एक API गेटवे एक एकल प्रवेश बिंदु है जो आपकी सेवाओं के सामने बैठता है और बाहरी दुनिया से आने वाले हर अनुरोध की मध्यस्थता करता है। अपने सबसे सरल रूप में यह एक स्मार्ट रिवर्स प्रॉक्सी है (एक सर्वर जो क्लाइंट के अनुरोध प्राप्त करता है और उन्हें सही बैकएंड तक आगे भेजता है), लेकिन एक गेटवे केवल आगे भेजने से कहीं अधिक करके अपना नाम सार्थक करता है। यह पाथ, होस्ट, या हेडर के आधार पर प्रत्येक अनुरोध को सही सेवा तक रूट करता है। यह कॉलर को ऑथेंटिकेट करता है (यह सत्यापित करते हुए कि वे कौन हैं) और अनुरोध को ऑथराइज़ करता है (यह जाँचते हुए कि वे क्या कर सकते हैं), ताकि इसके पीछे की सेवा यह भरोसा कर सके कि अनुरोध पहले ही सामने वाले द्वार से गुज़र चुका है। यह रेट लिमिटिंग (समय के साथ प्रति क्लाइंट अनुरोधों को सीमित करना) और कोटा (लंबी अवधि में कुल उपयोग को सीमित करना) लागू करता है ताकि एक शोरगुल वाला या दुरुपयोग करने वाला क्लाइंट बाकियों को भूखा न रख सके।

एक गेटवे ट्रैफ़िक को पुनः आकार भी देता है। अनुरोध रूपांतरण (request transformation) हेडर को फिर से लिखता है, प्रोटोकॉल के बीच अनुवाद करता है, या किसी पुराने क्लाइंट के फ़ॉर्मैट को नई सेवा की अपेक्षाओं के अनुरूप ढालता है। API कंपोज़िशन गेटवे को एक ही इनबाउंड अनुरोध को कई सेवाओं में फैलाने और उनकी प्रतिक्रियाओं को एक में जोड़ने देता है, ताकि क्लाइंट छह कॉल के बजाय एक कॉल करे। वर्ज़निंग समर्थन आपको किसी API के v1 और v2 को साथ-साथ चलाने और प्रत्येक क्लाइंट को उसकी अपेक्षित वर्ज़न पर रूट करने देता है, जो आपको बिना किसी को तोड़े विकसित होने की गुंजाइश देता है। इन सरोकारों को एज पर केंद्रित करना आपकी सेवाओं को बिज़नेस लॉजिक पर केंद्रित रखता है और आपको हर प्रवेश करने वाली चीज़ को देखने, सुरक्षित करने, और थ्रॉटल करने के लिए एक स्थान देता है। जिन API को यह गेटवे फ्रंट करता है, उनका डिज़ाइन अध्याय 2.3 का विषय है, और यह जो पहचान जाँच करता है, वह अध्याय 4.7 पर आधारित है।

भिन्न-भिन्न क्लाइंट के लिए बैकएंड-फॉर-फ्रंटएंड पैटर्न का उपयोग करें

एक ही सामान्य-प्रयोजन API अक्सर एक साथ एक वेब ऐप, एक मोबाइल ऐप, और पार्टनर इंटीग्रेशन की सेवा करता है, और यह इन सबकी सेवा थोड़ा खराब ढंग से करता है। मोबाइल क्लाइंट छोटे पेलोड और कम राउंड ट्रिप चाहता है क्योंकि बैंडविड्थ और बैटरी सीमित हैं; वेब क्लाइंट अधिक बातूनी, समृद्ध प्रतिक्रियाओं को संभाल सकता है; पार्टनर एक स्थिर कॉन्ट्रैक्ट चाहता है जो उसे कभी आश्चर्यचकित न करे। बैकएंड फॉर फ्रंटएंड (BFF) पैटर्न इस तनाव को हल करता है, हर प्रकार के क्लाइंट को उसका अपना पतला गेटवे देकर, जो उस क्लाइंट की ज़रूरतों के अनुरूप तैयार किया गया हो और इसके पीछे की साझा सेवाओं के सामने बैठता हो।

एक BFF एक संकुचित दर्शक वर्ग वाला गेटवे है। मोबाइल BFF प्रतिक्रियाओं को जोड़ता और छाँटता है ताकि ऐप एक कुशल कॉल करे; वेब BFF एक अधिक पूर्ण रूप प्रस्तुत करता है; पार्टनर BFF एक धीमी गति से बदलने वाला, सावधानी से वर्ज़न किया गया कॉन्ट्रैक्ट रखता है। हर टीम बिना दूसरों की प्रतीक्षा किए अपने खुद के BFF को विकसित कर सकती है, जो अक्सर असली फ़ायदा होता है, क्योंकि यह क्लाइंट टीमों को एक-दूसरे से अलग (decouple) कर देता है। इसकी लागत अधिक चलती-फिरती इकाइयाँ (moving parts) और BFF में कुछ डुप्लिकेट लॉजिक है, इसलिए इस पैटर्न को उन मामलों के लिए सुरक्षित रखें जहाँ क्लाइंट की ज़रूरतें वास्तव में भिन्न होती हैं। जब हर क्लाइंट एक ही चीज़ चाहता है, तो एक गेटवे अधिक सरल और बेहतर है।

समझें कि एक सर्विस मेश क्या करता है

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

यह क्या लागू करता है? पहला, म्यूचुअल TLS (mTLS), जिसमें हर कनेक्शन के दोनों पक्ष प्रमाणपत्र प्रस्तुत करते हैं और ट्रैफ़िक को एन्क्रिप्ट करते हैं, ताकि सेवा-से-सेवा कॉल डिफ़ॉल्ट रूप से ऑथेंटिकेटेड और निजी हों। दूसरा, ट्रैफ़िक प्रबंधन: मेश कैनरी रिलीज़ के लिए ट्रैफ़िक के एक छोटे प्रतिशत को नए वर्ज़न पर शिफ्ट कर सकता है, टेस्टिंग के लिए हेडर के आधार पर ट्रैफ़िक को विभाजित कर सकता है, या ट्रैफ़िक को एक शैडो सेवा पर मिरर कर सकता है। तीसरा, रेज़िलिएंस: रिट्राई, टाइमआउट, और सर्किट ब्रेकिंग (अध्याय 2.20 के पैटर्न) को प्लेटफ़ॉर्म लेयर पर लागू किया जाता है, जिन्हें हर सेवा में कोड करने के बजाय नीति द्वारा कॉन्फ़िगर किया जाता है। चौथा, ऑब्ज़र्वेबिलिटी: क्योंकि हर अनुरोध एक प्रॉक्सी से होकर गुज़रता है, मेश सभी सेवा-से-सेवा ट्रैफ़िक के लिए सुसंगत मेट्रिक्स, लॉग, और वितरित ट्रेस उत्सर्जित करता है, जो अध्याय 9.2 की ऑब्ज़र्वेबिलिटी प्रथाओं को आगे बढ़ाते हैं। सेवा का लेखक इनमें से कुछ भी नहीं लिखता और यह सब कुछ पाता है।

साइडकार पैटर्न और साइडकाररहित विकल्पों को जानें

साइडकार मॉडल सुरुचिपूर्ण है लेकिन मुफ़्त नहीं है। अब हर सेवा इंस्टेंस एक अतिरिक्त प्रॉक्सी कंटेनर चलाता है जो मेमोरी और CPU की खपत करता है, और हर कॉल दो अतिरिक्त नेटवर्क हॉप बनाता है (स्थानीय साइडकार में जाना और दूरस्थ वाले से बाहर निकलना), जिससे थोड़ी विलंबता (latency) जुड़ती है। मुट्ठी भर सेवाओं पर यह ओवरहेड अदृश्य होता है; हज़ारों पॉड में यह आपके कंप्यूट बिल और आपके लेटेंसी बजट में एक वास्तविक लाइन आइटम बन जाता है। इस लागत ने साइडकाररहित, या प्रॉक्सीरहित, दृष्टिकोणों की एक लहर को जन्म दिया है।

दो दिशाएँ मायने रखती हैं। एक मेश फ़ंक्शन को प्रति-पॉड साइडकार से हटाकर प्रति-नोड प्रॉक्सी में ले जाती है, ताकि एक ही मशीन पर कई सेवाएँ अपना-अपना अलग प्रॉक्सी चलाने के बजाय एक प्रॉक्सी साझा करें; यह कुछ आइसोलेशन के बदले ओवरहेड में बड़ी गिरावट लाता है। दूसरा, प्रॉक्सीरहित दृष्टिकोण मेश के लॉजिक को एक पतली लाइब्रेरी या रनटाइम के माध्यम से सीधे सेवा में एम्बेड करता है, जो प्रति-भाषा निर्भरता की कीमत पर अतिरिक्त हॉप को पूरी तरह हटा देता है। एक नया विकास eBPF का उपयोग करके कुछ मेश फ़ंक्शन को ऑपरेटिंग सिस्टम कर्नेल में धकेलता है (लिनक्स कर्नेल के भीतर सैंडबॉक्स्ड प्रोग्राम चलाने की एक तकनीक), जो एक यूज़रस्पेस प्रॉक्सी की तुलना में कम ओवरहेड के साथ नीति लागू कर सकता है और टेलीमेट्री एकत्र कर सकता है। आपको आज ही एक विजेता पर दांव लगाने की ज़रूरत नहीं है। आपको यह जानने की ज़रूरत है कि साइडकार टैक्स वास्तविक है, कि विकल्प मौजूद हैं, और कि आपके प्लेटफ़ॉर्म के चुनाव आपको बाद में इन्हें अपनाने से रोकने वाले नहीं होने चाहिए। ये पैटर्न अध्याय 8.3 की कंटेनर ऑर्केस्ट्रेशन नींव पर टिके हैं।

तय करें कि मेश अपनी जटिलता कब अर्जित करता है

एक सर्विस मेश शक्तिशाली है और चलाना वास्तव में जटिल है। यह चलाने के लिए एक कंट्रोल प्लेन, अपग्रेड करने के लिए प्रॉक्सी, घुमाने (rotate) के लिए प्रमाणपत्र, और जब कोई अनुरोध गुम हो जाए तो डीबग करने के लिए एक नई लेयर जोड़ता है। यह जटिलता तब खरीदने लायक है जब आपके पास इतनी सेवाएँ हों कि इन सरोकारों को हाथ से, प्रति सेवा और प्रति भाषा वायर करना, मेश चलाने से अधिक महंगा पड़े। मोटा संकेत यह है: स्केल और बहुभाषी (polyglot) विविधता , दर्जनों या सैकड़ों सेवाएँ, कई भाषाओं में लिखी गई, जहाँ mTLS और रिट्राई के लिए एक साझा लाइब्रेरी को सुसंगत रखना एक दुःस्वप्न होगा। उस स्केल पर, एक मेश समरूपता (uniformity) और सिद्ध किए जा सकने वाली सुरक्षा में अपनी कीमत वसूल कर लेता है।

जब आपके पास मुट्ठी भर सेवाएँ, एक ही भाषा, या एक छोटी टीम हो, तो मेश अपनी जटिलता अर्जित नहीं करता। एक साधारण सिस्टम के लिए, एक अच्छी लाइब्रेरी या फ्रेमवर्क आपको एक पूर्ण मेश की तुलना में कहीं कम परिचालन बोझ के साथ mTLS, रिट्राई, और मेट्रिक्स दे सकता है, और एक साधारण गेटवे प्लस समझदार क्लाइंट लाइब्रेरी अक्सर आपकी सभी ज़रूरतें पूरी कर देती है। अपने स्केल की माँग से पहले, केवल इसलिए मेश अपनाना क्योंकि यह प्रचलन में है, एक साल तक ऐसे इन्फ्रास्ट्रक्चर को चलाने में खर्च करने का एक आम तरीका है जो उस समस्या को हल करता है जो आपके पास है ही नहीं। गेटवे से शुरुआत करें, कोड या लाइब्रेरी में रेज़िलिएंस पैटर्न जोड़ें, और मेश तक तब पहुँचें जब सेवाओं और भाषाओं की संख्या प्रति-सेवा दृष्टिकोण को अधिक महंगा बना दे। यह वही “क्या यह अपनी जटिलता अर्जित करता है” वाला अनुशासन है जिस पर क्लाउड और वितरित-सिस्टम अध्याय (3.11 और 3.3) बार-बार लौटते हैं।

जहाँ गेटवे और मेश ओवरलैप करते हैं, वहाँ दोहरे प्रबंधन से बचें

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

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

गेटवे और मेश को ज़ीरो ट्रस्ट के लिए नीति प्रवर्तन बिंदु मानें

इन लेयर को चलाने का सबसे गहरा कारण सुरक्षा आर्किटेक्चर है। ज़ीरो ट्रस्ट यह सिद्धांत है कि किसी अनुरोध पर इसलिए भरोसा नहीं किया जाता कि वह कहाँ से आया है; हर अनुरोध को अपनी पहचान और अपना प्राधिकरण सिद्ध करना होगा, यहाँ तक कि आपके अपने नेटवर्क के भीतर भी। पुराना मॉडल पहले से ही परिधि (perimeter) के भीतर मौजूद किसी भी चीज़ पर भरोसा करता था, जिसका अर्थ था कि एक भंग की गई सेवा स्वतंत्र रूप से घूम सकती थी। ज़ीरो ट्रस्ट नेटवर्क-स्थान के भरोसे को हर हॉप पर पहचान-आधारित भरोसे से बदल देता है, और गेटवे तथा मेश वे स्वाभाविक प्रवर्तन बिंदु हैं जहाँ वह पहचान जाँची जाती है।

गेटवे बाहरी पहचान के लिए नीति प्रवर्तन बिंदु है: यह किसी भी चीज़ के आपकी सेवाओं तक पहुँचने से पहले एंड यूज़र या पार्टनर को सत्यापित करता है। मेश वर्कलोड पहचान के लिए नीति प्रवर्तन बिंदु है: हर सेवा को एक क्रिप्टोग्राफ़िक पहचान मिलती है, mTLS हर कॉल पर उसे सिद्ध करता है, और नीति तय करती है कि कौन सी सेवा किससे बात कर सकती है। साथ में वे आपको गहराई में रक्षा (defence in depth) देते हैं, जहाँ किसी अनुरोध की जाँच एज पर होती है और फिर सेवाओं के बीच फिर से होती है, ताकि एक सेवा का समझौता (compromise) बाकियों को मुक्त आवाजाही न दे दे। बहु-क्लस्टर और बहु-क्षेत्र डिप्लॉयमेंट में, एक मेश इस पहचान फैब्रिक को क्लस्टर सीमाओं के पार बढ़ा सकता है, ताकि एक क्लस्टर की सेवा दूसरे क्लस्टर की सेवा को उन्हीं mTLS गारंटियों के साथ ऑथेंटिकेट करे जिनका वह स्थानीय रूप से उपयोग करती है, जिससे फुटप्रिंट फैलने पर भी आपको सुसंगत ज़ीरो-ट्रस्ट नेटवर्किंग मिलती है। यहाँ की पहचान नींव सीधे अध्याय 4.7 से जुड़ती है।

ट्रेड-ऑफ़: लाभ और हानि

दृष्टिकोण	लाभ	हानि
API गेटवे	ऑथेंटिकेशन, रेट लिमिट, कंपोज़िशन, वर्ज़निंग के लिए एक स्थान	स्केल करने और उच्च उपलब्धता बनाए रखने के लिए एक ही चोक पॉइंट
बैकएंड फॉर फ्रंटएंड	हर क्लाइंट को एक अनुकूलित, स्वतंत्र रूप से विकसित होने वाला API मिलता है	चलाने के लिए अधिक गेटवे; BFF में लॉजिक डुप्लिकेट
सर्विस मेश (साइडकार)	बिना कोड बदले समान mTLS, रिट्राई, ऑब्ज़र्वेबिलिटी	प्रॉक्सी ओवरहेड, लेटेंसी, और चलाने के लिए एक कंट्रोल प्लेन
साइडकाररहित / प्रॉक्सीरहित मेश	प्रति-पॉड साइडकार की तुलना में कम ओवरहेड और लेटेंसी	कम परिपक्व; कमज़ोर आइसोलेशन या प्रति-भाषा निर्भरता
लाइब्रेरी-आधारित रेज़िलिएंस	चलाना सरल; कोई अतिरिक्त इन्फ्रास्ट्रक्चर नहीं	प्रति-भाषा डुप्लिकेशन; स्केल पर सुसंगत रखना कठिन
क्लस्टर के पार मेश	हर जगह सुसंगत ज़ीरो-ट्रस्ट पहचान	महत्वपूर्ण परिचालन और नेटवर्किंग जटिलता

केंद्रीय तनाव है समरूपता बनाम परिचालन लागत। एक साझा लेयर आपको सुसंगति, सिद्ध की जा सकने वाली सुरक्षा, और एक बार लिखी जाने वाली नीति देती है, लेकिन यह एक वास्तविक सिस्टम है जिसे आपको चलाना, स्केल करना, सुरक्षित करना, और डीबग करना पड़ता है, और यह खुद को हर अनुरोध के रास्ते में डाल देती है। इस तनाव को स्केल और ज़रूरत के आधार पर हल करें। एक गेटवे लगभग हमेशा तभी लाभदायक हो जाता है जब आपके पास बाहरी क्लाइंट होते हैं, क्योंकि जिन सरोकारों को यह केंद्रीकृत करता है वे ऐसे हैं जिनसे आप बच नहीं सकते। एक मेश बाद में लाभदायक होता है, जब सेवाओं और भाषाओं की संख्या प्रति-सेवा वायरिंग को अधिक महंगा रास्ता बना देती है। उस सीमा से नीचे, लाइब्रेरी और एक साधारण गेटवे लागत के एक अंश में अधिकांश लाभ दे देते हैं। उसके ऊपर, मेश की समरूपता अपनी कीमत के लायक है। दोनों दिशाओं में गलती है ज़रूरत के बजाय प्रचलन के आधार पर अपनाना: बहुत जल्दी अपनाया गया मेश एक साल की व्यर्थ मशक्कत है, और बहुत देर से छोड़ा गया मेश mTLS के सौ असंगत, हाथ से बनाए गए कार्यान्वयन हैं।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. हर क्रॉस-कटिंग सरोकार (ऑथेंटिकेशन, रिट्राई, टाइमआउट, रेट लिमिटिंग, एन्क्रिप्शन, टेलीमेट्री) के लिए, कौन सी एक लेयर उसकी स्वामी है, और क्या हर कोई बिना अंदाज़ा लगाए उस स्वामी का नाम बता सकता है? यह वह प्रश्न है जो दोहरे प्रबंधन को रोकता है, और अधिकांश टीमों ने इसका स्पष्ट उत्तर कभी नहीं दिया है, जिसका अर्थ है कि उत्तर सेवा और लेखक के अनुसार अलग-अलग होता है। सरोकारों की एक ठोस सूची बाईं ओर और अपनी लेयर (क्लाइंट लाइब्रेरी, गेटवे, मेश, व्यक्तिगत सेवा) को ऊपर रखें, और साथ मिलकर ग्रिड भरें। जिन स्थानों पर एक सरोकार के लिए दो सेल चेक की गई हैं, वे आपके होने वाले रिट्राई तूफान और टाइमआउट व्युत्क्रमण (inversion) हैं। खाली पंक्तियाँ वे सरोकार हैं जिन्हें कोई भी बिलकुल नहीं संभाल रहा है। डिलिवरेबल एक ऐसी सहमत तालिका है, जो वहाँ प्रकाशित हो जहाँ हर टीम उसे देख सके, जो यह बताती है कि हर सरोकार का स्वामी ठीक एक लेयर है और बाकी पास-थ्रू करते हैं। वह तालिका किसी भी मात्रा की गेटवे या मेश कॉन्फ़िगरेशन से अधिक मूल्यवान है, क्योंकि यह वही चीज़ है जो दोनों लेयर को एक-दूसरे से लड़ने से रोकती है।

2. क्या हमारे पास वास्तव में सर्विस मेश को उचित ठहराने के लिए पर्याप्त सेवाएँ और भाषा विविधता है, या हम एक ऐसी समस्या को हल करने के लिए कंट्रोल प्लेन खरीदने वाले हैं जो हमारे पास है ही नहीं? एक मेश एक गंभीर परिचालन प्रतिबद्धता है, और कई टीमों के लिए ईमानदार उत्तर यह है कि एक अच्छी लाइब्रेरी प्लस एक गेटवे आज उनकी बेहतर सेवा करेगा। अपनी सेवाओं की वास्तविक संख्या, उन्हें जिन भाषाओं में लिखा गया है उनकी संख्या, और यह ईमानदार आकलन लाएँ कि डुप्लिकेट नेटवर्किंग लॉजिक अभी वास्तव में आपको कितना नुकसान पहुँचा रहा है। फिर दूसरा पक्ष लाएँ: मेश को कौन चलाएगा, उसके प्रॉक्सी को कौन अपग्रेड करेगा, उसके प्रमाणपत्रों को कौन घुमाएगा, और जब यह किसी अनुरोध को गलत रूट करे तो किसे पेज किया जाएगा। यदि प्रति-सेवा वायरिंग की पीड़ा मेश चलाने की लागत से छोटी है, तो आपके पास आपका उत्तर है, और वह है प्रतीक्षा करना। यदि आप दर्जनों बहुभाषी सेवाओं में असंगत mTLS और रिट्राई कोड में डूबे हुए हैं, तो मेश अपनी कीमत वसूल कर लेता है। मुद्दा यह है कि प्रमाण के आधार पर निर्णय लें, न कि किसी कॉन्फ़्रेंस टॉक ने मेश को जैसा दिखाया उसके आधार पर।

3. आज हमारी ज़ीरो-ट्रस्ट सीमा कहाँ है, और यदि कोई आंतरिक सेवा समझौता कर ली जाए तो क्या होता है? कई सिस्टम अभी भी नेटवर्क के भीतर मौजूद किसी भी चीज़ पर भरोसा करते हैं, जिसका अर्थ है कि एक भंग की गई सेवा पार्श्व रूप से (laterally) आगे बढ़ सकती है और बाकी सब कुछ तक पहुँच सकती है, और टीमों को अक्सर इसका पता केवल किसी घटना के दौरान चलता है। ब्लास्ट रेडियस को ईमानदारी से समझें: यदि कोई हमलावर आपकी किसी सेवा पर कब्ज़ा कर ले, तो वह क्या कॉल कर सकता है, क्या पढ़ सकता है, और उसे क्या रोकता है? यह लाएँ कि सेवा-से-सेवा कॉल को कैसे ऑथेंटिकेट और एन्क्रिप्ट किया जाता है, इसका आपका वर्तमान उत्तर, और यह विशिष्ट रूप से बताएँ कि कौन सी कॉल mTLS द्वारा सुरक्षित हैं और कौन सी एक ही नेटवर्क पर होने के आधार पर प्लेनटेक्स्ट भरोसे पर हैं। जो कार्रवाई इसके बाद होती है वह हर हॉप पर पहचान-आधारित एक्सेस के लिए एक सुविचारित योजना है, जिसमें गेटवे बाहरी पहचान जाँचता है और मेश या उसके समकक्ष वर्कलोड पहचान जाँचता है, ताकि एक समझौता विनाशकारी होने के बजाय सीमित रहे। भले ही आप एक पूर्ण मेश चलाने के लिए तैयार न हों, यह बताना कि भरोसे की सीमा वास्तव में कहाँ है, पहला ईमानदार कदम है।

4. यदि हमारी API गेटवे टियर अभी विफल हो जाए, तो सिस्टम का कितना हिस्सा अंधेरे में चला जाएगा, और क्या हमने उस विफलता को टेस्ट किया है, या केवल यह मान लिया है कि ऐसा नहीं होगा? गेटवे इतना कुछ केंद्रीकृत करता है कि उसका आउटेज इसके पीछे की हर चीज़ को ऑफ़लाइन कर देता है, और बड़ी टीमें उसकी रिडंडेंसी में कम निवेश करने की प्रवृत्ति रखती हैं, ठीक इसलिए क्योंकि यह चुपचाप काम करता रहता है जब तक कि वह न रुके। प्रतिस्पर्धी खिंचावों को तौलें: एक एकल साधारण गेटवे के बारे में सोचना आसान है और चलाना सस्ता है, जबकि एक क्षैतिज रूप से स्केल की गई, बहु-ज़ोन टियर अधिक खर्च करती है और अपना खुद का फेलओवर कॉन्फ़िगरेशन और जटिलता जोड़ती है। चर्चा में वास्तविक आंकड़े लाएँ, जिनमें यह शामिल हो कि आज कितने इंस्टेंस चल रहे हैं, कितने उपलब्धता क्षेत्रों (availability zones) में, फेलओवर समय क्या है, और आपने आखिरी बार जानबूझकर गेटवे को मारने वाला गेम डे कब चलाया था। ऐसे एंटरप्राइज़ और सरकारी प्लेटफ़ॉर्म के लिए जो अपटाइम प्रतिबद्धताएँ या वैधानिक सर्विस लेवल वहन करते हैं, आउटेज के लिए अनुबंधात्मक या नियामक दंड भी जोड़ें, क्योंकि बिना रिडंडेंसी वाला सामने का द्वार एक उपलब्धता जोखिम है जिसे आपने इसके पीछे की हर सेवा और हर नागरिक की ओर से चुपचाप स्वीकार कर लिया है।

5. क्या हमने वह साइडकार टैक्स मापा है जो हमारा मेश वास्तव में वसूल करता है, और क्या हमारे पास साइडकाररहित और eBPF विकल्पों की योजना है, या हम इसे अंधेरे में चुका रहे हैं? स्केल पर, कंप्यूट और लेटेंसी में प्रति-पॉड प्रॉक्सी ओवरहेड अदृश्य नहीं रहता और बजट में एक वास्तविक लाइन बन जाता है, फिर भी कई टीमें कभी भी लागत मापे बिना हज़ारों साइडकार चलाती हैं। तनाव यह है: एक ओर साइडकार मॉडल की परिपक्वता और आइसोलेशन, दूसरी ओर प्रति-नोड प्रॉक्सी, प्रॉक्सीरहित लाइब्रेरी, या कर्नेल eBPF दृष्टिकोणों का कम ओवरहेड, जो नए हैं और कुछ आइसोलेशन खो देते हैं या प्रति-भाषा निर्भरता जोड़ देते हैं। मापे गए आंकड़े लाएँ: पूरे फ्लीट में प्रॉक्सी द्वारा खपत की गई मेमोरी और CPU, प्रति हॉप जुड़ी हुई टेल लेटेंसी, और आपके कंप्यूट बिल का कितना हिस्सा मेश दर्शाता है। हज़ारों पॉड में मेश चलाने वाले एक बड़े एंटरप्राइज़ के लिए, या बजट जाँच के दायरे में आने वाले सरकारी प्लेटफ़ॉर्म के लिए, यह एक खर्च का निर्णय है जिसके बारे में निगरानी करने वाले आखिरकार पूछेंगे, इसलिए यह जानना कि टैक्स क्या है और क्या आपके प्लेटफ़ॉर्म के चुनाव सस्ते विकल्पों को खुला रखते हैं, बुनियादी सावधानी है।

6. क्या हर क्लाइंट वर्ग को वास्तव में अपने खुद के बैकएंड फॉर फ्रंटएंड की ज़रूरत है, या हम उन क्लाइंट के लिए गेटवे में लॉजिक डुप्लिकेट करने वाले हैं जो वास्तव में एक ही चीज़ चाहते हैं? BFF पैटर्न क्लाइंट टीमों को अलग (decouple) करता है और हर एक को एक अनुकूलित कॉन्ट्रैक्ट विकसित करने देता है, लेकिन हर नया BFF चलाने, सुरक्षित करने, और सिंक में रखने के लिए एक और गेटवे है, और उनमें डुप्लिकेट लॉजिक चुपचाप एक रखरखाव टैक्स बन जाता है। प्रतिस्पर्धी विचार हैं टीम की स्वायत्तता और क्लाइंट-विशिष्ट दक्षता बनाम कई लगभग-समान गेटवे की परिचालन लागत और बहाव (drift)। यह प्रमाण लाएँ कि क्लाइंट की ज़रूरतें वास्तव में कितनी भिन्न हैं: पेलोड आकार, राउंड-ट्रिप संख्या, वर्ज़निंग की गति, और एक साझा गेटवे के तहत एक क्लाइंट के बदलाव ने कितनी बार दूसरे को रोका होगा। कई क्लाइंट टीमों वाले एक बड़े संगठन में, या एक साथ एक सार्वजनिक वेब ऐप, एक मोबाइल ऐप, और पार्टनर इंटीग्रेशन की सेवा करने वाले सरकारी प्लेटफ़ॉर्म में, ईमानदार प्रश्न यह है कि क्या यह भिन्नता प्रसार (proliferation) को उचित ठहराती है, क्योंकि प्रति क्लाइंट एक BFF जो सभी एक ही आकार चाहते हैं, ऐसा फैलाव है जिसे आप वर्षों तक बनाए रखने के लिए भुगतान करेंगे।

क्षेत्रीय दृष्टिकोण

स्टार्टअप। एक API गेटवे शिप करें और मेश को छोड़ दें। मुट्ठी भर सेवाओं और एक छोटी टीम के साथ, एक एकल गेटवे ऑथेंटिकेशन, रेट लिमिट, और कंपोज़िशन को संभालता है, जबकि एक साझा क्लाइंट लाइब्रेरी आपको एक कंट्रोल प्लेन की लागत के एक अंश में mTLS और रिट्राई देती है। आपका सबसे दुर्लभ संसाधन इंजीनियरिंग ध्यान है, इसलिए एक ऐसा मेश जिसे आप चला नहीं सकते, एक खाई (moat) नहीं बल्कि एक देनदारी है। गेटवे को इतना रिडंडेंट रखें कि वह एक नोड के मर जाने पर भी बच सके, और मेश पर तभी पुनर्विचार करें जब सेवाओं की संख्या और भाषा विविधता वास्तव में यह सवाल खड़ा कर दे।

छोटा व्यवसाय। आपके पास मेश चलाने के लिए कोई प्लेटफ़ॉर्म टीम नहीं है, इसलिए अपनी होस्टिंग प्लेटफ़ॉर्म या गेटवे उत्पाद जो कुछ शुरू से ही देता है, उस पर निर्भर रहें: मैनेज्ड TLS, बिल्ट-इन रेट लिमिटिंग, और एक होस्टेड गेटवे, न कि वह जिसे आप खुद पैच करते हैं। इस चुनाव को खरीदने बनाम बनाने के रूप में तैयार करें, और खरीदें, क्योंकि एक मैनेज्ड API गेटवे अपना खुद का चलाने के इंजीनियर-घंटों से कम खर्च करता है। आंतरिक सेवा-से-सेवा एन्क्रिप्शन को एक ऐसी सुविधा मानें जो आपका प्लेटफ़ॉर्म प्रदान करता है, न कि एक ऐसा प्रोजेक्ट जिसके लिए आप स्टाफ़ लगाते हैं।

एंटरप्राइज़। कई टीमों और भाषाओं में सैकड़ों सेवाओं के साथ, एक मेश अपनी जटिलता अर्जित करता है, और असली काम गवर्नेंस है: कार्य का एक लिखित विभाजन ताकि गेटवे और मेश कभी किसी सरोकार को दोहरा न संभालें, समान mTLS और टेलीमेट्री, और एक प्लेटफ़ॉर्म टीम जो प्रॉक्सी अपग्रेड और प्रमाणपत्र रोटेशन की स्वामी हो। ऑडिटर एक्सेस और एन्क्रिप्शन के लिए एक ही सिद्ध किए जा सकने वाला प्रवर्तन बिंदु चाहते हैं, इसलिए इंटरफ़ेस को मानकीकृत करें और नीति को ऐसी चीज़ बनाएँ जिसे टीमें फिर से लागू करने के बजाय विरासत में पाएँ। साइडकार टैक्स को एक वास्तविक बजट लाइन के रूप में प्रबंधित करें, और साइडकाररहित विकल्पों को खुला रखें ताकि आप बाद में सस्ते दृष्टिकोणों से वंचित न रह जाएँ।

सरकार। खरीद (procurement) नियम, पारदर्शिता, और सार्वजनिक जवाबदेही आर्किटेक्चर को आकार देते हैं। गेटवे और मेश को उस ज़ीरो-ट्रस्ट रीढ़ की हड्डी के रूप में मानें जिसकी नियामक अपेक्षा करते हैं: हर नागरिक और पार्टनर सामने वाले द्वार पर ऑथेंटिकेटेड, हर आंतरिक कॉल वर्कलोड पहचान द्वारा ऑथेंटिकेटेड और एन्क्रिप्टेड, और हर प्रवर्तन बिंदु पर एक ऑडिट ट्रेल जो यह सिद्ध करे कि एक्सेस की जाँच कहाँ हुई और ट्रैफ़िक कहाँ एन्क्रिप्ट किया गया। स्वामित्व वाले (proprietary) लॉक-इन के बजाय, जिसे खरीद नियम मना कर सकते हैं, खुले मानकों और पोर्टेबल कॉन्फ़िगरेशन को प्राथमिकता दें, और जहाँ उपयुक्त हो, यह प्रकाशित करें कि प्लेटफ़ॉर्म नागरिक डेटा की सुरक्षा कैसे करता है जब वह हर सीमा को पार करता है।

उदाहरण

स्टार्टअप। एक बारह-व्यक्ति वाला स्टार्टअप एक एकल API गेटवे के पीछे आठ सेवाएँ चलाता है। गेटवे सारा नॉर्थ-साउथ काम संभालता है: यह टोकन जाँच से उपयोगकर्ताओं को ऑथेंटिकेट करता है, प्रति-प्लान रेट लिमिट लागू करता है ताकि फ्री-टियर उपयोगकर्ता सिस्टम को न डुबो दें, और कुछ बातूनी एंडपॉइंट को एकल मोबाइल-अनुकूल कॉल में जोड़ता है। ईस्ट-वेस्ट ट्रैफ़िक के लिए वे जानबूझकर सर्विस मेश को छोड़ देते हैं, क्योंकि दो भाषाओं में आठ सेवाएँ एक कंट्रोल प्लेन को उचित नहीं ठहरातीं। इसके बजाय उन्हें एक साझा क्लाइंट लाइब्रेरी और उनके प्लेटफ़ॉर्म के बिल्ट-इन प्रमाणपत्र प्रबंधन से mTLS और रिट्राई मिलते हैं, और वे एक हल्के एजेंट से ट्रेस एकत्र करते हैं। जब वे बाद में सख्त पेलोड ज़रूरतों वाला एक समर्पित मोबाइल क्लाइंट जोड़ते हैं, तो वे मौजूदा वेब गेटवे के साथ एक मोबाइल बैकएंड फॉर फ्रंटएंड शुरू करते हैं। वे हर साल मेश के सवाल पर फिर से विचार करते हैं और सही ढंग से यह तय करते रहते हैं कि वे अभी उस सीमा को पार नहीं कर पाए हैं जहाँ यह लाभदायक होगा।

एंटरप्राइज़। एक बहुराष्ट्रीय बैंक कई टीमों और भाषाओं में कई सौ सेवाएँ चलाता है, और यहाँ एक सर्विस मेश अपनी जटिलता अर्जित करता है। हर सेवा को डिफ़ॉल्ट रूप से एक वर्कलोड पहचान और mTLS मिलता है, ताकि सारा आंतरिक ट्रैफ़िक बिना किसी टीम के क्रिप्टो कोड लिखे ऑथेंटिकेटेड और एन्क्रिप्टेड रहे, जो सुरक्षा संगठन और उन ऑडिटरों दोनों को संतुष्ट करता है जो एक ही सिद्ध किए जा सकने वाला प्रवर्तन बिंदु चाहते हैं। मेश नीति द्वारा समान रिट्राई, टाइमआउट, और सर्किट ब्रेकिंग लागू करता है, और कैनरी रिलीज़ के लिए धीरे-धीरे ट्रैफ़िक शिफ्ट करता है ताकि एक खराब डिप्लॉय सभी उपयोगकर्ताओं तक पहुँचने से पहले एक प्रतिशत उपयोगकर्ताओं को छुए। API गेटवे की एक टियर बाहरी और पार्टनर ट्रैफ़िक को फ्रंट करती है, ऑथेंटिकेशन, कोटा, और वर्ज़निंग की स्वामी होकर, इस दृढ़ लिखित नियम के साथ कि आंतरिक रिट्राई केवल मेश में रहती हैं और बाहरी रेट लिमिट केवल गेटवे में रहती हैं, ताकि दोनों लेयर कभी किसी अनुरोध को दोहरा न संभालें। हर प्रॉक्सी से सुसंगत टेलीमेट्री एक केंद्रीय ऑब्ज़र्वेबिलिटी प्लेटफ़ॉर्म को फ़ीड करती है जो एक ऑन-कॉल इंजीनियर को दर्जनों सेवा हॉप में एक अनुरोध को ट्रेस करने देती है।

सरकार। एक राष्ट्रीय कर एजेंसी एक नागरिक-केंद्रित फाइलिंग प्लेटफ़ॉर्म का आधुनिकीकरण करती है और गेटवे तथा मेश को उस ज़ीरो-ट्रस्ट आर्किटेक्चर की रीढ़ की हड्डी के रूप में मानती है जिसकी नियामक माँग करते हैं। API गेटवे नियंत्रित सामने का द्वार है: हर नागरिक और हर पार्टनर को वहाँ ऑथेंटिकेट और ऑथराइज़ किया जाता है, बाहरी रेट लिमिट फाइलिंग-समय-सीमा की भीड़ के दौरान सिस्टम की रक्षा करती हैं, और पुराने क्लाइंट फ़ॉर्मैट को एज पर रूपांतरित किया जाता है ताकि लेगेसी इंटीग्रेशन काम करते रहें। इसके पीछे, एक सर्विस मेश हर आंतरिक सेवा को एक क्रिप्टोग्राफ़िक पहचान देता है और हर कॉल पर mTLS लागू करता है, ताकि केवल नेटवर्क के भीतर होने के कारण किसी सेवा पर भरोसा न किया जाए, और एक्सेस नीति स्पष्ट रूप से सूचीबद्ध करती है कि कौन सी सेवा किसे कॉल कर सकती है। क्योंकि प्लेटफ़ॉर्म लचीलेपन के लिए कई डेटा केंद्रों में फैला हुआ है, मेश उन्हीं पहचान और एन्क्रिप्शन गारंटियों को क्लस्टर के पार बढ़ाता है, जिससे राष्ट्रव्यापी सुसंगत ज़ीरो-ट्रस्ट नेटवर्किंग मिलती है। हर प्रवर्तन बिंदु एक ऑडिट ट्रेल उत्सर्जित करता है, ताकि एजेंसी निगरानी निकायों को यह सिद्ध कर सके कि एक्सेस की जाँच वास्तव में कहाँ हुई और ट्रैफ़िक कहाँ एन्क्रिप्ट किया गया।

व्यावसायिक तर्क: प्रेरणाएँ, ROI, और TCO

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

सर्विस मेश का व्यावसायिक तर्क अधिक सूक्ष्म है, क्योंकि इसकी स्वामित्व की कुल लागत (TCO) वास्तविक और निरंतर है। आप प्रॉक्सी के कंप्यूट और लेटेंसी के लिए, कंट्रोल प्लेन चलाने वाले इंजीनियरों के लिए, और एक नई लेयर को डीबग करने की सीखने की प्रक्रिया के लिए भुगतान करते हैं। यह लागत तब उचित है जब विकल्प (mTLS, रिट्राई, और टेलीमेट्री के प्रति-सेवा, प्रति-भाषा कार्यान्वयन) बड़ा होता और, इससे भी बदतर, ऐसे तरीकों से असंगत होता जो सुरक्षा में खामियाँ और आउटेज पैदा करते। उच्च स्केल पर मेश सौ नाज़ुक हाथ से बनाए गए समाधानों को एक समान, सिद्ध किए जा सकने वाले समाधान में बदल देता है, और ROI कम सुरक्षा घटनाओं, ट्रैफ़िक शिफ्टिंग के ज़रिए तेज़ सुरक्षित डिप्लॉयमेंट, और नाटकीय रूप से बेहतर ऑब्ज़र्वेबिलिटी के रूप में दिखता है। उस स्केल से नीचे, ईमानदार गणना अक्सर लाइब्रेरी और एक गेटवे के पक्ष में जाती है, और अनुशासित कदम प्रतीक्षा करना है। नेतृत्व के सामने यह तर्क रखने के लिए, गेटवे को उन मेट्रिक्स से जोड़ें जिन्हें वे पहले से ट्रैक करते हैं (भेद्यताओं को ठीक करने का समय, ऑडिट लागत, API समन्वय ओवरहेड) और मेश को सुरक्षा घटना नियंत्रण, डिप्लॉयमेंट सुरक्षा, और उस बहुभाषी डुप्लिकेशन की लागत से जोड़ें जिसे यह प्रतिस्थापित करता है।

एंटी-पैटर्न और नुकसान

• ज़रूरत से पहले मेश: मुट्ठी भर सेवाओं पर एक पूर्ण सर्विस मेश अपनाना, ऐसी समस्या को हल करने के लिए कंट्रोल प्लेन खरीदना जो अभी आपके पास है ही नहीं।
• दोहरी रिट्राई: गेटवे और मेश दोनों रिट्राई करते हैं, जिससे एक क्लाइंट कॉल एक बैकएंड रिट्राई तूफान में गुणा हो जाती है जो एक आउटेज को बढ़ा देती है।
• टाइमआउट व्युत्क्रमण: बाहरी वाले से लंबा भीतरी टाइमआउट, जिससे कॉलर हार मान लेता है जबकि कॉली ऐसी प्रतिक्रिया पर काम करता रहता है जिसे कोई नहीं पढ़ेगा।
• मोनोलिथ के रूप में गेटवे: गेटवे में बिज़नेस लॉजिक ठूँसते रहना, जब तक कि यह एक साझा बॉटलनेक न बन जाए जिसे बदलने के लिए हर टीम को समन्वय करना पड़े।
• विफलता का एकल बिंदु: बिना रिडंडेंसी के एक ही गेटवे इंस्टेंस चलाना, ताकि सामने का द्वार विफल होने पर इसके पीछे की हर सेवा नीचे गिर जाए।
• नेटवर्क पर भरोसा करना: परिधि के भीतर मौजूद किसी भी चीज़ को सुरक्षित मानना, ताकि एक समझौता की गई सेवा पार्श्व रूप से आगे बढ़ सके और सब कुछ तक पहुँच सके।
• ओवरलैपिंग स्वामित्व: कार्य का कोई लिखित विभाजन न होना, ताकि गलती से एक ही सरोकार को दोनों लेयर में संभाला जाए और किसी को पता न हो कि कौन सी प्राधिकृत है।
• BFF फैलाव: जब क्लाइंट एक ही चीज़ चाहते हों तब भी प्रति क्लाइंट एक बैकएंड फॉर फ्रंटएंड शुरू करना, बिना किसी लाभ के गेटवे बढ़ाना और लॉजिक डुप्लिकेट करना।
• साइडकार टैक्स को नज़रअंदाज़ करना: कंप्यूट और लेटेंसी ओवरहेड को मापे बिना हज़ारों साइडकार डिप्लॉय करना, फिर यह सोचना कि बजट कहाँ चला गया।

परिपक्वता मॉडल

• लेवल 1, आरंभ (Initiate): सेवाएँ बिना किसी साझा लेयर के सीधे एक-दूसरे से बात करती हैं। ऑथेंटिकेशन, रिट्राई, और टाइमआउट प्रति सेवा हाथ से कोड किए जाते हैं और असंगत होते हैं। आंतरिक ट्रैफ़िक अक्सर प्लेनटेक्स्ट होता है और नेटवर्क पर होने के कारण भरोसेमंद माना जाता है, और नीति लागू करने या ट्रैफ़िक देखने के लिए कोई एक स्थान नहीं है। निर्णय प्रतिक्रियात्मक (reactive) होते हैं, जो समस्याएँ सामने आने पर सेवा-दर-सेवा लिए जाते हैं।
• लेवल 2, विकास (Develop): एक API गेटवे बाहरी ट्रैफ़िक को फ्रंट करता है और ऑथेंटिकेशन, रेट लिमिटिंग, और रूटिंग को केंद्रीकृत करता है, लेकिन ईस्ट-वेस्ट सरोकारों को साझा लाइब्रेरी द्वारा संभाला जाता है जिनका अपनाना असमान है। कुछ सेवाओं में mTLS है; कई में नहीं है। टीमें नॉर्थ-साउथ बनाम ईस्ट-वेस्ट के अंतर को पहचानती हैं, फिर भी स्वामित्व अनौपचारिक है और प्रथाएँ एक टीम से दूसरी टीम में अलग होती हैं।
• लेवल 3, मानकीकरण (Standardize): नॉर्थ-साउथ और ईस्ट-वेस्ट सरोकारों को कार्य के एक लिखित विभाजन के साथ स्पष्ट रूप से अलग किया गया है, जो पूरे संगठन में लागू है। गेटवे बाहरी पहचान, कोटा, और कंपोज़िशन का स्वामी है; एक मेश या एक सुसंगत लाइब्रेरी लेयर आंतरिक mTLS, रिट्राई, और टेलीमेट्री की स्वामी है। ओवरलैप हल कर दिए गए हैं ताकि किसी सरोकार को दोहरा न संभाला जाए, आंतरिक ट्रैफ़िक डिफ़ॉल्ट रूप से एन्क्रिप्टेड और पहचान-जाँचा गया होता है, और मानक को हर टीम के विवेक पर छोड़ने के बजाय दस्तावेज़ीकृत और लागू किया जाता है।
• लेवल 4, प्रबंधन (Manage): ट्रैफ़िक लेयर को बेसलाइन के विरुद्ध मापा और नियंत्रित किया जाता है। आप कंप्यूट और प्रति-हॉप टेल लेटेंसी में साइडकार टैक्स, एरर बजट के विरुद्ध गेटवे और मेश उपलब्धता, रिट्राई-प्रवर्धन (amplification) और टाइमआउट-व्युत्क्रमण घटनाओं, आंतरिक कॉल के प्रतिशत के रूप में mTLS कवरेज, और पूरे फ्लीट में एक नीति परिवर्तन को धकेलने के समय को ट्रैक करते हैं। मेट्रिक्स निर्णयों को नियंत्रित करते हैं: एक प्रॉक्सी अपग्रेड, एक नया रिट्राई बजट, या एक कैनरी नियम का मूल्यांकन अंतर्ज्ञान के बजाय बेसलाइन के विरुद्ध डेटा पर किया जाता है, और मानक से कोई भी विचलन एक सुधार को ट्रिगर करता है।
• लेवल 5, ऑर्केस्ट्रेशन (Orchestrate): गेटवे और मेश एक परिपक्व ज़ीरो-ट्रस्ट आर्किटेक्चर के लिए नीति प्रवर्तन बिंदु हैं, जिसमें क्लस्टर और क्षेत्रों के पार हर हॉप पर पहचान जाँची जाती है। ट्रैफ़िक शिफ्टिंग सुरक्षित प्रगतिशील डिलीवरी को चलाती है, ऑब्ज़र्वेबिलिटी समान और समृद्ध है, और संगठन लगातार साइडकाररहित, प्रॉक्सीरहित, और eBPF दृष्टिकोणों का मूल्यांकन करता है और जहाँ वे लाभदायक हों वहाँ उन्हें अपनाता है। ट्रैफ़िक लेयर सुरक्षा, डिलीवरी, और क्षमता योजना के साथ एकीकृत है, और यह स्केल, भाषाओं, और जोखिम चित्र के बदलने के साथ अनुकूलित होती है।

चर्चा के लिए विचार

1. यदि आपका एकल API गेटवे अभी नीचे चला जाए, तो कितनी सेवाएँ अनुपलब्ध हो जाएँगी, और सामने के द्वार को रिडंडेंट बनाने की आपकी क्या योजना है?
2. आपके सिस्टम में वर्तमान में कौन सा सरोकार गेटवे और किसी सेवा (या लाइब्रेरी) दोनों में संभाला जाता है, और आप यह कैसे सिद्ध करेंगे कि इसे दोहरा नहीं संभाला जा रहा है?
3. सेवाओं और भाषाओं की किस संख्या पर आपकी टीम सहमत होगी कि मेश ने आखिरकार अपनी जटिलता अर्जित कर ली है, और आप उस रेखा से कितनी दूर हैं?
4. यदि कोई हमलावर कल किसी आंतरिक सेवा से समझौता कर ले, तो वह किन अन्य सेवाओं तक पहुँच सकेगा, और कौन सी पहचान जाँच उसे रोकेगी?
5. क्या साइडकाररहित या eBPF-आधारित मेश दृष्टिकोण अभी आपके प्लेटफ़ॉर्म के लिए पर्याप्त परिपक्व हैं, और तय करने के लिए आप क्या मापेंगे?
6. क्या आपके प्रत्येक भिन्न क्लाइंट को वास्तव में अपने खुद के बैकएंड फॉर फ्रंटएंड की ज़रूरत है, या आप ऐसे लॉजिक को डुप्लिकेट करने वाले हैं जो साझा रह सकता था?

मुख्य निष्कर्ष

• नॉर्थ-साउथ ट्रैफ़िक (जिसे API गेटवे संभालता है) को ईस्ट-वेस्ट ट्रैफ़िक (जिसे सर्विस मेश संभालता है) से अलग रखें; प्रत्येक अपनी दिशा का स्वामी है, और इन्हें भ्रमित करने से दोहरा प्रबंधन होता है।
• एक गेटवे रूटिंग, ऑथेंटिकेशन, ऑथराइज़ेशन, रेट लिमिटिंग, कोटा, अनुरोध रूपांतरण, कंपोज़िशन, और वर्ज़निंग को केंद्रीकृत करता है, ताकि सेवाएँ पतली रहें और नीति एक ही स्थान पर रहे।
• एक सर्विस मेश आपको बिना सेवा का कोड बदले mTLS, ट्रैफ़िक शिफ्टिंग, प्लेटफ़ॉर्म-स्तर की रिट्राई और सर्किट ब्रेकिंग, और समान ऑब्ज़र्वेबिलिटी देता है, जो क्लासिक रूप से साइडकार प्रॉक्सी के माध्यम से होता है।
• मेश तभी अपनाएँ जब सेवाओं और भाषाओं की संख्या प्रति-सेवा वायरिंग को अधिक महंगा रास्ता बना दे; उससे नीचे, लाइब्रेरी प्लस एक गेटवे जीतते हैं, और साइडकार टैक्स इतना वास्तविक है कि उस पर नज़र रखी जाए।
• गेटवे और मेश को एक ज़ीरो-ट्रस्ट आर्किटेक्चर के नीति प्रवर्तन बिंदु मानें, हर क्रॉस-कटिंग सरोकार को ठीक एक लेयर सौंपें, और क्लस्टर के पार हर हॉप पर पहचान जाँचें।

संदर्भ और आगे पढ़ने के लिए

• Sam Newman, Building Microservices: Designing Fine-Grained Systems
• Chris Richardson, Microservices Patterns: With Examples in Java
• Lee Calcote and Zack Butcher, Istio: Up and Running
• Ken Owens, Alois Reitbauer, and others; the CNCF Cloud Native Landscape and service mesh documentation
• Evan Gilman and Doug Barth, Zero Trust Networks: Building Secure Systems in Untrusted Networks
• Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, Zero Trust Architecture, NIST Special Publication 800-207
• Susan Fowler, Production-Ready Microservices