OTUS शैक्षिक परियोजना में DevOps प्रथाओं और उपकरण पाठ्यक्रम के छात्रों के लिए लेख का अनुवाद तैयार किया गया था।

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

चलो माइक्रोसेर्विसेज के लिए क्यों के बारे में बात करते हैं

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

ऐसे समय थे, जब सर्वर की उच्च लागत के कारण, एकल सर्वर पर संपूर्ण एप्लिकेशन को तैनात करना आम था। एक मोनोलिथ को तैनात करने का मतलब था कि सर्वर पर आप भाग या सभी एप्लिकेशन को तैनात कर रहे थे।

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

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

एक सर्वर / उदाहरण पर सभी लॉजिक के साथ एक मोनोलिथ बनाने के बजाय, आप विभिन्न सर्वरों पर एप्लिकेशन के कुछ हिस्सों को रख सकते हैं और उन्हें किसी प्रकार के हल्के प्रोटोकॉल का उपयोग करके जोड़ सकते हैं - आमतौर पर एक HTTP एपीआई।

इस प्रकार, एप्लिकेशन आर्किटेक्चर मोनोलिथ से माइक्रोसर्विस में स्थानांतरित हो गया है।

हालांकि, मुझे आश्चर्य है कि क्यों? इस दृष्टिकोण का मूल्य यह है कि कोड को संपादित करते समय आप पूरे एप्लिकेशन के कोड आधार को नहीं बदलते हैं, लेकिन माइक्रो-सर्विस - केवल आवेदन का घटक भाग होता है। इसका मतलब है कि आप पूरे एप्लिकेशन को नहीं तोड़ सकते।

हालांकि यह केवल सैद्धांतिक रूप से है, लेकिन यह सिद्धांत एक मोनोलिथ से बेहतर है, हालांकि यह आदर्श नहीं है।

हर सेवा के लिए एक महत्वपूर्ण तत्व है ...

सेवा इंटरफ़ेस

यह अक्सर HTTP इंटरफ़ेस का कुछ रूप है (कम से कम यह सबसे आम दृष्टिकोण है)। एक नियम के रूप में, यह एक समस्या नहीं है, सिवाय इसके कि जब आपके पास बड़ी संख्या में सेवाएं हों और उनके समन्वय की समस्या हो सकती है।

सर्वरहित वास्तुकला की ओर बढ़ रहा है

इसलिए, AWS पर सर्वरहित अनुप्रयोगों के निर्माण के लिए प्रारंभिक दृष्टिकोण "चलो माइक्रोसिस्टर्स बनाएँ" था ...

इसका मतलब था कि इसके पीछे लैंबडा फ़ंक्शन के साथ गेटवे एपीआई और एक स्विच स्टेटमेंट जो राउटर के रूप में कार्य करता है।

प्रत्येक गेटवे एपीआई एक सेवा इंटरफ़ेस बन गया, और यह तर्कसंगत लग रहा था।

आप कई सेवाओं को एक-दूसरे से अलग कर सकते हैं, जो कुछ मामलों में बहुत महत्वपूर्ण हो सकते हैं।

सिवाय इसके कि कोई मतलब नहीं है जब आपको पता चलता है कि सामान्य रूप से AWS लैम्ब्डा और FaaS फ़ंक्शन को एक उदाहरण / सर्वर के रूप में नहीं माना जाना चाहिए।

क्योंकि हालांकि उनके पास हुड के तहत सर्वर हैं (हे, इंटरनेट पर काम करने वाली अधिकांश चीजों के तहत सर्वर हैं, लेकिन कोई भी नहीं कहता है कि "एस 3 में अभी भी सर्वर हैं" या "बिगटेबल में अभी भी सर्वर हैं" या "एज़्योर एक्टिव डायरेक्टरी सभी" अभी भी सर्वर "...) है, एक राय है कि आपको फ़ॉएस फ़ंक्शन का इलाज उसी सेवा के रूप में करना चाहिए ..." मिनिलिथ ", जैसा कि कुछ कहते हैं।

समस्या यह है कि यहाँ क्या याद आ रही है, मेरी राय में, सर्वर रहित वास्तुकला की कुंजी है:

सर्वरहित वास्तुकला सभी घटनाओं के बारे में है

सर्वर रहित वास्तुकला, घटनाएँ, और ट्रिगर

सर्वर रहित सिस्टम स्वाभाविक रूप से ईवेंट संचालित सिस्टम हैं, और इसलिए ईवेंट संचालित आर्किटेक्चर के प्रतिनिधि हैं। यह डिजाइन, प्रबंधन और वास्तुकला के लिए आपके दृष्टिकोण को बदल देता है।

माइक्रोसर्विसेज के मामले में, लब्बोलुआब यह है कि एक इंटरफ़ेस का जवाब देना है - यह तर्क के साथ बातचीत करने का मुख्य तंत्र है।

सर्वर रहित समाधान घटनाओं के जवाब के बारे में है, और एपीआई वास्तव में घटनाओं को उत्पन्न करने के लिए एक तंत्र है।

AWS इकोसिस्टम के एक हिस्से के रूप में, जो सर्वर रहित समाधानों में सबसे परिपक्व है, एपीआई को प्राथमिक इंटरफ़ेस के रूप में नहीं देखा जाता है। घटनाएँ अधिक महत्वपूर्ण हैं।

और यही कारण है कि लगभग 50 घटनाएं हैं जो अन्य AWS सेवाओं से लैंबडा फ़ंक्शन को ट्रिगर कर सकती हैं।

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

सर्वरलेस बेस्ट प्रैक्टिसेस पर एक नज़र डालें, आपको कई बिंदु दिखाई देंगे जो कि कितने डिज़ाइन माइक्रोसर्विसेस से भिन्न हैं।

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

डेटा लेयर को विभिन्न तरीकों से प्रबंधित और समझा भी जाता है। सबसे अच्छा अभ्यास एक स्विच स्टेटमेंट के साथ एक से अधिक प्रॉक्सी फ़ंक्शन के बजाय कई फ़ंक्शन हैं।

कई कार्यों का विचार भी माइक्रोसिस्टीवर्स पर अतिरिक्त लाभ प्रदान करता है। यदि कोई फ़ंक्शन एक त्रुटि फेंकता है, तो यह केवल इस फ़ंक्शन को प्रभावित करेगा, और बाकी एप्लिकेशन को नहीं, क्योंकि फ़ंक्शन की कोई स्थिति नहीं है (कम से कम यह होना चाहिए!)। और यह "मिनिलिथ" न करने का एक बहुत अच्छा कारण है!

इसलिए, हालांकि सर्वर रहित निर्माण में अनुभव आपको सर्वरहित समाधानों को डिजाइन करते समय कुछ फायदे देता है, वास्तव में आप सर्वर के अनुप्रयोगों को मूल्यवान बना सकते हैं।

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

माइक्रोसर्विस से सर्वरलेस आर्किटेक्चर तक का रास्ता

तो, microservices से सर्वर रहित समाधान के लिए रास्ता क्या है? वहाँ एक त्वरित तरीका है कि मूल बातें जानने के लिए एक से दूसरे में संक्रमण को आसान बनाने के लिए, क्योंकि माइक्रोसिस्टर्स व्यापक हैं?

मुझे लगता है कि यह सर्वर रहित दुनिया है। हाल ही में ट्विटर पर एक बड़ी चर्चा हुई जिसमें हमने इस विषय पर बात की। यहाँ यह इसका उल्लेख करने योग्य है, यदि केवल यह देखने के लिए कि समुदाय किस बारे में बात कर रहा है (विभिन्न उत्तरों को देखें और आप इस विषय पर कई राय देखेंगे, हालांकि कोई भी सीधे तौर पर माइक्रोसर्विस का उल्लेख नहीं करता है)।

वे कुछ उपकरणों के बारे में बात करते हैं जिन्हें सर्वर रहित अनुप्रयोगों के निर्माण की सुविधा के लिए कहा जाएगा, लेकिन अंत में वे मंच बन जाएंगे, जिस पर आपको सब कुछ बनाना होगा। मुझे नहीं लगता कि इससे वास्तुशिल्प शैली को बेहतर ढंग से समझने में किसी को फायदा होगा या मदद मिलेगी।

एक समुदाय के रूप में, हम समझते हैं कि सर्वर रहित वास्तुकला भविष्य है। लेकिन पुरानी वास्तुशिल्प शैलियों से संक्रमण हमेशा आसान नहीं होगा, भले ही सर्वर रहित वास्तुकला सही (और कभी-कभी सही नहीं) विकल्प हो।

इसका एक कारण है। किसी व्यक्ति की सोच को बदलना इतना आसान नहीं है। लैंबडा फंक्शन बनाना आसान है। लेकिन एक अच्छी तरह से डिज़ाइन किया गया सर्वर रहित एप्लिकेशन बनाना आसान नहीं है। क्योंकि इसके लिए सोच में बदलाव की आवश्यकता है, और यह अपेक्षाकृत कठिन है।

और जैसा कि मैंने कई बार कहा है, हमें लोगों को "हैलो वर्ल्ड" एप्लिकेशन पढ़ाना बंद करना चाहिए और इस पर रोक देना चाहिए क्योंकि बहुत से लोग सोचते हैं कि यह उनके लिए पर्याप्त होगा।

सर्वरलेस बेस्ट प्रैक्टिसेस को लिखने का कारण लोगों को यह समझने में मदद करना था कि उन्हें वर्तमान ज्ञान के आधार पर सर्वर रहित एप्लिकेशन बनाने के बारे में धारणा नहीं बनानी चाहिए।

सर्वर जो हम अब सर्वर रहित समाधान बनाने के लिए उपयोग करते हैं, वही उपकरण हैं जो हम "क्लाउड 1.0" एप्लिकेशन बनाने के लिए उपयोग करते हैं, लेकिन वे इन उद्देश्यों के लिए पूरी तरह से उपयुक्त नहीं हैं। ये उपकरण अपूर्ण हैं, लेकिन हम उन्हें समझाने और यथासंभव अच्छे बनाने की कोशिश कर रहे हैं।

हमें आपसे क्या चाहिए

मुझे लगता है कि समुदाय, वास्तव में, सर्वर रहित समाधान बनाने में लोगों को प्रशिक्षण और विकास में मदद करने के लिए बहुत खुला है।

इसलिए, एक समुदाय के रूप में, हमें आपके प्रश्नों की आवश्यकता है:
- आपकी मुश्किलें क्या हैं?
- अंतराल कहां हैं?
- क्या ट्यूटोरियल गायब हैं?

और ऐसा ही कुछ।

मैं कंपनियों को यह परिवर्तन करने में मदद करने के लिए तैयार हूं। मैंने वरिष्ठ प्रबंधन, सीटीओ और सीईओ के साथ काम करके यह निर्धारित करने में मदद की कि एक सर्वर रहित दृष्टिकोण का उपयोग करके कंपनी किस मूल्य का निर्माण करती है, और मुझे इन कंपनियों की मदद करने में खुशी होती है।

मैं मदद करने के लिए बहुत खुश हूं। लिंक्डइन से संपर्क करें ।