क्यों बड़े तकनीकी निगम मालिकाना समाधान बनाने के प्रति जुनूनी हैं?

नमस्ते! मैं इस बारे में बात करना चाहता हूं कि बड़े तकनीकी निगम अपने बुनियादी ढांचे के लिए मालिकाना समाधान बनाने के प्रति जुनूनी क्यों हैं। उत्तर स्पष्ट प्रतीत होता है: यह एनआईएच सिंड्रोम से अधिक कुछ नहीं है। लेकिन यह उत्तर पूर्ण से बहुत दूर है, उद्देश्य का उल्लेख करना तो दूर की बात है।

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

विकास चक्र को व्यवस्थित करने के लिए उपकरणों के उदाहरण

किसी समस्या को हल करने के लिए, हम अक्सर तैयार किए गए उपकरणों को लागू करने के बजाय मालिकाना उपकरण विकसित करते हैं। उदाहरण के लिए, टीम में एक प्रोग्रामर रहते हुए, मैंने C++ और Python में एक मात्रात्मक निगरानी प्रणाली पर काम किया और इसे दसियों अरब संसाधित मेट्रिक्स तक बढ़ाने में मदद की। इसलिए, अपने स्वयं के अनुभव के आधार पर, मुझे पता है कि कौन सी प्रेरणाएं और विकास पथ इन-हाउस टूल के उद्भव की ओर ले जाते हैं: नीचे, मैं उदाहरण के रूप में हमारे समाधानों का उपयोग करके उनके निर्माण के मूलभूत कारणों की पहचान करने का प्रयास करूंगा।

कहानी #1: यांडेक्स आंतरिक बादल

कार्य निर्धारित करना. हमारे आंतरिक रनटाइम क्लाउड या आरटीसी का लक्ष्य आंतरिक उपयोगकर्ताओं को सरल तैनाती और यातायात प्रबंधन उपकरण प्रदान करना है। आरटीसी उपयोगकर्ता वही इंजीनियर हैं जो यांडेक्स सेवाएं विकसित करते हैं। और उन्हें अपने द्वारा बनाए गए हजारों एप्लिकेशन लॉन्च करने, वहां उपयोगकर्ता अनुरोध भेजने, लोड को संतुलित करने और अन्य चीजों के साथ घटनाओं से निपटने की आवश्यकता है।

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

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

मूलतः, हमें कुबेरनेट्स की आवश्यकता थी (और, समय के साथ, आरटीसी बहुत करीब आ गई)। लेकिन यहाँ एक समस्या है: k8s की घोषणा केवल 2014 में की गई थी। अपाचे मेसोस उस समय अस्तित्व में था, लेकिन यह अपनी प्रारंभिक अवस्था में था।

बुनियादी कार्यों का कार्यान्वयन. हमने समस्या को एक प्रकार के एमवीपी के साथ हल करना शुरू किया - उपकरणों का एक सरल सेट, जो बिल्डिंग ब्लॉक्स के एक सेट की तरह था जो नियमित क्रियाओं को स्वचालित करता है, उदाहरण के लिए:

• क्लस्टर संसाधनों का आवंटन;
• क्लस्टर में एप्लिकेशन के आवश्यक संस्करण और विभिन्न कलाकृतियों की डिलीवरी;
• क्लस्टर पर एप्लिकेशन के आवश्यक संस्करण का लॉन्च।

समय के साथ, इन बिल्डिंग ब्लॉक्स (निरंतर वितरण के समान) का उपयोग करके एक पूर्ण सेवा लेआउट ग्राफ़ को एक साथ रखना संभव हो गया। पुनरावृत्तियों की एक निश्चित संख्या के बाद, आरटीसी में चल रही सेवाओं के प्रबंधन के लिए एक प्रणाली, नानी, 2013 में सामने आई।

नैनी का एक अन्य मूलभूत पहलू संसाधन खपत के आधार पर एप्लिकेशन अलगाव का कार्यान्वयन था। हमने शुरू में संसाधन अलगाव के बिना विभिन्न सेवाओं से एप्लिकेशन लॉन्च किए, जिसके परिणामस्वरूप बड़ी संख्या में परिचालन संबंधी समस्याएं और घटनाएं हुईं।

उस समय, एकमात्र तैयार समाधान LXC थे, जो तब तक विकसित होना बंद हो गया था, और Docker, जो केवल IPv6 का उपयोग नहीं कर सकता था और dockerd को अपडेट करते समय सभी कंटेनरों को पुनरारंभ करता था, जिससे उपयोगकर्ता को प्रभावित किए बिना dockerd को अपडेट करना असंभव हो जाता था। परिणामस्वरूप, हमने अपना विकास करना शुरू किया पोर्टो 2014 के मध्य में लिनक्स कर्नेल सीग्रुप के शीर्ष पर कंटेनरीकरण प्रणाली। अधिकांश एप्लिकेशन और सर्वर पर कुछ सिस्टम एजेंटों को 2015 में पहले ही पोर्टो कंटेनर में स्थानांतरित कर दिया गया था।

उपयोग की समस्याओं का समाधान. उस समय, आंतरिक क्लाउड में संसाधन प्रबंधन रिपॉजिटरी में प्रतिबद्धताओं के माध्यम से पूरा किया गया था। हालाँकि, इसने यांडेक्स के विकास को धीमा कर दिया और उपयोग बढ़ाने के कार्य में बाधा उत्पन्न की: इसे हल करने के लिए, हमें अपने मानचित्र कम करने वाले सिस्टम को बादलों में रखने की आवश्यकता थी, अर्थात् YTsaurus - बड़े डेटा और वितरित कंप्यूटिंग को संग्रहीत करने के लिए हमारी मालिकाना आंतरिक प्रणाली, जिसे हम उस समय लगभग 7 वर्षों से विकसित कर रहे थे। इसे आंतरिक क्लाउड में लाना था, लेकिन इसे उपयोगकर्ता अनुप्रयोगों के साथ भी चलाना था।

YTsaurus को RTC में लाने के लिए, रिपॉजिटरी कमिट के बजाय पॉड्स को गतिशील रूप से प्रबंधित करने की क्षमता की आवश्यकता थी। इसलिए, 2018 में, हमने बनाया यांडेक्स प्लानर , क्लस्टर कंप्यूटिंग संसाधनों के प्रबंधन के लिए एक प्रणाली। यांडेक्स प्लानर को मौजूदा नानी परिनियोजन प्रणाली के साथ एकीकृत किया गया था, जिससे वाईटीएसॉरस माइग्रेशन को अनब्लॉक किया गया और आरटीसी को एक पूर्ण क्लाउड में बदल दिया गया। उस समय आरटीसी के पास कई दसियों हज़ार सर्वर थे, और मानचित्र कटौती की शुरुआत के साथ, यह संख्या काफी बढ़ गई।

नये बढ़ते दर्द. उसी समय अवधि के दौरान, k8s एक अधिक परिपक्व समाधान के रूप में विकसित हुआ, जो 2017 में AWS सेवाओं में से एक बन गया। लेकिन यह अभी भी हमारी सभी आवश्यकताओं को पूरा नहीं करता है:

• हजारों सर्वरों का पैमाना - एक k8s इंस्टॉलेशन अभी भी हमारे पैमाने को संभाल नहीं सकता है।
• डुअल स्टैक IPv6 और IPv4 के लिए समर्थन केवल 2020 में k8s में दिखाई दिया, और IPv6 शुरू से ही हमारे लिए महत्वपूर्ण था।
• नेस्टेड कंटेनरों के लिए समर्थन, जिसकी हमें आवश्यकता थी क्योंकि हमने अलग बैच और कंप्यूट शेड्यूलर बनाने का निर्णय लिया था। हमने एक बिंदु पर इस विकल्प की प्रभावशीलता की तुलना एक सामान्य अनुसूचक से की, और हर चीज़ के लिए एक सामान्य अनुसूचक बनाने का प्रयास न करना अधिक सुविधाजनक और लाभदायक था।

YTsaurus ने एकल शेड्यूलर बनाने के बजाय सक्रिय रूप से नेस्टेड पोर्टो कंटेनर बनाने की क्षमता का उपयोग किया। निःसंदेह, हम स्वयं k8s में समान दोहरे स्टैक के लिए समर्थन जोड़ सकते हैं। हालाँकि, लिनक्स कर्नेल विकास अनुभव से पता चला है कि हर चीज़ को ओपन सोर्स पर नहीं भेजा जा सकता है, और हम नए संस्करणों में अपडेट करना आसान बनाने के लिए अपस्ट्रीम कर्नेल से डेल्टा को न्यूनतम रखने का प्रयास करते हैं।

हमारा आज का समाधान. आरटीसी की वास्तुकला कुबेरनेट्स के समान है। उपयोगकर्ता घोषणात्मक रूप से कुछ विशिष्टताओं के रूप में अपनी सेवा का वर्णन करता है जो बताता है कि निर्दिष्ट एप्लिकेशन को कैसे और किन डेटा केंद्रों में लॉन्च किया जाए। प्रत्येक डेटा सेंटर में यांडेक्स प्लानर की अपनी स्थापना होती है, जो एक ओर सभी क्लस्टर ऑब्जेक्ट के लिए डेटाबेस के रूप में और दूसरी ओर पॉड शेड्यूलर के रूप में कार्य करता है। डेटा सेंटर में प्रत्येक सर्वर एक एजेंट चलाता है जो यांडेक्स प्लानर से पॉड विनिर्देश प्राप्त करता है और हमारे मालिकाना पोर्टो कंटेनरीकरण सिस्टम का उपयोग करके उन्हें लॉन्च करता है।

वर्तमान में, आरटीसी ने 100,000 से अधिक सर्वरों को 5 मिलियन से अधिक कोर आवंटित करते हुए हजारों सेवाएं लॉन्च की हैं। हर दिन, सेवा विशिष्टताओं में 100,000 से अधिक परिवर्तन किए जाते हैं।

योजनाएं. क्या होगा यदि k8s हमारे पैमाने को संभाल सके? विशेष रूप से तब से जब k8s पारिस्थितिकी तंत्र ने किसी समय कार्यक्षमता के मामले में हमसे बेहतर प्रदर्शन करना शुरू कर दिया था। क्या k8s पर स्विच करना बेहतर नहीं होगा और आशा करें कि तैयार उपकरण अंततः वह मात्रा प्रदान करेंगे जिसकी हमें आवश्यकता है? व्यवहार में, हम k8s के लिए एक विशिष्ट उपभोक्ता बने हुए हैं क्योंकि केवल कुछ प्रतिशत कंपनियां ही इतने बड़े पैमाने पर काम करती हैं, जिनमें से प्रत्येक के पास अपने स्वयं के इन-हाउस क्लाउड समाधान हैं।

याद रखने योग्य एक और महत्वपूर्ण बिंदु प्रवासन मुद्दा है। जुलाई 2018 के अनुसार गार्टनर एक मल्टीप्लेटफ़ॉर्म एप्लिकेशन आधुनिकीकरण व्यवसाय केस का निर्माण कर रहा है रिपोर्ट के अनुसार, 2025 तक 90% आधुनिक एप्लिकेशन अभी भी उपयोग में होंगे, और इन प्रणालियों के विकास के लिए तकनीकी ऋण आईटी बजट का 40% से अधिक होगा। उपयोगकर्ता सेवाओं को यांडेक्स प्लानर में स्थानांतरित करने के हमारे अनुभव के आधार पर, यह वास्तविकता के करीब है: 2023 में, लगभग 100k कोर अभी भी यांडेक्स प्लानर में जाने के लिए अपनी बारी का इंतजार कर रहे थे।

2021 में, हमने अनुमान लगाया कि हमारी विकास रणनीति चुनते समय एक तैनाती प्रणाली से दूसरे में जाने में कितना खर्च आएगा। यांडेक्स का वेनिला k8s में स्थानांतरण एक अत्यंत महंगा कार्य होगा, जिसमें सैकड़ों मानव-वर्ष खर्च होंगे।

इस सरल तरीके से, हम अपने आंतरिक बादल के साथ समाप्त हो गए, जिसे हम अगले 5 वर्षों में त्यागने में सक्षम होने की संभावना नहीं है, भले ही हमने ऐसा लक्ष्य निर्धारित किया हो।

K8s की तुलना में आंतरिक क्लाउड कार्यक्षमता की कमी के बारे में क्या किया जाना चाहिए? व्यवहार में, हमारे ग्राहक यांडेक्स क्लाउड में प्रबंधित कुबेरनेट्स का उपयोग कर सकते हैं। यह विकल्प मुख्य रूप से उन परियोजनाओं के लिए उपयोग किया जाता है जहां सख्त अनुपालन आवश्यकताओं को पूरा किया जाना चाहिए - यह टीमों का एक छोटा सा अनुपात है, 1% से भी कम। ऊपर बताए गए कारणों से, बाकी आबादी को स्थानांतरित होने में कोई खास फायदा नहीं दिख रहा है।

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

• दूसरों के बारे में क्या? चूँकि हम इस लेख में सामान्य तौर पर बड़ी तकनीक पर चर्चा कर रहे हैं, इसलिए यह ध्यान देने योग्य है कि हमारा मामला अद्वितीय नहीं है। इसकी जाँच पड़ताल करो बोर्ग या रस्सी उदाहरण के लिए मामले.

कहानी #2: मोनोरिपॉजिटरी

समस्याएँ एवं समाधान आवश्यकताएँ । हमारी मोनोरिपॉजिटरी, अर्काडिया, हमारे आंतरिक क्लाउड के समान प्राथमिक लक्ष्य साझा करती है: सुविधाजनक विकास उपकरण प्रदान करना। इसमें रिपॉजिटरी के मामले में संपूर्ण विकास पारिस्थितिकी तंत्र शामिल है:

• संस्करण नियंत्रण प्रणाली (आर्क),
• इंटरफ़ेस (आर्कनम),
• बिल्ड सिस्टम (या बनाओ),
• सीआई/सीडी (न्यूसीआई)।

अर्काडिया लगभग उसी समय उभरा जब यैंडेक्स का आंतरिक बादल उभरा। मोनोरिपॉजिटरी के निर्माण का एक कारण यांडेक्स के भीतर कोड का पुन: उपयोग करने की आवश्यकता थी। उस समय कई निर्माण प्रणालियों की उपस्थिति के कारण इसमें बाधा उत्पन्न हुई थी। संपूर्ण यांडेक्स के पैमाने पर काम करने के लिए कुशल वितरित बिल्ड के समर्थन के साथ एक एकीकृत प्रणाली की आवश्यकता थी। यह स्थिर और प्रयोग योग्य भी होना चाहिए।

एकीकृत निर्माण प्रणाली का कार्यान्वयन। हमारा मालिकाना हक बिल्ड सिस्टम 2013 में शुरू हुआ, जब यह केवल C++ कोड के लिए था। आपके निर्माण से पहले, हमने CMake का उपयोग किया था, लेकिन इसकी गति ने इसे एक मोनोरिपोजिटरी के पैमाने तक बढ़ने से रोक दिया। आपके द्वारा बनाया गया स्वामित्व अर्काडिया के साथ बहुत तेजी से काम करता है। कोई अन्य खुला स्रोत विकल्प नहीं था जो हमारी समस्या का समाधान कर सके: उदाहरण के लिए, बेज़ेल को बहुत बाद में, 2015 में जारी किया गया था।

संस्करण नियंत्रण प्रणाली स्केलिंग. Yandex ने पहले SVN को अपने संस्करण नियंत्रण प्रणाली के रूप में उपयोग किया था। हालाँकि एसवीएन की क्षमता बड़ी थी, फिर भी यह सीमित थी और इसे बनाए रखना मुश्किल था। इसके अलावा, हम जानते थे कि अंततः हमें एसवीएन की क्षमताओं और सुविधा की सीमाओं का सामना करना पड़ेगा। उदाहरण के लिए, हेयुरिस्टिक्स का उपयोग रिपॉजिटरी या चयनात्मक चेकआउट के केवल आवश्यक हिस्से को डाउनलोड करने की क्षमता को लागू करने के लिए किया गया था। परिणामस्वरूप, 2016 में, हमने एसवीएन के अलावा अन्य संस्करण नियंत्रण प्रणालियों के साथ प्रयोग करना शुरू किया।

मर्क्यूरियल पहली पसंद थी। लेकिन हमारे सामने मुख्य मुद्दा गति का था। हमने मर्क्यूरियल को उत्पादन में लाने के लिए डेढ़ साल तक प्रयास किया, लेकिन परिणाम निराशाजनक रहे। उदाहरण के लिए, हमें अंततः FUSE का समर्थन करने के लिए मर्क्यूरियल के कुछ हिस्सों को फिर से लिखना पड़ा, या हमें प्रत्येक डेवलपर के लैपटॉप में संपूर्ण रिपॉजिटरी लानी पड़ी।

आखिरकार, यह पता चला कि स्क्रैच से इन-हाउस समाधान लिखना सस्ता था, और 2019 में, आर्क सामने आया - गिट-जैसे यूएक्स के साथ आर्काडिया उपयोगकर्ताओं के लिए एक नया संस्करण नियंत्रण प्रणाली। आर्क का आधार चयनात्मक चेकआउट के बजाय FUSE (उपयोगकर्ता स्थान में फ़ाइल सिस्टम) है। इसके अलावा, YDB एक स्केलेबल डेटाबेस के रूप में कार्य करता है, जो मर्क्यूरियल की तुलना में आर्क के संचालन को बहुत सरल बनाता है।

हमसे अक्सर पूछा जाता है कि हमने गिट का उपयोग क्यों नहीं किया। क्योंकि इसमें स्केल और कार्यक्षमता सीमाएँ भी हैं: यदि हम केवल आर्केडिया ट्रंक को गिट में आयात करते हैं, तो इस पैमाने पर गिट स्थिति में कुछ मिनट लगेंगे। उसी समय, git के शीर्ष पर कोई स्थिर FUSE कार्यान्वयन नहीं बनाया गया था: Git के लिए VFS अब विकसित नहीं किया जा रहा है, और EdenFS को अंततः सैपलिंग में बदल दिया गया था, लेकिन यह बहुत बाद में हुआ।

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

पैमाने के संदर्भ में, ट्रंक में वर्तमान में 10 मिलियन फ़ाइलें हैं, कुल मिलाकर रिपॉजिटरी 2 TiB से अधिक है, और प्रत्येक सप्ताह 30 हजार से अधिक कमिट किए जाते हैं।

परिणामस्वरूप, हमारे द्वारा बनाए गए पारिस्थितिकी तंत्र में, हमें शुरू से ही कई घटकों का निर्माण करना होगा। हालाँकि, अब यह वैश्विक मानकों के अनुपालन की ओर बढ़ रहा है। उदाहरण के लिए, आर्क, परियोजनाओं के पूर्वनिर्धारित सेट के लिए Git के साथ काम करने का समर्थन करता है।

• दूसरों के बारे में क्या? फिर, यदि आप सामान्य तौर पर बड़ी तकनीक को देखते हैं, तो एक उदाहरण के रूप में आपको इस पर ध्यान देना चाहिए पौधा और PIPER .

इन कहानियों में क्या समानता है?

तो बड़ी तकनीकी कंपनियों को अपने स्वयं के समाधान क्यों ईजाद करने पड़ते हैं, और उन्हें आम तौर पर स्वीकृत मानक का पालन करने वाले समाधानों से क्यों नहीं बदला जा सकता है?

1. नवाचार। बड़े निगमों को अक्सर उन समस्याओं के समाधान विकसित करने की आवश्यकता होती है जो भविष्य में आम हो जाएंगी। इस प्रकार बाज़ार मानक बनने की क्षमता वाले नवोन्वेषी समाधान सामने आ सकते हैं।

   
   

   ऐसा हमेशा नहीं होता है कि किसी कंपनी द्वारा हल की गई समस्या का सामना कंपनी के अलावा किसी और को करना पड़ता है। कभी-कभी किसी विशिष्ट समस्या के साथ बड़ी तकनीक का अनुभव पूरे उद्योग को पूरी तरह से अलग विकास पथ अपनाकर उस समस्या से बचने में मदद करता है। बाज़ार के विकास की भविष्यवाणी करना हमेशा संभव नहीं होता है, और परिणामस्वरूप, मालिकाना समाधानों के विभिन्न उदाहरणों के परिणाम बहुत भिन्न होते हैं।

   
   

   ClickHouse वास्तव में सफल नवोन्मेषी परियोजना का एक उदाहरण है जिसने ऑनलाइन विश्लेषणात्मक प्रसंस्करण (OLAP) के क्षेत्र को काफी समृद्ध किया है। हालाँकि, यह सभी परियोजनाओं के लिए मामला नहीं है। पोर्टो, जो एक ओपन सोर्स प्रोजेक्ट के रूप में शुरू हुआ, कई कारणों से लोकप्रियता हासिल करने में विफल रहा। हालाँकि इसकी कुछ विशेषताएं, जैसे नेस्टेड कंटेनर बनाने की क्षमता, अद्वितीय बनी हुई हैं।

   
   

2. पैमाना। यह बिंदु कुछ मायनों में पिछले बिंदु के समान है, क्योंकि हर कंपनी को स्केलेबिलिटी समस्या का सामना नहीं करना पड़ता है। एक समय था जब 640 किलोबाइट हर किसी के लिए पर्याप्त से अधिक था, है ना?

   
   

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

   
   

   सार्वजनिक उपकरणों में स्केलिंग संबंधी समस्याएं बनी रहती हैं (आखिरकार, यह एक अपेक्षाकृत दुर्लभ परिदृश्य है, और इसमें निवेश करना अक्सर लाभहीन होता है)।

   
   

3. जड़ता. एक इन-हाउस टूल पर विचार करें जो किसी कंपनी के भीतर किसी समस्या का समाधान करता है। एक कंपनी जो सक्रिय रूप से इस उपकरण का उपयोग करती है, वह इसे अपनी आवश्यकताओं के अनुरूप बेहतर ढंग से तैयार करने के लिए संसाधनों को समर्पित करेगी, अंततः इसे एक अत्यधिक विशिष्ट उपकरण में बदल देगी। यह प्रक्रिया वर्षों तक चल सकती है.

   
   

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

   
   

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

   
   

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

   
   

5. व्यावसायिक निरंतरता। सच कहें तो, इस बिंदु को हाल ही में पर्याप्त महत्व मिला है। पहले, विक्रेता लॉक-इन के बारे में चिंताओं के कारण बहुत कम संख्या में कंपनियों ने इसे गंभीरता से लिया था। किसी ऐसे विक्रेता पर महत्वपूर्ण प्रक्रियाओं पर भरोसा करना जो किसी भी समय सहयोग समाप्त कर सकता है, जोखिम भरा है। JetBrains इसका एक प्रमुख उदाहरण है, जिसने अपने IDE के उपयोग को कुछ कंपनियों तक सीमित कर दिया है। एक अन्य मामला जीथब एंटरप्राइज का है, जिसने रूसी-आधारित उपयोगकर्ता खातों को निलंबित करना शुरू कर दिया है।

   
   

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

   
   

   साथ ही, मुद्दे का कानूनी पहलू खुले स्रोत को प्रभावित करता है: उदाहरण के लिए, गोलांग या के8 में प्रतिबद्धताओं के लिए सीएलए पर हस्ताक्षर करना आवश्यक हो जाता है। क्या यह मुद्दा बना रहेगा?

   
   

6. एनआईएच। हां, वस्तुनिष्ठ कारणों के अतिरिक्त यह संभव है कि लिए गए निर्णय व्यावहारिक न हों। यह एनआईएच सिंड्रोम अपने चरम पर है।

   
   

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

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