टाइम फॉर मी टू फ्लाई... रेंडर करने के लिए

गार्टनर प्रचार चक्र , जिसे नीचे दिखाया गया है, प्रौद्योगिकी के अधिकांश पहलुओं पर लागू किया जा सकता है:

जैसे-जैसे नए नवाचार अपने-अपने चक्र में प्रवेश करते हैं, वैसे-वैसे अपेक्षाएँ अंततः साकार होती जाती हैं - जिससे कुछ हद तक अपनाने की ओर अग्रसर होता है।

प्रत्येक नवाचार का लक्ष्य उत्पादकता के उस स्तर तक पहुंचना है जहां उपभोक्ताओं ने निर्धारित किया है कि नवाचार को अपनाने का प्रतिफल ज्ञात जोखिमों से कहीं अधिक है।

इसी समय, एक ऐसा बिंदु आता है जहां उत्पादकता का पठार कम होने लगता है, जिससे उस नवाचार से दूर पलायन होता है। एक सरल उदाहरण पेजर (या बीपर्स) होगा, जो मोबाइल फोन/उपकरणों के उत्पादकता के पठार तक पहुंचने से पहले आम थे।

प्रौद्योगिकीविदों के रूप में, हम उत्पादकता के पठार को बढ़ाने वाली सुविधाओं, रूपरेखाओं, उत्पादों या सेवाओं को वितरित करने का प्रयास करते हैं। जो हम उपयोग करते हैं उनके लिए भी यही सच है।

हाल ही में, मुझे ऐसा लगा कि मेरा वर्तमान होस्टिंग प्लेटफ़ॉर्म उत्पादकता के पठार से गिरने लगा है। वास्तव में, एक हालिया घोषणा ने मुझे आश्चर्यचकित कर दिया कि क्या यह अन्य विकल्पों पर विचार करने का समय है।

चूँकि मेरे पास Render PaaS का उपयोग करने का एक सकारात्मक अनुभव था, इसलिए मैं यह देखना चाहता था कि मैं कितनी आसानी से अपने एक हरोकू एप्लिकेशन को परिवर्तित कर सकता हूँ, PostgreSQL को अपना सकता हूँ, और रेंडर में माइग्रेट कर सकता हूँ। मैं इस दो-भाग की श्रृंखला में उस यात्रा का वर्णन कर रहा हूँ:

• भाग 1: हम अपनी बैकएंड सेवाओं (स्प्रिंग बूट और ClearDB MySQL) को माइग्रेट करने पर ध्यान केंद्रित करेंगे।
• भाग 2: हम अपने फ्रंटएंड एंगुलर क्लाइंट को पोर्ट करने और माइग्रेट करने पर ध्यान केंद्रित करेंगे।

मैंने रेंडर क्यों चुना

यदि आपने रेंडर के बारे में पहले कभी नहीं सुना है, तो मेरे पिछले कुछ प्रकाशनों को देखें:

• रेंडर पास के साथ DevOps पर जीरो टाइम बिताएं

• द परफेक्ट क्लाउड: AWS, GCP और Azure ऑल-इन-वन

• उद्देश्य-संचालित माइक्रोसर्विस डिज़ाइन

• एक दिन में अपना स्टार्टअप आइडिया लॉन्च करें

• मैंने आसानी से अपने माइक्रोसर्विसेज ऐप को स्केल करने के लिए रेंडर का उपयोग कैसे किया

मुझे रेंडर के बारे में जो रोमांचक लगता है वह यह है कि वे उत्पादकता के पठार को पहचानने वाले गोद लेने वालों के लिए सक्रिय रूप से एक ठोस समाधान प्रदान करते हुए ज्ञान की ढलान पर चढ़ना जारी रखते हैं।

जैसा कि मैंने अपने लेखों में उल्लेख किया है, रेंडर एक "शून्य DevOps" वादा प्रदान करता है। यह पूरी तरह से मेरी जरूरतों के अनुरूप है क्योंकि मेरे पास DevOps कार्यों पर ध्यान केंद्रित करने का समय नहीं है।

हेरोकू प्लेटफॉर्म में कई चीजें हैं जो मुझे पसंद नहीं हैं:

• दैनिक पुनरारंभ के कारण मेरी एक सेवा के लिए अप्रत्याशित डाउनटाइम हुआ।

• एंट्री-लेवल (मुझे वास्तव में जरूरत है) हरोकू पर पोस्टग्रेज प्रति माह चार घंटे डाउनटाइम की अनुमति देता है।

• मूल्य निर्धारण स्तर, उपभोक्ता दृष्टिकोण से, अच्छी तरह से स्केल नहीं करते हैं।

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

एकल सेवा परिवर्तित करना

जैसा कि मैंने ऊपर उल्लेख किया है, यह दो-भाग की श्रृंखला का एक भाग है, और मैं इस लेख में सेवा स्तर पर ध्यान केंद्रित करूँगा। मैं जिस सेवा में कनवर्ट करना चाहता हूं उसमें निम्नलिखित विशेषताएं हैं:

• स्प्रिंग बूट रेस्टफुल एपीआई सेवा

• हेरोकू क्लाउडएएमक्यूपी (रैबिटएमक्यू) संदेश ब्रोकर

• Heroku ClearDB (MySQL) डेटाबेस (एकल स्कीमा)

• ओक्टा एकीकरण

Render PaaS की तरफ, नई सर्विस डिजाइन इस तरह दिखेगी:

• रेंडर वेब सर्विस होस्टिंग स्प्रिंग बूट रेस्टफुल एपीआई सर्विस (डॉकर के माध्यम से)

• रैबिटएमक्यू संदेश ब्रोकर की मेजबानी करने वाली निजी सेवा प्रस्तुत करें (डॉकर के माध्यम से)

• कई स्कीमाओं के मौजूद होने की क्षमता के साथ रेंडर पोस्टग्रेज

• ओक्टा एकीकरण

नीचे दो पारिस्थितिक तंत्रों की साथ-साथ तुलना की गई है:

रूपांतरण के लिए हमले की मेरी उच्च स्तरीय योजना इस प्रकार है:

रूपांतरण के लिए हेरोकू तैयार करें

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

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

हेरोकू सेवाओं का रूपांतरण

रूपांतरण के दृष्टिकोण से, मेरे पास कनवर्ट करने के लिए दो आइटम थे: स्वयं सेवा और ClearDB (MySQL) डेटाबेस।

मेरी स्प्रिंग बूट रेस्टफुल सेवा के रूपांतरण में अधिक काम शामिल नहीं था। वास्तव में, मैं अपने पिछले प्रोजेक्ट के लिए उपयोग किए गए दृष्टिकोण का लाभ उठाने में सक्षम था।

डेटाबेस के लिए, मुझे MySQL से PostgreSQL में बदलने की आवश्यकता थी। मेरा लक्ष्य रेंडर के हरोकू माइग्रेटर का उपयोग आसानी से हेरोकू पोस्टग्रेज को रेंडर पोस्टग्रेज में माइग्रेट करने के लिए करना था, लेकिन मुझे पहले MySQL से पोस्टग्रेएसक्यूएल में बदलने की जरूरत थी।

प्रारंभ में, मैंने pgloader पथ शुरू किया, जो डेटाबेस रूपांतरण के लिए एक सामान्य दृष्टिकोण प्रतीत होता था। हालाँकि, मेरे M1-चिप मैकबुक प्रो का उपयोग करने से कुछ अप्रत्याशित समस्याएँ पैदा हुईं।

इसके बजाय, मैंने MySQL को PostgreSQL में बदलने के लिए NMIG का उपयोग करने का विकल्प चुना। अधिक जानकारी के लिए, कृपया नीचे " डेटाबेस रूपांतरण से हाइलाइट्स " अनुभाग देखें।

रेंडर में सेवाएं बनाएं

डॉकर के अंदर चल रहे डेटाबेस और स्प्रिंग बूट रेस्टफुल सेवा को परिवर्तित करने के बाद, अगला कदम स्प्रिंग बूट रेस्टफुल एपीआई सेवा के लिए रेंडर वेब सेवा बनाना था।

यह सेवा बनाने, इसे एक नाम देने और GitLab में मेरे कोड के लिए उपयुक्त रिपॉजिटरी की ओर इशारा करने जितना आसान था।

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

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

सेवाओं को प्रारंभ और मान्य करें

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

एक बार जब सब कुछ ठीक हो गया और चल रहा था, तो मेरा रेंडर डैशबोर्ड नीचे दिखाए गए अनुसार दिखाई दिया:

अगले कदम

इस बिंदु पर जो कुछ बचा था, वह अभी भी हरोकू पर चल रहे डेटाबेस को हटाना था और हेरोकू पारिस्थितिकी तंत्र से माइग्रेट की गई सेवाओं को हटाना था।

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

हालाँकि, रेंडर के साथ स्रोत फ़ाइल रिपॉजिटरी में कोड जोड़ने की कोई आवश्यकता नहीं है। मुझे केवल सेवा के लिए रेंडर डैशबोर्ड में बिल्ड एंड डिप्लॉय ब्रांच को निर्दिष्ट करने की आवश्यकता है:

मुझे Zero DevOps का वादा बहुत पसंद है।

डेटाबेस रूपांतरण से हाइलाइट्स

ऊपर दिए गए चरणों का पालन करके, हेरोकू से रेंडर में रूपांतरण सुचारू और सफल रहा। मेरे लिए सबसे बड़ी चुनौती डेटा का रूपांतरण था। उच्च स्तर पर, यह ज्यादातर मेरे मैकबुक प्रो के टर्मिनल से निष्पादित आदेशों की एक श्रृंखला के लिए उबला हुआ है।

सबसे पहले, मैंने डॉकर के माध्यम से एक स्थानीय पोस्टग्रेज उदाहरण शुरू किया:

 docker run --publish 127.0.0.1:5432:5432 --name postgres -e POSTGRES_PASSWORD=dbo -d postgres

अगला, मैंने निम्नलिखित कमांड (या pgAdmin) का उपयोग करके "उदाहरण" नामक एक डेटाबेस बनाया:

 createdb example

Heroku पर चल रहे मेरे ClearDB (MYSQL) उदाहरण को स्थानीय रूप से चल रहे Postgres डेटाबेस के उदाहरण में बदलने के लिए, मैंने NMIG का उपयोग किया, जो एक Node.js- आधारित डेटाबेस रूपांतरण उपयोगिता है।

NMIG को स्थापित करने के बाद, मैंने डेटाबेस एंडपॉइंट जानकारी और क्रेडेंशियल्स के साथ config.json फ़ाइल सेट की, और फिर मैं भागा:

 /path/to/nmig$ npm start

इसके बाद, मैंने निम्न आदेश का उपयोग कर डेटा को फ़ाइल में बैक अप लिया:

 pg_dump -Fc --no-acl --no-owner -h localhost -U postgres example > example.dump

AWS में एक हस्ताक्षरित URL बनाने की परेशानी से गुजरने के बजाय, मैंने सिर्फ pgAdmin क्लाइंट का उपयोग Heroku पर एक नए बनाए गए पोस्टग्रेज इंस्टेंस में बैकअप आयात करने के लिए किया।

पोस्टग्रेज इंस्टेंस के चलने और डेटा के सत्यापन के साथ, मैंने रेंडर पास पर एक नया पोस्टग्रेज डेटाबेस बनाया । तब मुझे बस इतना करना था कि निम्नलिखित कमांड जारी करें:

 pg_restore --verbose --no-acl --no-owner -d postgres://username:[email protected]/example example.dump

रास्ते में सीखे गए सबक

हेरोकू से रेंडर में मेरे रूपांतरण को देखते हुए, यहां कुछ सबक हैं जो मैंने सीखे हैं:

• डीएसटी ऑफ़सेट को शामिल करने के लिए दिनांक/समय मान को अपडेट करने वाले पोस्टग्रेस डेटाबेस के साथ मुझे मामूली समस्या थी। यह मेरे मूल डेटाबेस डिज़ाइन के साथ एक समस्या हो सकती है, लेकिन मैं इसे पास करना चाहता था। मेरे मामले में, प्रभावित स्तंभ का उपयोग केवल दिनांक मानों के लिए किया जाता है, जो मेरे लिए नहीं बदला।

• मैंने अपनी एक तालिका में END नाम का एक डेटाबेस कॉलम शामिल किया, जिससे समस्या तब हुई जब या तो पोस्टग्रेज या हाइबरनेट ने एक मूल क्वेरी वापस करने का प्रयास किया। सेवा ने END कॉलम नाम देखा और इसे SQL कीवर्ड के रूप में इंजेक्ट किया। मैंने इस समस्या को ठीक करने के लिए बस कॉलम का नाम बदल दिया, जिसे मुझे पहले स्थान पर नहीं करना चाहिए था।

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

कुल मिलाकर, ये छोटी-छोटी बाधाएँ रेंडर में माइग्रेट करने के मेरे निर्णय को प्रभावित करने के लिए पर्याप्त नहीं थीं।

निष्कर्ष

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

जब मैंने इस निष्कर्ष को रेंडर में एक डेवलपर एडवोकेट एड के साथ साझा किया, तो उनकी प्रतिक्रिया कुछ ऐसी थी जिसे मैं साझा करना चाहता था:

"रेंडर स्पष्ट रूप से 'फैशनेबल' बनने की कोशिश नहीं कर रहा है।" हम आश्चर्यजनक और भरोसेमंद बनने की कोशिश कर रहे हैं।"

एड की प्रतिक्रिया मेरे साथ गहराई से प्रतिध्वनित हुई और मुझे उस समय की याद दिला दी जब मेरे पूर्व सहयोगी ने मुझे बताया कि मेरा कोड उनके लिए "उबाऊ" था। उनकी टिप्पणी मुझे मिली सबसे बड़ी तारीफ साबित हुई। आप यहां और अधिक पढ़ सकते हैं।

प्रौद्योगिकी के किसी भी पहलू में, किस प्रदाता को चुनने का निर्णय हमेशा आपकी तकनीकी स्थिति से मेल खाना चाहिए। यदि आप अनिश्चित हैं, तो गार्टनर प्रचार चक्र एक महान संदर्भ बिंदु है, और आप यहां उनकी सेवा की सदस्यता के साथ आरंभ कर सकते हैं।

मैं निम्नलिखित मिशन वक्तव्य पर केंद्रित रहा हूं, जो मुझे लगता है कि किसी भी आईटी पेशेवर पर लागू हो सकता है:

"अपनी बौद्धिक संपदा के मूल्य को बढ़ाने वाली सुविधाओं/कार्यक्षमता को वितरित करने पर अपना समय केंद्रित करें। बाकी सभी चीजों के लिए लीवरेज फ्रेमवर्क, उत्पाद और सेवाएं।"

- जे वेस्टर

जब मैं Render PaaS पारिस्थितिकी तंत्र को देखता हूं, तो मुझे एक समाधान दिखाई देता है जो मेरे प्रचार चक्र वरीयता के भीतर रहते हुए मेरे मिशन कथन का पालन करता है।

जो बात चीजों को बेहतर बनाती है वह यह है कि मैं अपनी व्यक्तिगत आउट-ऑफ-पॉकेट लागतों में 44% बचत देखने की पूरी उम्मीद करता हूं - इससे भी अधिक क्योंकि मेरी सेवाओं को लंबवत रूप से स्केल करने की आवश्यकता है।

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

इस सीरीज का दूसरा भाग रोमांचक होगा। मैं प्रदर्शित करूंगा कि एंगुलर में लिखे अपने स्टैटिक क्लाइंट के लिए भुगतान करने से कैसे नेविगेट करें और Vue या Svelte का उपयोग करके रेंडर की मुफ्त स्टेटिक साइट्स सेवा का लाभ उठाएं। मैं कौन सा ढांचा चुनूंगा ... और क्यों?

आपका दिन वाकई बहुत अच्छा हो!