मोनोलिथ से माइक्रोसर्विसेज में कब माइग्रेट करना है (और कब नहीं)

अधिकांश स्टार्टअप जो माइक्रोसर्विसेज को बहुत जल्दी अपना लेते हैं, उन्हें इसका पछतावा होता है। अधिकांश उद्यम जो बहुत लंबे समय तक मोनोलिथ से चिपके रहते हैं, उन्हें इसका पछतावा होता है। प्रश्न यह नहीं है कि कौन सा बेहतर है। यह कब स्विच करना है.

यह आलेख मोनोलिथिक और माइक्रोसर्विसेज आर्किटेक्चर के बीच वास्तविक ट्रेडऑफ़ को कवर करता है, सिग्नल जो आपको बताते हैं कि यह माइग्रेट करने का समय है, सिग्नल जो आपको बताते हैं कि यह नहीं है, और चरण-दर-चरण दृष्टिकोण जो सबसे आम (और सबसे महंगी) गलतियों से बचाता है।

मोनोलिथ क्या है और यह क्यों काम करता है

एक मोनोलिथ एक एकल तैनाती योग्य इकाई है। एक कोडबेस, एक डेटाबेस, एक बिल्ड पाइपलाइन, एक तैनाती। आपका प्रमाणीकरण मॉड्यूल, आपका बिलिंग सिस्टम, आपकी अधिसूचना सेवा, आपकी एपीआई परत; वे सभी एक ही भंडार में रहते हैं और एक साथ तैनात होते हैं।

यह सीमित लगता है, लेकिन अधिकांश टीमों के लिए यह विपरीत है। एक मोनोलिथ आपको देता हैरफ़्तार. आप एक ही पुल अनुरोध में मॉड्यूल सीमाओं के पार रिफैक्टर करते हैं। आप एक परीक्षण सूट चलाते हैं. आप एक आर्टिफैक्ट तैनात करते हैं। आप लॉग के एक सेट को पढ़कर डिबग करते हैं। सेवाओं के बीच कोई नेटवर्क विलंबता नहीं है क्योंकि कोई नेटवर्क कॉल नहीं हैं; यह सभी इन-प्रोसेस फ़ंक्शन कॉल हैं।

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

यदि आपके पास एक ही कोडबेस पर काम करने वाले 20 से कम इंजीनियर हैं, तो एक मोनोलिथ लगभग निश्चित रूप से सही विकल्प है। पूर्ण विराम।

माइक्रोसर्विसेज क्या हैं, और उनकी कीमत क्या है

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

वादा: टीमें स्वतंत्र रूप से तैनात हो सकती हैं, अलग-अलग घटकों को माप सकती हैं, और जहां वे समझ में आती हैं वहां विभिन्न तकनीकों का उपयोग कर सकती हैं। बिलिंग सेवा पूरे एप्लिकेशन को स्केल किए बिना महीने के अंत में चालान प्रसंस्करण को संभालने के लिए स्केल कर सकती है। खोज सेवा Elasticsearch का उपयोग कर सकती है जबकि बाकी ऐप PostgreSQL पर चलता है।

लागत: अब आप एक वितरित प्रणाली चला रहे हैं। वितरित सिस्टम बनाना कठिन है, परीक्षण करना कठिन है, और डीबग करना कठिन है। यहां बताया गया है कि आप किसके लिए साइन अप कर रहे हैं:

• सेवाओं के बीच नेटवर्क विफलता.एक मोनोलिथ में, एक फ़ंक्शन कॉल या तो काम करती है या एक अपवाद फेंकती है। माइक्रोसर्विसेज में, अनुरोध का समय समाप्त हो सकता है, आंशिक प्रतिक्रिया मिल सकती है, या चुपचाप विफल हो सकता है। आपको प्रत्येक अंतर-सेवा कॉल के लिए पुनः प्रयास तर्क, सर्किट ब्रेकर और फ़ॉलबैक रणनीतियों की आवश्यकता होती है।
• वितरित लेनदेन.जब एक एकल ऑपरेशन दो सेवाओं तक फैला होता है (ग्राहक से शुल्क लेता है, फिर इन्वेंट्री अपडेट करता है), तो आपको सागा या अंतिम स्थिरता पैटर्न की आवश्यकता होती है। इन्हें बनाना जटिल है और डीबग करना दर्दनाक है।
• अवलोकनीयता ओवरहेड.एक एकल अनुरोध 6 सेवाओं को छू सकता है। वितरित ट्रेसिंग (जैगर, जिपकिन, या डेटाडॉग एपीएम) के बिना, एक असफल अनुरोध को डीबग करने का अर्थ है टाइमस्टैम्प को सहसंबंधित करने की उम्मीद में 6 अलग-अलग लॉग स्ट्रीम के माध्यम से खोजना।
• परिनियोजन जटिलता.आपको प्रत्येक सेवा के लिए कंटेनर ऑर्केस्ट्रेशन (कुबेरनेट्स या ईसीएस), सेवा खोज, एपीआई गेटवे और सीआई/सीडी पाइपलाइन की आवश्यकता है। एक पाइपलाइन 15 हो जाती है.
• डेटा संगति चुनौतियाँ।प्रत्येक सेवा का अपना डेटाबेस होता है। सभी सेवाओं में डेटा जोड़ने का मतलब एपीआई कॉल है, न कि SQL जुड़ना। रिपोर्टिंग एक इंजीनियरिंग प्रोजेक्ट बन जाती है, प्रश्न नहीं।

इनमें से कोई भी समस्या समाधान योग्य नहीं है। लेकिन हर एक इंजीनियरिंग घंटे, बुनियादी ढांचे की लागत और परिचालन जटिलता को जोड़ता है जो एक मोनोलिथ में नहीं होता है।

मोनोलिथ तब तक ठीक है जब तक ऐसा न हो

चार विशिष्ट संकेत आपको बताते हैं कि आपका मोनोलिथ स्वयं बड़ा हो गया है:

1. आवृत्ति संघर्षों को तैनात करें

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

2. टीमें एक-दूसरे पर कदम रख रही हैं

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

3. एक मॉड्यूल का बग सब कुछ नष्ट कर देता है

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

4. एक फीचर को स्केल करने का मतलब है पूरे ऐप को स्केल करना

आपके वीडियो ट्रांसकोडिंग मॉड्यूल को आपकी एपीआई परत के 8x सीपीयू की आवश्यकता है। लेकिन वे एक इकाई के रूप में तैनात होते हैं, इसलिए आप एक घटक की जरूरतों को पूरा करने के लिए अपने पूरे एप्लिकेशन के लिए 8x सीपीयू चला रहे हैं। आपका बुनियादी ढांचा बिल आवश्यकता से 5-10 गुना अधिक है क्योंकि आप घटकों को स्वतंत्र रूप से माप नहीं सकते हैं।

यदि आप इनमें से दो या अधिक संकेतों का लगातार अनुभव कर रहे हैं, तो निष्कर्षण के बारे में सोचना शुरू करने का समय आ गया है। पूर्ण पुनर्लेखन नहीं. निष्कर्षण.

संकेत कि आप माइक्रोसर्विसेज के लिए तैयार नहीं हैं

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

• आपके पास 5 से कम इंजीनियर हैं।माइक्रोसर्विसेज टीम समन्वय समस्याओं का समाधान करती है। 3 लोगों की टीम में समन्वय की समस्या नहीं होती है; इसमें एक स्लैक चैनल और एक व्हाइटबोर्ड है। वितरित बुनियादी ढांचे को चलाने का ओवरहेड आपकी छोटी टीम की क्षमता का 30-40% उपभोग करेगा।
• आप 10,000 से कम उपयोगकर्ताओं को सेवा प्रदान करते हैं।कम ट्रैफ़िक में, एक सर्वर आराम से सब कुछ संभाल लेता है। माइक्रोसर्विसेज इस मात्रा में सार्थक स्केलिंग लाभ प्रदान किए बिना विलंबता (सेवाओं के बीच नेटवर्क हॉप्स) और जटिलता जोड़ते हैं।
• आपके पास टीम में कोई DevOps अनुभव नहीं है।माइक्रोसर्विसेज को कंटेनर ऑर्केस्ट्रेशन, सर्विस मेश कॉन्फ़िगरेशन, वितरित लॉगिंग और स्वचालित तैनाती पाइपलाइनों की आवश्यकता होती है। किसी ऐसे व्यक्ति के बिना जिसने उत्पादन में इन प्रणालियों को संचालित किया है, आप सुविधाओं के बजाय बुनियादी ढांचे के निर्माण में महीनों खर्च करेंगे।
• आपके पास कोई निगरानी या अवलोकन क्षमता नहीं है।यदि आप आज अपने मोनोलिथ के माध्यम से किसी अनुरोध का पता नहीं लगा सकते हैं, तो आप निश्चित रूप से कल इसे 10 सेवाओं में नहीं ढूंढ पाएंगे। कुछ भी विभाजित करने से पहले संरचित लॉगिंग, त्रुटि ट्रैकिंग (सेंट्री), और एप्लिकेशन प्रदर्शन मॉनिटरिंग (डेटाडॉग, न्यू रेलिक) सेट करें।
• आपने अपने मोनोलिथ में स्पष्ट मॉड्यूल सीमाओं को परिभाषित नहीं किया है।यदि आपका कोड एक पेचीदा वेब है जहां बिलिंग मॉड्यूल सीधे उपयोगकर्ता सत्र तालिका से पढ़ता है और अधिसूचना प्रणाली ऑर्डर डेटाबेस को लिखती है, तो सेवा निकालना एक बुरा सपना होगा। पहले सीमाओं को साफ करो.

माइग्रेशन पथ: स्ट्रैंगलर अंजीर पैटर्न

टीमों द्वारा की जाने वाली सबसे बड़ी गलती बिग बैंग को फिर से लिखने का प्रयास करना है। वे पूरे सिस्टम को माइक्रोसर्विसेज के रूप में पुनर्निर्माण करने में 6-12 महीने बिताते हैं जबकि मोनोलिथ उत्पादन में चलता रहता है। जब तक पुनर्लेखन "पूरा" हो जाता है, तब तक मोनोलिथ में 6-12 महीने की नई विशेषताएं होती हैं जो पुनर्लेखन में नहीं होती हैं। पुनर्लेखन कभी पकड़ में नहीं आता. प्रोजेक्ट रद्द हो जाता है. टीम हतोत्साहित है.

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

• स्टेप 1:निकालने के लिए एक घटक की पहचान करें। इसके ट्रैफ़िक को API गेटवे या प्रॉक्सी के माध्यम से रूट करें।
• चरण दो:मोनोलिथ के साथ-साथ नई सेवा का निर्माण करें। दोनों एक साथ उत्पादन में चलते हैं। प्रॉक्सी निकाले गए घटक के लिए ट्रैफ़िक को नई सेवा तक और बाकी सभी चीज़ों के लिए मोनोलिथ तक रूट करता है।
• चरण 3:एक बार जब नई सेवा अपने 100% ट्रैफ़िक को विश्वसनीय रूप से संभाल लेती है, तो पुराने कोड को मोनोलिथ से हटा दें। अगले घटक के साथ दोहराएँ.

इस दृष्टिकोण में कम जोखिम होता है क्योंकि आप कभी भी पूरे सिस्टम को एक साथ नहीं बदल रहे हैं। यदि नई सेवा में समस्याएँ हैं, तो प्रॉक्सी ट्रैफ़िक को वापस मोनोलिथ पर भेज देता है। उपयोगकर्ता कभी ध्यान नहीं देते.

पहले क्या निकालना है

आपके पहले निष्कर्षण के लिए आपके पास दो अच्छे विकल्प हैं:

विकल्प ए: वह घटक जो सबसे अधिक बार बदलता है।अपना गिट लॉग देखें। पिछले 6 महीनों में किस निर्देशिका में सबसे अधिक प्रतिबद्धताएँ हैं? यही वह घटक है जो सबसे अधिक तैनाती संघर्षों का कारण बनता है। इसे निकालने से आपकी टीमों को तत्काल तैनाती की स्वतंत्रता मिलती है।

विकल्प बी: वह घटक जिसे स्वतंत्र स्केलिंग की आवश्यकता है।यदि आपका वीडियो प्रोसेसिंग मॉड्यूल आपकी एपीआई परत के संसाधनों का 10 गुना उपभोग करता है, तो इसे निकालने से आपको प्रत्येक घटक को स्वतंत्र रूप से स्केल करने (और भुगतान करने) की सुविधा मिलती है। अकेले लागत बचत ही प्रवासन प्रयास को उचित ठहरा सकती है।

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

सामान्य गलतियाँ जो माइक्रोसर्विसेज़ माइग्रेशन को ख़त्म कर देती हैं

बहुत अधिक सेवाएँ बहुत तेजी से निकालना

टीमें अपने पहले सफल निष्कर्षण के बाद उत्साहित हो जाती हैं और एक ही बार में सब कुछ विभाजित करने का प्रयास करती हैं। अचानक वे 12 परिनियोजन पाइपलाइनों, लॉग के 12 सेट और विफलता के 12 संभावित बिंदुओं के साथ 12 सेवाएँ चला रहे हैं। परिचालन का बोझ टीम पर हावी हो जाता है। एक सेवा निकालें, इसे 4-6 सप्ताह तक उत्पादन में चलाएं, परिचालन चुनौतियों से सीखें, फिर अगली निकालें।

वितरित मोनोलिथ

यह सबसे आम विफलता मोड है. आपने अपने एप्लिकेशन को 8 सेवाओं में विभाजित किया है, लेकिन वे सभी एक ही डेटाबेस साझा करते हैं। वे सभी एक साथ तैनात होते हैं क्योंकि एक सेवा में परिवर्तन के लिए स्कीमा परिवर्तन की आवश्यकता होती है जो दूसरों को प्रभावित करती है। आपके पास बिना किसी लाभ के माइक्रोसर्विसेज की सभी परिचालन जटिलताएं हैं। प्रत्येक सेवा के पास अपना डेटा पूरी तरह से होना चाहिए। यदि दो सेवाओं को समान डेटा की आवश्यकता होती है, तो वे एपीआई या ईवेंट के माध्यम से संचार करते हैं, साझा तालिकाओं के माध्यम से नहीं।

कोई सेवा जाल या अवलोकनशीलता नहीं

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

लागत तुलना: मोनोलिथ बनाम माइक्रोसर्विसेज

इन आर्किटेक्चर के बीच बुनियादी ढांचे की लागत में अंतर महत्वपूर्ण है, और टीमें इसे लगातार कम आंकती हैं।

ये श्रेणियाँ मध्य-चरण स्टार्टअप और विकास-चरण कंपनियों को दर्शाती हैं। एंटरप्राइज़-स्केल परिनियोजन दोनों छोर पर उच्चतर चल सकते हैं।

बुनियादी ढाँचा लागत दृश्य भाग है। छिपी हुई लागत इंजीनियरिंग का समय है। माइक्रोसर्विसेज चलाने वाली एक टीम अपनी क्षमता का 20-30% परिचालन कार्यों पर खर्च करती है: कुबेरनेट्स कॉन्फ़िगरेशन को अपडेट करना, अंतर-सेवा संचार को डीबग करना, कई सेवाओं में डेटाबेस माइग्रेशन का प्रबंधन करना और सीआई/सीडी पाइपलाइनों को बनाए रखना। यह इंजीनियरिंग का समय है जो उन सुविधाओं की ओर नहीं जा रहा है जिनकी आपके उपयोगकर्ता परवाह करते हैं।

"मॉड्यूलर मोनोलिथ" मध्य मैदान

एक तीसरा विकल्प है जिसे अधिकांश वास्तुकला लेख छोड़ देते हैं: मॉड्यूलर मोनोलिथ। आप एक एकल तैनाती योग्य इकाई रखते हैं लेकिन उसके अंदर सख्त मॉड्यूल सीमाएं लागू करते हैं।

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

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

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

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

सावी क्या सिफ़ारिश करती है

हमने फिनटेक, ईकॉमर्स और SaaS में ग्राहकों के लिए मोनोलिथ, मॉड्यूलर मोनोलिथ और माइक्रोसर्विसेज आर्किटेक्चर का निर्माण किया है। यहां वह प्लेबुक है जिसका हम अनुसरण करते हैं:

• अखंड प्रारंभ करें.प्रत्येक नया उत्पाद एक मोनोलिथ के रूप में शुरू होता है। प्राथमिकता शिपिंग सुविधाएँ, बाज़ार को मान्य करना और तेजी से पुनरावृत्ति करना है। यदि कोई आपके उत्पाद का उपयोग नहीं करता है तो वास्तुशिल्प शुद्धता कोई मायने नहीं रखती।
• पहले दिन से मॉड्यूल सीमाएं लागू करें।यहां तक ​​कि एक मोनोलिथ में भी, प्रत्येक मॉड्यूल का अपना डेटा होना चाहिए और एक स्पष्ट इंटरफ़ेस प्रदर्शित करना चाहिए। इसमें पहले से लगभग कुछ भी खर्च नहीं होता है और बाद में रिफैक्टरिंग के महीनों की बचत होती है।
• अवलोकनशीलता शीघ्र स्थापित करें.संरचित लॉगिंग, त्रुटि ट्रैकिंग और बुनियादी प्रदर्शन निगरानी। चाहे आप अखंड रहें या प्रवास करें, आपको इसकी आवश्यकता है। यह टेबल स्टेक है.
• विशिष्ट दर्द प्रकट होने पर ही सेवाएँ निकालें।परिनियोजन विरोध रिलीज़ को अवरुद्ध कर रहा है। मॉड्यूल के बीच संसाधन विवाद. टीम समन्वय इंजीनियरिंग क्षमता पर भारी पड़ रहा है। ये वास्तविक संकेत हैं, सैद्धांतिक चिंताएँ नहीं।
• निष्कर्षण के लिए स्ट्रैंगलर अंजीर पैटर्न का उपयोग करें।एक समय में एक सेवा. इसे मोनोलिथ के साथ चलाएं। सत्यापित करें कि यह काम करता है। फिर अगले पर आगे बढ़ें। कभी भी बिग बैंग का पुनर्लेखन न करें।
• मॉड्यूलर मोनोलिथ को अपनी दीर्घकालिक वास्तुकला के रूप में मानें।कई उत्पादों के लिए, यह दोनों दुनियाओं में सर्वश्रेष्ठ है। आप सच्चे माइक्रोसर्विसेज की ओर तभी बढ़ते हैं जब मॉड्यूलर मोनोलिथ की एकल-तैनाती बाधा बाधा बन जाती है।

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

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

अक्सर पूछे जाने वाले प्रश्नों