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

मेरा अनुभव

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

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

यह मोनोलिथ या माइक्रोसर्विसेज के बारे में नहीं है

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

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

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

मैं क्या सलाह दूं?

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

1. विभिन्न वातावरणों में अपने एप्लिकेशन को विकसित करने और तैनात करने और उनके बीच संस्करणों को स्थानांतरित करने में सक्षम होने के लिए आपको एक कुशल प्रक्रिया (पूरी तरह से स्वचालित या नहीं) की आवश्यकता है।
2. उत्पादन में तैनात किए गए अपने स्रोत कोड परिवर्तनों का पता लगाने के लिए आपको एक कुशल प्रक्रिया की आवश्यकता है।
3. अंत में और सबसे महत्वपूर्ण बात यह है कि जब गड़बड़ होती है और क्या होगी, क्या आपके पास ट्रैक करने और पता लगाने की क्षमता है कि क्या हो रहा है, उस घटक का पता लगाएं जो समस्या पैदा कर रहा है, कुशलतापूर्वक डीबग करें और मूल कारण को समझें और फिर रोल आउट करने की प्रक्रिया करें प्रभावित उपयोगकर्ताओं को कम करने के लिए परिवर्तन।

अब अगर मोनोलिथ्स और/या माइक्रोसर्विसेज आर्किटेक्चर आपकी मदद कर सकते हैं, तो आपके संगठन की बाधाओं को देखते हुए, उसके साथ जाएं। आप Google, Facebook, Microsoft, Amazon नहीं हैं और वे आप नहीं हैं। आपको तत्काल अन्य संगठनों से अपनी तुलना करने की भी आवश्यकता नहीं है, जो अधिक होशियार, फुर्तीले या उनमें से कोई विशेषता हो सकती है।

आपको बस इतना करना है कि सच्ची भावना से, अपने संगठन में एक स्वस्थ संस्कृति का निर्माण करना है जो चर्चा के लिए खुला हो और जो DORA अनुशंसा करता है उसे मापना शुरू करे:

• सेवा बहाल करने का समय
• विफलता दर बदलें
• परिवर्तन के लिए लीड टाइम
• परिनियोजन आवृत्ति।

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