माइक्रोसर्विसेज़ एक ऐसा टैक्स हैं जिसे स्टार्टअप झेल नहीं सकते

• शुरुआती स्टार्टअप में अगर कोड को जल्दबाज़ी में माइक्रोसर्विसेज़ में बाँट दिया जाए तो टीम की प्रोडक्टिविटी में गंभीर गिरावट और जटिलता में बढ़ोतरी होती है
• Monolithic (single) architecture सरल deployment, नए फीचर्स की तेज़ रिलीज़, और कुशल सहयोग के ज़रिए survival को optimize करता है
• Microservices केवल तब अलग करने का फायदा देते हैं जब बड़े पैमाने की scalability, अलग-अलग workload, या अलग runtime की ज़रूरत हो
• अत्यधिक service split, repositories की भरमार, अस्थिर local development environment, और tech stack mismatch जैसी चीज़ें स्पीड कम होने और टीम morale गिरने से जुड़ती हैं
• स्टार्टअप को monolith से शुरुआत करनी चाहिए और केवल तब split करना चाहिए जब कोई स्पष्ट bottleneck सामने आए

---

परिचय और पृष्ठभूमि

• स्टार्टअप का survival तेज़ iteration, नए फीचर्स की डिलीवरी, और user value बनाने पर निर्भर करता है
• प्रोजेक्ट की बुनियादी architecture, tech stack, और programming language का चुनाव टीम की गति को प्रभावित करता है
• जल्दी microservices अपनाना ऊपर से भले polished लगे, लेकिन व्यवहार में यह productivity में गिरावट, अधूरी services, और अत्यधिक जटिलता पैदा करता है
• डेटा: service orchestration, Docker/script समस्याएँ, दोहराया हुआ CI/CD, services के बीच coupling, observability cost, और बिखरी हुई testing जैसी कई development लागतें पैदा होती हैं
• बिना सोचे-समझे जटिल architecture की ओर बढ़ने के बजाय, व्यावहारिक architecture की अहमियत पर ज़ोर दिया गया है

Monolith की ताकत

• चाहे SaaS हो या एक simple database wrapper, समय के साथ app जटिल होता जाता है, लेकिन monolith architecture को सरल और लचीला बनाए रखना अपेक्षाकृत आसान होता है
• deployment आसान होता है, लोकप्रिय frameworks (Django, ASP.Net, Nest.js आदि) का समर्थन मिलता है, और open source community का बड़ा लाभ मिलता है
• वास्तविक उदाहरण: एक real estate startup ने Laravel monolith का उपयोग करके कई third-party integrations और feature विस्तार आसानी से हासिल किया
• जटिल infrastructure या microservices में split किए बिना, टीम business requirements और expectations पूरी करने पर ध्यान दे सकी
• सीख: architecture की सादगी टीम को deployment पर केंद्रित रहने में मदद करती है, और अगर internal modularization सही रहे तो scale भी पर्याप्त मिल सकता है

क्या माइक्रोसर्विसेज़ हमेशा सबसे अच्छा विकल्प हैं?

• कई engineers मानते हैं कि microservices ही best practice हैं, लेकिन वास्तव में वे तभी चमकते हैं जब scaling जैसी कोई खास वजह हो
• कम लोगों वाली, छोटे पैमाने की, तेज़ बदलाव वाली अवस्था में यह अक्सर duplicate infrastructure, धीमा local development, और धीमे iteration cycle के रूप में उल्टा असर डालता है
• Segment जैसी कंपनियों ने भी अप्रभावी संरचना के कारण बदलाव का अनुभव किया है
• सीख: microservices bottleneck हल करने का एक tool हैं, शुरुआती template नहीं

माइक्रोसर्विसेज़ खासकर शुरुआती चरण में क्यों विफल होते हैं

1. मनमानी service boundaries

• domain-driven design और clean architecture जैसी थ्योरी लेकर business logic के हिसाब से services बाँटने की कोशिश की जाती है → लेकिन असली logic और service boundaries अक्सर ठीक से मेल नहीं खाते
• उदाहरण: user, authentication, और authorization को अलग करने से deployment complexity और API development की कठिनाई बढ़ जाती है
• जब तक वास्तविक bottleneck न आया हो, उस चरण में split करना system को अस्थिर और धीमा बना देता है
• internal flags या toggles से भविष्य के split को simulate करते हुए, जल्दबाज़ infrastructure काम की जगह organic boundaries तलाशना ज़्यादा प्रभावी है
• सीख: split का फैसला थ्योरी पर नहीं, वास्तविक bottleneck पर आधारित होना चाहिए

2. repository/infrastructure की अति

• code style, tests, configuration, documentation, CI/CD जैसे सभी तत्व service की संख्या के साथ बढ़ते जाते हैं
• monorepo structure अपनाने से सभी configurations एक जगह संभाली जा सकती हैं, जिससे code consistency और collaboration efficiency बढ़ती है
• Node.js में nx या turborepo जैसे tools internal services के बीच dependency और build management को आसान बनाते हैं
• नुकसान यह हैं कि dependency relationship जटिल हो सकते हैं, CI performance tuning की ज़रूरत पड़ सकती है, और तेज़ build tools चाहिए हो सकते हैं
• Go ecosystem में भी शुरुआत में single workspace से manage करना ठीक रहता है, और scale बढ़ने पर modules split करने पर विचार किया जा सकता है
• सीख: छोटी टीम monorepo और shared infrastructure से काफ़ी समय बचा सकती है

3. अस्थिर local development environment

• local run में बहुत समय लगना, जटिल scripts, और system-specific dependencies जैसी चीज़ें onboarding में देरी और productivity में कमी लाती हैं
• documentation की कमी, compatibility issues, और OS-specific hacks (जैसे macOS-only scripts) बड़े अवरोध बनते हैं
• एक प्रोजेक्ट में Node.js proxy से Docker की जटिलता कम की गई और developers का onboarding time घटाया गया
• सीख: अगर app केवल एक ही OS पर चलता है, तो टीम की productivity अंततः एक ही laptop की reliability पर निर्भर रह जाती है

4. tech stack mismatch

• Node.js और Python तेज़ iteration के लिए अच्छे हैं, लेकिन microservices environment में build/runtime mismatch की समस्या बार-बार आती है
• Go static binaries, तेज़ builds, और operational simplicity में मजबूत है
• शुरुआत में tech stack का चुनाव सावधानी से होना चाहिए, और ज़रूरत पड़ने पर gRPC जैसे protocols के ज़रिए multi-language setup अपनाया जा सकता है
• ML·ETL जैसी विशेष ज़रूरतों के बिना stack mixing अक्सर केवल जटिलता बढ़ाती है
• सीख: सपनों के stack के बजाय टीम की वास्तविक स्थिति के हिसाब से stack चुनें

5. छिपी हुई जटिलता: communication और monitoring

• microservices में service discovery, API versioning, distributed tracing, centralized log management जैसी चीज़ें अनिवार्य हो जाती हैं
• bug या outage ट्रैक करना monolith में एक stack trace से संभव हो सकता है, लेकिन distributed environment में यह कहीं ज़्यादा जटिल होता है
• इसे सही तरीके से करने के लिए OpenTelemetry जैसे विशेष tools और observability stack की ज़रूरत होती है
• यह समझना ज़रूरी है कि distributed system अतिरिक्त engineering challenges के लिए अनिवार्य निवेश की मांग करते हैं

माइक्रोसर्विसेज़ कब सही साबित होते हैं

• workload isolation: image processing, OCR जैसे खास asynchronous tasks को अलग करना उपयोगी हो सकता है
• scaling needs में असंतुलन: अगर web API और ML workload की hardware और operational ज़रूरतें अलग हों, तो उन्हें अलग रखना उचित है
• अलग runtime की ज़रूरत: legacy C++ code जैसे components जो मुख्य app runtime के साथ compatible नहीं हैं, उन्हें अलग service के रूप में रखना चाहिए
• बड़े engineering organizations (जैसे Uber) के उदाहरण से दिखता है कि यह केवल तब उपयुक्त है जब स्पष्ट organizational need और mature operations capability मौजूद हो
• छोटी टीमों में भी कभी-कभी, जैसे किसी बाहरी analytics service में, यदि management सरल हो तो split व्यावहारिक हो सकता है
• सीख: केवल उन्हीं workloads में अपनाएँ जहाँ split के फायदे स्पष्ट और वास्तविक हों

स्टार्टअप के लिए व्यावहारिक गाइड

• शुरुआत monolith से करें और किसी proven framework के साथ execution पर ध्यान दें
• single repository शुरुआती टीम के लिए operations, management efficiency, और security के नज़रिए से अधिक फायदेमंद है
• local development environment को सरल बनाना महत्वपूर्ण है, और अगर यह कठिन हो तो विस्तृत documentation और videos देना ज़रूरी है
• CI/CD में जल्दी निवेश करें ताकि repetitive काम automate हों और टीम पर मानसिक दबाव कम हो
• केवल स्पष्ट bottleneck आने पर ही चुनिंदा split करें, वरना monolith के भीतर modularization और testing मज़बूत करने पर ध्यान दें
• सबसे बड़ी प्राथमिकता development speed बनाए रखना है
• सीख: सादगी से शुरुआत करें, और split की ज़रूरत के अनुसार ही scale करें

अगर माइक्रोसर्विसेज़ का उपयोग करना ही पड़े

• tech stack का मूल्यांकन और developer experience tools में निवेश: हर service के लिए automation, स्पष्ट scripts, और integrated deployment management tools की ज़रूरत होगी
• विश्वसनीय service communication protocols और standardization: message schema consistency, documentation, error handling जैसी अतिरिक्त implementation ज़रूरतों को समझना होगा
• test infrastructure को स्थिर करना: unit, integration, और E2E tests को service split के अनुरूप scale करना होगा
• shared libraries पर विचार: observability और communication के shared code को न्यूनतम दायरे में रखें ताकि बार-बार सभी services को rebuild न करना पड़े
• observability को जल्दी अपनाएँ: structured JSON logs, correlation IDs जैसे बुनियादी logging tools से शुरुआत करें
• निष्कर्षतः, अगर जटिलता स्वीकार कर रहे हैं तो पूरी ताकत से उसे manage करने लायक system design करना महत्वपूर्ण है

निष्कर्ष

• जल्दबाज़ी में microservices अपनाना सिर्फ़ बोझ बढ़ाता है, इसलिए सादगी को सर्वोच्च प्राथमिकता दें
• बिना किसी स्पष्ट pain point के split न करें, और survival व growth के लिए जितनी न्यूनतम जटिलता ज़रूरी हो, उतनी ही जोड़ें
• पहले survive करें, scaling उसके बाद आती है

[kuil09]

मैं मूल लेख की बात से कुल मिलाकर सहमत हूँ.
मुझे लगता है कि यह संगठन के अनुभव का सवाल है.
अगर आप कल्पना करें कि एक food truck में खाना बेचते-बेचते वह एक restaurant में बदल रहा है, तो समझना आसान होगा.
शुरुआत से ही काम के बंटवारे और specialization पर विचार करने के लिए stakeholders के पास अनुभव की बिल्कुल कमी होती है.

[dhlee0305]

मेरा मानना है कि startup को अपनी survival अवधि बढ़ाने के लिए कम लागत वाले तरीकों को चुनना चाहिए। microservices बिल्कुल भी सस्ते नहीं होते। इन्हें वास्तव में production में लागू करने पर काफी लागत आती है। जितना संभव हो, अपनी सेवा के अनुरूप architecture डिज़ाइन करना कम लागत में मिलते-जुलते प्रभाव पाने का तरीका हो सकता है।
यह नहीं कह रहा कि microservices बुरे हैं। यह एक ऐसा मॉडल है जिसमें बहुत अधिक लागत लगती है।

[mhj5730]

मुझे लगता है कि सिर्फ़ दो चीज़ें होना ही काफ़ी है: एक synchronous-only monolith और एक asynchronous-only monolith... और microservices अपनाना आखिरकार इस बात पर निर्भर करता है कि DB में मैनेज की जाने वाली tables का scale कितना है। अगर tables बेहिसाब ज़्यादा और complex हों, तो MSA पर विचार करना चाहिए, और अगर चीज़ें simple हों, तो monolith सबसे उपयुक्त है।

[roxie]

जब ये सारी लहरें गुजर जाएँगी, तो आने वाली पीढ़ियाँ इस दौर को कैसे याद करेंगी?

[n1ghtc4t]

तब भी उस समय की अपनी एक लहर थी...

[bungker]

मुझे लगता है कि startup में microservice के भी कई फायदे होते हैं। सबसे पहले, monorepo इस्तेमाल करने के फायदे मैं सच में recommend करूँगा।

• जब product की दिशा बदलती है, तो microservice में monolithic की तुलना में बदलने वाले हिस्से ज़्यादा स्पष्ट होते हैं और कम भी। मुझे लगता है यह सच में बहुत बड़ा फ़ायदा है।
• AI development के युग में, microservice की छोटी units को AI के ज़रिए develop करना आसान होता है। (यह नहीं कह रहा कि monolithic में नहीं हो सकता)
• CI/CD का burden मैं मानता हूँ, लेकिन direction तय करने के चरण में ऐसे services भी होती हैं जिन्हें समेट दिया जाता है। आख़िर में जब दिशा तय हो जाए, तब भी इसे बनाना लगभग copy-paste के स्तर का होता है, इसलिए एक हफ़्ते के भीतर setup किया जा सकता है।
• अलग-अलग languages के हिसाब से मज़बूत open source स्पष्ट रूप से मौजूद हैं। जैसे Security और business logic Java में, और AI Python में — इस तरह microservice architecture में जितना संभव हो उतना ज़्यादा open source इस्तेमाल किया जा सकता है.

[andone]

मैं इस बात से सहमत हूँ कि AI development के दौर में छोटे units और single responsibility के साथ implement करना ज़रूरी है

[bus710]

टिप्पणियों में भी यह थोड़ा आया था, लेकिन beam/otp परिवार काफ़ी लचीला और अच्छा लगता है। Gleam के मामले में, go और rust दोनों की अच्छी syntax के साथ beam की स्थिरता जुड़कर यह काफ़ी प्रभावशाली भाषा बन गई है। इसे छोटे प्रोजेक्ट्स में धीरे-धीरे आज़माना चाहूँगा।

[ndrgrd]

टीमों को बेवजह बहुत ज़्यादा बाँट दें, तो सिर्फ़ साथ बैठकर राय साझा करना भी बहुत बड़ा काम बन जाता है।

[GN⁺]

Hacker News राय

• यह समझ आया कि जब तक सच में scale की समस्या, बहुत बड़ी टीम, या ऐसे domain न हों जिन्हें स्वतंत्र रूप से evolve करना हो, तब तक microservices सिर्फ लागत बढ़ाते हैं और खास लाभ नहीं देते; Segment ने भी इसी वजह से microservices विभाजन को वापस लिया था; यह तकनीक से ज़्यादा एक organizational pattern है; आम तौर पर एक single monolith चलाया जाता है और केवल frontend, backend, या लंबे समय लेने वाले jobs (जैसे PDF generation) को अलग service में निकाला जाता है; बाद में जब services बढ़ने लगती हैं तभी standardization और architecture पर गंभीर विचार शुरू होता है; 200 से कम engineers वाली organization में यह अक्सर productivity घटाता है; लोग microservices की वजह से नहीं बचते, बल्कि उसके बावजूद बचते हैं
  • कुछ developers भविष्य में बड़ी tech company की resume value के लिए microservices अपनाना चाहते हैं, लेकिन असली startup में इसका बहुत कम फायदा होता है; इसे रोकने के लिए सचमुच समझदार technical leadership चाहिए
  • 50 engineers वाले startup में दर्जनों services में system बाँटते देखा; नए लोगों को system समझने में कम से कम 6 महीने लगते थे; users सिर्फ कुछ सौ थे, लेकिन complexity बहुत ज़्यादा थी; VC funding के $50 million जला दिए और अंत में company बंद हो गई; product innovative था और अच्छी तरह designed भी, पर कोई मतलब नहीं निकला
  • services को बाँटते समय codebase को अलग किए बिना, एक सामान्य monolith को सिर्फ role flags के आधार पर अलग-अलग deploy करने का तरीका भी मौजूद है; background workers को web server के साथ चलाया जा सकता है, health checks और metrics का उपयोग किया जा सकता है, और load balancer role के हिसाब से traffic बाँट सकता है
  • Khan Academy के अनुभव की तरह, monolith को पर्याप्त scale करने के बाद अनुभव के आधार पर service boundaries तय करना संभव होता है; उस समय microservices अपनाना उचित हो सकता है
  • तकनीकी रूप से अलग करने के कारण दिए जा सकते हैं, लेकिन service बनाना अपने आप में कठिन काम है; फिर भी अगर जरूरत हो तो skill बढ़ाने का रवैया महत्वपूर्ण है; सिर्फ इसलिए इनकार नहीं करना चाहिए कि यह कोई trend है, बल्कि trade-offs को तौलना चाहिए
  • सिर्फ "कई teams" होने से organization को बाँटना जरूरी नहीं होता, लेकिन वास्तव में छोटे दो squads बनते ही कुछ directors monolith तोड़ने की कोशिश करते हैं; अगर teams हर 9 महीने में reorganize हो रही हों, तो architecture boundaries जल्दी तय करना उलटा disaster हो सकता है; कम से कम 18 महीने तक एक स्थिर team के रूप में चलाकर देखना चाहिए, तभी उसे architecture boundary मानने लायक समझा जा सकता है
  • microservices की मूल परिभाषा ही "ऐसे domain जो स्वतंत्र रूप से evolve कर सकें" थी, इसलिए इसमें कुछ बहुत नया नहीं लगता
  • एक बहुत विशेष URL के traffic/memory requirements इतने अलग थे कि PHP server उस पर उपयुक्त नहीं था, इसलिए दूसरी भाषा में एक अलग server जोड़ा गया; इससे performance और cost में 1000x सुधार मिला; Java/Spring/Guava शैली में service की अवधारणा को process के "बाहर" या "अंदर" implement करने के रूप में भी सोचना चाहिए; अगर tech stack/version और serialization का standardization ठीक हो तो productivity बढ़ भी सकती है, लेकिन standardization की कमी communication errors और compatibility issues जैसी अव्यवस्था पैदा करती है
  • Conway's law (code structure organization structure को reflect करता है) सच में सही बात है
  • service वह चीज़ है जो इंसान provide करता है; microservice कंपनी के भीतर की economy में एक service है — इस बात पर जोर दिया गया
  • 15 साल पुराना अनुभव: छोटी team की single solution आसानी से चल रही थी, लेकिन microservices लाने के बाद हर service को start और coordinate करना पड़ता था, जिससे बहुत परेशानी हुई; YAGNI (जब तक जरूरत न हो, मत बनाओ) का महत्व तब समझ आया
  • high-traffic या critical paths को अलग करना जैसे कई valid technical कारण हो सकते हैं; छोटी organizations में यह आम तौर पर desirable नहीं होता, लेकिन सिर्फ high-load paths को काटकर अलग करने से startup में भी बड़ा फायदा हो सकता है
  • असल में microservices का मुख्य लाभ यह है कि छोटे groups एक-दूसरे को disturb किए बिना स्वतंत्र रूप से काम कर सकें; लेकिन जब कई teams अपनी-अपनी microservices own करती हैं, तो standardization meetings कभी खत्म नहीं होतीं, और सहयोग से ज्यादा "दूसरों के काम में मत पड़ो" वाली diplomacy महत्वपूर्ण हो जाती है
• 2-3 developers की team में सिर्फ cool दिखने के लिए microservices अपनाने की सलाह के बावजूद उसे लागू किया गया; 2 साल बाद जाकर पुराना code फिर से rebuild करना पड़ा; 3 साल बाद भी deployment और दूसरी समस्याएँ हल नहीं हुईं; अगर शुरुआत में modular monolith चुना होता तो ये समस्याएँ नहीं आतीं; इस लेख से सहमति है
  • अगर कोई सिर्फ flashy tech/project history छोड़कर जल्दी job बदल दे, तो उसके बाद का fallout किसी और को झेलना पड़ता है
  • microservices तभी सच में उपयोगी होते हैं जब हर service के लिए एक dedicated team हो; एक ही team कई services संभाले, ऐसा कोई अच्छा उदाहरण नहीं देखा
  • समस्या का बड़ा हिस्सा इस वजह से आता है कि team members microservices को भी एक single system (monolith) की तरह सोचते रहते हैं; design से deployment तक हर चरण में friction पैदा होता है; सफलता के लिए पूरी organization का गहरा buy-in जरूरी है; किसी existing system को microservices में बदलने पर internal resistance बहुत होता है
  • आखिरकार startup में सब लगभग एक जैसी मुश्किलों से गुजरते दिखते हैं
  • 8-12 microservices से बने internal UI project में भी असली users सिर्फ 5-10 थे; complexity बेवजह बढ़ गई; कारण समझ नहीं आता
  • Thoughtworks consulting की वजह से microservices + Java अपनाने का अनुभव रहा; consulting company पैसा कमाकर चली गई, लेकिन organization feature-rich monolith को distributed microservices के रूप में फिर से implement करने में भटकती रही; project अंततः fail हुआ और company भी खत्म हो गई; उसके बाद से बड़ी consulting firms पर भरोसा नहीं रहा
• grug brain स्टाइल में देखें तो सवाल यह है कि कोई जान-बूझकर system को तोड़कर उसमें network calls जैसी अतिरिक्त कठिनाई क्यों जोड़े
  • यह वैसा लगता है जैसे Python जैसी किसी भाषा में, जहाँ "monkey patch" feature न हो, वहाँ उसे जबरन जोड़ना
  • एक राय यह है कि network calls किसी नियम (rule) को कानून (law) में बदल देती हैं
  • grug humor के हिसाब से, बहुत सारे grug brain वाले grug यह भ्रम पाल लेते हैं कि overgroup के 9 grug मिलकर 1 महीने में baby grug बना देंगे
• microservices बड़े संगठनों में लोगों से जुड़ी समस्याएँ सुलझाने, bureaucracy की बाधाएँ हटाने और developers को autonomy देने में प्रभावी हैं; छोटे startups में वास्तविक लाभ बहुत बड़ा नहीं होता; हाँ, अगर किसी खास domain में tech stack मिलाना पड़े (जैसे Elixir और Python/Go), तो ऐसा विभाजन जरूरी हो सकता है
  • अगर app के अलग-अलग हिस्सों की load या resource requirements अलग हों, तो छोटे startup में भी अलग service बनाना फायदेमंद हो सकता है; ज्यादातर business logic monolith में रहे और सिर्फ GPU जैसे special work अलग हों; लेकिन इस pattern को 100 services तक फैलाना सही नहीं; मूल रूप से monolith बेहतर है, और अलगाव केवल जरूरत पड़ने पर
  • microservices उलटे नई organizational dependencies और coordination की जरूरत पैदा कर देते हैं; उदाहरण के लिए "कोई भी किसी भी service का इस्तेमाल कर ले" जैसी policy maintenance बहुत बढ़ा देती है, और system चलाने के लिए हर किसी को सब कुछ सीखना पड़ता है; अंत में लोगों को ढूँढ़ने में ही समय जाता है
  • अगर teams में conflict या duplication हो, तो inefficiency और बढ़ जाती है
• software architecture में microservices कुछ हद तक Conway's Law (organization structure code structure को प्रभावित करता है) जैसे हैं; हर team boundary एक पार करने वाली boundary बन जाती है, और अंदर ही अंदर बड़े architecture boundaries कृत्रिम रूप से बनाना अक्सर non-productive होता है; इसके बजाय dependency injection, module boundary design, actor model आदि के साथ modular monolith बेहतर रहता है; बाद में सच में जरूरत हो तो service separation भी आसान हो जाता है; cost-benefit के हिसाब से यह तरीका अच्छा रहा; monolith को 3-4 बार सफलतापूर्वक तोड़ने का प्रत्यक्ष अनुभव भी बताया गया
  • Conway's Law असल में communication boundaries का नियम है; हर team boundary को छूना जरूरी नहीं; बल्कि कई बार software के हिसाब से organization को reorganize करना पड़ता है, यानी architecture बदलते ही company reorg की जरूरत पड़ सकती है; ऐसा करने से team और business goals के बीच disconnect बढ़ सकता है; बेवजह Amazon-style approach को ideal नहीं मानना चाहिए
• तकनीकी रूप से startup में microservices इन स्थितियों में उचित हो सकते हैं: (1) जब core app से अलग language जरूरी हो (जैसे Rails + R), (2) जब सिर्फ कुछ services की scale जरूरत बहुत अलग हो, (3) जब कुछ data की security या lifetime requirements अलग हों, जैसे medical information; इसके अलावा system को बारीक हिस्सों में बाँटने का कारण लगभग नहीं होता; छोटे संगठनों को उलटा नुकसान होता है
  • कुछ नई services अलग करना असली microservices जैसा नहीं है; वास्तविक microservices में वे चीज़ें भी अलग कर दी जाती हैं जिन्हें सामान्य app में module के रूप में रखा जा सकता था
  • scale के अलावा reliability और availability requirements भी अगर बहुत अलग हों, तो separate service बनाना तार्किक हो सकता है; SLA बनाए रखने के लिए concern separation से risk घट सकता है और deployment speed बढ़ सकती है
  • फिर भी ऐसे मामलों को कुछ लोग केवल DB server अलग चलाने से बहुत अलग नहीं मानते
• microservices की असली उपलब्धि organizational स्तर पर होती है; समस्या को टुकड़ों में बाँटकर हर team एक हिस्से की पूरी ownership लेती है, end-to-end delivery की जिम्मेदारी उठाती है, इसलिए specialization संभव होता है; बदलाव मूल रूप से incremental होते हैं, और API ही interaction का एकमात्र रास्ता होता है; shared DB/file system/API नहीं होता; इसके बदले standardization और management tooling (monitoring, testing, CI/CD सहित) महत्वपूर्ण हो जाते हैं, जो monolith हो या कुछ और, किसी भी system में कुछ न कुछ स्तर पर चाहिए ही
  • infra, logging, auth आदि को package किया जा सकता है या gRPC, message queue वगैरह से manage किया जा सकता है; नई service जल्दी बनाई जा सकती है, और team के भीतर merge requests छोटी होने से conflicts कम होते हैं और productivity बढ़ती है; 5-10 लोगों की टीम में monolith के समय conflicts, deployment और release issues अधिक थे, लेकिन microservices में जाने के बाद productivity, collaboration और lead time बेहतर हुआ; हालांकि testing, documentation और endpoints पर नियम बहुत महत्वपूर्ण थे
  • DB separation जैसी performance reasons से तकनीकी रूप से service split जरूरी हो सकता है, लेकिन सामान्य startup में यह दुर्लभ हो सकता है
• BEAM/OTP (Erlang, Elixir) ecosystem की ताकत यह है कि monolith बनाए रखते हुए भी "microservice-जैसी" design का अभ्यास किया जा सकता है, और जब सच में separation की जरूरत पड़े तो आसानी से switch किया जा सकता है; छोटे scale पर monolith के फायदे मिलते हैं, और बड़े होने पर scaling तथा independence दोनों हासिल किए जा सकते हैं; हालांकि immutable objects, concurrency communication, और fault handling जैसी चीजें सीखनी पड़ती हैं, और hiring भी कठिन हो सकती है
• अधिकांश बातों से सहमति है; startup माहौल में service boundaries तय करना लगभग असंभव होता है; लेकिन छोटे teams में कभी-कभी बाहरी API या complex dependency issues की वजह से microservices फायदेमंद हो सकते हैं; ऐसे में network boundary पहले से जरूरी होती है, इसलिए अलग service बनाने से complexity बहुत नहीं बढ़ती; या build/deploy complexity होने पर separation monolith को सरल भी बना सकता है
• microservices केवल बड़े scale या team micromanagement की जरूरत होने पर उपयुक्त हैं; स्पष्ट module boundaries को कभी नहीं छोड़ना चाहिए; message-passing शैली वाली object-oriented design से monolith के भीतर भी microservices के लाभ लिए जा सकते हैं; DB को सीधे छूने से बचने की आदत जरूरी है; Java जैसी भाषाओं में modularization, DB schema namespaces, और केवल minimal interfaces expose करके independent testing/monitoring संभव होती है, और कई services को एक साथ deploy करना भी आसान हो सकता है
  • यदि logical boundaries अच्छी तरह समझ ली जाएँ, तो ArchUnit जैसे tools से उन्हें enforce भी किया जा सकता है