Ulinganifu si lengo unalolifikia. Ni ada ya usajili unayolipa. Kila shirika la uhandisi hugundua hili hatimaye, mara nyingi wakati timu ya pili au ya tatu inapoanza kuweka kodi kwenye repository moja. Iwe unatumia monolith moja ya React au mkusanyiko wa frontends zinazoweza kuwekwa (deploy) kando kando, haufanyi uboreshaji kwa gharama sifuri. Unachofanya ni kuchagua ni ankara ipi itakayotokea kila robo mwaka.

Kodi ya Uratibu ya Monoliths

Katika muundo wa monolithic, ankara huandikwa kwa saa za binadamu. Timu hutumia siku zao kulinganisha kodi inayotumiwa na wote, mitindo (styles), na ratiba za utoaji (release schedules). Mhandisi anayetaka kufanya marekebisho madogo ya malipo (checkout) anaweza kuhitaji kuongeza toleo la utegemezi (dependency) inayotumiwa na timu nyingine sita, kisha asubiri seti kamili ya majaribio ya regression ikamilike. Gharama hii huongezeka kimyakimya. Haionekani kamwe kama kipengele kwenye bili ya wingu (cloud bill). Inajificha katika kupungua kwa kasi ya utendaji, katika wahandisi kubadilisha mazingira ya kazi (context-switching) kati ya mijadala ya Slack kuhusu mtindo wa kodi, na katika msuguano wa polepole wa muundo wa CSS ambao hakuna anayemiliki lakini kila mtu anaugusa.

Timu yako inapokua, kodi hii pia hukua pamoja nayo. Vikwazo vya mapitio ya kodi vinabadilika kutoka masuala ya kiufundi kwenda masuala ya kijamii. Repository moja yenye washiriki mia mbili haikui kwa njia ya mstari; inakua kwa njia ya mchanganyiko (combinatorially). Foleni za kuunganisha (merge queues) hujijaza. Treni za utoaji (release trains) huchukua siku nyingi. Mfumo wa usanifu (design system) unakuwa chombo cha kisiasa kinachohitaji baraza la uongozi kuidhinisha aina mpya ya kitufe. Monolith haipingi mabadiliko kwa nia mbaya. Inapinga mabadiliko kwa sababu kila sehemu inashirikiwa, na kila mabadiliko yanahitaji makubaliano.

Kuchora Mipaka

Microfrontends huhamishia gharama za uratibu kwenye mipaka maalum. Badala ya mkutano wa kila wiki kuhusu usimamizi wa hali inayoshirikiwa (shared state management), unachora mstari. Timu A inamiliki katalogi ya bidhaa. Timu B inamiliki kikapu. Wanakubaliana juu ya mkataba (contract), kwa kawaida ni mpaka wa uelekezaji (routing boundary) au mpangilio mdogo wa matukio (event schema), na kisha wanaacha kuzungumza. Huu ndio mabadiliko ya msingi: uhuru (autonomy) kwa kubadilishana na aina tofauti ya nidhamu.

Nadharia hiyo ni safi. Ikiwa Timu ya Usafirishaji (Shipping) itarekebisha tabaka lake la uelekezaji (routing layer), Timu ya Malipo (Billing) haipaswi kujali. Ikiwa kioleswizi cha utafutaji kinahitaji kuwekwa (deploy) mara tano kwa siku, hakipaswi kusubiri ukurasa wa mipangilio ya akaunti umalize majaribio

Hakuna mfumo ambao ni bure. Kampuni changa ya watu kumi na tano haihitaji timu ya jukwaa (platform team). Gharama za ziada za module federation, mifumo huru ya kupeleka programu (independent deployment pipelines), na contract testing ya kusambazwa (distributed contract testing) zingekula kasi yao nzima ya utendaji. Wanapaswa kulipa kwa uratibu kwa sababu uratibu huo ni rahisi. Wanaweza kukubaliana juu ya mfumo wa usimamizi wa hali (state management pattern) katika mazungumzo ya dakika kumi na kuusambaza (ship) alasiri hiyo hiyo.

Shirika kubwa la watu mia tano lenye vitengo vya biashara kadhaa vinavyofanya kazi katika mizunguko tofauti ya robo mwaka linakabili tatizo la kinyume. "Kodi" ya uratibu imekuwa kubwa sana. Michakato ya kutoa matoleo (release trains) inachukua wiki kadhaa. Idadi ya wafanyakazi wa uhandisi wa jukwaa (platform engineering) tayari ni sehemu ya bajeti, hivyo kuongeza miundombinu ya microfrontend ni gharama ndogo ya ziada, siyo kipengele kipya cha bajeti. Kwao, kubadilisha mikutano ya upatanishi (alignment meetings) kuwa michoro ya kupeleka programu (deployment graphs) ni hesabu ya kimantiki.

Swali halisi ni ni ankara ipi inayoweza kukua vizuri zaidi kwa timu yako. Monoliths hukutoza kodi kwenye ukomo wa uratibu wa kibinadamu. Microfrontends hukutoza kodi kwenye msingi wa uhandisi wa jukwaa (platform engineering).

Kuchagua Sarafu Yako

Ukichagua microfrontends, kuwa wazi kuhusu kile unachonunua. Unanunua uhuru wa timu na uwezo wa kupeleka programu bila kutegemeana (independent deployability). Kuwa tayari kugharamia yafuatayo:

  • Runtime shell inayoshughulikia muundo (composition), uelekezaji (routing), na mipaka ya makosa (error boundaries) kati ya vipande (fragments).
  • Sera ya utegemezi wa pamoja (shared dependency policy) inayolenga mkakati wa kuondoa marudio (deduplication strategy), siyo mantiki ya utekelezaji wa pamoja.
  • Contract testing ya timu mbalimbali kwa kila sehemu ya muunganisho (integration surface).
  • Uangalizi wa pamoja (unified observability) unaoweza kuhusisha bofyo ya mtumiaji katika vifurushi vilivyosambazwa (distributed bundles).
  • Mfumo wa usimamizi wa utendaji (performance governance model), kwa sababu hakuna timu moja inayomiliki mzigo wa mwisho (final payload) ambao kivinjari (browser) unapakua.

Ukichagua monolith, kuwa mkweli kuhusu ankara. Unanunua urahisi kwa kubadilishana na usawazishaji (synchronization). Tarajia kulipia:

  • Umiliki wa pamoja wa kodi na taratibu za usimamizi zinazohitajika ili kuifanya iwe thabiti.
  • Mzunguko wa kutoa matoleo (release cadence) unaoamuliwa na jaribio la muunganisho (integration test) la polepole zaidi katika mfumo (pipeline).
  • Athari pana (wide blast radius) wakati wa kuhuisha maktaba (library upgrades).
  • Ukweli unaojijenga kwamba wahandisi wako wenye kasi zaidi watafanya kazi kwa kasi ya wale walioangalifu zaidi.

Hitimisho Halisi

Hakuna usanifu unaoondoa gharama. Kuna tu uchaguzi wa sarafu. Mashirika yenye akili huacha kutafuta chaguo la bure na kuanza kuchunguza ni gharama gani wanaweza kumudu kubeba. Lazima uamue ikiwa unataka kulipa kwa uratibu wa kibinadamu au kwa gharama za ziada za jukwaa (platform overhead). Ulinganifu (uniformity), katika hali zote mbili, unabaki kuwa kama usajili (subscription). Swali pekee ni nani anatoa malipo.