- एकल backend से microservices architecture में बदलाव की लागत और लाभ पर लेख
- जैसे-जैसे एक ही codebase में योगदान देने वाली टीमों की संख्या बढ़ती है, components आपस में अधिक जुड़े हुए हो जाते हैं, जिससे productivity घटती है और complexity बढ़ती है
- इन समस्याओं को कम करने का एक समाधान है एकल backend को API के ज़रिए संचार करने वाली स्वतंत्र रूप से deploy की जा सकने वाली services के सेट में बाँटना, यानी microservices
- 'micro' शब्द भ्रामक है, क्योंकि services का वास्तव में 'micro' होना ज़रूरी नहीं है। अधिक उपयुक्त शब्द service-oriented architecture है
- backend को स्पष्ट रूप से परिभाषित सीमाओं वाली services के सेट में विभाजित करने से application development की गति बढ़ती है, क्योंकि हर service को विकसित और संचालित करने के लिए एक छोटी टीम पर्याप्त हो सकती है
- हर microservice स्वतंत्र रूप से scale हो सकती है और अपनी ज़रूरत के अनुसार अलग technology stack अपना सकती है, जिससे नई technologies के experiment और evaluation आसान हो जाते हैं
- लेकिन microservices architecture पूरे system में अधिक moving parts जोड़कर complexity बढ़ाता है और एक निश्चित स्तर के standardization की आवश्यकता पैदा करता है
- हर microservice के लिए अलग language, library और datastore का उपयोग application maintenance को कठिन बनाने वाली अव्यवस्था में बदल सकता है, और developers के लिए टीमों के बीच move करना मुश्किल हो जाता है
- बड़ी संख्या में स्वतंत्र services को support करने के लिए नए servers, datastores और अन्य resources को आसानी से बनाया जा सकना चाहिए, जिसके लिए काफ़ी automation की ज़रूरत होती है
- remote calls महंगे होते हैं और system failure के नए तरीके लाते हैं, इसलिए timeout, retry और circuit breaker जैसे defense mechanisms की आवश्यकता होती है
- continuous integration यह सुनिश्चित करता है कि code changes automatic build और test process से गुजरने के बाद main branch में merge हों
- सभी microservices का integration testing, monolith testing की तुलना में कहीं अधिक कठिन है; जब अलग-अलग services एक-दूसरे के साथ interact करती हैं, तो बहुत सूक्ष्म और अप्रत्याशित व्यवहार सामने आ सकते हैं
- services विकसित करने वाली टीमें आमतौर पर उनके on-call support की ज़िम्मेदारी भी उठाती हैं, जिससे development work और operational cost के बीच friction पैदा होता है
- microservices के साथ system failures को debug करना अधिक कठिन हो जाता है; हर स्तर पर अच्छा logging और monitoring महत्वपूर्ण है
- application को अलग-अलग services में बाँटने से data model अब एक ही datastore में नहीं रहता, इसलिए आम तौर पर eventual consistency को स्वीकार करना पड़ता है
- आम तौर पर monolith से शुरुआत करना सबसे अच्छा है, और केवल तब विभाजित करना चाहिए जब services के बीच boundaries को सटीक रूप से तय करना कठिन होने लगे
- microservices-first approach से शुरुआत केवल तभी करनी चाहिए जब आपके पास पहले से इसका अनुभव हो, इसके लिए platform बना लिया हो, या उसे बनाने में लगने वाले समय को ध्यान में रखा हो
अभी कोई टिप्पणी नहीं है.