लेट स्टेज माइक्रोसर्विसेज
मैंने अमेज़ॅन प्राइम वीडियो टीम के माइक्रोसर्विसेज को एक मोनोलिथ में जोड़कर लागत को 90% तक बढ़ाने और कम करने के प्रयास के बारे में पढ़ा। जबकि मुझे यकीन है कि यहाँ कहानी के लिए और भी बहुत कुछ है, इंटरनेट पर इसी तरह की कहानियाँ प्रकाशित हुई हैं; पिछले दशक के माइक्रोसर्विसेज क्रेज का एक प्रकार का खंडन।
इसने मुझे ट्विटर पर बिताए पिछले कुछ वर्षों की याद दिला दी, जहां ट्रैफ़िक बढ़ने के बावजूद माइक्रोसर्विसेज (हजारों में) की संख्या चरम पर थी और फिर गिरना शुरू हो गई। सभी प्रकार के अनुप्रयोग तर्क एक प्रकार या किसी अन्य के अखंड प्रबंधित प्लेटफार्मों में समाहित हो गए थे। उद्देश्य-निर्मित माइक्रोसर्विसेज बनाने का सिद्धांत आंतरिक रूप से अच्छा नहीं है, और एक निश्चित बिंदु के बाद, हमारी कई टीमों के लिए भी सकारात्मक आरओआई नहीं लगता है।
एक माइक्रोसर्विस आर्किटेक्चर महंगा हो सकता है। पिछले एक दशक में एक कथा रही है कि यह बड़े इंजीनियरिंग संगठनों के लिए एक स्वाभाविक नीति है, क्योंकि:
- टीमें व्यापक संगठन और उसके कोड से स्वायत्तता के साथ अपनी सेवाओं पर पुनरावृति कर सकती हैं
- सर्विंग आर्किटेक्चर के छोटे घटकों को बड़े सिस्टम में व्यवधान के बिना संशोधित किया जा सकता है
- आर्किटेक्चर स्वतंत्र सेवाओं के माध्यम से स्पष्ट, प्रबंधनीय अनुप्रयोग और विफलता डोमेन की परिभाषा की अनुमति देता है
- आर्किटेक्चर स्वतंत्र रूप से ट्यून करने योग्य या स्केलेबल वर्कलोड की अनुमति देता है
किसी को काम की जटिलता के लिए हिसाब देना पड़ता है जो छोटी सेवा वाली टीमों और व्यापक पारिस्थितिकी तंत्र के परिणामस्वरूप होता है - एक विलक्षण या छोटी संख्या में मोनोलिथ के विपरीत। ऑफलोड किया गया कार्य संगठन के प्रौद्योगिकी स्टैक की परिपक्वता पर निर्भर करता है; लेकिन इसमें शामिल हो सकते हैं:
सभी सेवा-स्वामित्व वाली टीमों के बीच परिचालन संबंधी ज़िम्मेदारियों और ओवरहेड को वितरित किया
- जॉब शेड्यूलिंग और डिप्लॉयमेंट टूल्स, सर्विस डिस्कवरी, आरपीसी फ्रेमवर्क, वीएम और संबंधित ट्यूनिंग, सर्विस मॉनिटरिंग और लॉगिंग से सर्विस इंफ्रास्ट्रक्चर घटकों की समझ और कॉन्फ़िगरेशन
- एसएलओ और एसएलआई के लिए वितरित परिभाषाएं और विकास प्रक्रियाएं, सेवा विफलता और गलती से निपटने, बैकप्रेशर से निपटने और त्रुटि संकेतन
- वितरित और अक्सर असंगठित क्षमता योजना, भार परीक्षण, एकीकरण परीक्षण कार्यान्वयन और जिम्मेदारियां
- एप्लिकेशन लॉजिक जो कई बैकएंड सेवाओं के साथ इंटरैक्ट करता है, अक्सर बीस्पोक सर्विस एपीआई परिभाषाओं, सिमेंटिक्स, डेटा मॉडल, वर्जनिंग सिस्टम और कभी-कभी अलग-अलग प्रोटोकॉल की एक श्रृंखला को नेविगेट करता है।
- कार्यात्मक चीजों के निर्माण के लिए इंजीनियरों को समग्र सेवा वास्तुकला और यातायात पैटर्न के बारे में समझना और तर्क देना चाहिए
- सबऑप्टिमल या टोंटी वाले सर्विंग पाथ, वितरित डेटा प्रतिकृति और खपत, सर्कुलर अनुरोध निर्भरता के लिए ऑर्गेनिक वर्कअराउंड
- अनुमान और रैंकिंग, इवेंट प्रोसेसिंग, एचटीटीपी/इंटरनल प्रोटोकॉल एपीआई ट्रांसलेशन और डेटा मॉडल मैपिंग की समस्याओं के लिए स्थानीय दृष्टिकोण
- सामान्य विखंडन और ढेर में मानकों को पकड़ना मुश्किल है
समस्या यह है कि एक नई सेवा के निर्माण, निर्माण और संचालन की प्रक्रिया महंगी है । उत्पादन सेवारत वास्तुकला में उस सेवा का एकीकरण कठिन है। कुशल संचालन के लिए किसी अन्य सेवा को ट्यून करने के लिए आवश्यक ध्यान ; संबंधित सेवा खातों को स्थापित करने के लिए, अवलोकन और लॉगिंग प्रोफाइल, एकीकरण परीक्षण, ऑनकॉल रोटेशन और बाकी सब कुछ टीम के रखरखाव और परिचालन ओवरहेड में जोड़ता है। अधिकांश संगठनों में इस तरह के जटिल बॉयलरप्लेट कार्य के लिए स्वचालन और एंड-टू-एंड मचान की कमी है।
यह ओवरहेड टीमों के लिए " एक काम अच्छी तरह से करें " के UNIX- प्रेरित माइक्रोसर्विस आर्किटेक्चरल सिद्धांत से चिपके रहने के लिए एक प्रमुख निस्संक्रामक है। मौजूदा सेवाओं में नए उपयोग के मामले बनाना बहुत आसान है। स्पेक्ट्रम के सबसे दूर के छोर पर, टीमें "मैक्रो" सेवाओं का संचालन करती हैं, जो एक टीम के रूप में जिम्मेदार होने वाली हर चीज को इनकैप्सुलेट करना शुरू कर देती हैं, जिसमें विभिन्न प्रकार के उत्पाद या क्षमताएं शामिल हो सकती हैं। स्वामित्व की गुणवत्ता समय के साथ गिरती है, क्योंकि पुनर्गठन एक अपेक्षाकृत सामान्य घटना है। आप मिट्टी के गोले के साथ काम कर रहे हैं।
मैक्रो-सर्विस आउटेज एक विशिष्ट सुविधा सेट तक सीमित नहीं हैं, बल्कि इसके बजाय सिस्टम का एक अप्रत्याशित या असैद्धांतिक स्वाथ है, जो ऐतिहासिक ऑर्ग चार्ट के समान हो सकता है। साइट इन सेवाओं के अनुपलब्ध होने को सहन कर भी सकती है और नहीं भी। विषम कार्यभार के लिए सेवाओं का अनुकूलन करना कठिन है; कॉल पथों को अलग नहीं किया जा सकता है। एक पूर्व सहयोगी ने इसे "माइक्रोलिथ" बनाया।
माइक्रोसर्विसेज सर्विंग आर्किटेक्चर में स्थानीय अनुकूलन को एनकोड और प्रोत्साहित करते हैं। जब लक्ष्य सेवा विकास का संघ हो तो सेवा वास्तुकला के लिए एक सैद्धांतिक डिजाइन के लिए टीमों को जवाबदेह ठहराना कठिन है। इसी तरह, बैकएंड-वाइड ऑप्टिमाइज़ेशन समस्याओं को हल करना मुश्किल है, जब निर्भर सेवाओं के गुण बीस्पोक होते हैं। सावधानीपूर्वक डिज़ाइन किए गए सर्विंग आर्किटेक्चर और सपोर्टिंग सर्विस प्लेटफॉर्म के बिना, लीवरेज को खोजना मुश्किल है - पुन: प्रयोज्य उत्पाद प्लेटफॉर्म कोड बड़ी-ईश सेवाओं या साझा पुस्तकालयों की एक श्रृंखला में बिखरा हुआ है ; फ्रंटएंड सेवाएं आमतौर पर बीस्पोक होती हैं।
माइक्रोसर्विस लीवरेज को कंप्यूट लेयर (जो कुछ भी ऑर्केस्ट्रेटिंग और सर्विस जॉब या कंटेनर निष्पादित कर रहा है), सर्विस डिस्कवरी, VM (कुछ संदर्भों में लागू) सर्विस फ्रेमवर्क (जैसे gRPC , Finagle या Rest.Li ) और केंद्रीकृत डेवलपर टूलिंग में पाया गया है। बेशक, सर्विस मेश इनमें से कुछ चिंताओं को अच्छी तरह से समझाता है।
इन समस्याओं से निपटने का दूसरा तरीका कार्यात्मक ओवरहेड को कम कर रहा है। इसलिए सेवा चलाने के बार-बार होने वाले बुनियादी ढांचे के ओवरहेड को कम करने की कोशिश करने के बजाय , आप काम की सामान्य कक्षाओं को फिर से लागू करने वाली टीमों की लागत को कम कर सकते हैं । यही कारण है कि प्रबंधित प्लेटफ़ॉर्म इतने सफल होते हैं - भले ही किसी सेवा का निर्माण या संचालन महंगा हो, अगर हम किसी सार्वजनिक या निजी प्रबंधित प्लेटफ़ॉर्म को आउटसोर्स करके इसके एप्लिकेशन लॉजिक को कम कर सकते हैं, तो यह अपनी टीम पर बोझ कम हो जाता है।
संगठनों के लिए यह महत्वपूर्ण है कि वे अपनी विशिष्ट आवश्यकताओं, लक्ष्यों और प्रौद्योगिकी स्टैक की परिपक्वता के आधार पर आर्किटेक्चरल ट्रेड-ऑफ का सावधानीपूर्वक मूल्यांकन करें। माइक्रोसर्विसेज कुछ लाभ प्रदान करते हैं। वे जटिलताओं और परिचालन ओवरहेड का भी परिचय देते हैं जो पहली बार में प्रबंधनीय लगते हैं, लेकिन समय के साथ जटिल हो जाते हैं। उन समस्याओं को दूर करने में विफलता एक मोनोलिथ में काम करने की तुलना में एंड-टू-एंड विकास प्रक्रिया को थोड़ा आसान बनाती है।
कुछ बातों को ध्यान में रखना चाहिए, खासकर यदि आप एक पुराने माइक्रोलिथ के साथ काम कर रहे हैं:
- "बड़ी सेवाएं" या मोनोलिथ आवश्यक रूप से खराब नहीं हैं; उन्हें माइक्रोसर्विसेज की तुलना में एक अलग तरह के टूलिंग, इन्फ्रा सपोर्ट और सिद्धांतों के सेट की आवश्यकता होती है, लेकिन उन्हें सर्विंग आर्किटेक्चर के अच्छी तरह से परिभाषित सामान्य तत्वों को पकड़ने के लिए बनाया जाना चाहिए।
- "एक कार्य, एक सेवा" के सिद्धांत की वकालत तंग सहयोग, प्रदर्शन चिंताओं और विशिष्ट विफलता डोमेन के क्षेत्रों के आसपास सहज सीमाओं को चित्रित करने और टीमों को योजना से चिपके रहने के लिए धकेलने की तुलना में बहुत कम व्यावहारिक है।
- आप "बहुत अधिक सेवाओं" की जटिलताओं और ओवरहेड को कम कर सकते हैं या तो स्टैक सेवा मालिकों की ऊर्ध्वाधर गहराई को कम कर सकते हैं (सेवा ढांचे, सेवा जाल, गणना), साथ ही साथ प्रबंधित सेवाओं के माध्यम से आवेदन स्थान की अवधि या सामान्य वर्कफ़्लोज़ के लिए प्लेटफ़ॉर्म