साधारण आर्किटेक्चर के पक्ष में (2022)
इंजीनियर “बोरिंग,” मोनोलिथिक architectures के लाभों की तुलना जटिल microservice-heavy stacks से करते हैं, और तर्क देते हैं कि अधिकांश व्यवसाय एक relational database से समर्थित एक अच्छी तरह संरचित single app के साथ काफ़ी दूर तक scale कर सकते हैं। कई लोग resume-driven development, FAANG-style patterns के प्रति hype, और कमजोर technical leadership को अनावश्यक जटिलता के लिए ज़िम्मेदार मानते हैं, जो reliability को नुकसान पहुँचाती है, delivery धीमी करती है, और teams को थकाती है। अन्य लोग नोट करते हैं कि microservices और event-driven designs संगठनात्मक scaling या विशिष्ट performance needs के लिए उचित हो सकते हैं, लेकिन केवल तब जब वे fashion के बजाय वास्तविक constraints से प्रेरित हों।
साधारण बनाम जटिल आर्किटेक्चर
- कई टिप्पणीकार “बोरिंग” स्टैक्स (Rails/Django या Python+Postgres, SSR टेम्पलेट्स + htmx, एकल VPS) को अधिकांश CRUD/व्यावसायिक ऐप्स, खासकर B2B, के लिए पर्याप्त मानते हैं।
- वे ज़ोर देते हैं कि साधारण सिस्टम समझने, मेंटेन करने, डिबग करने और स्टाफिंग के लिए आसान होते हैं; “पुराना और भरोसेमंद” अक्सर “नया और चमकदार” से बेहतर होता है।
- दूसरों का तर्क है कि “साधारण” क्या है, यह व्यक्तिपरक है: कंटेनर, k8s, GraphQL, या async I/O उनसे परिचित लोगों को साधारण और दूसरों को जटिल लग सकते हैं।
मोनोलिथ, माइक्रोसर्विसेज, और इवेंट सोर्सिंग
- स्पष्ट मॉड्यूल और सीमाओं के साथ संरचित मोनोलिथ से शुरुआत करने के लिए मज़बूत समर्थन है; कई लोग दावा करते हैं कि अनुशासित मोनोलिथ बहुत दूर तक स्केल कर सकता है।
- माइक्रोसर्विसेज के आलोचक कहते हैं कि वे जटिलता कम नहीं करते, बस उसे नेटवर्क के पार भेज देते हैं, जिससे consistency, transactions, debugging, और deployments कठिन हो जाते हैं।
- माइक्रोसर्विसेज के समर्थक उन्हें मुख्यतः संगठनात्मक और समन्वय उपकरण के रूप में पेश करते हैं: स्वतंत्र टीमों, अलग failure, और लक्षित scaling को संभव बनाना।
- कुछ लोगों के अनुसार Event sourcing/CQRS “microservices done right” है, लेकिन अन्य इसे अपरिपक्व और जटिल बताते हैं (PII deletion, replay semantics, determinism)।
तकनीकी विकल्प: Python, GraphQL, Kubernetes
- कुछ लोग मानते हैं कि वर्णित stack (Python monolith + Postgres + queues + GraphQL + k8s + custom protocol) वास्तव में “साधारण” नहीं है और इनमें से कई विकल्पों पर सवाल उठाते हैं।
- फ़ाइनेंस में Python पर बहस: कुछ लोगों के लिए money-handling में static typing अत्यंत महत्वपूर्ण है; अन्य का तर्क है कि आधुनिक Python tooling (mypy, C FFI, rich libs) पर्याप्त है।
- GraphQL को कुछ लोग सराहते हैं (REST endpoint sprawl घटाता है, shared schema, strong typing) और कुछ विरोध भी करते हैं (conceptual complexity, response size, REST पर सख्ती से आवश्यक नहीं)।
- Kubernetes को कुछ लोग छोटी टीमों के लिए अनावश्यक overhead मानते हैं; अन्य कहते हैं कि managed k8s cluster एक “plain” three-tier app चलाने का सीधा तरीका हो सकता है।
मानवीय और संगठनात्मक कारक
- कई लोग जटिलता का दोष resume-driven या “magpie” engineering पर डालते हैं: Kafka/microservices/cloud आदि को वास्तविक समस्याएँ हल करने के बजाय सीखने या प्रभावित करने के लिए अपनाना।
- अन्य लोग नोट करते हैं कि अन्वेषण का मूल्य है, लेकिन इसे prototypes, side projects, या सीमित संदर्भों में होना चाहिए, core production systems में नहीं।
- कई लोग ज़ोर देते हैं कि आर्किटेक्चर को संगठन की वास्तविकता से मेल खाना चाहिए: team size, experience, ownership, और incentives specific patterns से अधिक महत्वपूर्ण हैं।
स्केल, प्रदर्शन, और “आपको इसकी ज़रूरत नहीं पड़ेगी”
- एक पक्ष का तर्क है कि synchronous I/O और single DBs “millions of requests per month” आसानी से संभाल लेते हैं; distributed complexity से पहले बड़े boxes के साथ scale करें।
- दूसरा पक्ष चेतावनी देता है कि blocking I/O और खराब चुनी गई stacks कम volume पर भी गिर सकती हैं, खासकर जब downstream latency spikes हों।
- व्यापक सहमति है कि समय से पहले “Netflix की तरह बनाना” कई कंपनियों को डुबो चुका है या धीमा कर चुका है, लेकिन यह भी कि कम-डिज़ाइन बाद में ठीक करना महँगा पड़ सकता है।
करियर, प्रोत्साहन, और मूल्य
- कुछ लोग चिंता करते हैं कि “boring tech” पर ध्यान देने से करियर संभावनाएँ खराब होती हैं क्योंकि hiring अक्सर buzzword stacks के आधार पर फ़िल्टर करता है।
- अन्य लोग जवाब देते हैं कि मापने योग्य business impact (“saved X, enabled Y revenue”) senior levels पर tech bingo से अधिक प्रभावशाली होता है।
- कई लोग असंतुलित incentives नोट करते हैं: सस्ता capital और growth-at-all-costs ने फिजूल जटिलता को बढ़ावा दिया; engineers को business outcomes के और करीब बाँधना एक सुधार के रूप में सुझाया जाता है।