स्टार्टअप, क्या आप वास्तव में माइक्रोसेवेज कर का भुगतान करना चाहते हैं?

क्यों अपने कोडबेस को बहुत जल्दी विभाजित करना चुपचाप आपकी टीम की गति को नष्ट कर सकता है - और इसके बजाय क्या करना है।

क्यों अपने कोडबेस को बहुत जल्दी विभाजित करना चुपचाप आपकी टीम की गति को नष्ट कर सकता है - और इसके बजाय क्या करना है.

एक स्टार्टअप में,your survival depends on how quickly you can iterate, ship features, and deliver value to end-usersयह वह जगह है जहां आपके स्टार्टअप की बुनियादी वास्तुकला एक बड़ी भूमिका निभाती है; इसके अलावा, आपकी तकनीकी स्टैक और प्रोग्रामिंग भाषा के विकल्प जैसे चीजें सीधे आपकी टीम की गति को प्रभावित करती हैं।

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

विशिष्ट पट्टियों में डूबने से पहले, यहां आप वास्तव में microservices को समय से पहले पेश करते समय क्या साइन अप कर रहे हैं:

Microservices Early On: What You’re Paying For

तैनाती की जटिलता

एक ही सुविधा के लिए 5+ सेवाओं को संगठित करना

Hours lost per release

स्थानीय डेव Fragility

Docker विशाल, टूटे हुए स्क्रिप्ट, प्लेटफॉर्म विशिष्ट हैक

Slow onboarding, frequent breakage

सीआई / सीडी डुप्लिकेशन

दोहराया तर्क के साथ कई पाइपलाइन

Extra toil per service

क्रॉस-सेवा कनेक्शन

"अनुकूलित" सेवाएं जो साझा राज्य द्वारा मजबूत रूप से जुड़ी हुई हैं

Slower changes, coordination tax

Overhead पर नजर रखें

वितरित ट्रैकिंग, लॉगिंग, निगरानी

Weeks to instrument properly

परीक्षण सूट विघटन

सेवाओं के माध्यम से वितरित परीक्षण

Brittle tests, low confidence

आइए जानें कि microservices अक्सर शुरुआत में क्यों वापस आते हैं, जहां वे वास्तव में मदद करते हैं, और गति और जीवित रहने के लिए अपने स्टार्टअप के प्रणालियों को कैसे संरचित करें।

Monoliths दुश्मन नहीं हैं

यदि आप कुछ SaaS उत्पाद का निर्माण कर रहे हैं, तो यहां तक कि एक सरल SQL डेटाबेस Wrapper अंततः आपके व्यवसाय तर्क के काम करने के तरीके में बहुत अधिक आंतरिक जटिलता ला सकता है; इसके अलावा, आप विभिन्न एकीकरणों और पृष्ठभूमि कार्यों तक पहुंच सकते हैं जो एक डेटा सेट को दूसरे में परिवर्तित करने की अनुमति देते हैं।

समय के साथ, कभी-कभी अनावश्यक सुविधाएं, यह अपरिहार्य है कि आपका ऐप गड़बड़ हो सकता है।Monoliths, even when messy, keep your team focused on what matters most:

• जिंदा रहना
• ग्राहक मूल्य प्रदान करना

मोनोलिट का सबसे बड़ा फायदा उनके तैनाती में सरलता है. आम तौर पर, ऐसे परियोजनाएं मौजूदा फ्रेमवर्क के आसपास बनाई जाती हैं - यह पियथन के लिए Django हो सकता है,ASP.NET के लिएC# के लिए, Node.js एप्लिकेशन के लिए Nest.js, आदि जब आप मोनोलिटिक आर्किटेक्चर को पकड़ते हैं, तो आपको फैंसी माइक्रोसेवेज की तुलना में सबसे बड़ा लाभ मिलता है - खुले स्रोत समुदाय और परियोजना रखरखावकर्ताओं का व्यापक समर्थन जो मुख्य रूप से उन फ्रेमवर्क को एकल प्रक्रिया, मोनोलिटिक ऐप के रूप में काम करने के लिए डिज़ाइन किया गया था।

एक अचल संपत्ति स्टार्टअप में जहां मैंने फ्रंट-एंड टीम का नेतृत्व किया, और कभी-कभी तकनीकी विकल्पों पर बैक-एंड टीम से परामर्श किया, हमारे पास एक रोमांचक विकास था Laravel-आधारित ऐप।

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

टीम ने Laravel समुदाय द्वारा अनुशंसित सर्वोत्तम प्रथाओं पर भारी भरोसा किया. उस अनुशासन को भुगतान किया, हम व्यवसाय की जरूरतों और अपेक्षाओं को पूरा करते हुए अनुप्रयोग की क्षमताओं को काफी बढ़ाने में सक्षम थे।

दिलचस्प बात यह है कि हमें कभी भी सिस्टम को माइक्रो सेवाओं में अलग करने या अधिक जटिल बुनियादी ढांचा पैटर्न को अपनाने की ज़रूरत नहीं थी. हमने इस तरह से कई यादृच्छिक जटिलताओं से बचने के लिए।“मजबूत मोनोलिथ”, जो यह समझाता है कि सरलता शुरुआत में एक सुपर शक्ति क्यों है।

लोग अक्सर इंगित करते हैं कि मोनोलिट को स्केलेबल करना मुश्किल है, लेकिन यह खराब मॉड्यूलरेशन हैअंदरएक मोनोलिट जो ऐसी समस्याएं ला सकता है।

Takeaway: A well-structured monolith keeps your team focused on shipping, not firefighting.

लेकिन क्या माइक्रो सेवाएं "अच्छे प्रथाएं" नहीं हैं?

बहुत से इंजीनियर पहले से ही माइक्रोसेस के लिए पहुंचते हैं, सोचते हैं कि वे "सही रास्ता" हैं और निश्चित रूप से - पैमाने पर, वे मदद कर सकते हैं।

माइक्रोसेवेज केवल तब भुगतान करते हैं जब आपके पास वास्तविक स्केलिंग बोतलों, बड़े टीम, या स्वतंत्र रूप से विकसित डोमेन हैं. इससे पहले? आप लाभ प्राप्त किए बिना कीमत का भुगतान कर रहे हैं: डुप्लिकेट इन्फ्रा, संवेदनशील स्थानीय सेटिंग्स, और धीमी पुनरावृत्ति।Segmentअंत मेंअपने माइक्रोसेवर्स विभाजन को बदल दियाइस सटीक कारण के लिए - बहुत अधिक लागत, पर्याप्त मूल्य नहीं।

Takeaway: Microservices are a scaling tool — not a starting template.

जहां माइक्रो सेवाएं गलत हो जाती हैं (विशेष रूप से शुरुआत में)

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

यहां सबसे आम विरोधी पैटर्न हैं जो शुरुआत में खींचते हैं।

1. स्वैच्छिक सेवा सीमाएं

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

• साझा डेटाबेस
• सरल कार्य प्रवाहों के लिए क्रॉस-सेवा कॉल
• कनेक्शन को "सेप्शन" के रूप में दर्शाया गया

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

वास्तव में, व्यावसायिक तर्क सीधे सेवा सीमाओं पर नक्शा नहीं करता है. समय से पहले अलगाव प्रणाली को अधिक संवेदनशील बना सकता है और अक्सर समय में परिवर्तनों को जल्दी लागू करना मुश्किल हो सकता है।

इसके बजाय, शल्य चिकित्सा रूप से बोतलों को अलग करें - वास्तविक स्केलिंग दर्द पर आधारित, सैद्धांतिक सुंदरता नहीं।

जब मैंने प्रारंभिक चरण की टीमों को प्रशिक्षित किया था, तो हमने कभी-कभी भविष्य की सेवा विभाजनों को अनुकरण करने के लिए आंतरिक झंडे या तैनाती स्विच का उपयोग किया - तत्काल संचालन भार के बिना।

Takeaway: Don’t split by theory — split by actual bottlenecks.

2. Repository और Infrastructure Sprawl

एप्लिकेशन पर काम करते समय, आमतौर पर अगले सेट चीजें महत्वपूर्ण हैं:

• कोड स्टाइल स्थिरता (लिंटिंग)
• एकीकरण परीक्षण सहित बुनियादी ढांचा परीक्षण
• स्थानीय पर्यावरण संस्करण
• दस्तावेज
• सीआई / सीडी संस्करण

यदि आपका प्रोजेक्ट एक monorepo के रूप में संरचित है, तो आप अपने जीवन को एक केंद्रीय सीआई / सीडी कॉन्फ़िगरेशन (जब GitHub Actions या GitLab CI के साथ काम करते हैं) के साथ सरल बना सकते हैं।

तीन व्यक्तियों की टीम के लिए, यह क्रूर है. संदर्भ भंडारण और उपकरणों के बीच स्विच प्रत्येक फ़ीचर के विकास का समय जोड़ता है जो भेजा जाता है।

monorepos और एकल प्रोग्रामिंग भाषा का उपयोग करके समस्याओं को कम करना

इस समस्या को कम करने के कई तरीके हैं. प्रारंभिक परियोजनाओं के लिए, सबसे महत्वपूर्ण बात यह है - अपने कोड को एक monorepo में रखें. यह सुनिश्चित करता है कि prod पर केवल एक संस्करण कोड मौजूद है, और यह कोड समीक्षाओं को समन्वय करना और छोटे समूहों के लिए सहयोग करना बहुत आसान है.

Node.js परियोजनाओं के लिए, मैं एक monorepo उपकरण का उपयोग करने की सलाह देता हूं जैसेnxयाturborepoदोनों :

• उप-प्रोजेक्टों के बीच सीआई / सीडी कॉन्फ़िगर को सरल करें
• Graph-based build caching का समर्थन करें
• आंतरिक सेवाओं को टाइपस्क्रिप्ट लाइब्रेरी के रूप में व्यवहार करें (ES6 आयात के माध्यम से)

ये उपकरण समय बचाते हैं अन्यथा लेबल कोड लिखने या ऑर्केस्ट्रेशन को फिर से आविष्कार करने के लिए खर्च किया जाता है।

• जटिल निर्भरता पेड़ तेजी से बढ़ सकते हैं
• सीआई प्रदर्शन ट्यूनिंग गैर-ट्रिवील है
• निर्माण समय को नीचे रखने के लिए आपको तेजी से टूलिंग (जैसे बन) की आवश्यकता हो सकती है

उदाहरण के लिए:Tooling likenxयाturborepoछोटी टीमों को monorepo गति देता है - यदि आप उन्हें साफ रखने में निवेश करने के लिए तैयार हैं।

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

Takeaway: A monorepo with shared infra buys you time, consistency, and sanity.

Broken Local Dev = टूटा हुआ गति

If it takes three hours, a custom shell script, and a Docker marathon just to run your app locally, you've already lost velocity.

प्रारंभिक परियोजनाएं अक्सर पीड़ित होती हैं:

• अनुपस्थित दस्तावेज
• पुरानी निर्भरताएं
• ओएस विशिष्ट हैक (हैलो, लिनक्स-केवल सेटिंग्स)

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

एक अन्य परियोजना में, एक एकल डेवलपर्स ने एक संवेदनशील माइक्रोसेस सेटअप बनाया था, जिससे Docker कंटेनर चलाने के कार्यप्रवाह को एक स्थानीय फ़ाइल सिस्टम में स्थापित किया गया था।

लेकिन एक पुराने विंडोज लैपटॉप के साथ एक नए फ्रंट-एंड डेवलपर्स को एक बुरे सपने में बदल दिया. उन्हें केवल यूआई को देखने के लिए दस कंटेनरों को स्पिन करना पड़ा. सब कुछ टूट गया - वॉल्यूम, नेटवर्किंग, कंटेनर संगतता - और सेटअप बहुत खराब रूप से दस्तावेज किया गया।

हमने एक Node.js प्रॉक्सी को एक साथ हैक किया जो कंटेनर के बिना nginx / Docker कॉन्फ़िगरेशन की नकल करता था. यह सुंदर नहीं था, लेकिन यह डेवलपर्स को अवरुद्ध करने और योगदान देने की अनुमति देता था।

Takeaway: If your app only runs on one OS, your team’s productivity is one laptop away from disaster.

Tip:आदर्श रूप से, लक्ष्य के लिएgit clone <repo> && make upयदि यह संभव नहीं है, तो विंडोज / मैकओएस / लिनक्स के लिए निर्देशों के साथ एक अद्यतन README फ़ाइल बनाए रखना एक अनिवार्य है. आजकल, कुछ प्रोग्रामिंग भाषाएं और टूलचेन हैं जो विंडोज पर अच्छी तरह से काम नहीं करते हैं (जैसे OCaml), लेकिन आधुनिक व्यापक रूप से लोकप्रिय स्टैक हर व्यापक रूप से उपयोग किए गए ऑपरेटिंग सिस्टम पर ठीक से चलता है; अपने स्थानीय सेटिंग को एक ही ऑपरेटिंग सिस्टम तक सीमित करके, यह अक्सर डीएक्स में कमी निवेश का लक्षण है।

4. तकनीक गलतफहमी

वास्तुकला के अलावा, आपकी तकनीकी स्टैक यह भी आकार देती है कि कितने दर्दनाक माइक्रोसेस हो जाते हैं - माइक्रोसेस वास्तुकला में हर भाषा चमकती नहीं है।

• Node.js और पायथन: तेजी से पुनरावृत्ति के लिए महान, लेकिन सेवाओं के बीच बिल्डिंग आर्टिफैक्ट्स, निर्भरता संस्करणों, और चलने समय सामंजस्य को प्रबंधित करना दर्दनाक तेजी से हो जाता है।
• जाओ: स्थैतिक बाइनरी, तेजी से निर्माण समय, और कम ऑपरेटिंग ओवरहेड के लिए संकलित करता है. अधिक प्राकृतिक फिट जब विभाजन वास्तव में आवश्यक है।

यदि आप प्रदर्शन की तलाश कर रहे हैं, तो शायद JVM और इसके पारिस्थितिकी तंत्र की तलाश करें और माइक्रोसेस-आधारित आर्किटेक्चर में आर्टिफैक्ट्स को पैमाने पर वितरित करने और चलाने की क्षमता।

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

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

Takeaway: Match the tech to your constraints, not your ambition.

5. छिपे हुए जटिलता: संचार और निगरानी

माइक्रोसेवेज आवश्यकताओं का एक अदृश्य वेब पेश करते हैं:

• सेवा की खोज
• API संस्करण
• Retries, सर्किट ब्रेकर, Fallbacks
• वितरित ट्रैकिंग
• केंद्रित लॉगिंग और अलार्म

एक मोनोलिट में, एक बग एक सरल स्टैक ट्रैक हो सकता है। एक वितरित प्रणाली में, यह है "क्यों सेवा A विफल हो जाता है जब बी की तैनाती 30 सेकंड के लिए C में देरी करती है? "आपको अपने निरीक्षण स्टैक में पूरी तरह से निवेश करना होगा। इसे "सही तरीके से" करने के लिए, इसे अपने अनुप्रयोगों को विशिष्ट तरीकों से इंस्टाग्राम करने की आवश्यकता होती है, उदाहरण के लिए, ट्रैकिंग का समर्थन करने के लिए OpenTelemetry को एकीकृत करना, या अपने क्लाउड प्रदाता के उपकरणों पर भरोसा करना जैसे कि AWS XRay यदि आप एक जटिल सर्वरहीन प्रणाली के साथ जाते हैं।actuallyउत्पादन में काम करते हैं।

बेशक, अवलोकनशीलता उपकरणों में से कुछ को मोनोलिट ऐप्स पर किया जाना चाहिए, लेकिन यह सेवाओं की संख्या के संदर्भ में ऐसा करने की तुलना में बहुत सरल है।

Tip:समझें किdistributed systems aren't free.वे इंजीनियरिंग चुनौतियों की एक पूरी नई श्रेणी के लिए एक प्रतिबद्धता हैं।

जब microservicesदोमहसूस करें

माइक्रो सेवाओं के साथ उल्लेखित कठिनाइयों के बावजूद, ऐसे समय होते हैं जब सेवा स्तर पर डिस्कनेक्शन वास्तव में बहुत फायदेमंद होता है. ऐसे मामले हैं जहां यह निश्चित रूप से मदद करता है:

• वर्कलोडिंग इन्सुलेशन: इसके लिए एक आम उदाहरण एस 3 घटना सूचनाओं का उपयोग करने के लिए एडब्ल्यूएस सर्वोत्तम प्रथाओं में होगा - जब एक छवि एस 3 में लोड की जाती है, तो एक छवि बदलाव / ओसीआर प्रक्रिया का कारण बनता है, आदि क्यों यह उपयोगी है: हम अंधेरे डेटा प्रसंस्करण पुस्तकालयों को एक स्व-अन्यक्त सेवा में अलग कर सकते हैं और इसे एपीआई बना सकते हैं जो केवल छवि प्रसंस्करण पर ध्यान केंद्रित करता है और अपलोड किए गए डेटा से आउटपुट उत्पन्न करता है।
• Divergent Scalability Needs: - कल्पना करें कि आप एक एआई उत्पाद का निर्माण कर रहे हैं। सिस्टम का एक हिस्सा (वेब एपीआई) जो एमएल वर्क लोड को चालू करता है और पिछले परिणाम दिखाता है, संसाधन-अनुकूल नहीं है, यह हल्का है, क्योंकि यह मुख्य रूप से डेटाबेस के साथ बातचीत करता है। इसके विपरीत, जीपीयू पर चलने वाला एमएल मॉडल वास्तव में चलाने के लिए भारी है और अतिरिक्त कॉन्फ़िगरेशन के साथ जीपीयू समर्थन के साथ विशेष मशीनों की आवश्यकता है।
• विभिन्न संचालित समय आवश्यकताएं: - मान लीजिए कि आपके पास सी + + में लिखे गए कोड का कुछ प्राचीन हिस्सा है. आपके पास 2 विकल्प हैं - जादुई रूप से इसे अपने कोर प्रोग्रामिंग भाषा में परिवर्तित करें या इसे कोडबेस के साथ एकीकृत करने के तरीके ढूंढें. उस प्राचीन ऐप की जटिलता के आधार पर, आपको उस सेवा के साथ बातचीत स्थापित करने के लिए अतिरिक्त नेटवर्किंग / प्रोटोकॉल लागू करने के लिए चिपकने वाला कोड लिखना होगा, लेकिन अंत में - आपको संचालित समय असंगतताओं के कारण इस ऐप को अलग-अलग सेवा के रूप में अलग करना होगा।

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

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

Takeaway: Use microservices when workloads diverge — not just because they sound clean.

Startups के लिए व्यावहारिक मार्गदर्शन

यदि आप अपने पहले उत्पाद को शिपिंग कर रहे हैं, तो यहां खेल पुस्तक है जिसे मैं सिफारिश करता हूं:

• मोनोलिटिक शुरू करें। एक आम फ्रेमवर्क चुनें और सुविधाओं को पूरा करने पर ध्यान केंद्रित करें। सभी ज्ञात फ्रेमवर्क कुछ एपीआई या वेबसाइट बनाने और उपयोगकर्ताओं की सेवा करने के लिए पर्याप्त हैं।
• एकल रीपो. अपने कोड को कई रिकॉर्डर में विभाजित करने में परेशानी न करें. मैंने उन संस्थापकों के साथ काम किया है जो रीपो को अलग करना चाहते थे ताकि अनुबंधक आईपी को कॉपी करने के जोखिम को कम कर सकें - एक वैध चिंता। लेकिन अभ्यास में, यह सुरक्षा की तुलना में अधिक घर्षण जोड़ता है: धीमी बिल्डिंग, विभाजित सीआई / सीडी, और टीमों के बीच खराब दृश्यता।
• Dead-simple local setup. Make up work. If it takes more, be very specific on the steps, record a video/Loom, and add screenshots. If your code is going to be run by an intern or junior developer, they will likely hit a roadblock, and you will spend time explaining how to troubleshoot a problem. मैंने पाया कि प्रत्येक ऑपरेटिंग सिस्टम के लिए हर संभावित समस्या को दस्तावेज करने से यह स्पष्ट करने के लिए खर्च किए गए समय को खत्म हो जाता है कि एक स्थानीय सेटिंग में कुछ चीजें क्यों काम नहीं करती हैं.
• सीआई / सीडी में जल्दी निवेश करें. यहां तक कि अगर यह एक सरल एचटीएमएल है जिसे आप केवल मैन्युअल रूप से सर्वर पर scp कर सकते हैं, तो आप इसे स्वचालित कर सकते हैं और इसे करने के लिए सीआई / सीडी के साथ स्रोत नियंत्रण पर भरोसा कर सकते हैं।
• सर्जिकल रूप से विभाजित करें. केवल तब विभाजित करें जब यह स्पष्ट रूप से एक दर्दनाक बोतल काटता है. अन्यथा, मॉड्यूलरता में निवेश करें और मोनोलिट के अंदर परीक्षण करें - इसे बनाए रखना तेजी से और आसान है।

और सबसे पहले:optimize for developer velocity.

Velocity is your startup’s oxygen.प्रारंभिक माइक्रोसेवेज धीरे-धीरे उस ऑक्सीजन को छीनते हैं - एक दिन तक, आप सांस नहीं ले सकते।

Takeaway: Start simple, stay pragmatic, and split only when you must.

यदि आप एक माइक्रो-सेवा आधारित दृष्टिकोण के साथ जाते हैं

मेरे पास माइक्रो-सेवा-आधारित परियोजनाओं को पहले से बनाया गया था, और यहां निम्नलिखित सिफारिशें हैं जो मैं इसके बारे में दे सकता हूं:

• अपने तकनीकी स्टैक का मूल्यांकन करें जो आपके माइक्रो-सेवा-आधारित आर्किटेक्चर को सशक्त करता है। डेवलपर्स अनुभव टूलिंग में निवेश करें. जब आपके पास सेवा-आधारित विभाजन है, तो अब आपको अपने माइक्रो-सेवा स्टैक को स्वचालित करने के बारे में सोचना होगा, स्थानीय और उत्पादन वातावरण दोनों पर कॉन्फ़िग को स्वचालित करने के लिए। कुछ परियोजनाओं में, मुझे एक अलग सीएलआई बनाने की ज़रूरत थी जो monorepository पर प्रशासनिक कार्य करता है. एक परियोजना में मैंने 15-20 माइक्रो-सेवा डिप्लोमेंट शामिल किए थे, और स्थानीय वातावरण के लिए, मुझे नियमित डेवलपर्स के लिए सुचारू रूप से एक आदेश स्टार्ट-अप के लिए docker-compose.yml फ़
• सेवा संचार के आसपास विश्वसनीय संचार प्रोटोकॉल पर ध्यान केंद्रित करें. यदि यह असंक्र संदेश है, तो सुनिश्चित करें कि आपके संदेश योजनाएं लगातार और मानकीकृत हैं. यदि यह REST है, तो OpenAPI दस्तावेज पर ध्यान केंद्रित करें. इंटर-सेवा संचार क्लाइंट को कई चीजों को लागू करना होगा जो बॉक्स से बाहर नहीं आते हैं: एक्सपोजेनिकल बैकऑफ, टाइमऑफ के साथ रिट्री।
• सुनिश्चित करें कि आपका इकाई, एकीकरण परीक्षण, और अंत से अंत परीक्षण सेटिंग स्थिर है और सेवा स्तर के विभाजनों की मात्रा के साथ स्केल करता है जिसे आप अपने कोडबेस में पेश करते हैं।
• छोटी परियोजनाओं पर जो माइक्रो-सेवा-आधारित कार्य भार का उपयोग करते हैं, आप शायद एक सामान्य सहायक के साथ एक साझा पुस्तकालय के लिए डिफ़ॉल्ट करने के लिए अपने निरीक्षण, संचार कोड को एक स्थिर तरीके से उपकरण करने के लिए. एक महत्वपूर्ण विचार यहां - अपने साझा पुस्तकालय को जितना संभव हो उतना छोटा रखें।
• संरचित-जेसन लॉग्स जोड़ें और अपने ऐप को तैनात करने के बाद चीजों को डिबग करने के लिए विभिन्न संदर्भ आईडी बनाएं. यहां तक कि बुनियादी सहायक जो समृद्ध लॉगिंग जानकारी का आउटपुट करते हैं (जब तक कि आप अपने ऐप को उचित लॉगिंग / ट्रैकिंग सुविधाओं के साथ उपकरणित नहीं करते हैं) अक्सर समय बचाते हैं।

संक्षेप में: यदि आप अभी भी माइक्रो सेवाओं के लिए जा रहे हैं, तो आपको अपने टीम के हर इंजीनियर के लिए सेटअप को काम करने योग्य बनाने के लिए अतिरिक्त विकास समय और रखरखाव के संदर्भ में भुगतान करने वाले कर को पहले से समझना चाहिए।

Takeaway: If you embrace complexity, invest fully in making it manageable.

निष्कर्ष

Premature microservices are a tax you can’t afford. Stay simple. Stay alive.केवल तब विभाजित करें जब दर्द इसे स्पष्ट बनाता है।

Survive first. Scale later. Choose the simplest system that works — and earn every layer of complexity you add.

संबंधित संसाधन

• Monolith First – मार्टिन फोलर
• The Majestic Monolith - डीएचएच / बेस कैम्प
• अलविदा Microservices: 100s समस्या बच्चों से 1 सुपरस्टार - सेगमेंट Eng.
• डिस्चार्ज करें - Shopify Eng.
• डोमेन उन्मुख माइक्रोसेस आर्किटेक्चर - Uber Eng.
• Go + Services = One Goliath Project - कैन अकादमी