सर्व्हरलेस ऍप्लिकेशन तयार करण्यासाठी टिपा आणि संसाधने

अलिकडच्या वर्षांत सर्व्हरलेस तंत्रज्ञानाने झपाट्याने लोकप्रियता मिळवली असली तरी, त्यांच्याशी संबंधित अनेक गैरसमज आणि चिंता अजूनही आहेत. जेव्हा सर्व्हरलेस तंत्रज्ञानाचा विचार केला जातो तेव्हा विक्रेता अवलंबित्व, टूलिंग, खर्च व्यवस्थापन, कोल्ड स्टार्ट, मॉनिटरिंग आणि डेव्हलपमेंट लाइफसायकल हे सर्व चर्चेचे विषय आहेत. या लेखात, आम्ही नमूद केलेले काही विषय एक्सप्लोर करू, तसेच नवशिक्यांना शक्तिशाली, लवचिक आणि किफायतशीर सर्व्हरलेस अॅप्लिकेशन्स तयार करण्यात मदत करण्यासाठी उपयुक्त संसाधनांच्या टिपा आणि लिंक्स शेअर करू.

सर्व्हरलेस तंत्रज्ञानाबद्दल गैरसमज

बर्‍याच लोकांचा असा विश्वास आहे की सर्व्हरलेस आणि सर्व्हरलेस डेटा प्रोसेसिंग (सेवा म्हणून कार्ये, FaaS) जवळजवळ समान गोष्टी आहेत. याचा अर्थ असा की फरक फार मोठा नाही आणि नवीन उत्पादन सादर करणे योग्य आहे. जरी AWS Lambda सर्व्हरलेस तंत्रज्ञानाच्या उदयातील एक तारा आणि सर्व्हरलेस आर्किटेक्चरच्या सर्वात लोकप्रिय घटकांपैकी एक होता, तरीही या आर्किटेक्चरमध्ये FaaS पेक्षा बरेच काही आहे.

सर्व्हरलेसचे मुख्य तत्व हे आहे की तुम्हाला तुमची पायाभूत सुविधा व्यवस्थापित करण्याची किंवा स्केल करण्याबद्दल काळजी करण्याची गरज नाही; तुम्ही जे वापरता त्यासाठीच तुम्ही पैसे द्या. अनेक सेवा या निकषांमध्ये बसतात - AWS DynamoDB, S3, SNS किंवा SQS, Graphcool, Auth0, Now, Netlify, Firebase आणि इतर अनेक. सर्वसाधारणपणे, सर्व्हरलेस म्हणजे स्केलिंगच्या फायद्यासाठी पायाभूत सुविधा व्यवस्थापित आणि ऑप्टिमाइझ न करता क्लाउड कॉम्प्युटिंगच्या सर्व क्षमता वापरणे. याचा अर्थ असा आहे की पायाभूत सुविधांच्या पातळीवर सुरक्षा ही आता तुमची समस्या नाही, जी सुरक्षा मानकांची पूर्तता करण्यात अडचण आणि जटिलता लक्षात घेऊन एक मोठा फायदा आहे. शेवटी, तुम्हाला प्रदान केलेल्या पायाभूत सुविधा खरेदी करण्याची गरज नाही.

सर्व्हरलेस ही "मनाची स्थिती" मानली जाऊ शकते: उपाय डिझाइन करताना एक विशिष्ट मानसिकता. कोणत्याही पायाभूत सुविधांची देखभाल आवश्यक असणारे दृष्टिकोन टाळा. सर्व्हरलेस पध्दतीने, आम्ही प्रकल्पावर थेट परिणाम करणार्‍या आणि आमच्या वापरकर्त्यांना मूल्य मिळवून देणार्‍या समस्यांचे निराकरण करण्यात वेळ घालवतो: मजबूत व्यवसाय तर्क तयार करणे, वापरकर्ता इंटरफेस विकसित करणे आणि प्रतिसादात्मक आणि विश्वासार्ह API विकसित करणे.

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

क्लाउड ऍप्लिकेशन्स विकसित करताना काही लोक विक्रेत्याच्या अवलंबनामुळे गोंधळलेले असतात. सर्व्हरलेस तंत्रज्ञानाच्या बाबतीतही असेच आहे आणि हे चुकीच्या समजुतीचे परिणाम असण्याची शक्यता नाही. आमच्या अनुभवानुसार, AWS वर सर्व्हरलेस ऍप्लिकेशन्स तयार करणे, AWS Lambda ची इतर AWS सेवा एकत्रित करण्याच्या क्षमतेसह, सर्व्हरलेस आर्किटेक्चर्सला उत्कृष्ट बनविण्याचा एक भाग आहे. हे समन्वयाचे एक चांगले उदाहरण आहे, जेव्हा संयोगाचा परिणाम त्याच्या भागांच्या बेरीजपेक्षा जास्त असतो. विक्रेता लॉक-इन टाळण्याचा प्रयत्न केल्यास आणखी समस्या उद्भवू शकतात. कंटेनरसह काम करताना, क्लाउड प्रदात्यांमध्ये तुमचा स्वतःचा अ‍ॅब्स्ट्रॅक्शन लेयर व्यवस्थापित करणे सोपे आहे. परंतु जेव्हा सर्व्हरलेस सोल्यूशन्सचा विचार केला जातो, तेव्हा प्रयत्नांचे फळ मिळणार नाही, विशेषत: जर तुम्ही सुरुवातीपासूनच किंमत-प्रभावीपणाचा विचार केला तर. विक्रेते सेवा कशा देतात हे शोधण्याची खात्री करा. काही विशेष सेवा इतर विक्रेत्यांसह एकत्रीकरण बिंदूंवर अवलंबून असतात आणि बॉक्सच्या बाहेर प्लग-अँड-प्ले कनेक्टिव्हिटी प्रदान करू शकतात. काही कंटेनर किंवा EC2 उदाहरणांना विनंती प्रॉक्सी करण्यापेक्षा गेटवे API एंडपॉईंटवरून Lambda कॉल प्रदान करणे सोपे आहे. Graphcool Auth0 वापरून सोप्या कॉन्फिगरेशनला अनुमती देते, जे थर्ड-पार्टी ऑथेंटिकेशन टूल्स वापरण्यापेक्षा सोपे आहे.

तुमच्या सर्व्हरलेस ऍप्लिकेशनसाठी योग्य विक्रेता निवडणे हा एक वास्तु-स्तरीय निर्णय आहे. तुम्ही एखादे अॅप्लिकेशन तयार करता तेव्हा, तुम्ही एक दिवस सर्व्हर व्यवस्थापित करण्यासाठी परत येण्याची अपेक्षा करत नाही. क्लाउड विक्रेता निवडणे हे कंटेनर किंवा डेटाबेस किंवा प्रोग्रामिंग भाषा वापरण्यापेक्षा वेगळे नाही.

विचार करा:

• आपल्याला कोणत्या सेवांची आवश्यकता आहे आणि का.
• क्लाउड प्रदाते कोणती सेवा देतात आणि तुम्ही निवडलेल्या FaaS सोल्यूशनचा वापर करून तुम्ही त्या कशा एकत्र करू शकता.
• कोणत्या प्रोग्रामिंग भाषा समर्थित आहेत (गतिशीलपणे किंवा स्थिरपणे टाइप केलेल्या, संकलित किंवा व्याख्या, बेंचमार्क काय आहेत, कोल्ड स्टार्ट कार्यप्रदर्शन काय आहे, ओपन सोर्स इकोसिस्टम काय आहे इ.).
• तुमच्या सुरक्षा आवश्यकता काय आहेत (SLA, 2FA, OAuth, HTTPS, SSL, इ.).
• तुमची CI/CD आणि सॉफ्टवेअर डेव्हलपमेंट सायकल कशी व्यवस्थापित करावी.
• तुम्ही कोणत्या इन्फ्रास्ट्रक्चर-एज-कोड सोल्यूशन्सचा लाभ घेऊ शकता?

जर तुम्ही विद्यमान ऍप्लिकेशनचा विस्तार करत असाल आणि सर्व्हरलेस फंक्शन्स वाढीव प्रमाणात जोडत असाल, तर हे काही प्रमाणात उपलब्ध क्षमता मर्यादित करू शकते. तथापि, जवळजवळ सर्व सर्व्हरलेस तंत्रज्ञान काही प्रकारचे API (REST किंवा संदेश रांगेद्वारे) प्रदान करतात जे तुम्हाला ऍप्लिकेशन कोरपासून स्वतंत्र आणि सुलभ एकत्रीकरणासह विस्तार तयार करण्यास अनुमती देतात. स्पष्ट API, चांगले दस्तऐवज आणि मजबूत समुदाय असलेल्या सेवा शोधा आणि तुम्ही चुकीचे होऊ शकत नाही. एकत्रीकरणाची सुलभता ही बहुधा मुख्य मेट्रिक असू शकते आणि 2015 मध्ये लॅम्बडा बाहेर आल्यापासून AWS यशस्वी होण्याचे मुख्य कारण आहे.

सर्व्हरलेस केव्हा उपयुक्त आहे?

सर्व्हरलेस तंत्रज्ञान जवळजवळ कुठेही वापरले जाऊ शकते. तथापि, त्यांचे फायदे केवळ अर्जाच्या पद्धतींपुरते मर्यादित नाहीत. क्लाउड कॉम्प्युटिंगसाठी प्रवेशाचा अडथळा आज अगदी कमी आहे कारण सर्व्हरलेस तंत्रज्ञानामुळे. जर विकसकांना कल्पना असेल, परंतु त्यांना क्लाउड इन्फ्रास्ट्रक्चर कसे व्यवस्थापित करावे आणि खर्च ऑप्टिमाइझ कसे करावे हे माहित नसेल, तर त्यांना ते करण्यासाठी काही अभियंता शोधण्याची आवश्यकता नाही. जर एखाद्या स्टार्टअपला प्लॅटफॉर्म तयार करायचा असेल परंतु खर्च नियंत्रणाबाहेर जाण्याची चिंता असेल तर ते सहजपणे सर्व्हरलेस सोल्यूशन्सकडे वळू शकतात.

खर्च बचत आणि स्केलिंग सुलभतेबद्दल धन्यवाद, सर्व्हरलेस सोल्यूशन्स हे बहु-दशलक्ष-डॉलर प्रेक्षक असलेल्या वेब ऍप्लिकेशनपर्यंत अंतर्गत आणि बाह्य दोन्ही प्रणालींना तितकेच लागू आहेत. खाती युरो ऐवजी सेंट मध्ये मोजली जातात. एका महिन्यासाठी सर्वात सोपा AWS EC2 उदाहरण (t1.micro) भाड्याने देण्यासाठी €15 खर्च येईल, जरी तुम्ही त्यासह काहीही केले नाही (कोण कधी ते बंद करण्यास विसरले आहे?!). त्या तुलनेत, त्याच कालावधीत खर्चाची ही पातळी गाठण्यासाठी, तुम्हाला 512 सेकंदासाठी अंदाजे 1 दशलक्ष वेळा 3 MB Lambda चालवावा लागेल. आणि आपण हे वैशिष्ट्य वापरत नसल्यास, आपण काहीही देय देत नाही.

सर्व्हरलेस हे प्रामुख्याने इव्हेंट-चालित असल्याने, लेगसी सिस्टममध्ये सर्व्हरलेस इन्फ्रास्ट्रक्चर जोडणे अगदी सोपे आहे. उदाहरणार्थ, AWS S3, Lambda आणि Kinesis वापरून, तुम्ही एपीआय द्वारे डेटा प्राप्त करू शकणार्‍या लीगेसी रिटेल सिस्टमसाठी विश्लेषण सेवा तयार करू शकता.

बहुतेक सर्व्हरलेस प्लॅटफॉर्म एकाधिक भाषांना समर्थन देतात. बहुतेकदा हे Python, JavaScript, C#, Java आणि Go असतात. सामान्यतः, सर्व भाषांमध्ये लायब्ररीच्या वापरावर कोणतेही निर्बंध नाहीत, त्यामुळे तुम्ही तुमची आवडती मुक्त स्रोत लायब्ररी वापरू शकता. तथापि, अवलंबनांचा अतिवापर न करणे उचित आहे जेणेकरुन तुमची कार्ये चांगल्या प्रकारे पार पाडतील आणि तुमच्या सर्व्हरलेस ऍप्लिकेशन्सच्या प्रचंड स्केलेबिलिटीचे फायदे रद्द करू नका. कंटेनरमध्ये जितके अधिक पॅकेज लोड करणे आवश्यक आहे, कोल्ड स्टार्टला जास्त वेळ लागेल.

कोल्ड स्टार्ट म्हणजे जेव्हा तुम्हाला कंटेनर, रनटाइम आणि एरर हँडलर वापरण्यापूर्वी ते सुरू करण्याची आवश्यकता असते. यामुळे, फंक्शन्स करण्यात विलंब 3 सेकंदांपर्यंत असू शकतो आणि अधीर वापरकर्त्यांसाठी हा सर्वोत्तम पर्याय नाही. तथापि, काही मिनिटांच्या निष्क्रिय कार्यानंतर पहिल्या कॉलवर सर्दी सुरू होते. त्यामुळे अनेकजण याला एक किरकोळ गैरसोय मानतात ज्यावर नियमितपणे फंक्शन पिंग करून ते निष्क्रिय ठेवता येते. किंवा ते या पैलूकडे पूर्णपणे दुर्लक्ष करतात.

AWS सोडले तरी सर्व्हरलेस एसक्यूएल डेटाबेस सर्व्हरलेस अरोरातथापि, SQL डेटाबेस या प्रकारच्या वापरासाठी आदर्श नाहीत कारण ते व्यवहार करण्यासाठी कनेक्शनवर अवलंबून असतात, जे AWS Lambda वर भरपूर रहदारी असताना त्वरीत अडथळा बनू शकतात. होय, विकासक सतत सर्व्हरलेस अरोरा सुधारत आहेत, आणि तुम्ही त्याचा प्रयोग केला पाहिजे, परंतु आज NoSQL उपाय जसे डायनामोडीबी. मात्र, ही स्थिती लवकरच बदलेल, यात शंका नाही.

टूलकिट अनेक मर्यादा देखील लादते, विशेषत: स्थानिक चाचणीच्या क्षेत्रात. डॉकर-लॅम्बडा, डायनॅमोडीबी लोकल आणि लोकलस्टॅक सारखे उपाय असले तरी, त्यांना परिश्रमपूर्वक काम आणि लक्षणीय कॉन्फिगरेशन आवश्यक आहे. तथापि, हे सर्व प्रकल्प सक्रियपणे विकसित होत आहेत, त्यामुळे साधने आम्हाला आवश्यक असलेल्या स्तरावर पोहोचण्याआधीच वेळ आहे.

विकास चक्रावर सर्व्हरलेस तंत्रज्ञानाचा प्रभाव

तुमची इन्फ्रास्ट्रक्चर फक्त कॉन्फिगरेशन असल्याने, तुम्ही शेल स्क्रिप्ट्स सारख्या स्क्रिप्टचा वापर करून कोड परिभाषित आणि उपयोजित करू शकता. किंवा तुम्ही कॉन्फिगरेशन-एज-कोड क्लास सोल्यूशन्सचा अवलंब करू शकता जसे की AWS क्लाउड फॉर्मेशन. ही सेवा सर्व क्षेत्रांसाठी कॉन्फिगरेशन प्रदान करत नसली तरी, ती तुम्हाला Lambda फंक्शन्स म्हणून वापरण्यासाठी विशिष्ट संसाधने परिभाषित करण्याची परवानगी देते. म्हणजेच, जेथे क्लाउडफॉर्मेशन तुम्हाला अयशस्वी करते, तुम्ही तुमचे स्वतःचे संसाधन (लॅम्बडा फंक्शन) लिहू शकता जे हे अंतर बंद करेल. अशा प्रकारे तुम्ही काहीही करू शकता, अगदी तुमच्या AWS वातावरणाच्या बाहेर अवलंबित्व कॉन्फिगर करू शकता.

हे सर्व फक्त कॉन्फिगरेशन असल्यामुळे, तुम्ही विशिष्ट वातावरण, प्रदेश आणि वापरकर्त्यांसाठी तुमच्या डिप्लॉयमेंट स्क्रिप्टचे पॅरामीटराइज करू शकता, विशेषत: जर तुम्ही क्लाउडफॉर्मेशन सारखी इन्फ्रास्ट्रक्चर-एज-कोड सोल्यूशन्स वापरत असाल. उदाहरणार्थ, तुम्ही प्रत्येक शाखेसाठी इन्फ्रास्ट्रक्चरची एक प्रत रेपॉजिटरीमध्ये उपयोजित करू शकता जेणेकरून विकासादरम्यान तुम्ही त्यांची पूर्णपणे अलगावमध्ये चाचणी करू शकता. जेव्हा विकसकांना त्यांचा कोड थेट वातावरणात पुरेसा कार्य करतो की नाही हे समजून घ्यायचे असेल तेव्हा त्यांना अभिप्राय मिळण्याच्या वेळेत हे मूलत: गती वाढवते. व्यवस्थापकांना एकाधिक वातावरणे तैनात करण्याच्या किंमतीबद्दल काळजी करण्याची गरज नाही कारण ते केवळ वास्तविक वापरासाठी पैसे देतात.

DevOps ला काळजी करण्याची कमी गरज आहे कारण त्यांना फक्त डेव्हलपरकडे योग्य कॉन्फिगरेशन असल्याची खात्री करणे आवश्यक आहे. यापुढे उदाहरणे, बॅलन्सर किंवा सुरक्षा गट व्यवस्थापित करू नका. म्हणूनच, NoOps हा शब्द वाढत्या प्रमाणात वापरला जात आहे, तरीही पायाभूत सुविधा कॉन्फिगर करण्यात सक्षम असणे महत्त्वाचे आहे, विशेषत: जेव्हा ते IAM कॉन्फिगरेशन आणि क्लाउड संसाधनांचे ऑप्टिमायझेशन येते.

Epsagon, Thundra, Dashbird आणि IOPipe सारखी अतिशय शक्तिशाली देखरेख आणि दृश्यमानता साधने आहेत. ते तुम्हाला सर्व्हरलेस ऍप्लिकेशन्सच्या सद्य स्थितीचे निरीक्षण करण्यास, लॉग आणि ट्रेस प्रदान करण्यास, कार्यप्रदर्शन मेट्रिक्स आणि आर्किटेक्चरल अडथळे कॅप्चर करण्यास, खर्चाचे विश्लेषण आणि अंदाज आणि बरेच काही करण्यास अनुमती देतात. ते केवळ DevOps अभियंते, विकासक आणि आर्किटेक्टना अनुप्रयोग कार्यप्रदर्शनाचे सर्वसमावेशक दृश्य देत नाहीत, तर ते व्यवस्थापकांना रिअल-टाइम, दुसऱ्या-दर-सेकंद संसाधन खर्च आणि खर्च अंदाजामध्ये दृश्यमानता प्राप्त करण्यास सक्षम करतात. व्यवस्थापित पायाभूत सुविधांसह हे आयोजित करणे अधिक कठीण आहे.

सर्व्हरलेस ऍप्लिकेशन्स डिझाईन करणे खूप सोपे आहे कारण तुम्हाला वेब सर्व्हर तैनात करणे, व्हर्च्युअल मशीन किंवा कंटेनर, पॅच सर्व्हर, ऑपरेटिंग सिस्टम, इंटरनेट गेटवे इ. व्यवस्थापित करणे आवश्यक नाही. या सर्व जबाबदाऱ्या अमूर्त करणे सर्व्हरलेस आर्किटेक्चरला सर्वात महत्त्वाचे असलेल्या गोष्टींवर लक्ष केंद्रित करण्यास अनुमती देते: समाधान व्यवसाय आणि ग्राहकांच्या गरजा.

टूलिंग अधिक चांगले असू शकते (ते दररोज सुधारत आहे), विकासक व्यावसायिक तर्क लागू करण्यावर आणि आर्किटेक्चरमधील विविध सेवांमध्ये अनुप्रयोगाची जटिलता कशी वितरित करावी यावर लक्ष केंद्रित करू शकतात. सर्व्हरलेस अॅप्लिकेशन मॅनेजमेंट इव्हेंट-आधारित आणि क्लाउड प्रदात्याद्वारे अ‍ॅब्स्ट्रॅक्ट केलेले आहे (उदाहरणार्थ, SQS, S3 इव्हेंट्स किंवा DynamoDB प्रवाह). म्हणून, विकासकांना विशिष्ट इव्हेंट्सवर प्रतिक्रिया देण्यासाठी फक्त व्यवसाय तर्क लिहिणे आवश्यक आहे, आणि डेटाबेस आणि संदेश रांग कसे अंमलात आणायचे किंवा विशिष्ट हार्डवेअर स्टोरेजमध्ये डेटासह चांगल्या प्रकारे कसे कार्य करावे याबद्दल काळजी करण्याची गरज नाही.

कोणत्याही विकास प्रक्रियेप्रमाणे, कोड स्थानिक पातळीवर कार्यान्वित आणि डीबग केला जाऊ शकतो. युनिट चाचणी समान राहते. सानुकूल स्टॅक कॉन्फिगरेशन वापरून संपूर्ण ऍप्लिकेशन इन्फ्रास्ट्रक्चर उपयोजित करण्याची क्षमता विकासकांना चाचणीच्या खर्चाची किंवा महाग व्यवस्थापित वातावरणावरील प्रभावाची चिंता न करता द्रुतपणे महत्त्वपूर्ण अभिप्राय प्राप्त करण्यास अनुमती देते.

सर्व्हरलेस ऍप्लिकेशन्स तयार करण्यासाठी साधने आणि तंत्रे

सर्व्हरलेस ऍप्लिकेशन्स तयार करण्याचा कोणताही विशिष्ट मार्ग नाही. तसेच या कार्यासाठी सेवांचा संच. आज शक्तिशाली सर्व्हरलेस सोल्यूशन्समधील नेता AWS आहे, परंतु लक्ष द्या Google मेघ, वेळ и फायरबेज. जर तुम्ही AWS वापरत असाल, तर आम्ही अर्ज गोळा करण्यासाठी एक दृष्टिकोन म्हणून शिफारस करू शकतो सर्व्हरलेस ऍप्लिकेशन मॉडेल (SAM), विशेषत: C# वापरताना, कारण व्हिज्युअल स्टुडिओमध्ये उत्तम साधने आहेत. SAM CLI व्हिज्युअल स्टुडिओ जे काही करू शकतो ते करू शकते, त्यामुळे तुम्ही वेगळ्या IDE किंवा टेक्स्ट एडिटरवर स्विच केल्यास तुम्ही काहीही गमावणार नाही. अर्थात, SAM इतर भाषांसह देखील कार्य करते.

तुम्ही इतर भाषांमध्ये लिहिल्यास, सर्व्हरलेस फ्रेमवर्क हे एक उत्कृष्ट ओपन सोर्स टूल आहे जे तुम्हाला खूप शक्तिशाली YAML कॉन्फिगरेशन फाइल्स वापरून काहीही कॉन्फिगर करण्याची परवानगी देते. सर्व्हरलेस फ्रेमवर्क विविध क्लाउड सेवांना देखील सपोर्ट करते, त्यामुळे जे मल्टी-क्लाउड सोल्यूशन शोधत आहेत त्यांना आम्ही याची शिफारस करतो. यात एक मोठा समुदाय आहे ज्याने कोणत्याही गरजेसाठी प्लगइनचा समूह तयार केला आहे.

स्थानिक चाचणीसाठी, ओपन सोर्स टूल्स डॉकर-लॅम्बडा, सर्व्हरलेस लोकल, डायनामोडीबी लोकल आणि लोकलस्टॅक योग्य आहेत. सर्व्हरलेस तंत्रज्ञान अद्याप विकासाच्या सुरुवातीच्या टप्प्यावर आहेत, जसे की त्यांच्यासाठी साधने आहेत, त्यामुळे जटिल चाचणी परिस्थिती सेट करताना तुम्हाला कठोर परिश्रम करावे लागतील. तथापि, फक्त वातावरणात स्टॅक तैनात करणे आणि तेथे त्याची चाचणी करणे आश्चर्यकारकपणे स्वस्त असल्याचे दिसून येते. आणि तुम्हाला तुमच्या क्लाउड वातावरणाची अचूक स्थानिक प्रत बनवण्याची गरज नाही.

उपयोजित पॅकेज आकार कमी करण्यासाठी आणि लोडिंग वेळा वेगवान करण्यासाठी AWS Lambda स्तर वापरा.

विशिष्ट कामांसाठी योग्य प्रोग्रामिंग भाषा वापरा. वेगवेगळ्या भाषांचे स्वतःचे फायदे आणि तोटे आहेत. अनेक बेंचमार्क आहेत, परंतु JavaScript, Python, आणि C# (.NET Core 2.1+) हे AWS Lambda कामगिरीच्या बाबतीत आघाडीवर आहेत. AWS Lambda ने अलीकडे रनटाइम API सादर केला जो तुम्हाला तुमची इच्छित भाषा आणि रनटाइम वातावरण निर्दिष्ट करण्यास अनुमती देतो, म्हणून प्रयोग करा.

डिप्लॉयमेंट पॅकेजचे आकार लहान ठेवा. ते जितके लहान आहेत तितक्या वेगाने लोड होतात. मोठ्या लायब्ररी वापरणे टाळा, विशेषत: जर तुम्ही त्यातील काही वैशिष्ट्ये वापरत असाल. जर तुम्ही JavaScript मध्ये प्रोग्रामिंग करत असाल, तर तुमची बिल्ड ऑप्टिमाइझ करण्यासाठी Webpack सारखी बिल्ड टूल्स वापरा आणि फक्त तुम्हाला जे आवश्यक आहे ते समाविष्ट करा. .NET Core 3.0 मध्ये QuickJit आणि Tiered Compilation समाविष्ट आहे, जे कार्यक्षमतेत सुधारणा करतात आणि कोल्ड स्टार्टमध्ये खूप मदत करतात.

इव्हेंटवर सर्व्हरलेस फंक्शन्सचे अवलंबित्व प्रथम व्यवसाय तर्कशास्त्र समन्वयित करणे कठीण करू शकते. संदेश रांग आणि राज्य मशीन या संदर्भात आश्चर्यकारकपणे उपयुक्त ठरू शकतात. Lambda फंक्शन्स एकमेकांना कॉल करू शकतात, परंतु हे फक्त तेव्हाच करा जेव्हा तुम्हाला प्रतिसादाची अपेक्षा नसेल ("फायर आणि विसरा") - दुसरे फंक्शन पूर्ण होण्याची वाट पाहण्यासाठी तुम्हाला बिल मिळू इच्छित नाही. संदेशाच्या रांगा व्यवसाय तर्कशास्त्राचे तुकडे वेगळे करण्यासाठी, अनुप्रयोगातील अडथळे व्यवस्थापित करण्यासाठी आणि व्यवहारांवर प्रक्रिया करण्यासाठी (FIFO रांग वापरून) उपयुक्त आहेत. AWS Lambda फंक्शन्स SQS रांगांना अडकलेल्या मेसेज क्यू म्हणून नियुक्त केले जाऊ शकतात जे नंतरच्या विश्लेषणासाठी अयशस्वी संदेशांचा मागोवा घेतात. एडब्ल्यूएस स्टेप फंक्शन्स (स्टेट मशीन्स) जटिल प्रक्रिया व्यवस्थापित करण्यासाठी खूप उपयुक्त आहेत ज्यांना फंक्शन्स चेनिंग आवश्यक आहे. लॅम्बडा फंक्शन दुसर्‍या फंक्शनला कॉल करण्याऐवजी, स्टेप फंक्शन्स स्टेट ट्रांझिशन समन्वयित करू शकतात, फंक्शन्समधील डेटा पास करू शकतात आणि फंक्शन्सची जागतिक स्थिती व्यवस्थापित करू शकतात. हे तुम्हाला पुन्हा प्रयत्न करण्याच्या अटी किंवा विशिष्ट त्रुटी आल्यावर काय करावे हे परिभाषित करण्यास अनुमती देते - विशिष्ट परिस्थितींमध्ये एक अतिशय शक्तिशाली साधन.

निष्कर्ष

अलिकडच्या वर्षांत, सर्व्हरलेस तंत्रज्ञान अभूतपूर्व वेगाने विकसित होत आहे. या पॅराडाइम शिफ्टशी संबंधित काही गैरसमज आहेत. पायाभूत सुविधांचे अमूर्तीकरण करून आणि स्केलेबिलिटी व्यवस्थापित करून, सर्व्हरलेस सोल्यूशन्स सरलीकृत विकास आणि DevOps प्रक्रियेपासून ऑपरेशनल खर्चात मोठ्या कपातीपर्यंत महत्त्वपूर्ण फायदे देतात.
जरी सर्व्हरलेस दृष्टीकोन त्याच्या दोषांशिवाय नसला तरी, तेथे विश्वसनीय डिझाइन नमुने आहेत ज्याचा वापर मजबूत सर्व्हरलेस ऍप्लिकेशन्स तयार करण्यासाठी किंवा सर्व्हरलेस घटकांना विद्यमान आर्किटेक्चरमध्ये समाकलित करण्यासाठी केला जाऊ शकतो.

स्त्रोत: www.habr.com