ഏകത എന്നത് നിങ്ങൾ എത്തിച്ചേരുന്ന ഒരു ലക്ഷ്യമല്ല. അത് നിങ്ങൾ നൽകിക്കൊണ്ടിരിക്കുന്ന ഒരു സബ്‌സ്‌ക്രിപ്‌ഷനാണ്. എല്ലാ എഞ്ചിനീയറിംഗ് ഓർഗനൈസേഷനുകളും ഒടുവിൽ ഇത് തിരിച്ചറിയുന്നു, സാധാരണയായി രണ്ടാമത്തെയോ മൂന്നാമത്തെയോ ടീം ഒരേ റെപ്പോസിറ്ററിയിലേക്ക് കോഡ് സമർപ്പിക്കാൻ തുടങ്ങുന്ന സമയത്താണ്. നിങ്ങൾ ഒരു സിംഗിൾ React monolith ഉപയോഗിക്കുകയാണോ അതോ സ്വതന്ത്രമായി വിന്യസിക്കാവുന്ന ഫ്രണ്ട്‌എൻഡുകളുടെ ഒരു കൂട്ടമാണോ ഉപയോഗിക്കുന്നത് എന്നതിലുപരി, നിങ്ങൾ പൂജ്യം ചിലവിൽ കാര്യങ്ങൾ ചെയ്യാൻ ശ്രമിക്കുകയല്ല. പകരം, ഓരോ പാദത്തിലും ഏത് ബില്ലാണ് വരുന്നത് എന്ന് നിങ്ങൾ തിരഞ്ഞെടുക്കുകയാണ് ചെയ്യുന്നത്.

മോണോലിത്തുകളുടെ കോർഡിനേഷൻ ടാക്സ്

ഒരു മോണോലിത്തിക് ആർക്കിടെക്ചറിൽ, ബില്ല് കണക്കാക്കുന്നത് മനുഷ്യ മണിക്കൂറുകൾ ഉപയോഗിച്ചാണ്. ടീമുകൾ അവരുടെ ദിവസങ്ങൾ പങ്കിട്ട കോഡ്, സ്റ്റൈലുകൾ, റിലീസ് ഷെഡ്യൂളുകൾ എന്നിവ ഏകോപിപ്പിക്കുന്നതിനായി ചെലവഴിക്കുന്നു. ഒരു ചെറിയ ചെക്ക്ഔട്ട് ഫിക്സ് (checkout fix) ചെയ്യാൻ ആഗ്രഹിക്കുന്ന ഒരു ഡെവലപ്പർക്ക്, മറ്റ് ആറ് ടീമുകൾ ഉപയോഗിക്കുന്ന ഒരു ഷെയർഡ് डिपൻഡൻസി (shared dependency) അപ്‌ഡേറ്റ് ചെയ്യേണ്ടി വന്നേക്കാം, തുടർന്ന് ഒരു ഫുൾ റഗ്രഷൻ സ്യൂട്ട് (full regression suite) പൂർത്തിയാകുന്നത് വരെ കാത്തിരിക്കേണ്ടി വരും. ഈ ചിലവ് നിശബ്ദമായി വർദ്ധിച്ചുകൊണ്ടിരിക്കും. ഇത് ക്ലൗഡ് ബില്ലിലെ ഒരു വരിയായി ഒരിക്കലും പ്രത്യക്ഷപ്പെടില്ല. ഇത് കുറഞ്ഞ വേഗതയിലും, കോഡ് സ്റ്റൈലിനെക്കുറിച്ചുള്ള Slack ചർച്ചകൾക്കിടയിൽ എഞ്ചിനീയർമാർ നേരിടുന്ന കോൺടെക്സ്റ്റ്-സ്വിച്ചിംഗിലും, ആരും ഉടമസ്ഥത വഹിക്കാത്ത എന്നാൽ എല്ലാവരും ഉപയോഗിക്കുന്ന ഒരു CSS ആർക്കിടെക്ചറിന്റെ സാവധാനത്തിലുള്ള തടസ്സങ്ങളിലും ഒളിഞ്ഞിരിക്കുന്നു.

നിങ്ങളുടെ ടീം വളരുന്നതിനനുസരിച്ച്, ഈ ടാക്സും വളരുന്നു. കോഡ് റിവ്യൂ തടസ്സങ്ങൾ സാങ്കേതിക പ്രശ്നങ്ങളിൽ നിന്ന് സാമൂഹിക പ്രശ്നങ്ങളിലേക്ക് മാറുന്നു. ഇരുനൂറ് കൺട്രിബ്യൂട്ടർമാരുള്ള ഒരു സിംഗിൾ റെപ്പോസിറ്ററി ലീനിയർ ആയി വളരില്ല; അത് കോമ്പിനേറ്റോറിയൽ (combinatorially) ആയി വളരുന്നു. മെർജ് ക്യൂകൾ (Merge queues) കുരുങ്ങിക്കിടക്കുന്നു. റിലീസ് ട്രെയിനുകൾ ദിവസങ്ങളോളം നീണ്ടുനിൽക്കുന്നു. ഒരു പുതിയ ബട്ടൺ വേരിയന്റിന് അംഗീകാരം നൽകാൻ ഒരു ഗവേണിംഗ് കൗൺസിൽ ആവശ്യമായ ഒരു രാഷ്ട്രീയ സംവിധാനമായി ഡിസൈൻ സിസ്റ്റം മാറുന്നു. മോണോലിത്ത് മാറ്റങ്ങളെ എതിർക്കുന്നത് വിദ്വേഷം കൊണ്ടല്ല. എല്ലാ ഭാഗങ്ങളും പങ്കിട്ടതായതുകൊണ്ടും, ഓരോ മാറ്റത്തിനും എല്ലാവരുടെയും സമ്മതം ആവശ്യമായതുകൊണ്ടുമാണ് അത് മാറ്റങ്ങളെ പ്രതിരോധിക്കുന്നത്.

അതിരുകൾ നിശ്ചയിക്കൽ

മൈക്രോഫ്രണ്ട്‌എൻഡുകൾ കോർഡിനേഷൻ ചിലവുകളെ പ്രത്യേക അതിരുകളിലേക്ക് മാറ്റുന്നു. ഷെയർഡ് സ്റ്റേറ്റ് മാനേജ്‌മെന്റിനെക്കുറിച്ചുള്ള പ്രതിവാര മീറ്റിംഗുകൾക്ക് പകരം, നിങ്ങൾ ഒരു അതിര് നിശ്ചയിക്കുന്നു. ടീം A ഉൽപ്പന്ന കാറ്റലോഗ് (product catalog) കൈകാര്യം ചെയ്യുന്നു. ടീം B കാർട്ട് (cart) കൈകാര്യം ചെയ്യുന്നു. അവർ ഒരു കോൺട്രാക്ട് (contract) - സാധാരണയായി ഒരു റൂട്ടിംഗ് ബൗണ്ടറിയോ അല്ലെങ്കിൽ ഒരു ഇടുങ്ങിയ ഇവന്റ് സ്കീമയോ - അംഗീകരിക്കുന്നു, അതിനുശേഷം അവർ പരസ്പരം ഇടപെടുന്നത് നിർത്തുന്നു. ഇതാണ് ഇതിന്റെ കാതൽ: മറ്റൊരു തരത്തിലുള്ള അച്ചടക്കത്തിന് പകരമായി ലഭിക്കുന്ന സ്വയംഭരണം (autonomy).

ഇതിന്റെ സിദ്ധാന്തം ലളിതമാണ്. ഷിപ്പിംഗ് ടീം അവരുടെ റൂട്ടിംഗ് ലെയർ റീഫാക്ടർ ചെയ്താൽ, ബില്ലിംഗ് ടീമിനെ അത് ബാധിക്കരുത്. സെർച്ച് ഇന്റർഫേസിന് ദിവസം അഞ്ച് തവണ ഡെപ്ലോയ് ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, അക്കൗണ്ട് സെറ്റിംഗ്സ് പേജിന്റെ എൻഡ്-ടു-എൻഡ് ടെസ്റ്റുകൾ പൂർത്തിയാകുന്നത് വരെ അത് കാത്തിരിക്കേണ്ടതില്ല. അതിരുകൾ സംഘടനാപരമായ തടസ്സങ്ങളെ സാങ്കേതിക ഇന്റർഫേസുകളാക്കി മാറ്റുന്നു. എന്നാൽ ആ അതിരുകൾ നിശ്ചയിക്കുന്നത് സൗജന്യമല്ല.

ഇൻഫ്രാസ്ട്രക്ചർ ബില്ല്

മൈക്രോഫ്രണ്ട്‌എൻഡുകൾ പ്ലാറ്റ്‌ഫോം ചിലവുകൾ ഉണ്ടാക്കുന്നു. റൺടൈമിൽ ഫ്രാഗ്മെന്റുകൾ കൂട്ടിച്ചേർക്കാൻ കഴിയുന്ന ഒരു ഷെൽ ആപ്ലിക്കേഷൻ (shell application) നിങ്ങൾക്ക് ആവശ്യമാണ്. ഒന്നിലധികം ബിൽഡ് ജോബുകളിൽ നിന്നുള്ള ആർട്ടീഫാക്റ്റുകൾ (artifacts) ഒരു ഏകീകൃത പേജായി എങ്ങനെ സംയോജിപ്പിക്കണമെന്ന് മനസ്സിലാക്കുന്ന ഒരു ഡെപ്ലോയ്‌മെന്റ് പൈപ്പ്‌ലൈൻ നിങ്ങൾക്ക് ആവശ്യമാണ്. നിങ്ങൾ Webpack Module Federation ആണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, സ്വതന്ത്രമായി നിർമ്മിച്ച ബണ്ടിലുകൾക്കിടയിൽ ഷെയർഡ് डिपൻഡൻസി വേർഷനുകൾ നിങ്ങൾ ഇപ്പോൾ മാനേജ് ചെയ്യേണ്ടതുണ്ട്. നിങ്ങൾ iframes ആണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, ക്രോസ്-ഒറിജിൻ മെസേജിംഗും (cross-origin messaging) ലേഔട്ട് ഷിഫ്റ്റുകളും (layout shifts) നിങ്ങൾ ഡീബഗ് ചെയ്യേണ്ടി വരും. നിങ്ങൾ web components ആണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, ഒരു ടീമിന്റെ അപ്‌ഗ്രേഡ് മറ്റൊരു ടീമിനെ ബാധിക്കാത്ത രീതിയിൽ ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് ഗ്രാഫിൽ കസ്റ്റം എലമെന്റുകളുടെ വേർഷനുകൾ നിങ്ങൾ കൈകാര്യം ചെയ്യേണ്ടി വരും.

ഈ ചിലവുകൾ കൃത്യവും ആവർത്തിച്ചുള്ളതുമാണ്. ഏഴ് ഫ്രണ്ട്‌എൻഡുകളെ തകരാറിലാക്കാതെ ആറ് ഫ്രണ്ട്‌എൻഡുകളെ റിലീസ് ചെയ്യാൻ കഴിയുന്ന ബിൽഡ് ഓർക്കസ്ട്രേഷനായി നിങ്ങൾ പണം നൽകുന്നു. മൂന്ന് വ്യത്യസ്ത ടീമുകൾ ഉടമസ്ഥതയിലുള്ള മൂന്ന് വ്യത്യസ്ത JavaScript ബണ്ടിലുകളിലുടനീളം ഒരു ഉപയോക്താവിന്റെ പ്രവർത്തനം ട്രാക്ക് ചെയ്യുന്ന ഒബ്സർവബിലിറ്റിക്കായി (observability) നിങ്ങൾ പണം നൽകുന്നു. ആരെങ്കിലും ഒരു ഡെഡ്യൂപ്ലിക്കേഷൻ സ്ട്രാറ്റജി (deduplication strategy) നിർമ്മിച്ചില്ലെങ്കിൽ, ആറ് ടീമുകൾ അവരുടെ യൂട്ടിലിറ്റി ലൈബ്രറികളുടെ കോപ്പികൾ ബണ്ടിൽ ചെയ്യുന്നത് നിങ്ങളുടെ പേജിനെ ഭാരമേറിയതാക്കും, അതിനാൽ പെർഫോമൻസ് ഗവേണൻസിനായി നിങ്ങൾ പണം നൽകുന്നു. ആ ഘട്ടത്തിൽ, നിങ്ങൾ രക്ഷപ്പെടാൻ ശ്രമിച്ച മോണോലിത്തിന്റെ ഒരു ഭാഗം തന്നെ വീണ്ടും നിർമ്മിച്ചിരിക്കുകയാണ്, വ്യത്യാസം ഇപ്പോൾ അത് നിലനിർത്താൻ ഒരു പ്ലാറ്റ്‌ഫോം ടീം ആവശ്യമാണ് എന്നതാണ്.

ചിലവുകൾ മാറുന്നപ്പോൾ

നാല് ഫ്രണ്ട്‌എൻഡ് ടീമുകൾ ഒരു സിംഗിൾ Next.js ആപ്ലിക്കേഷൻ പങ്കിടുന്ന ഇടത്തരം ഒരു SaaS കമ്പനിയെ പരിഗണിക്കുക. മൂന്ന് മണിക്കൂർ നീളുന്ന CI റണ്ണിന് ശേഷം ദിവസം രണ്ടുതവണ ഡെപ്ലോയ്‌മെന്റുകൾ നടക്കുന്നു. ഷിപ്പിംഗ് ടീമിന് നാവിഗേഷൻ (navigation) റീഫാക്ടർ ചെയ്യണമെന്നുണ്ടെങ്കിൽ, അവർ കമന്റുകൾക്കായി ഒരു അഭ്യർത്ഥന നൽകുന്നു, ട്രീയിലുടനീളം ഇംപോർട്ട് പാത്തുകൾ (import paths) അപ്‌ഡേറ്റ് ചെയ്യുന്നു, കൂടാതെ ബില്ലിംഗ് ടീം അവരുടെ ഇന്റഗ്രേഷൻ ടെസ്റ്റുകൾ ക്രമീകരിക്കുന്നതിനായി രണ്ടാഴ്ച കാത്തിരിക്കുന്നു. ഇതിന്റെ ചിലവ് കോർഡിനേഷൻ മാത്രമാണ്, ലളിതമായി പറഞ്ഞാൽ.

അവർ മൈക്രോഫ്രണ്ട്‌എൻഡുകളായി മാറുന്നു. ഓരോ ടീമും ഇപ്പോൾ ഒരു വെർട്ടിക്കൽ (vertical) കൈകാര്യം ചെയ്യുകയും സ്വന്തം ഷെഡ്യൂളിൽ പ്രൊഡക്ഷനിലേക്ക് പഷ് ചെയ്യുകയും ചെയ്യുന്നു. ആദ്യ മാസം ഒരു സ്വാതന്ത്ര്യം പോലെ തോന്നുന്നു. എന്നാൽ ഒരു ബഗ് പ്രത്യക്ഷപ്പെടുന്നു. സെർച്ച് ടീം ഇൻജക്റ്റ് ചെയ്ത ബേസ് സ്റ്റൈലുകളുമായി (base styles) സംഘർഷം ഉണ്ടാക്കുന്ന ഒരു CSS-in-JS ലൈബ്രറി ഷിപ്പിംഗ് ടീം അപ്‌ഗ്രേഡ് ചെയ്തതിനാൽ സഫാരിയിൽ (Safari) ഗ്ലോബൽ ഹെഡർ റെൻഡർ ചെയ്യുന്നതിൽ പരാജയപ്പെടുന്നു. ഇത് ഡീബഗ് ചെയ്യാൻ മൂന്ന് ഓൺ-കോൾ എഞ്ചിനീയർമാരും, ഒരു ഷെയർഡ് വാർ റൂമും (war room), കൂടാതെ ഷെൽ ആപ്പ് മോഡ്യൂൾ മാനിഫെസ്റ്റുകൾ (module manifests) കാഷെ ചെയ്യുന്നതിനാൽ രണ്ട് സർവീസുകളുടെ വേദനാജനകമായ റോൾബാക്കും ആവശ്യമാണ്. ചിലവ് മാറിയിരിക്കുന്നു, അത് ഇല്ലാതായിട്ടില്ല.

സ്കെയിലിംഗ് അരിത്മെറ്റിക്

ഒരു മോഡലും സൗജന്യമല്ല. പതിനഞ്ച് പേരുള്ള ഒരു സ്റ്റാർട്ടപ്പിന് ഒരു പ്ലാറ്റ്‌ഫോം ടീമിന്റെ ആവശ്യമില്ല. module federation, സ്വതന്ത്രമായ deployment pipelines, distributed contract testing എന്നിവയുടെ അധികഭാരം അവരുടെ വേഗതയെ (velocity) പൂർണ്ണമായും തടസ്സപ്പെടുത്തും. അവർ ഏകോപനത്തിലൂടെ (coordination) പണം നൽകണം, കാരണം ഏകോപനം ചിലവ് കുറഞ്ഞതാണ്. പത്ത് മിനിറ്റ് സംഭാഷണത്തിലൂടെ അവർക്ക് ഒരു state management pattern-ൽ ധാരണയിലെത്താനും അതേ ഉച്ചകഴിഞ്ഞ് തന്നെ അത് പുറത്തിറക്കാനും സാധിക്കും.

വ്യത്യസ്ത ക്വാർട്ടർലി സൈക്കിളുകളിൽ പ്രവർത്തിക്കുന്ന ഡസൻ കണക്കിന് ബിസിനസ്സ് യൂണിറ്റുകളുള്ള അഞ്ഞൂറ് പേരുള്ള ഒരു എന്റർപ്രൈസ് നേരെ വിപരീത പ്രശ്നമാണ് നേരിടുന്നത്. ഏകോപനത്തിനുള്ള ചിലവ് (coordination tax) വർദ്ധിച്ചുകൊണ്ടിരിക്കുന്നു. റിലീസ് ട്രെയിനുകൾക്ക് ആഴ്ചകൾ എടുക്കുന്നു. പ്ലാറ്റ്‌ഫോം എഞ്ചിനീയറിംഗ് ഹെഡ്കൗണ്ട് നിലവിൽ ബജറ്റിൽ ഉൾപ്പെട്ടിട്ടുള്ളതാണ്, അതിനാൽ microfrontend ഇൻഫ്രാസ്ട്രക്ചർ ചേർക്കുന്നത് ഒരു ചെറിയ അധികച്ചെലവ് മാത്രമാണ്, പുതിയൊരു ചിലവല്ല. അവർക്ക്, അലൈൻമെന്റ് മീറ്റിംഗുകൾക്ക് പകരം ഡിപ്ലോയ്മെന്റ് ഗ്രാഫുകൾ ഉപയോഗിക്കുന്നത് യുക്തിസഹമായ കണക്കുകൂട്ടലാണ്.

യഥാർത്ഥ ചോദ്യം നിങ്ങളുടെ ടീമിന് ഏത് ബില്ലാണ് കൂടുതൽ അനുയോജ്യമായി വർദ്ധിച്ചു വരുന്നത് എന്നതാണ്. മനുഷ്യർ തമ്മിലുള്ള ഏകോപനത്തിന്റെ പരിധിയിൽ monoliths നിങ്ങളെ ബാധിക്കുന്നു. പ്ലാറ്റ്‌ഫോം എഞ്ചിനീയറിംഗിന്റെ അടിസ്ഥാനത്തിൽ microfrontends നിങ്ങളെ ബാധിക്കുന്നു.

നിങ്ങളുടെ കറൻസി തിരഞ്ഞെടുക്കുക

നിങ്ങൾ microfrontends തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, നിങ്ങൾ എന്താണ് വാങ്ങുന്നത് എന്നതിനെക്കുറിച്ച് വ്യക്തത ഉണ്ടായിരിക്കണം. നിങ്ങൾ വാങ്ങുന്നത് ടീമിന്റെ സ്വയംഭരണാധികാരവും (autonomy) സ്വതന്ത്രമായ വിന്യാസക്ഷമതയുമാണ് (independent deployability). താഴെ പറയുന്നവയ്ക്കായി തയ്യാറെടുക്കുക:

  • ഫ്രാഗ്‌മെന്റുകൾക്കിടയിലെ composition, routing, error boundaries എന്നിവ കൈകാര്യം ചെയ്യുന്ന ഒരു runtime shell.
  • shared implementation logic-ന് പകരം deduplication strategy-യിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്ന ഒരു shared dependency policy.
  • ഓരോ ഇന്റഗ്രേഷൻ സർഫസിനും വേണ്ടിയുള്ള cross-team contract testing.
  • വിതരണം ചെയ്യപ്പെട്ട ബണ്ടിലുകൾക്കിടയിലുള്ള (distributed bundles) ഒരു ഉപയോക്താവിന്റെ ക്ലിക്ക് തമ്മിൽ ബന്ധിപ്പിക്കാൻ കഴിയുന്ന unified observability.
  • ഒരു പെർഫോമൻസ് ഗവേണൻസ് മോഡൽ, കാരണം ബ്രൗസർ ഡൗൺലോഡ് ചെയ്യുന്ന അവസാന പേലോഡിന് (final payload) ഒരു ടീമിനും പൂർണ്ണ ഉത്തരവാദിത്തമില്ല.

നിങ്ങൾ monolith തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, ബില്ലിനെക്കുറിച്ച് സത്യസന്ധത പുലർത്തുക. സിൻക്രണൈസേഷന് (synchronization) പകരമായി നിങ്ങൾ വാങ്ങുന്നത് ലാളിത്യമാണ്. ഇതിനായി ചിലവ് പ്രതീക്ഷിക്കുക:

  • കോഡ് പങ്കിട്ടുള്ള ഉടമസ്ഥാവകാശവും (shared code ownership) അത് ഏകോപിപ്പിച്ചു നിർത്താൻ ആവശ്യമായ ഗവേണൻസ് രീതികളും.
  • പൈപ്പ്‌ലൈനിലെ ഏറ്റവും സാവധാനത്തിലുള്ള ഇന്റഗ്രേഷൻ ടെസ്റ്റ് നിശ്ചയിക്കുന്ന ഒരു റിലീസ് കഡൻസ് (release cadence).
  • ലൈബ്രറി അപ്‌ഗ്രേഡുകൾ വരുത്തുമ്പോൾ ഉണ്ടാകാൻ സാധ്യതയുള്ള വലിയ പ്രത്യാഘാതങ്ങൾ (wide blast radius).
  • നിങ്ങളുടെ ഏറ്റവും വേഗതയേറിയ എഞ്ചിനീയർമാർ നിങ്ങളുടെ ഏറ്റവും ജാഗ്രതയുള്ളവരുടെ വേഗതയിൽ പ്രവർത്തിക്കേണ്ടി വരുന്ന യാഥാർത്ഥ്യം.

യഥാർത്ഥ പാഠം

വില ഒഴിവാക്കുന്ന ഒരു ആർക്കിടെക്ചറും ഇല്ല. കറൻസി തിരഞ്ഞെടുക്കൽ മാത്രമേയുള്ളൂ. ബുദ്ധിയുള്ള സ്ഥാപനങ്ങൾ സൗജന്യമായ ഓപ്ഷനുകൾ തിരയുന്നത് നിർത്തി, ഏത് ചിലവ് വഹിക്കാൻ തങ്ങൾക്ക് സാധിക്കുമെന്ന് പരിശോധിച്ചു തുടങ്ങുന്നു. മനുഷ്യർ തമ്മിലുള്ള ഏകോപനത്തിലൂടെയാണോ അതോ പ്ലാറ്റ്‌ഫോം ഓവർഹെഡ് (platform overhead) വഴിയാണോ നിങ്ങൾ പണം നൽകാൻ ആഗ്രഹിക്കുന്നത് എന്ന് നിങ്ങൾ തീരുമാനിക്കണം. ഏത് സാഹചര്യത്തിലും ഏകീകരണം (uniformity) എന്നത് ഒരു സബ്‌സ്‌ക്രിപ്ഷൻ പോലെയാണ്. ആരാണ് പണം നൽകുന്നത് എന്നതാണ് ഏക ചോദ്യം.