𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝘃𝘀. 𝗠𝗼𝗻𝗼𝗹𝗶𝘁𝗵𝗶𝗰 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲: 𝗪𝗵𝗮𝘁 𝗦𝗵𝗼𝘂𝗹𝗱 𝗬𝗼𝘂 𝗕𝘂𝗶𝗹𝗱?
एक फाउंडर ने एक बार मुझसे आर्किटेक्चर पिच की समीक्षा करने के लिए कहा।
एजेंसी ने ग्यारह सेवाओं, एक मैसेज क्यू (message queue) और एक सर्विस मेश (service mesh) का प्रस्ताव दिया। यह शून्य उपयोगकर्ताओं वाले एक साधारण बुकिंग टूल के लिए था।
यह एक जाल है।
आर्किटेक्चर के निर्णय आपके होस्टिंग बिल, आपकी शिपिंग स्पीड और आपकी हायरिंग योजना तय करते हैं। किसी डेवलपर को बजट सौंपने से पहले आपको इसकी लागत का पता होना चाहिए।
The Monolith एक मोनोलिथ में एक ही कोडबेस, एक ही डिप्लॉयमेंट और एक ही डेटाबेस का उपयोग होता है। यह सरल है।
पहले दिन, आपको अपने डोमेन की सीमाओं (domain boundaries) का पता नहीं होता है। यदि आप सेवाओं को बहुत जल्दी विभाजित करते हैं, तो आप उन दीवारों को हटाने में समय बर्बाद करते हैं जिनका अस्तित्व होना ही नहीं चाहिए था। जब आपकी टीम छोटी होती है, तो मोनोलिथ को प्रबंधित करना आसान होता है। आप API सेटअप करने के बजाय एक फंक्शन को कॉल करते हैं। जब रात के 2 बजे कोई बग आता है, तो त्रुटि (error) कोड की ओर इशारा करती है, न कि नेटवर्क विफलता की ओर।
Microservices माइक्रोसर्विसेज संगठनात्मक समस्याओं का समाधान करती हैं। वे विभिन्न टीमों को अपने स्वयं के शेड्यूल पर कोड शिप करने की अनुमति देती हैं। Netflix इनका उपयोग इसलिए करता है ताकि एक खराबी पूरे सिस्टम को डुबो न दे।
हालाँकि, इसकी कीमत आपको हर दिन चुकानी पड़ती है। नेटवर्क कॉल्स से लेटेंसी (latency) बढ़ जाती है। डेटा कंसिस्टेंसी (data consistency) कठिन हो जाती है। लॉग्स और ट्रेसिंग को प्रबंधित करने के लिए आपको विशेष उपकरणों और एक बड़ी टीम की आवश्यकता होती है। सही कर्मचारियों (headcount) के बिना, आप एक 'डिस्ट्रीब्यूटेड मोनोलिथ' (distributed monolith) के साथ समाप्त होते हैं। यह आपको नेटवर्क की सारी जटिलता तो देता है, लेकिन स्वतंत्रता बिल्कुल नहीं।
The Modular Monolith यह एक बीच का रास्ता है। यह एक ही ऐप है जिसमें कोड के विभिन्न हिस्सों के बीच मजबूत दीवारें होती हैं। बिलिंग (Billing) आपके ऑर्डर्स के मुख्य हिस्से (guts) को प्रभावित नहीं कर सकती।
Shopify और GitHub इसी दृष्टिकोण का उपयोग करते हैं। आपको स्पष्ट सीमाएँ मिलती हैं और आप 'नेटवर्क टैक्स' से बच जाते हैं। जब आपके ऐप के किसी हिस्से को अंततः अकेले स्केल करने की आवश्यकता होती है, तो आप उसे आसानी से अलग कर सकते हैं क्योंकि उसकी सीमाएँ पहले से ही परिभाषित होती हैं।
How to decide:
- टीम का आकार: यदि आपके पास तीन लोग हैं, तो आप अलग-अलग सेवाओं और आवश्यक ऑन-कॉल रोटेशन को प्रबंधित नहीं कर सकते।
- उत्पाद की स्थिरता: यदि आपका उत्पाद हर हफ्ते बदलता है, तो अगले महीने तक आपकी सर्विस सीमाएँ गलत हो जाएँगी।
- ऑपरेशन्स: क्या आपके पास ऑटोमेटेड रोलबैक और लॉग एग्रीगेशन (log aggregation) है? यदि नहीं, तो माइक्रोसर्विसेज परेशानी का कारण बनेंगी।
- स्केल: काल्पनिक विकास के लिए निर्माण न करें। उस ठोस रास्ते के लिए निर्माण करें जिसे आप देख सकते हैं।
यदि आपके उत्तर "अभी नहीं" हैं, तो एक मॉड्यूलर मोनोलिथ बनाएँ।
माइक्रोसर्विसेज की मांग इसलिए न करें क्योंकि यह शब्द सुनने में आधुनिक लगता है। अपने पार्टनर को बताएं कि उत्पाद क्या करता है और इसका रखरखाव कौन करेगा।
उत्पाद इसलिए विफल हो जाते हैं क्योंकि वे कभी लॉन्च ही नहीं हो पाते। एक क्लीन मोनोलिथ (clean monolith) उपयोगकर्ताओं तक पहुँचने का सबसे तेज़ तरीका है। सबसे पहले वही बनाएं। अपने ट्रैफिक को यह तय करने दें कि चीजों को विभाजित करने का समय कब आया है।
वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi