RubyRussia 2019: सर्वर रहित के बारे में निकोले Sverchkov

28 सितंबर को सम्मेलन में रूबिरसिया निकोलाई स्वेर्कोव एक प्रस्तुति करेंगे जो सर्वर रहित रूबी फ्यूचर है। इवान सोलोविओव ने एक साक्षात्कार में चर्चा की कि यह प्रवृत्ति दिलचस्प क्यों है, और क्यों रूबिस्टों को इस पर ध्यान देना चाहिए।




मुझे बताओ कि तुम रूबी के पास कैसे आए?

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

सर्वर रहित पर आपकी रिपोर्ट। आपने इस दिशा में काम करना कैसे शुरू किया? क्या प्रौद्योगिकी में प्रवेश मुश्किल है?

उन्होंने अपने खाली समय में अध्ययन करना शुरू किया। मेरे पास असली था, लेकिन मुख्य कार्य कार्य से संबंधित नहीं था। फिर उसने कंपनी की परियोजनाओं में सर्वर रहित का उपयोग करना शुरू कर दिया। प्रवेश सीमा काफी कम है, मुझे लगता है कि यह हरोकू की तुलना में थोड़ा अधिक है। अपना पहला लिखें "हैलो, दुनिया!" यह बहुत सरल होगा - अमेज़न से लेख, ट्यूटोरियल, अत्यंत समृद्ध प्रलेखन का एक समूह है। और फिर, ज़ाहिर है, तब कठिनाइयाँ होंगी। कुछ नुकसान हैं, मैं रिपोर्ट में उनमें से कुछ के बारे में बात करूंगा।

क्या शुरुआती लोगों को सर्वर रहित होना चाहिए और उत्पादन में इसका उपयोग करना चाहिए?

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

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

मुझे इस रूबी ढांचे के बारे में अधिक बताएं?

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

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

आप पूछते हैं कि हम अक्सर हमारी बातचीत में "लंबोदर" शब्द का उपयोग क्यों करते हैं? मुझे लगता है कि कहानी कर्चर या ज़ेरॉक्स के साथ है। ऐसे ब्रांड हैं जिनके नाम से उत्पादों की एक पूरी जगह पर कॉल करने की प्रथा है। 2014 में, अमेज़ॅन सर्वर-रहित कंप्यूटिंग मॉडल - AWS लैम्ब्डा के लिए सार्वजनिक पहुँच प्रदान करने वाला पहला था। बाकी सभी: Microsoft के साथ Azure Functions, Google with Cloud Function, IBM के साथ IBM Cloud Functions, अभी भी मानसिक रूप से पकड़ने की भूमिका में है। हालाँकि सर्वर रहित बाजार फलफूल रहा है, लेकिन AWS की सेवा की कीमतें अक्सर प्रतियोगियों से अधिक होती हैं। इसलिए नए रिलीज़, जैसे Google क्लाउड रन , खेल को रात भर चालू कर सकते हैं। यदि हम प्लेटफ़ॉर्म तुलनाओं का अधिक विस्तृत विश्लेषण करते हैं, तो मैं डीयूएमपी 2019 सम्मेलन से डेटाअर्ट से रुस्लान सेर्किन का वीडियो देखने की सलाह दूंगा ।

आप क्या सोचते हैं, सर्वरलेस किस दिशा में विकसित होगा?

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

क्या सर्वरहीन मोनोलिथ को मारेंगे?

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

वेंडर लॉक का क्या करें? उदाहरण के लिए, आपने अमेज़न के लिए एक लैम्ब्डा विकसित किया, लेकिन Google में जाने का फैसला किया।

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

कोड का उपयोग करते समय आम लैम्ब्डा के साथ क्या करना है? उदाहरण के लिए, कुछ सामान्य घटक, कुछ उपयोगितावादी कार्य, और इसी तरह।

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

हम रूबरूसिया पर रिपोर्ट के बाद अधिक विस्तार से चर्चा करेंगे!

आओ और तुम, पंजीकरण अभी भी खुला है, सम्मेलन अगले शनिवार, 28 सितंबर को आयोजित किया जाएगा।

केवल रिपोर्टें ही नहीं होंगी, बल्कि सबसे अच्छी कंपनियों के स्टैंड भी होंगे:

आयोजक - एवरोन
सामान्य साझेदार - शीर्षताल
गोल्ड पार्टनर - गेट
सिल्वर पार्टनर्स - वेलारम , जेटब्रेन , बुकमेट और कैशवगन
कांस्य भागीदार - InSales