सर्वर रहित एप्लिकेशन बनाने के लिए टिप्स और संसाधन

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

सर्वर रहित तकनीकों के बारे में गलत धारणाएँ

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

सर्वर रहित तकनीकों के पीछे मूल सिद्धांत यह है कि आपको अपने बुनियादी ढांचे के प्रबंधन और विस्तार के बारे में चिंता करने की ज़रूरत नहीं है, आप केवल उसी का भुगतान करते हैं जिसका आप उपयोग करते हैं। कई सेवाएँ इन मानदंडों पर खरी उतरती हैं - AWS DynamoDB, S3, SNS या SQS, Graphcool, Auth0, Now, Netlify, Firebase और कई अन्य। सामान्य तौर पर, सर्वर रहित का अर्थ है बुनियादी ढांचे का प्रबंधन करने और स्केलिंग के लिए इसे अनुकूलित करने की आवश्यकता के बिना क्लाउड कंप्यूटिंग की पूरी शक्ति का उपयोग करना। इसका मतलब यह भी है कि बुनियादी ढांचे के स्तर पर सुरक्षा अब आपकी चिंता नहीं है, जो कि सुरक्षा मानकों को पूरा करने की कठिनाई और जटिलता को देखते हुए एक बड़ा लाभ है। अंत में, आपको प्रदान किए गए बुनियादी ढांचे को खरीदने की ज़रूरत नहीं है।

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

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

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

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

विचार करना:

• आपको किन सेवाओं की आवश्यकता है और क्यों।
• क्लाउड प्रदाता कौन सी सेवाएं प्रदान करते हैं और आप उन्हें अपने चुने हुए FaaS समाधान के साथ कैसे जोड़ सकते हैं।
• कौन सी प्रोग्रामिंग भाषाओं का समर्थन किया जाता है (गतिशील या स्थिर टाइपिंग के साथ, संकलित या व्याख्या की गई, बेंचमार्क क्या हैं, कोल्ड स्टार्ट पर प्रदर्शन क्या है, ओपन सोर्स इकोसिस्टम क्या है, आदि)।
• आपकी सुरक्षा आवश्यकताएँ क्या हैं (SLA, 2FA, OAuth, HTTPS, SSL, आदि)।
• अपने सीआई/सीडी और सॉफ्टवेयर विकास चक्रों का प्रबंधन कैसे करें।
• आप किस इंफ्रास्ट्रक्चर-एज-कोड समाधान का लाभ उठा सकते हैं।

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

जब सर्वर रहित अच्छा है

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

लागत बचत और स्केलिंग में आसानी के कारण, सर्वर रहित समाधान आंतरिक और बाहरी दोनों प्रणालियों के लिए समान रूप से लागू होते हैं, एक बहु-मिलियन दर्शकों वाले वेब एप्लिकेशन तक। खातों को यूरो के बजाय सेंट में मापा जाता है। AWS EC2 (t1.micro) के सबसे सरल उदाहरण को एक महीने के लिए किराए पर लेने पर €15 का खर्च आएगा, भले ही आप इसके साथ कुछ न करें (जो इसे बंद करना कभी नहीं भूले?!)। इसकी तुलना में, इसी अवधि में खर्च के इस स्तर तक पहुंचने के लिए, आपको 512 एमबी लैम्ब्डा को 1 सेकंड के लिए लगभग 3 मिलियन बार चलाने की आवश्यकता होगी। और यदि आप इस सुविधा का उपयोग नहीं करते हैं, तो आप कुछ भी भुगतान नहीं करते हैं।

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

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

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

हालांकि एडब्ल्यूएस जारी किया सर्वर रहित SQL डेटाबेस सर्वर रहित अरोराहालाँकि, SQL डेटाबेस इस एप्लिकेशन के लिए आदर्श नहीं हैं, क्योंकि वे लेन-देन करने के लिए कनेक्शन पर निर्भर करते हैं, जो AWS लैम्ब्डा पर भारी ट्रैफ़िक के साथ जल्दी से एक अड़चन बन सकता है। हां, डेवलपर्स सर्वर रहित अरोरा में लगातार सुधार कर रहे हैं, और आपको इसके साथ प्रयोग करना चाहिए, लेकिन आज NoSQL समाधान जैसे DynamoDB. हालांकि, इसमें कोई शक नहीं है कि यह स्थिति बहुत जल्द बदलेगी।

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

विकास चक्र पर सर्वर रहित प्रौद्योगिकियों का प्रभाव

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

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

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

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

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

जबकि टूलकिट बेहतर हो सकता है (यह हर दिन बेहतर होता जाता है), डेवलपर्स व्यावसायिक तर्क को लागू करने और आर्किटेक्चर के भीतर विभिन्न सेवाओं में एप्लिकेशन की जटिलता को सर्वोत्तम रूप से वितरित करने पर ध्यान केंद्रित कर सकते हैं। सर्वर रहित अनुप्रयोग प्रबंधन क्लाउड प्रदाता (जैसे SQS, S3 ईवेंट या DynamoDB स्ट्रीम) द्वारा ईवेंट आधारित और अमूर्त है। इसलिए, डेवलपर्स को केवल कुछ घटनाओं का जवाब देने के लिए व्यावसायिक तर्क लिखने की आवश्यकता होती है, और इस बारे में चिंता करने की ज़रूरत नहीं है कि डेटाबेस और संदेश कतारों को कैसे लागू किया जाए, या विशिष्ट हार्डवेयर स्टोरेज में डेटा के साथ इष्टतम कार्य कैसे व्यवस्थित किया जाए।

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

सर्वर रहित अनुप्रयोगों के निर्माण के लिए उपकरण और तकनीकें

सर्वर रहित एप्लिकेशन बनाने का कोई विशिष्ट तरीका नहीं है। साथ ही इस कार्य के लिए सेवाओं का एक सेट। AWS आज शक्तिशाली सर्वर रहित समाधानों में अग्रणी है, लेकिन इसे भी देखें Google मेघ, Zeit и Firebase. यदि आप AWS का उपयोग कर रहे हैं, तो एप्लिकेशन एकत्र करने के लिए अनुशंसित तरीका है सर्वरहित अनुप्रयोग मॉडल (एसएएम), विशेष रूप से सी # का उपयोग करते समय, क्योंकि विजुअल स्टूडियो में बहुत अच्छी टूलिंग है। एसएएम सीएलआई वह सब कुछ कर सकता है जो विजुअल स्टूडियो कर सकता है, इसलिए यदि आप किसी अन्य आईडीई या टेक्स्ट एडिटर पर स्विच करते हैं तो आप कुछ भी नहीं खोएंगे। बेशक, एसएएम अन्य भाषाओं के साथ भी काम करता है।

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

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

तैनात पैकेजों के आकार को कम करने और डाउनलोड को गति देने के लिए AWS लैम्ब्डा लेयर्स का उपयोग करें।

विशिष्ट कार्यों के लिए सही प्रोग्रामिंग भाषाओं का प्रयोग करें। अलग-अलग भाषाओं के अपने-अपने फायदे और नुकसान हैं। कई बेंचमार्क हैं, लेकिन AWS लैम्ब्डा प्रदर्शन के मामले में जावास्क्रिप्ट, पायथन और C# (.NET Core 2.1+) अग्रणी हैं। AWS लैम्ब्डा ने हाल ही में रनटाइम एपीआई पेश किया है, जो आपको अपनी वांछित रनटाइम भाषा और वातावरण निर्दिष्ट करने की अनुमति देता है, इसलिए प्रयोग करें।

परिनियोजन के लिए पैकेज का आकार छोटा रखें। वे जितने छोटे होते हैं, उतनी ही तेजी से लोड होते हैं। बड़े पुस्तकालयों का उपयोग करने से बचें, खासकर यदि आप उनकी कुछ विशेषताओं का उपयोग करते हैं। यदि आप जावास्क्रिप्ट में प्रोग्रामिंग कर रहे हैं, तो अपने बिल्ड को ऑप्टिमाइज़ करने के लिए वेबपैक जैसे बिल्ड टूल का उपयोग करें और केवल वही शामिल करें जिसकी आपको वास्तव में आवश्यकता है। .NET Core 3.0 में QuickJit और Tiered Compilation है जो प्रदर्शन में सुधार करता है और ठंड शुरू होने पर बहुत मदद करता है।

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

निष्कर्ष

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

स्रोत: www.habr.com