𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝘃𝘀. 𝗠𝗼𝗻𝗼𝗹𝗶𝘁𝗵𝗶𝗰 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲: तुम्ही काय तयार केले पाहिजे?
एका संस्थापकाने मला एकदा आर्किटेक्चर पिच (architecture pitch) तपासायला सांगितले.
त्या एजन्सीने अकरा सेवा (services), एक मेसेज क्यू (message queue) आणि सर्व्हिस मेश (service mesh) सुचवले होते. हे शून्य वापरकर्ते असलेल्या एका साध्या बुकिंग टूलसाठी होते.
हा एक सापळा आहे.
आर्किटेक्चरचे निर्णय तुमचे होस्टिंग बिल, तुमच्या डिलिव्हरीचा वेग (shipping speed) आणि तुमची भरती योजना (hiring plan) ठरवतात. डेव्हलपरला बजेट देण्यापूर्वी तुम्हाला त्याची किंमत माहित असणे आवश्यक आहे.
द मोनोलिथ (The Monolith) मोनोलिथमध्ये एक कोडबेस (codebase), एक डिप्लॉयमेंट (deployment) आणि एक डेटाबेस (database) वापरला जातो. हे सोपे असते.
पहिल्या दिवसापासून तुम्हाला तुमच्या डोमेनच्या सीमा (domain boundaries) माहित नसतात. जर तुम्ही सेवा खूप लवकर विभागल्या, तर तुम्हाला अशा भिंती हलवण्यात वेळ घालवावा लागेल ज्या अस्तित्वातच नसायला हव्या होत्या. जेव्हा तुमची टीम लहान असते, तेव्हा मोनोलिथ व्यवस्थापित करणे सोपे असते. तुम्ही API सेट करण्याऐवजी थेट फंक्शन (function) कॉल करता. जेव्हा रात्री २ वाजता एखादा बग (bug) येतो, तेव्हा त्रुटी कोडमध्ये दिसते, नेटवर्क फेल्युअरमध्ये नाही.
मायक्रोसर्व्हिसेस (Microservices) मायक्रोसर्व्हिसेस संघटनात्मक समस्या सोडवतात. त्या वेगवेगळ्या टीमना त्यांच्या स्वतःच्या वेळापत्रकानुसार कोड शिप (ship) करण्याची परवानगी देतात. नेटफ्लिक्स (Netflix) एका त्रुटीमुळे संपूर्ण सिस्टम कोलमडू नये म्हणून त्यांचा वापर करते.
तथापि, याची किंमत तुम्हाला दररोज चुकवावी लागते. नेटवर्क कॉल्समुळे लॅटन्सी (latency) वाढते. डेटा सुसंगतता (data consistency) राखणे कठीण होते. लॉग्स (logs) आणि ट्रेसिंग (tracing) व्यवस्थापित करण्यासाठी तुम्हाला विशेष साधने आणि मोठ्या टीमची आवश्यकता असते. योग्य कर्मचारी संख्या नसल्यास, शेवटी तुमच्याकडे 'डिस्ट्रिब्युटेड मोनोलिथ' (distributed monolith) उरतो. यामुळे तुम्हाला नेटवर्कची सर्व गुंतागुंत मिळते, पण स्वातंत्र्य मात्र मिळत नाही.
मॉड्युलर मोनोलिथ (The Modular Monolith) हा एक सुवर्णमध्य आहे. हे एकच ॲप आहे, परंतु कोडच्या विविध भागांमध्ये स्पष्ट सीमा असतात. बिलिंग विभाग तुमच्या ऑर्डर्सच्या अंतर्गत रचनेला (guts of your orders) स्पर्श करू शकत नाही.
शॉपिफाय (Shopify) आणि गिटहब (GitHub) या दृष्टिकोनाचा वापर करतात. यामुळे तुम्हाला स्पष्ट सीमा मिळतात आणि नेटवर्कचा अतिरिक्त भार (network tax) टाळता येतो. जेव्हा तुमच्या ॲपचा एखादा भाग स्वतंत्रपणे स्केल (scale) करण्याची गरज पडते, तेव्हा तुम्ही तो सहजपणे वेगळा करू शकता कारण त्याच्या सीमा आधीच निश्चित केलेल्या असतात.
निर्णय कसा घ्यावा:
- टीमचा आकार: जर तुमच्याकडे तीन लोक असतील, तर तुम्ही स्वतंत्र सेवा आणि आवश्यक ऑन-कॉल रोटेशन (on-call rotation) व्यवस्थापित करू शकणार नाही.
- उत्पादनाची स्थिरता: जर तुमचे उत्पादन दर आठवड्याला बदलत असेल, तर पुढच्या महिन्यापर्यंत तुमच्या सेवांच्या सीमा चुकीच्या ठरतील.
- ऑपरेशन्स: तुमच्याकडे ऑटोमेटेड रोलबॅक (automated rollbacks) आणि लॉग अॅग्रिगेशन (log aggregation) आहे का? नसेल तर, मायक्रोसर्व्हिसेसमुळे अडचणी येतील.
- स्केल: केवळ काल्पनिक वाढीसाठी काहीही तयार करू नका. तुम्हाला दिसणाऱ्या प्रत्यक्ष मार्गासाठी तयार करा.
जर तुमची उत्तरे "अजून नाही" अशी असतील, तर मॉड्युलर मोनोलिथ तयार करा.
केवळ 'मायक्रोसर्व्हिसेस' हा शब्द आधुनिक वाटतो म्हणून त्याची मागणी करू नका. तुमचे उत्पादन काय करते आणि त्याची देखभाल कोण करणार आहे, हे तुमच्या भागीदाराला सांगा.
उत्पादने कधीही लाँच (ship) होत नाहीत, म्हणून ती अपयशी ठरतात. वापरकर्त्यांपर्यंत पोहोचण्याचा सर्वात वेगवान मार्ग म्हणजे एक स्वच्छ 'मोनोलिथ' (monolith) आर्किटेक्चर आहे. आधी तेच तयार करा. गोष्टींचे विभाजन करण्याची वेळ कधी येईल, हे तुमच्या ट्रॅफिकवरून ठरू द्या.
ऐच्छिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi