એકરૂપતા એ કોઈ લક્ષ્ય નથી જેને તમે પ્રાપ્ત કરો છો. તે એક સબ્સ્ક્રિપ્શન છે જે તમે ચૂકવો છો. દરેક એન્જિનિયરિંગ સંસ્થા આ વાતનો અંતે અનુભવ કરે છે, સામાન્ય રીતે જ્યારે બીજી અથવા ત્રીજી ટીમ એક જ રિપોઝિટરીમાં કમિટ (commit) કરવાનું શરૂ કરે છે ત્યારે. તમે એક સિંગલ React monolith ચલાવો અથવા સ્વતંત્ર રીતે ડિપ્લોય કરી શકાય તેવા frontends નો સમૂહ રાખો, તમે શૂન્ય ખર્ચ માટે ઓપ્ટિમાઇઝ કરી રહ્યા નથી. તમે ફક્ત એ પસંદ કરી રહ્યા છો કે દર ત્રિમાસિક ગાળે કયું ઇન્વોઇસ આવે.

મોનોલિથ્સનો કોઓર્ડિનેશન ટેક્સ

મોનોલિથિક આર્કિટેક્ચરમાં, ઇન્વોઇસ માનવ કલાકોમાં લખાયેલું હોય છે. ટીમો તેમનો દિવસ શેર કરેલા કોડ, સ્ટાઇલ્સ અને રિલીઝ શેડ્યૂલ સાથે સુસંગત થવામાં વિતાવે છે. એક ડેવલપર જે ચેકઆઉટમાં નાનો સુધારો કરવા માંગે છે, તેણે કદાચ અન્ય છ ટીમો દ્વારા ઉપયોગમાં લેવાતા શેર કરેલા ડિપેન્ડન્સી (dependency) ને અપડેટ કરવી પડે, અને પછી સંપૂર્ણ રિગ્રેશન સૂટ (regression suite) ક્લિયર થવાની રાહ જોવી પડે. આ ખર્ચ શાંતિથી વધતો જાય છે. તે ક્લાઉડ બિલમાં ક્યારેય લાઇન આઇટમ તરીકે દેખાતો નથી. તે ઘટેલી વેલોસિટીમાં, કોડ સ્ટાઇલ વિશેના Slack થ્રેડ્સ વચ્ચે એન્જિનિયરો વચ્ચે થતા કોન્ટેક્સ્ટ-સ્વિચિંગમાં, અને એવી CSS આર્કિટેક્ચરના ધીમા ઘર્ષણમાં છુપાયેલો હોય છે જેનું માલિક કોઈ નથી પણ તેને બધા જ સ્પર્શે છે.

જેમ તમારી ટીમ વધે છે, તેમ આ ટેક્સ પણ વધે છે. કોડ રિવ્યુના અવરોધો ટેકનિકલ ચિંતાઓમાંથી સામાજિક ચિંતાઓ તરફ વળે છે. બસો કન્ટ્રીબ્યુટર્સ ધરાવતી એક સિંગલ રિપોઝિટરી લિનિયરલી સ્કેલ થતી નથી; તે કોમ્બિનેટોરિયલી (combinatorially) સ્કેલ થાય છે. મર્જ ક્યુ (Merge queues) લાંબા થાય છે. રિલીઝ ટ્રેન દિવસો સુધી ચાલે છે. ડિઝાઇન સિસ્ટમ એક રાજકીય સંસ્થા બની જાય છે જેને નવા બટન વેરિઅન્ટને મંજૂરી આપવા માટે ગવર્નિંગ કાઉન્સિલની જરૂર પડે છે. મોનોલિથ દ્વેષના કારણે ફેરફારનો વિરોધ કરતો નથી. તે ફેરફારનો વિરોધ એટલા માટે કરે છે કારણ કે દરેક સપાટી શેર કરેલી છે, અને દરેક ફેરફાર માટે સર્વસંમતિની જરૂર પડે છે.

સીમાઓ નક્કી કરવી

Microfrontends સંકલન ખર્ચને ચોક્કસ સીમાઓમાં ખસેડે છે. શેર કરેલા સ્ટેટ મેનેજમેન્ટ વિશે સાપ્તાહિક મીટિંગ કરવાને બદલે, તમે એક રેખા દોરો છો. ટીમ A પ્રોડક્ટ કેટલોગની માલિક છે. ટીમ B કાર્ટની માલિક છે. તેઓ એક કોન્ટ્રાક્ટ પર સહમત થાય છે, જે સામાન્ય રીતે રાઉટિંગ બાઉન્ડ્રી અથવા સાંકડો ઇવેન્ટ સ્કીમા હોય છે, અને પછી તેઓ વાત કરવાનું બંધ કરી દે છે. આ મુખ્ય વ્યવહાર છે: અલગ પ્રકારના શિસ્તના બદલામાં સ્વાયત્તતા (autonomy).

આ સિદ્ધાંત સ્પષ્ટ છે. જો શિપિંગ ટીમ તેના રાઉટિંગ લેયરને રિફેક્ટર કરે, તો બિલિંગ ટીમને તેની ચિંતા હોવી જોઈએ નહીં. જો સર્ચ ઇન્ટરફેસે દિવસમાં પાંચ વાર ડિપ્લોય કરવાની જરૂર હોય, તો તેણે એકાઉન્ટ સેટિંગ્સ પેજ તેના એન્ડ-ટુ-એન્ડ ટેસ્ટ પૂર્ણ કરે તેની રાહ જોવી જોઈએ નહીં. સીમાઓ સંસ્થાકીય ઘર્ષણને ટેકનિકલ ઇન્ટરફેસમાં ફેરવે છે. પરંતુ તે રેખા દોરવી ક્યારેય મફત હોતી નથી.

ઇન્ફ્રાસ્ટ્રક્ચર બિલ

Microfrontends પ્લેટફોર્મ ખર્ચ ઊભા કરે છે. તમારે રનટાઇમ પર ફ્રેગમેન્ટ્સને જોડવા માટે સક્ષમ શેલ એપ્લિકેશનની જરૂર છે. તમારે એવા ડિપ્લોયમેન્ટ પાઇપલાઇનની જરૂર છે જે સમજી શકે કે મલ્ટીપલ બિલ્ડ જોબ્સમાંથી આર્ટિફેક્ટ્સને એક સિંગલ સુસંગત પેજમાં કેવી રીતે જોડવા. જો તમે Webpack Module Federation નો ઉપયોગ કરી રહ્યા હોવ, તો તમે હવે સ્વતંત્ર રીતે બિલ્ડ થયેલા બંડલ્સમાં શેર કરેલા ડિપેન્ડન્સી વર્ઝનને મેનેજ કરી રહ્યા છો. જો તમે iframes નો ઉપયોગ કરી રહ્યા હોવ, તો તમે cross-origin મેસેજિંગનું ડીબગિંગ કરી રહ્યા છો અને લેઆઉટ શિફ્ટ સામે લડી રહ્યા છો. જો તમે web components નો ઉપયોગ કરી રહ્યા હોવ, તો તમે ડિસ્ટ્રિબ્યુટેડ ગ્રાફમાં કસ્ટમ એલિમેન્ટ્સનું વર્ઝનિંગ કરી રહ્યા છો જ્યાં એક ટીમનું અપગ્રેડ બીજી ટીમ પર અસર કરી શકે છે.

આ ખર્ચો નક્કર અને વારંવાર થતા હોય છે. તમે બિલ્ડ ઓર્કેસ્ટ્રેશન માટે ચૂકવો છો જે સાતમી ફ્રન્ટએન્ડને તોડ્યા વગર છ ફ્રન્ટએન્ડ્સને રિલીઝ કરી શકે. તમે ઓબ્ઝર્વેબિલિટી (observability) માટે ચૂકવો છો જે ત્રણ અલગ-અલગ ટીમોની માલિકી ધરાવતા ત્રણ અલગ-અલગ JavaScript બંડલ્સમાં યુઝર એક્શનને ટ્રેસ કરે છે. તમે પરફોર્મન્સ ગવર્નન્સ માટે ચૂકવો છો કારણ કે જો છ ટીમો તેમની પોતાની યુટિલિટી લાઇબ્રેરીઓની નકલો બંડલ કરશે, તો જ્યાં સુધી કોઈ ડુપ્લિકેશન ઘટાડવાની વ્યૂહરચના (deduplication strategy) ન બનાવે ત્યાં સુધી તે તમારા પેજને ભારે અને ધીમું બનાવી દેશે. તે સમયે, તમે મોનોલિથનો એ ભાગ ફરીથી બનાવી દીધો છે જેનાથી તમે બચવાનો પ્રયાસ કરી રહ્યા હતા, સિવાય કે હવે તેને જાળવવા માટે પ્લેટફોર્મ ટીમની જરૂર પડે છે.

જ્યારે ખર્ચ બદલાય છે

ચાર ફ્રન્ટએન્ડ ટીમો ધરાવતી એક મધ્યમ કદની SaaS કંપનીનો વિચાર કરો જે એક સિંગલ Next.js એપ્લિકેશન શેર કરે છે. ત્રણ કલાકના CI રન પછી દિવસમાં બે વાર ડિપ્લોય થાય છે. જ્યારે શિપિંગ ટીમ નેવિગેશનને રિફેક્ટર કરવા માંગે છે, ત્યારે તેઓ કોમેન્ટ્સ માટે વિનંતી કરે છે, ટ્રીમાં ઇમ્પોર્ટ પાથ અપડેટ કરે છે, અને બિલિંગ ટીમને તેના ઇન્ટિગ્રેશન ટેસ્ટ એડજસ્ટ કરવા માટે બે અઠવાડિયા રાહ જુએ છે. ખર્ચ એ સંકલન (coordination) છે, સાવ સરળ.

તેઓ માઇક્રોફ્રન્ટએન્ડ્સમાં વિભાજિત થાય છે. દરેક ટીમ હવે એક વર્ટિકલની માલિક છે અને પોતાના શેડ્યૂલ મુજબ પ્રોડક્શનમાં પુશ કરે છે. પહેલો મહિનો આઝાદી જેવો લાગે છે. પછી એક બગ (bug) દેખાય છે. ગ્લોબલ હેડર Safari માં રેન્ડર થવામાં નિષ્ફળ જાય છે કારણ કે શિપિંગ ટીમે CSS-in-JS લાઇબ્રેરી અપગ્રેડ કરી છે જે સર્ચ ટીમ દ્વારા ઇન્જેક્ટ કરેલી બેઝ સ્ટાઇલ્સ સાથે સંઘર્ષ કરે છે. ડીબગિંગ માટે ત્રણ ઓન-કોલ એન્જિનિયરો, એક શેર કરેલ વોર રૂમ અને બે સર્વિસના પીડાદાયક રોલબેકની જરૂર પડે છે કારણ કે શેલ એપ મોડ્યુલ મેનિફેસ્ટને કેશ (cache) કરે છે. ખર્ચ બદલાયો છે. તે અદૃશ્ય થયો નથી.

સ્કેલિંગ અરીથમટિક

બંનેમાંથી એક પણ મોડેલ મફત નથી. પંદર લોકોની સ્ટાર્ટઅપને પ્લેટફોર્મ ટીમની જરૂર નથી. મોડ્યુલ ફેડરેશન, સ્વતંત્ર ડિપ્લોયમેન્ટ પાઇપલાઇન્સ અને ડિસ્ટ્રિબ્યુટેડ કોન્ટ્રાક્ટ ટેસ્ટિંગનો વધારાનો બોજ (overhead) તેમની સમગ્ર ઝડપ (velocity) ઘટાડી દેશે. તેમણે સંકલન (coordination) દ્વારા ચૂકવણી કરવી જોઈએ કારણ કે સંકલન સસ્તું છે. તેઓ દસ મિનિટની વાતચીતમાં સ્ટેટ મેનેજમેન્ટ પેટર્ન પર સહમત થઈ શકે છે અને તે જ બપોરે તેને શિપ કરી શકે છે.

અલગ-અલગ ત્રિમાસિક ચક્રમાં કામ કરતા ડઝનબંધ બિઝનેસ યુનિટ્સ ધરાવતી પાંચસો લોકોની એન્ટરપ્રાઇઝ વિરોધી સમસ્યાનો સામનો કરે છે. સંકલનનો ટેક્સ (coordination tax) ઘણો વધી ગયો છે. રિલીઝ ટ્રેઇન્સમાં અઠવાડિયાઓ લાગે છે. પ્લેટફોર્મ એન્જિનિયરિંગ હેડકાઉન્ટ પહેલેથી જ બજેટની વાસ્તવિકતા છે, તેથી માઇક્રોફ્રન્ટએન્ડ ઇન્ફ્રાસ્ટ્રક્ચર ઉમેરવું એ એક સીમિત ખર્ચ છે, ન કે નવો ખર્ચનામું. તેમના માટે, એલાઈનમેન્ટ મીટિંગ્સના બદલે ડિપ્લોયમેન્ટ ગ્રાફ્સ અપનાવવું એ તર્કસંગત ગણિત છે.

સાચો પ્રશ્ન એ છે કે તમારી ટીમ માટે કયું બિલ વધુ સારી રીતે સ્કેલ થાય છે. મોનોલિથ્સ તમને માનવ સંકલનની સીમા પર ટેક્સ કરે છે. માઇક્રોફ્રન્ટએન્ડ્સ તમને પ્લેટફોર્મ એન્જિનિયરિંગના પાયા પર ટેક્સ કરે છે.

તમારી ચલણ પસંદ કરો

જો તમે માઇક્રોફ્રન્ટએન્ડ્સ પસંદ કરો છો, તો તમે શું ખરીદી રહ્યા છો તે વિશે સ્પષ્ટ રહો. તમે ટીમની સ્વાયત્તતા અને સ્વતંત્ર ડિપ્લોયબિલિટી ખરીદી રહ્યા છો. નીચેની બાબતો માટે ભંડોળ આપવા તૈયાર રહો:

  • એક રનટાઇમ શેલ જે ફ્રેગમેન્ટ્સ વચ્ચેનું કમ્પોઝિશન, રાઉટિંગ અને એરર બાઉન્ડ્રીઝ સંભાળે છે.
  • ડુપ્લીકેશન ઘટાડવાની વ્યૂહરચના પર ધ્યાન કેન્દ્રિત કરતી શેર કરેલી ડિપેન્ડન્સી પોલિસી, નહીં કે શેર કરેલી ઇમ્પ્લીમેન્ટેશન લોજિક.
  • દરેક ઇન્ટિગ્રેશન સપાટી માટે ક્રોસ-ટીમ કોન્ટ્રાક્ટ ટેસ્ટિંગ.
  • યુનિફાઇડ ઓબ્ઝર્વેબિલિટી જે ડિસ્ટ્રિબ્યુટેડ બંડલ્સમાં યુઝરના ક્લિકને સંબંધિત કરી શકે છે.
  • પર્ફોર્મન્સ ગવર્નન્સ મોડેલ, કારણ કે બ્રાઉઝર જે ફાઇનલ પેલોડ ડાઉનલોડ કરે છે તેનો માલિક કોઈ એક ટીમ નથી.

જો તમે મોનોલિથ પસંદ કરો છો, તો ઇનવોઇસ વિશે પ્રમાણિક રહો. તમે સિંક્રનાઇઝેશનના બદલામાં સરળતા ખરીદી રહ્યા છો. આ માટે ચૂકવણી કરવાની અપેક્ષા રાખો:

  • શેર કરેલી કોડ માલિકી અને તેને સુસંગત રાખવા માટે જરૂરી ગવર્નન્સ રિચ્યુઅલ્સ.
  • પાઇપલાઇનમાં સૌથી ધીમા ઇન્ટિગ્રેશન ટેસ્ટ દ્વારા નક્કી કરવામાં આવેલ રિલીઝ કેડન્સ.
  • લાઇબ્રેરી અપગ્રેડ પર વ્યાપક અસર (wide blast radius).
  • એ વાસ્તવિકતા કે તમારા સૌથી ઝડપી એન્જિનિયરો તમારા સૌથી સાવધ એન્જિનિયરોની ગતિએ કામ કરશે.

મુખ્ય નિષ્કર્ષ

એવું કોઈ આર્કિટેક્ચર નથી જે કિંમત દૂર કરે. ત્યાં માત્ર ચલણની પસંદગી છે. સમજદાર સંસ્થાઓ મફત વિકલ્પ શોધવાનું બંધ કરે છે અને તેઓ ખરેખર કયો ખર્ચ ઉઠાવી શકે છે તેનું ઓડિટ કરવાનું શરૂ કરે છે. તમારે નક્કી કરવું પડશે કે તમે માનવ સંકલનમાં ચૂકવણી કરવા માંગો છો કે પ્લેટફોર્મ ઓવરહેડમાં. બંને કિસ્સામાં, એકરૂપતા એ સબ્સ્ક્રિપ્શન સમાન જ રહે છે. એકમાત્ર પ્રશ્ન એ છે કે ચુકવણી કોણ કરે છે.