सुसूत्रता हे तुम्ही गाठण्याचे ध्येय नाही. ते तुम्ही भरलेले एक सबस्क्रिप्शन आहे. प्रत्येक अभियांत्रिकी संस्था (engineering organization) कालांतराने याचा अनुभव घेते, सहसा जेव्हा दुसरी किंवा तिसरी टीम एकाच रिपॉझिटरीमध्ये काम करण्यास सुरुवात करते. तुम्ही एक सिंगल React monolith चालवत असाल किंवा स्वतंत्रपणे तैनात करता येण्याजोग्या (independently deployable) फ्रंटएंड्सचा समूह चालवत असाल, तरीही तुम्ही शून्य खर्चासाठी ऑप्टिमाइझ करत नाही आहात. तुम्ही फक्त दर तिमाहीला कोणते बिल समोर येईल, याची निवड करत असता.

Monoliths चा समन्वयाचा कर (The Coordination Tax of Monoliths)

मोनोलिथिक आर्किटेक्चरमध्ये, हे बिल मानवी तासांमध्ये मोजले जाते. टीम्स आपला दिवस सामायिक कोड, स्टाइल्स आणि रिलीज शेड्यूल्सवर एकमत करण्यासाठी खर्च करतात. एखाद्या डेव्हलपरला चेकआउटमधील किरकोळ सुधारणा (minor checkout fix) शिप करायची असेल, तर त्याला कदाचित इतर सहा टीम्सद्वारे वापरल्या जाणाऱ्या सामायिक डिपेंडन्सीला (shared dependency) अपडेट करावे लागू शकते आणि त्यानंतर पूर्ण रिग्रेशन सूट (regression suite) पूर्ण होण्याची प्रतीक्षा करावी लागते. हा खर्च शांतपणे वाढत जातो. क्लाउड बिलावर ही रक्कम कधीही स्वतंत्रपणे दिसत नाही. ती कमी झालेल्या वेगामध्ये (velocity), कोड स्टाईल बद्दलच्या Slack थ्रेड्समध्ये इंजिनिअर्सच्या कॉन्टेक्स्ट-स्विचिंगमध्ये आणि अशा CSS आर्किटेक्चरमधील संथ घर्षणामध्ये लपलेली असते ज्याचा मालक कोणीही नाही पण स्पर्श सर्वच करतात.

जसजशी तुमची टीम वाढते, तसतसा हा करही वाढतो. कोड रिव्ह्यूमधील अडथळे (bottlenecks) तांत्रिक बाबींकडून सामाजिक बाबींकडे वळतात. दोनशे योगदानकर्त्यांची (contributors) एक सिंगल रिपॉझिटरी रेषीय पद्धतीने (linearly) स्केल होत नाही; ती कॉम्बिनेटोरियल पद्धतीने (combinatorially) स्केल होते. मर्ज क्यू (Merge queues) मागे पडतात. रिलीज ट्रेन्स (Release trains) अनेक दिवस ताणल्या जातात. डिझाइन सिस्टम ही एक राजकीय संस्था बनते ज्याला नवीन बटण व्हेरिएंट मंजूर करण्यासाठी नियामक परिषदेची (governing council) आवश्यकता लागते. मोनोलिथ द्वेषपोटी बदलाला विरोध करत नाही. तो बदलाला विरोध करतो कारण प्रत्येक पृष्ठभाग सामायिक आहे आणि प्रत्येक बदलासाठी सर्वसंमती आवश्यक असते.

सीमा निश्चित करणे (Drawing Boundaries)

Microfrontends समन्वयाचा खर्च विशिष्ट सीमांमध्ये (boundaries) विभागतात. सामायिक स्टेट मॅनेजमेंटबद्दल साप्ताहिक मीटिंग करण्याऐवजी, तुम्ही एक रेषा आखता. टीम A प्रॉडक्ट कॅटलॉगची मालकी घेते. टीम B कार्टची मालकी घेते. ते एका करारावर (contract) सहमत होतात, जो सहसा राउटिंग बाउंड्री किंवा एक मर्यादित इव्हेंट स्कीमा असतो, आणि त्यानंतर ते एकमेकांशी संवाद थांबवतात. हा मुख्य व्यापार आहे: एका वेगळ्या प्रकारच्या शिस्तीच्या बदल्यात स्वायत्तता (autonomy) मिळवणे.

याचा सिद्धांत स्पष्ट आहे. जर 'शिपिंग टीम' तिच्या राउटिंग लेयरमध्ये रिफॅक्टर (refactor) करत असेल, तर 'बिलिंग टीम'ला त्याचा फरक पडू नये. जर सर्च इंटरफेसला दिवसातून पाच वेळा डिप्लॉय करण्याची गरज असेल, तर त्याने अकाउंट सेटिंग्स पेजचे एंड-टू-एंड टेस्ट्स पूर्ण होण्याची वाट पाहू नये. सीमा (Boundaries) संस्थात्मक घर्षणामध्ये तांत्रिक इंटरफेसमध्ये रूपांतरित करतात. पण ती रेषा आखणे कधीही मोफत नसते.

इन्फ्रास्ट्रक्चर बिल (The Infrastructure Bill)

Microfrontends प्लॅटफॉर्म खर्च निर्माण करतात. तुम्हाला रनटाइमला फ्रॅगमेंट्स एकत्र करण्यास सक्षम असलेल्या एका शेल ॲप्लिकेशनची (shell application) गरज असते. तुम्हाला अशा डिप्लॉयमेंट पाइपलाइनची गरज असते जिला समजते की अनेक बिल्ड जॉब्समधून आर्टिफॅक्ट्स एकत्र करून एक सुसंगत पेज कसे तयार करायचे. जर तुम्ही Webpack Module Federation वापरत असाल, तर तुम्ही आता स्वतंत्रपणे तयार केलेल्या बंडल्समध्ये सामायिक डिपेंडन्सी व्हर्जन मॅनेज करत आहात. जर तुम्ही iframes वापरत असाल, तर तुम्ही क्रॉस-ओरिजिन मेसेजिंगमधील त्रुटी शोधत आहात आणि लेआउट शिफ्ट्सशी (layout shifts) लढत आहात. जर तुम्ही web components वापरत असाल, तर तुम्ही एका डिस्ट्रिब्युटेड ग्राफमध्ये कस्टम एलिमेंट्सचे व्हर्जनिंग करत आहात, जिथे एका टीमचे अपग्रेड दुसऱ्या टीमच्या कामात अडथळा आणू शकते.

हे खर्च प्रत्यक्ष आणि वारंवार लागणारे आहेत. सहा फ्रंटएंड्स सातवे न मोडता रिलीज करू शकेल अशा बिल्ड ऑर्केस्ट्रेशनसाठी तुम्ही पैसे मोजता. तीन वेगवेगळ्या टीम्सच्या तीन वेगवेगळ्या JavaScript बंडल्समध्ये युजरच्या कृतीचा मागोवा घेणाऱ्या ऑब्झर्व्हेबिलिटीसाठी (observability) तुम्ही पैसे मोजता. तुम्ही परफॉर्मन्स गव्हर्नन्ससाठी पैसे मोजता, कारण जर सहा टीम्स त्यांच्या स्वतःच्या युटिलिटी लायब्ररीच्या प्रती बंडल करत असतील, तर जोपर्यंत कोणीतरी ड्युप्लिकेशन टाळण्यासाठीची रणनीती (deduplication strategy) तयार करत नाही, तोपर्यंत तुमचे पेज जड आणि संथ होईल. त्या बिंदूवर, तुम्ही ज्या मोनोलिथपासून सुटका करून घेण्याचा प्रयत्न करत होता, त्याचाच एक भाग पुन्हा तयार केला आहे, फक्त आता तो टिकवून ठेवण्यासाठी प्लॅटफॉर्म टीमची आवश्यकता आहे.

जेव्हा खर्च बदलतो (When the Costs Shift)

एका मध्यम आकाराच्या SaaS कंपनीचा विचार करा जिथे चार फ्रंटएंड टीम्स एक सिंगल Next.js ॲप्लिकेशन शेअर करत आहेत. तीन तासांच्या CI रननंतर दिवसातून दोनदा डिप्लॉयमेंट होते. जेव्हा शिपिंग टीमला नेव्हिगेशन रिफॅक्टर करायचे असते, तेव्हा ते कमेंट्ससाठी विनंती दाखल करतात, संपूर्ण ट्रीमध्ये इम्पोर्ट पाथ अपडेट करतात आणि बिलिंग टीमने त्यांचे इंटिग्रेशन टेस्ट्स समायोजित करण्यासाठी दोन आठवडे वाट पाहतात. हा खर्च निव्वळ समन्वय साधण्याचा आहे.

ते Microfrontends मध्ये विभागले जातात. प्रत्येक टीम आता स्वतःचा व्हर्टिकल (vertical) मालकी हक्क घेते आणि स्वतःच्या वेळापत्रकानुसार प्रोडक्शनमध्ये पुश करते. पहिला महिना स्वातंत्र्यासारखा वाटतो. मग एक बग येतो. ग्लोबल हेडर Safari मध्ये रेंडर होत नाही कारण शिपिंग टीमने CSS-in-JS लायब्ररी अपडेट केली आहे जी सर्च टीमने इंजेक्ट केलेल्या बेस स्टाइल्सशी विसंगत आहे. डीबगिंगसाठी तीन ऑन-कॉल इंजिनिअर्स, एक सामायिक वॉर रूम आणि दोन सर्व्हिसेसचा वेदनादायक रोलबॅक (rollback) आवश्यक असतो कारण शेल ॲप मॉड्यूल मॅनिफेस्ट्स कॅश करते. खर्च बदलला आहे. तो नाहीसा झालेला नाही.

स्केलिंगचे गणित (Scaling Arithmetic)

दोन्हीपैकी कोणतेही मॉडेल मोफत नाही. पंधरा लोकांच्या स्टार्टअपला प्लॅटफॉर्म टीमची गरज नसते. मॉड्यूल फेडरेशन, स्वतंत्र डिप्लॉयमेंट पाइपलाइन्स आणि डिस्ट्रिब्युटेड कॉन्ट्रॅक्ट टेस्टिंगचा ओव्हरहेड त्यांच्या संपूर्ण गतीवर परिणाम करेल. त्यांनी समन्वयाद्वारे किंमत मोजली पाहिजे कारण समन्वय स्वस्त आहे. ते दहा मिनिटांच्या संवादात स्टेट मॅनेजमेंट पॅटर्नवर सहमत होऊ शकतात आणि त्याच दुपारी ते कार्यान्वित करू शकतात.

वेगवेगळ्या त्रैमासिक चक्रांवर काम करणाऱ्या डझनभर बिझनेस युनिट्स असलेल्या पाचशे लोकांच्या मोठ्या संस्थेला (enterprise) याच्या अगदी उलट समस्या भेडसावते. समन्वयाचा भार (coordination tax) आता घातांकीय झाला आहे. रिलीज ट्रेन्ससाठी आठवडे लागतात. प्लॅटफॉर्म इंजिनीअरिंग हेडकाउंट हा आधीच बजेटचा भाग आहे, त्यामुळे मायक्रोफ्रंटएंड इन्फ्रास्ट्रक्चर जोडणे हा एक अल्प खर्च आहे, नवीन खर्च नाही. त्यांच्यासाठी, अलाइनमेंट मीटिंग्सच्या बदल्यात डिप्लॉयमेंट ग्राफ्स स्वीकारणे हे तर्कसंगत गणित आहे.

खरा प्रश्न हा आहे की तुमच्या टीमसाठी कोणता खर्च अधिक चांगल्या प्रकारे स्केल होऊ शकतो. मोनोलिथ्स तुमच्याकडून मानवी समन्वयाच्या मर्यादेवर कर वसूल करतात. मायक्रोफ्रंटएंड्स तुमच्याकडून प्लॅटफॉर्म इंजिनीअरिंगच्या पायाभूत स्तरावर कर वसूल करतात.

तुमची निवड (Currency) करा

जर तुम्ही मायक्रोफ्रंटएंड्स निवडले, तर तुम्ही नक्की काय खरेदी करत आहात याबद्दल स्पष्ट राहा. तुम्ही टीमची स्वायत्तता आणि स्वतंत्र डिप्लॉयबिलिटी खरेदी करत आहात. खालील गोष्टींसाठी निधी देण्यासाठी तयार राहा:

  • एक रनटाइम शेल जे कंपोझिशन, राउटिंग आणि फ्रॅगमेंट्समधील एरर बाउंड्रीज हाताळते.
  • ड्युप्लिकेशन टाळण्याच्या धोरणावर (deduplication strategy) लक्ष केंद्रित करणारे शेअर डिपेंडन्सी पॉलिसी, केवळ शेअर केलेल्या अंमलबजावणीच्या लॉजिकवर नाही.
  • प्रत्येक इंटिग्रेशन सरफेससाठी क्रॉस-टीम कॉन्ट्रॅक्ट टेस्टिंग.
  • युनिफाइड ऑब्झर्व्हेबिलिटी (Unified observability) जी डिस्ट्रिब्युटेड बंडल्समधील युजर क्लिकचा संबंध जोडू शकते.
  • एक परफॉर्मन्स गव्हर्नन्स मॉडेल, कारण ब्राउझर जे फायनल पेलोड डाउनलोड करतो त्यावर कोणत्याही एका टीमचे नियंत्रण नसते.

जर तुम्ही मोनोलिथ निवडले, तर बिलाबाबत प्रामाणिक राहा. तुम्ही सिंक्रोनाइझेशनच्या बदल्यात साधेपणा खरेदी करत आहात. खालील गोष्टींसाठी खर्च अपेक्षित ठेवा:

  • शेअर कोड ओनरशिप आणि तो सुसंगत ठेवण्यासाठी आवश्यक असलेले गव्हर्नन्स रिचुअल्स.
  • पाइपलाइनमधील सर्वात संथ इंटिग्रेशन टेस्टद्वारे ठरवलेला रिलीज कॅडन्स (release cadence).
  • लायब्ररी अपग्रेड्सचा मोठा परिणाम (wide blast radius).
  • ही हळूहळू जाणारी वास्तवता की तुमचे सर्वात वेगवान इंजिनीअर्स तुमच्या सर्वात सावध इंजिनीअर्सच्या वेगाने काम करतील.

मुख्य निष्कर्ष

अशी कोणतीही आर्किटेक्चर नाही जी किंमत काढून टाकेल. तिथे फक्त 'करन्सी'ची निवड असते. हुशार संस्था मोफत पर्यायाचा शोध घेणे थांबवतात आणि कोणता खर्च ते खरोखर पेलू शकतात याचे ऑडिट करण्यास सुरुवात करतात. तुम्हाला मानवी समन्वयाद्वारे खर्च करायचा आहे की प्लॅटफॉर्म ओव्हरहेडद्वारे, हे तुम्हाला ठरवावे लागेल. दोन्ही परिस्थितीत, एकरूपता (Uniformity) ही एक सबस्क्रिप्शनसारखीच आहे. एकमेव प्रश्न हा आहे की, याचे पेमेंट कोण करणार.