रेल्स 8 एक साहसिक आधार के साथ आया: "नो PaaS रिक्वायर्ड।" जैसे-जैसे क्लाउड प्लेटफॉर्म अधिक महंगे होते गए, रूबी ऑन रेल्स ने बाहरी इंफ्रास्ट्रक्चर निर्भरताओं को कम करने की ओर रुख किया ताकि डेवलपर्स कम सर्विस निर्भरताओं के साथ एप्लिकेशन को डिप्लॉय और चला सकें।
परंपरागत रूप से, एक रेल्स ऐप को इंटरनेट पर डिप्लॉय करने का मतलब एक डेटाबेस सर्वर (जैसे, PostgreSQL) और Redis जैसी अतिरिक्त सेवाओं को प्रोविजन करना होता था, जो कैशिंग, बैकग्राउंड जॉब्स, या WebSockets के लिए होती हैं। रेल्स 8 के साथ, कोर टीम इसे बदलने की उम्मीद करती है, जिसमें कैशिंग, जॉब क्यू, और रियल-टाइम WebSockets के लिए समाधान बेक किए गए हैं - ये सभी आपके एप्लिकेशन के डेटाबेस द्वारा संचालित हैं।
इस लेख में, हम यह पता लगाएंगे कि रेल्स 8 "नो PaaS रिक्वायर्ड" वादे को कैसे पूरा करता है, "सॉलिड ट्रिफेक्टा" के अवलोकन से शुरू करके।
सॉलिड कैश आपको Redis के बिना कैश करने में मदद करता है
रेल्स 8 में मेरे पसंदीदा एडिशन में से एक सॉलिड कैश है, एक नया कैश स्टोर जो Redis या Memcached की आवश्यकता को प्रतिस्थापित करता है। सॉलिड कैश कैश्ड डेटा को इन-मेमोरी की-वैल्यू स्टोर के बजाय डेटाबेस में स्टोर करता है। जबकि डिस्क पर कैश्ड ऑब्जेक्ट्स को स्टोर करना तकनीकी रूप से RAM की तुलना में धीमा है, कुछ महत्वपूर्ण फायदे हैं।
सबसे पहले, डिस्क स्टोरेज आपको अधिक स्थान देता है और मेमोरी की तुलना में बहुत सस्ता है। सॉलिड कैश के साथ, आप RAM खत्म हुए बिना कहीं अधिक डेटा कैश कर सकते हैं (और इसे लंबे समय तक रख सकते हैं)। 37सिग्नल्स (Basecamp और HEY के पीछे की कंपनी) में, Redis से सॉलिड कैश पर स्विच करने से उन्हें अपने कैश को 10+ टेराबाइट डेटा तक विस्तारित करने की अनुमति मिली, जिससे अंततः उनके P95 रेंडर समय में 50% की कमी आई।
हां, मेमोरी से पढ़ना डिस्क से पढ़ने की तुलना में तेज है। कई मामलों में (जैसे Basecamp के उपयोग में), अधिक डेटा कैश करने का ट्रेडऑफ इस गति के नुकसान को इसके लायक बनाता है।
डिफ़ॉल्ट रूप से, रेल्स 8 सॉलिड कैश का उपयोग करता है (SQLite द्वारा समर्थित)। बेशक, हमेशा की तरह रेल्स कन्वेंशन के लिए, आप अभी भी Redis जैसे किसी अन्य विकल्प का चयन कर सकते हैं यदि यह आपके लिए बेहतर विकल्प है। लेकिन इस डिफ़ॉल्ट के साथ बने रहने से आप Redis जैसी एक और प्रोडक्शन सर्विस को सपोर्ट किए बिना चीजों को कैश कर सकते हैं, जो आपके इंफ्रास्ट्रक्चर बोझ को सरल बनाता है।
सॉलिड क्यू आपको बैकग्राउंड जॉब्स करने में मदद करता है — Redis के बिना
"सॉलिड" ट्रिफेक्टा का मेरा दूसरा पसंदीदा हिस्सा सॉलिड क्यू है, एक नया Active Job बैकएंड जो Redis या यहां तक कि Sidekiq जैसे अलग जॉब सिस्टम डिपेंडेंसी की आवश्यकता के बिना बैकग्राउंड जॉब प्रोसेसिंग को संभालता है।
कई रेल्स डेवलपर्स बैकग्राउंड जॉब्स के लिए Sidekiq (जो Redis पर निर्भर करता है) या डिलेड जॉब जैसे जेम्स का उपयोग करते हैं। सॉलिड क्यू एक और डिपेंडेंसी की आवश्यकता को हटाने का रेल्स का प्रयास है। यह जॉब क्यूइंग को आपके एप्लिकेशन के डेटाबेस में एकीकृत करता है, इसलिए आपको मेमोरी सॉल्यूशन या क्यूइंग सिस्टम की आवश्यकता नहीं है।
सॉलिड क्यू जॉब्स को डेटाबेस टेबल में रिकॉर्ड के रूप में स्टोर करता है और जॉब क्यू को प्रबंधित करने के लिए कुशल SQL सुविधाओं का उपयोग करता है। यह या तो रेल्स वेब प्रोसेस में एम्बेडेड चल सकता है (सिंगल-सर्वर सेटअप के लिए Puma प्लगइन के रूप में) या अलग वर्कर प्रोसेस में।
जैसा कि एक रेल्स कोर टीम के सदस्य ने नोट किया, लक्ष्य एक डेवलपर को "रेल्स इंस्टॉल करने, एक डेटाबेस सेट करने, और सात अलग-अलग जेम्स और अन्य सिस्टम को प्रबंधित किए बिना बॉक्स से बाहर बैकग्राउंड जॉब प्रोसेसिंग प्राप्त करने" देना था।
सॉलिड केबल आपको वेब सॉकेट्स करने में मदद करता है (आश्चर्य, Redis के बिना)
रेल्स 8 की "नो-Redis-नीडेड" पहेली का तीसरा टुकड़ा सॉलिड केबल है — एक नया Action Cable एडाप्टर जो, आपने अनुमान लगाया, डेटाबेस का उपयोग करता है। ऐतिहासिक रूप से, Action Cable को कई रेल्स प्रोसेस के बीच संदेश प्रसारित करने के लिए एक Redis सर्वर की आवश्यकता होती थी। सॉलिड केबल के साथ, आप चैट और नोटिफिकेशन जैसी एप्लिकेशन सुविधाओं के लिए लाइव अपडेट अनलॉक करते हुए, रियल-टाइम WebSocket कार्यक्षमता के लिए Action Cable का लाभ उठा सकते हैं — अतिरिक्त सेवाएं चलाए बिना।
मुझे उम्मीद है कि "सॉलिड" ट्रिफेक्टा का लाभ अब तक स्पष्ट हो रहा है। आप लॉन्ग-टर्म डेटा कैश कर सकते हैं, हाई-थ्रूपुट बैकग्राउंड जॉब्स प्रोसेस कर सकते हैं, और Redis सर्वर या अन्य पब/सब सर्विस खड़े किए बिना रियल-टाइम सुविधाओं को डिप्लॉय कर सकते हैं। साथ में, ये सुविधाएं छोटे ऐप्स के लिए जटिलता को कम करती हैं (आप एक डेटाबेस के साथ सिंगल होस्ट पर सब कुछ चला सकते हैं) और रेल्स 8 के डिप्लॉयमेंट को आसान बनाने के दर्शन के अनुरूप हैं।
क्या Redis की आवश्यकता को हटाना इतना बड़ा सौदा है?
यह देखने के बाद कि रेल्स 8 का कितना हिस्सा Redis पर निर्भरता को हटाने के बारे में है, आप उत्सुक हो सकते हैं कि यह वास्तव में कितना मायने रखता है। उत्तर आपके संदर्भ पर निर्भर करता है, लेकिन निर्विवाद रूप से कुछ उल्लेखनीय लाभ हैं।
कम मूविंग पार्ट्स का मतलब कम जटिलता है, विशेष रूप से डिप्लॉयमेंट में। हर अतिरिक्त सर्विस (Redis, एक अलग बैकग्राउंड जॉब रनर, आदि.) एक और चीज है जो टूट सकती है या स्केलिंग की आवश्यकता हो सकती है। डेटाबेस का अधिक उपयोग करके, आप अपने प्रोडक्शन ऑपरेशन को सरल बनाते हैं। आपको Redis मेमोरी की निगरानी करने या यह सुनिश्चित करने की आवश्यकता नहीं है कि एक Redis इंस्टेंस हमेशा चल रहा है।
कई रेल्स डेवलपर्स ने उस परिदृश्य का सामना किया है जहां, डेवलपमेंट में, आप कैश सर्वर नहीं चलाते या शायद एक अलग क्यू एडाप्टर का उपयोग करते हैं, लेकिन प्रोडक्शन में, आप Redis/Sidekiq का उपयोग करते हैं। नए रेल्स डिफॉल्ट्स के साथ, आप डेवलपमेंट और प्रोडक्शन में एक ही सेटअप चला सकते हैं, जिससे आश्चर्य कम से कम होते हैं। स्टैक अधिक आत्म-निहित है और प्रोडक्शन के लिए विशेष कॉन्फ़िगरेशन के बिना बॉक्स से बाहर "बस काम करता है"।
कम सर्वर या एड-ऑन का अर्थ सस्ता होस्टिंग बिल भी है। बड़े पैमाने पर भी, इंफ्रास्ट्रक्चर को समेकित करने से कुछ लागत दक्षता आती है। डेटाबेस स्पेस मेमोरी से सस्ता है!
रेल्स आपको Redis या अन्य सेवाओं का उपयोग करने से नहीं रोकता। यह सिर्फ उन्हें वैकल्पिक बनाता है। आप बिल्ट-इन सॉलिड एडाप्टर्स के साथ शुरू कर सकते हैं, और यदि आपको आवश्यकता है, तो आप बाद में Redis या अन्य समाधान पेश कर सकते हैं।
SQLite डेटाबेस प्रोसेस की आवश्यकता को हटाता है
रेल्स 8 में एक और सार्थक बदलाव SQLite को एक उपयोगी प्रोडक्शन डेटाबेस के रूप में अपनाना है, जिसे रेल्स के SQLite एडाप्टर में कई सुधारों द्वारा सक्षम किया गया है। यदि आपका ऐप प्रोडक्शन में SQLite का उपयोग कर सकता है, तो आपको एक अलग डेटाबेस सर्वर चलाने की आवश्यकता नहीं है। इसके बजाय, आपका डेटा ऐप प्रोसेस द्वारा प्रबंधित डिस्क पर एक साधारण फ़ाइल में रहता है। रेल्स 8 के SQLite में सुधार इसे पहले की तुलना में अधिक यथार्थवादी बनाते हैं।
SQLite डिप्लॉयमेंट को बहुत सरल बना सकता है। आपको सर्वर पर MySQL या Postgres इंस्टॉल या प्रबंधित करने की आवश्यकता नहीं है या (और भुगतान!) एक प्रबंधित DB सर्विस का उपयोग करने की आवश्यकता नहीं है। यह सिर्फ एक फ़ाइल है जिसे रेल्स ऐप पढ़ता और लिखता है।
यदि आप SQLite से आगे निकल जाते हैं, तो आप निश्चित रूप से बाद में एक पूर्ण-विशेषताओं वाले डेटाबेस सिस्टम पर माइग्रेट कर सकते हैं। रेल्स कोर टीम ने सिर्फ डिफ़ॉल्ट को एक हल्के विकल्प में बदल दिया — जो "नो PaaS" कथा के साथ अच्छी तरह से फिट बैठता है।
Kamal 2 आपको डिप्लॉय करने में मदद करता है
रेल्स 8 प्रोडक्शन में ऐप चलाने को सरल बनाता है — लेकिन ऐप को प्रोडक्शन तक पहुंचाने के बारे में क्या? Kamal 2 का रिलीज उस प्रश्न का उत्तर देने का प्रयास करता है।
Kamal एक ऑर्केस्ट्रेशन टूल है जो आपके ऐप को (Docker कंटेनर के माध्यम से) न्यूनतम उपद्रव के साथ किसी भी Linux सर्वर पर डिप्लॉय करता है। यह आपके ऐप की इमेज बनाने, इसे पुश करने, और इसे सर्वर पर चलाने को स्वचालित करता है, बिना आपको सभी सर्वर सेटअप को हाथ से बनाने के।
कुछ कॉन्फ़िगरेशन और एक कमांड (kamal setup) के साथ, Kamal एक ताजा Linux बॉक्स लेगा और इसे आपके Docker कंटेनर को चलाने के लिए आवश्यक चीजों के साथ प्रोविजन करेगा।
उसके बाद, डिप्लॉयमेंट kamal deploy चलाने जितना सरल है, जो नवीनतम इमेज को खींचता है और पुराने कंटेनर को नए के साथ शून्य-डाउनटाइम डिप्लॉयमेंट के रूप में स्वैप करता है।
Kamal 2 आपको किसी भी Linux होस्ट पर PaaS जैसा डिप्लॉयमेंट अनुभव देने की उम्मीद करता है। आप एक कमांड के साथ किसी भी सर्वर को अपना ऐप चलाने वाले रेल्स सर्वर में बदल सकते हैं। प्रारंभिक कॉन्फ़िगरेशन दर्दनाक हो सकता है, लेकिन बाद के डिप्लॉय बहुत अधिक सीधे हैं। यह सेल्फ-होस्टिंग को Heroku जैसे प्लेटफॉर्म पर पुश करने जितना सुविधाजनक बनाने की दिशा में एक बड़ा कदम है।
क्या "नो PaaS" एक अच्छा विचार है?
क्या रेल्स 8 वास्तव में प्लेटफॉर्म को अतीत की बात बनाता है? और क्या छोटी से मध्यम आकार की टीमें वास्तव में सेल्फ-होस्टिंग करके पैसे बचा सकती हैं?
मैंने हाल ही में Kamal का उपयोग करके एक VPS पर एक हॉबी प्रोजेक्ट डिप्लॉय किया, और यह एक निराशाजनक अनुभव था। जबकि एक बार काम करने के बाद डिप्लॉयमेंट अपेक्षाकृत सहज हैं, सेटअप इससे बहुत दूर था, और अगर मुझे कभी इस प्रोजेक्ट को स्केल करने की आवश्यकता हुई तो मेरा काम खत्म हो गया है।
तो, मेरे लिए, उत्तर नहीं है — रेल्स 8 प्लेटफॉर्म के मूल्य प्रस्ताव को नहीं हटाता। मैं अपने ऐप पर ध्यान केंद्रित करूंगा और Heroku जैसे प्लेटफॉर्म को इंफ्रास्ट्रक्चर संभालने दूंगा।
सोलो डेवलपर्स और छोटी टीमों को स्केल की अर्थव्यवस्थाओं का पीछा करने के बजाय अपने उपयोगकर्ताओं पर ध्यान केंद्रित करने से अधिक लाभ होगा। क्यों न होस्टिंग, डिप्लॉयमेंट, और स्केलिंग को एक ऐसे प्लेटफॉर्म को आउटसोर्स किया जाए जो इन क्षेत्रों में कुचलता है और एक ऐसा प्रोडक्ट बनाने पर ध्यान केंद्रित किया जाए जिसे आपके ग्राहक पसंद करते हैं?
बेशक, जैसे-जैसे आपकी टीम और एप्लिकेशन बढ़ते हैं, आप पा सकते हैं कि प्लेटफॉर्म की कीमत कम आकर्षक है। किसी बिंदु पर, SRE और ऑप्स जिम्मेदारियों के लिए समर्पित समय और/या लोग रखना समझ में आता है, और Kamal (अन्य भयानक रेल्स 8 डिफॉल्ट्स के साथ) इसे आसान बनाने की दिशा में एक बड़ा कदम है।
इसे एक साथ लाना
रेल्स 8 सेल्फ-होस्टिंग और प्लेटफॉर्म का उपयोग करने के बीच के अंतर को कम करता है, लेकिन यह "नो PaaS रिक्वायर्ड" का ईमानदारी से दावा करने के लिए इसे पर्याप्त रूप से बंद नहीं करता है। हालांकि, यह स्पष्ट है कि रेल्स 8 एक VPS को PaaS पर चुनना आसान बनाता है बिना अधिक डेवलपर अनुभव का त्याग किए; मुझे बस नहीं लगता कि यह एक प्लेटफॉर्म किलर है।
सॉलिड कैश, सॉलिड क्यू, और सॉलिड केबल सभी पहले से वेब ऐप्स के लिए थर्ड-पार्टी आवश्यकताओं को फर्स्ट-पार्टी सपोर्ट में लाते हैं, और मैं इसके लिए आभारी हूं। हल्के लेकिन शक्तिशाली डिफॉल्ट्स का होना बहुत अच्छा है जो एक एप्लिकेशन को जमीन पर उतारने के लिए हैं, और इससे भी बेहतर, उन्हें अधिक इंफ्रास्ट्रक्चर की आवश्यकता नहीं है। यदि आप सेल्फ-होस्ट करना चुनते हैं, तो Kamal आपके लिए डिप्लॉयमेंट के कुछ बोझ को दूर कर सकता है।
चाहे आप प्लेटफॉर्म का उपयोग कर रहे हों या नहीं, त्रुटियों और आउटेज का तुरंत जवाब देने और अपने ग्राहकों को एक शानदार उपयोगकर्ता अनुभव प्रदान करने के लिए मॉनिटरिंग आवश्यक है। अपने रेल्स एप्लिकेशन के स्वास्थ्य और प्रदर्शन में रियल-टाइम अंतर्दृष्टि प्राप्त करने के लिए हनीबैजर के लिए साइन अप करें।
