Monolithic Architecture ဆိုတာဘာလဲ - All-in-One Application

Monolith ဆိုတာဘာလဲ?

Monolithic Architecture ဆိုတာ Application တစ်ခုကို တည်ဆောက်တဲ့အခါ Software ရဲ့ အစိတ်အပိုင်းအားလုံးကို Unit တစ်ခုတည်းအနေနဲ့ ပေါင်းစပ်ထားတာ ဖြစ်ပါတယ်။ E-commerce website တစ်ခုကို မြင်ယောင်ကြည့်ပါ။ Monolith မှာဆိုရင် user management, product catalog, shopping cart, payment processing တို့အတွက် code တွေအားလုံးက codebase တစ်ခုတည်းမှာ အတူတူရှိနေပါတယ်။ သူတို့ကို Application အကြီးကြီးတစ်ခုအနေနဲ့ အတူတူ develop, test, deploy လုပ်ရပါတယ်။

ဥပမာတစ်ခုနဲ့ ရှင်းပြရရင် - ကုန်တိုက်ကြီး (Department Store)

Monolith တစ်ခုက ကုန်တိုက်ကြီးတစ်ခုနဲ့တူတယ်။ ဌာနအားလုံး—အဝတ်အထည်၊ အီလက်ထရောနစ်၊ ကုန်ခြောက်၊ ပရိဘောဂ—အားလုံးက အမိုးတစ်ခုအောက်၊ အဆောက်အအုံတစ်ခုတည်းမှာ ရှိနေတယ်။ ဆိုင်တစ်ခုလုံးက တစ်ချိန်တည်းဖွင့်၊ တစ်ချိန်တည်းပိတ်ပြီး၊ အဖွဲ့အစည်းတစ်ခုတည်းက စီမံခန့်ခွဲတယ်။ အစပိုင်းမှာတော့ ဒါက စီမံခန့်ခွဲရတာ အလွန်ရိုးရှင်းပြီး ထိရောက်ပါတယ်။

အားသာချက်များ (အစပိုင်းမှာ ဘာလို့ကောင်းလဲ)

Monolith နဲ့ စတင်ခြင်းရဲ့ ကောင်းကျိုးတွေကတော့:

Development လုပ်ရတာ ရိုးရှင်းခြင်း: Code အားလုံးက တစ်နေရာတည်းမှာပဲ ရှိတယ်။ Developer တွေက component တွေကြား network ဆက်သွယ်ရေးကို စိတ်ပူစရာမလိုဘဲ Application ရဲ့ မတူညီတဲ့ အစိတ်အပိုင်းတွေကို အလွယ်တကူ ဝင်ရောက်နားလည်ပြီး ပြင်ဆင်နိုင်တယ်။
End-to-End Testing လုပ်ရတာ လွယ်ကူခြင်း: Application တစ်ခုလုံးကို ကိုယ့်စက်ထဲမှာတင် run ပြီး user journey အစအဆုံး (login ကနေ checkout အထိ) ကို အလွယ်တကူ စမ်းသပ်နိုင်တယ်။
Deployment လုပ်ရတာ ရှင်းလင်းခြင်း: Deploy လုပ်ဖို့ Application တစ်ခုပဲရှိတယ်။ ဒါက အစောပိုင်းအဆင့်တွေမှာ release process ကို ရိုးရှင်းစေတယ်။

အားနည်းချက်များ (ကြီးထွားလာတဲ့အခါ ကြုံရတဲ့ ပြဿနာတွေ)

Application က ပိုအောင်မြင်ပြီး ရှုပ်ထွေးလာတာနဲ့အမျှ အားနည်းချက်တွေ စပြီးပေါ်လာပါတယ်။

နားလည်ရခက်ခဲလာခြင်း: Monolith အကြီးကြီးတစ်ခုက “ရှုပ်ထွေးနေတဲ့ ရွှံ့စိုင်ကြီး (Big Ball of Mud)” ဖြစ်လာနိုင်တယ်။ Codebase က အရမ်းကြီးပြီး ရှုပ်ထွေးလာတဲ့အခါ ဘယ် developer မှ အကုန်လုံးကို နားမလည်နိုင်တော့ဘဲ၊ bug တွေကို ပြင်ဖို့ ဒါမှမဟုတ် feature အသစ်တွေ ဘေးကင်းကင်းထည့်ဖို့ ခက်ခဲလာတယ်။
Scaling လုပ်ရတာ စိန်ခေါ်မှုများခြင်း: ကုန်တိုက်ရဲ့ အစိတ်အပိုင်းတစ်ခု (ဥပမာ - အီလက်ထရောနစ်ဌာန) က အရမ်းအလုပ်ရှုပ်လာရင်၊ အဲ့ဒီနေရာလေးတစ်ခုတည်းကို သီးသန့်နေရာချဲ့လို့မရဘူး။ ကုန်တိုက်ကြီးတစ်ခုလုံးကို အသစ်၊ ပိုကြီးအောင် ဆောက်ရသလိုပါပဲ။ အလားတူပဲ၊ feature တစ်ခု (ဥပမာ - product search) က site ကို နှေးစေရင်၊ Application တစ်ခုလုံးကို scale လုပ်ရပြီး၊ ဒါက ထိရောက်မှုမရှိဘဲ စရိတ်လည်းပိုကြီးတယ်။
နည်းပညာတစ်ခုတည်းမှာ ပိတ်မိနေခြင်း (Technology Lock-in): Application တစ်ခုလုံးကို technology stack တစ်ခုတည်း (ဥပမာ - programming language နဲ့ framework တစ်ခု) နဲ့ တည်ဆောက်ထားတယ်။ ကိုယ်က feature အသစ်တစ်ခုအတွက် ပိုခေတ်မီပြီး ပိုကောင်းတဲ့ နည်းပညာတစ်ခုကို သုံးချင်ရင်တောင်၊ အဲ့ဒါကို ပေါင်းစပ်ဖို့ အလွန်ခက်ခဲသွားပြီး ကိုယ့်ရဲ့ မူလရွေးချယ်မှုမှာပဲ ပိတ်မိနေတတ်တယ်။
Deployment တွေ နှေးကွေးလာခြင်း: အရေးမပါတဲ့ feature တစ်ခုက သေးငယ်တဲ့ ပြောင်းလဲမှုတစ်ခုအတွက်တောင်၊ Application အကြီးကြီးတစ်ခုလုံးကို ပြန်ပြီး build, test, deploy လုပ်ဖို့လိုလာတယ်။ ဒီ process က နှေးကွေးပြီး မကြာခဏ update လုပ်ဖို့ အဆင်မပြေတော့ဘူး။
အမှားမခံနိုင်ခြင်း (Low Fault Tolerance): ဌာနတစ်ခုမှာ ပြဿနာတစ်ခုရှိနေရင် (ဥပမာ - ပရိဘောဂကဏ္ဍမှာ ရေစိမ့်နေရင်)၊ ကုန်တိုက်ကြီးတစ်ခုလုံးကို ပိတ်ပစ်ရနိုင်တယ်။ Monolith မှာလည်း အရေးမကြီးတဲ့ feature တစ်ခု (ဥပမာ - PDF report ထုတ်တာ) က bug တစ်ခုက website တစ်ခုလုံးကို crash ဖြစ်သွားစေနိုင်တယ်။