हमारे प्लेटफॉर्म का कोर आर्किटेक्चर AWS के बजाय Equinix LD4 के करीब क्यों डिजाइन किया गया था?
आज के समय में, अधिकांश सेवाओं के लिए क्लाउड प्लेटफॉर्म आमतौर पर पहला इंफ्रास्ट्रक्चर विकल्प माना जाता है।
वे मांग पर तेजी से स्केलिंग की अनुमति देते हैं, प्रबंधित सेवाओं (managed services) की एक विस्तृत श्रृंखला तक पहुंच प्रदान करते हैं, और परिचालन स्वचालन (operational automation) को सरल बनाते हैं। यही कारण है कि AWS कई संगठनों के लिए एक मानक (de facto standard) बन गया है।
हालांकि, इंफ्रास्ट्रक्चर डिजाइन हमेशा एक ही सिद्धांत का पालन करता है:
सही चुनाव वह नहीं है जो सबसे सामान्य या व्यापक रूप से अपनाया गया है, बल्कि वह है जो सेवा की मुख्य आवश्यकताओं के साथ सबसे अच्छा मेल खाता है।
हमारे प्लेटफॉर्म की विशेषताएं एक विशिष्ट वेब सेवा से भिन्न हैं।
मुख्य आवश्यकता केवल सर्वर स्केलेबिलिटी नहीं है, बल्कि लो-लेटेंसी मार्केट डेटा इंजेक्शन, स्थिर नेटवर्क पाथ और पूर्वानुमानित प्रदर्शन (predictable performance) है। इस प्रकृति के वर्कलोड की ऐसी आवश्यकताएं होती हैं जिन्हें केवल सार्वजनिक क्लाउड के लाभों के माध्यम से पूरी तरह से संबोधित नहीं किया जा सकता है। और यही कारण है कि Equinix LD4-आधारित आर्किटेक्चर एक अधिक उपयुक्त विकल्प बन जाता है।
— लेकिन यह हर समस्या का समाधान नहीं है। AWS एक उत्कृष्ट प्लेटफॉर्म है।
यह तेजी से सेवा परिनियोजन (service deployment) को सक्षम बनाता है, इंफ्रास्ट्रक्चर-एज़-कोड प्रबंधन को सीधा बनाता है, और बैकअप, रिकवरी, वैश्विक विस्तार और परिचालन स्वचालन के लिए व्यापक समर्थन प्रदान करता है। कई कंपनियों द्वारा AWS को चुनने के कारण पूरी तरह से तर्कसंगत हैं।
हालांकि, हर सेवा एक ही तरह से इंफ्रास्ट्रक्चर का उपयोग नहीं करती है।
एक विशिष्ट वेब एप्लिकेशन के लिए, हॉरिजॉन्टल स्केलेबिलिटी और परिचालन सुविधा सबसे महत्वपूर्ण प्राथमिकताएं हो सकती हैं। लेकिन वे प्लेटफॉर्म जहां रीयल-टाइम प्रतिक्रिया महत्वपूर्ण है, अलग परिस्थितियों में काम करते हैं। इन वातावरणों में, औसत प्रोसेसिंग प्रदर्शन से अधिक महत्वपूर्ण यह है कि लेटेंसी को कितनी निरंतरता से बनाए रखा जा सकता है, और डेटा किन रास्तों से सिस्टम में प्रवेश करता है और बाहर निकलता है।
दूसरे शब्दों में, मुख्य प्रश्न यह नहीं है:
“कौन सा वातावरण अधिक सुविधाजनक है?”
बल्कि यह है:
“कौन सा वातावरण एक छोटा, अधिक पूर्वानुमानित और अधिक नियंत्रणीय मार्ग प्रदान कर सकता है?”
हमारे प्लेटफॉर्म के लिए, केवल "गति" मायने नहीं रखती, बल्कि गति की निरंतरता (consistency of speed) मायने रखती है।
लो-लेटेंसी वातावरण में, केवल तेज होना ही पर्याप्त नहीं है।
इससे भी अधिक महत्वपूर्ण यह है कि क्या सिस्टम हर समय एक समान गति से काम कर सकता है।
प्लेटफॉर्म के दृष्टिकोण से, सबसे कठिन चुनौती औसत प्रतिक्रिया समय नहीं है, बल्कि अप्रत्याशित लेटेंसी स्पाइक्स और अस्थिर नेटवर्क गुणवत्ता है। मार्केट डेटा इंजेक्शन या ट्रेड निष्पादन जैसे संवेदनशील प्रवाहों में, छोटे बदलाव भी पूरे सिस्टम की गुणवत्ता को महत्वपूर्ण रूप से प्रभावित कर सकते हैं।
इन विशेषताओं के कारण, कोर वर्कलोड के लिए "सुविधा" की तुलना में "पूर्वानुमान योग्यता" अधिक महत्वपूर्ण हो जाती है। और यह पूर्वानुमान योग्यता शायद ही कभी केवल एप्लिकेशन कोड के माध्यम से हल की जाती है। अंततः, इंफ्रास्ट्रक्चर-स्तर के निर्णय — जैसे नेटवर्क टोपोलॉजी, कनेक्शन पाथ और परिचालन नियंत्रण — सिस्टम की समग्र गुणवत्ता निर्धारित करते हैं।
LD4 की ताकत केवल यह नहीं है कि सर्वर लंदन में रखे जा सकते हैं।
इससे ज्यादा महत्वपूर्ण वह ईकोसिस्टम है जिसके भीतर कनेक्शन स्थापित किए जा सकते हैं।
लो-लेटेंसी वर्कलोड में, मुख्य कारक केवल CPU स्पेसिफिकेशन या मेमोरी साइज नहीं होते हैं। व्यवहार में, सेवा की गुणवत्ता इस बात से कहीं अधिक प्रभावित होती है कि सिस्टम अपने डेटा स्रोतों के कितना करीब है, नेटवर्क पाथ कितना सरल है, और बाहरी परिवर्तनशीलता के बिना प्रवाह कितना निरंतर स्थिर रह सकता है।
इस दृष्टिकोण से, LD4 केवल एक IDC सुविधा नहीं है, बल्कि महत्वपूर्ण कनेक्शन पाथ डिजाइन करने के लिए एक रणनीतिक स्थान है।
हमारे प्लेटफॉर्म के लिए सबसे महत्वपूर्ण यह नहीं है:
“सर्वर कहां स्थित होने चाहिए?”
बल्कि यह है:
“मुख्य डेटा प्रवाह को सबसे स्थिर और पूर्वानुमानित तरीके से कहां प्राप्त और संसाधित किया जा सकता है?”
यही कारण है कि उत्तर हमें LD4 के करीब ले जाता है।
पब्लिक क्लाउड की सबसे बड़ी खूबियों में से एक 'एब्स्ट्रैक्शन' (abstraction) है।
यह इंफ्रास्ट्रक्चर को जल्दी से तैयार करने की अनुमति देता है जबकि भौतिक इंफ्रास्ट्रक्चर की मात्रा को काफी कम कर देता है जिसे ऑपरेटरों को सीधे प्रबंधित करना पड़ता है। अधिकांश सेवाओं के लिए, यह एक बड़ा लाभ है।
हालांकि, उन प्लेटफार्मों के लिए जहां कोर पाथ की गुणवत्ता महत्वपूर्ण है, यह एब्स्ट्रैक्शन कभी-कभी एक सीमा बन सकता है।
हम जिस क्षेत्र को सीधे देख सकते हैं, सीधे नियंत्रित कर सकते हैं और सीधे अनुकूलित कर सकते हैं, वह जितना व्यापक होगा, लाभ उतना ही अधिक होगा।
ऑन-प्रिमाइसेस या कोलोकेशन-आधारित आर्किटेक्चर परिचालन रूप से अधिक मांग वाले होते हैं और इनमें अधिक व्यावहारिक प्रबंधन की आवश्यकता होती है।
बदले में, वे नेटवर्क कॉन्फ़िगरेशन, सुरक्षा नीतियों, रूट डिजाइन और प्रदर्शन विशेषताओं पर बहुत बेहतर नियंत्रण प्रदान करते हैं। और नियंत्रण का यह स्तर उन प्लेटफार्मों के लिए एक वास्तविक प्रतिस्पर्धी लाभ बन जाता है जिन्हें लो-लेटेंसी और उच्च स्थिरता की आवश्यकता होती है।
अंततः, कोई भी पूर्ण "बेहतर" इंफ्रास्ट्रक्चर नहीं है।
सही चुनाव इस पर निर्भर करता है कि प्लेटफॉर्म को कितने नियंत्रण की आवश्यकता है।
यही कारण है कि हमारा उत्तर "क्लाउड को बदलना" नहीं है, बल्कि "जिम्मेदारियों को अलग करना" है।
इस बिंदु पर, हम एक महत्वपूर्ण गलतफहमी को स्पष्ट करना चाहते हैं।
इस चर्चा का यह मतलब नहीं है कि "ऑन-प्रिमाइसेस इंफ्रास्ट्रक्चर हमेशा AWS से बेहतर होता है।"
वास्तव में, एक यथार्थवादी इंफ्रास्ट्रक्चर रणनीति अक्सर इसके विपरीत होती है।
इससे ज्यादा महत्वपूर्ण यह है कि प्रत्येक वातावरण जो सबसे अच्छा प्रदर्शन करता है, उनकी भूमिकाओं को अलग करना और सेवा की प्रकृति के आधार पर उन्हें उचित रूप से संयोजित करना।
यही सिद्धांत हमारे प्लेटफॉर्म पर भी लागू होता है।
वे क्षेत्र जहां लेटेंसी और नेटवर्क पाथ की गुणवत्ता महत्वपूर्ण है — जैसे कोर ट्रेडिंग पाथ और लो-लेटेंसी मार्केट डेटा इंजेक्शन — LD4 जैसे वातावरण के लिए बेहतर अनुकूल हैं। दूसरी ओर, AWS तेजी से स्केलिंग, सामान्य-उद्देश्य वाले एप्लिकेशन वर्कलोड, सहायक सेवाओं, बैकअप और परिचालन स्केलेबिलिटी के लिए बेहद प्रभावी है।
दूसरे शब्दों में, LD4 और AWS एक-दूसरे के प्रतिस्पर्धी विकल्प नहीं हैं।
वे पूरक इंफ्रास्ट्रक्चर (complementary infrastructures) हैं जिन्हें अलग-अलग समस्याओं को हल करने के लिए डिज़ाइन किया गया है।
प्रौद्योगिकी के निर्णय अक्सर रुझानों (trends) से प्रभावित होते हैं।
इंफ्रास्ट्रक्चर के फैसले विशेष रूप से इससे प्रभावित होते हैं।
जब हर कोई क्लाउड के बारे में बात कर रहा हो, तो क्लाउड के बाहर कुछ चुनना कभी-कभी रूढ़िवादी लग सकता है।
फिर भी, जो वास्तव में मायने रखता है वह चलन नहीं है, बल्कि वर्कलोड की प्रकृति है।
एक सामान्य-उद्देश्य वाली वेब सेवा के विपरीत, हमारा प्लेटफॉर्म कच्ची गति के बजाय स्थिर लेटेंसी विशेषताओं, पूर्वानुमानित नेटवर्क पाथ और उच्च नियंत्रण को प्राथमिकता देता है। यही कारण है कि हमारा कोर इंफ्रास्ट्रक्चर AWS की तुलना में Equinix LD4 के करीब डिजाइन किया गया था। यह किसी विशेष तकनीक के प्रति झुकाव का परिणाम नहीं था, बल्कि उस आर्किटेक्चर को चुनने का परिणाम था जो सेवा की वास्तविक विशेषताओं के साथ सबसे अच्छा मेल खाता है।
अच्छा इंफ्रास्ट्रक्चर वह नहीं है जो नवीनतम तकनीकों का सबसे आक्रामक रूप से उपयोग करता है।
अच्छा इंफ्रास्ट्रक्चर वह है जो सेवा के लिए वास्तव में आवश्यक विशेषताओं को सबसे सटीक रूप से पूरा करता है।
AWS एक अत्यंत शक्तिशाली प्लेटफॉर्म बना हुआ है।
हालांकि, हमारे प्लेटफॉर्म के कोर को जिस चीज की आवश्यकता है, वह सामान्य लचीलापन नहीं है, बल्कि एक छोटा, अधिक स्थिर और अधिक सीधे नियंत्रणीय मार्ग है। और वह उत्तर जो उन आवश्यकताओं के साथ अधिक निकटता से मेल खाता है, वह Equinix LD4 है।
अंततः, प्रश्न सरल है:
यह नहीं है कि “कौन सा प्लेटफॉर्म अधिक प्रसिद्ध है?”
बल्कि यह है:
“कौन सा प्लेटफॉर्म हमारी सेवा के मूल (core) की सबसे अच्छी रक्षा करता है?”
हमारे लिए, उत्तर स्पष्ट है।
कोर प्लेटफॉर्म के लिए, LD4 बेहतर विकल्प है।
