ယခု ရေးသားထားသော စာစု သည် မူရင်း တွင် အင်္ဂလိပ်ဘာသာဖြင့် ရေးသားထားပြီ ယခု မြန်မာဘာသာ ပြန်ဆို တင်ဆက်ခြင်းဖြစ်ပါသည် ။ မူရင်းကို ကြည့် ရှု လိုပါက ဤတွင် ကြည့်ပါ။

အတွေး

ယခု နောက်ပိုင်း Cloud Service တွေ ဒီဇိုင်းလုပ်ရာမှာ အသုံးပြုတဲ့ နည်းပညာတွေ အလေ့အကျင့် တွေကို သုံးသပ်ရင်း၊ သုံးဆွဲရင်း စဉ်းစားမိတာ လေးပေါ့။ မိုက်ခရို ဆိုပြီး လူပြောများ သော်လည်း သုံးဆွဲရန် ပြောင်းလဲရန် ခက်ခဲတဲ့ Methodology ကိုု သုံးရင်း Security ပိုင်း လျေ့ာသွားတာမျိုး မရှိပဲ Performance ကို မြန်အောင် ဘယ်လိုလုပ်ရမလဲပေါ့။

Product Makerတွေ မန်နေဂျာတွေကတော့ မိုက်ခရို က ခက်တယ် Resource Consuming ဖြစ်တယ် အရမ်း ထိန်းချုပ်ရတာ လက်ဝင်တယ် ထင်ကြမယ်။ ဒါပေမယ့် အဲ့လိုခက်လို့ကို ပဲ ကိုယ့်ဆားဗစ်ကို နှစ်ရှည်လများ သွားမယ်ရည်ရွယ်ထားရင် အစကတည်း ကို က Design မှာ လုပ်သင့် တယ် လို့မြင်တယ်။

အကယ်လို့ကြားထဲက အပိုစာသားတွေရှည် တယ်ထင်ခဲ့ရင် စာစုရဲ့မူရင်း Main Title ဖြစ်တဲ့ Section:4 Baremetal ကိုုကျော်ဖတ်နိုင်ပါတယ်။

MICRO IS GOOD

စစခြင်း တော့ Monolithic Stack တွေဖြစ်တဲ့ ROR တို့ Laravel တို့နဲ့ Logic တွေ API တွေ ရေးလေ့ရှိခဲ့ကြပါတယ်။ Framework တွေက Powerful ဖြစ်သလို Code လည်းသန့်ပြီး Feature တွေပစ်ထည့်ရတာလွယ်ပါတယ်။ Framework Specific Developer တစ်ယောက် နှစ်ယောက် လောက်နဲ့ Service တစ်ခုလုံးကို Implement လုပ်လို့ရပါတယ်။ Micro သွားစရာမရှိဘူးလို့မြင် ကောင်းမြင်ပါလိမ့်မယ်။

အဲသလိုနဲ့ Launch လိုက်ပါလေရော။ လုပ်ထားတဲ့ အိုင်ဒီယာ လေးက ကောင်းတော့ Growth က လိုက်လာတယ်။ ပြီးတော့ Hype ဖြစ်လာပြီးတော့ Features အသစ်တွေ ထည့်သင့် တာ ထည့် ဖြုတ်သင့် တာ ဖြုတ် ( နောက် မှ ဖြုတ်တာ နှမျော တတ်တဲ့ Product Owner တွေ အကြောင်း ပြော ပြမယ် မသုံးရင် အမှိုက်ပဲ ) ။ စပြီ Dev team က Rockstars တွေဆိုတော့ ထားပါ တစ်လ နှစ်လ ခံလိမ့်မယ်။ သုံးလဆို စပြီး အသံထွက်လာမယ်။ Service QOS ညံ့လာမယ် ပြီးရင် သုံးတဲ့လူတွေ ချဉ်လာမယ်( တကယ်ပြောတာ စကားလှစရာ မလိုဘူး)။

Mono လုပ်ထားတော့ Function တစ်ခုတည်းကို ကွက် ပြီး Release ရခက်လာတယ် ။ အသုံးများတဲ့ ကိုယ့်ဆားဗစ်ထဲက Function တွေကို Micro မခွဲထားဘူး။ Git branching တွေ Git tagging တွေနဲ့ ဘယ်လိုပဲ hack တစ်ခုခုကတော့ ဒုက္ခပေးနေလိမ့်မယ်။ အဲ့တော့ စောင့်ရရော။ Monthly or quarterly release cycle တွေဖြစ်ကုန်တယ်။ Product က အတက်မှာ အရှိန်နှေးသွားပြီး User acquisition ကျသွားတယ်။

Stack တစ်ခုလုံး Micro လုပ်စရာမလိုဘူး။ အချို့ main feature တွေ conventions တွေသုံးပြီး Release traffic မရှိအောင် လုပ်လို့ရတယ် သုံးသူ ပျော်အောင်ထားလို့ရမယ်။ ဒါမလို့ နှစ်နှစ်ဆယ် သုံးဆယ်လောက် ကိုယ့် ဝန်ဆောင်မှု ဆက် ပေးထားမယ် မှန်းထားရင် အစကတည်းက Micro သွားသင့်တယ်။ ဒါပေမယ့် နောက်ဆုံးတော့လည်း resources တွေ အချိန်တွေနဲ့ ကိုက်မှ လုပ်တာကောင်းတယ်။ Must ဆိုတာမျိုးတော့ ကျွန်တော်လည်း လက်မခံပါဘူး။

STACKS

Stack ရွေးရတာလည်း ခေါင်း တော့ ခြောက်ရပါတယ်။ လူတိုင်းက Agile ဆိုလို့လည်း လုပ်စရာမလိုပါဘူး။ Linkedin ရဲ့ Teams တော်တော်များများက သူတို့ နဲ့ကိုက်တဲ့ Methodology ကိုု Practice လုပ်ပါတယ်။ Infra လို Team မျိုးမှာ Agile လုပ်လို့ခက်ပါလိမ့်မယ်။

၎င်းလိုပဲဲဲ Programming Launage တွေ Obsess ဖြစ်တာ လျော့ပါ။ Cool ဖြစ်တာ တွေ မဖြစ်တာတွေ က ပိုက်ဆံမပေးပါဘူး။ အသုံးကျပြီး Industry မှာ အများသုံးတယ် နောက်မှာ Community သို့မဟုတ် Google/Facebook/MS တို့လို Company တွေရှိတယ််််််််််််ဆိုတာမျိုး ။ Local မှာ ခန့်ရတာ လွယ်တာ မျိုးကို ရွေးပြီးတော့သာ လုပ်ပါ။ အထွန့်ရှည်ပါလိမ့်မယ်။

Realistic ဖြစ်ပြီး Practical ကျတဲ့ Choice မျိုးရွေးတာမျိုးက ပို ကောင်းပါတယ်။ အခြားလူတွေ ဘာတွေ ဘယ်လိုအောင်မြင်ပြီး ဘယ်လောက် မိုက်နေတယ် ဆိုတာမျိုးတွေ သိပ် မဖတ်ပါနဲ့။ ဂျင်း အော် ဆေး ဖြစ်တတ်ပါတယ်။ ကိုယ့် Team က ဘာ Comfortable ဖြစ်လည်း ပဲ မေး။ ဘယ်ကို ကြည့် ကြည့် ညာကို ကြည့်ကြည့် သူတို့ပဲ ရှိတာ သူတို့ ပဲ ကူ မှာ တခြား အွန်လိုင်းပေါ်က ဂျင်း တွေလာလုပ်ပေးမလား မေးကြည့် ဘယ်သူမှ မလာဘူး စိတ်ချ။

HOW MICRO?

တော်တော်များများက Micro ဆိုတာနဲ့ Monolithic App တစ်ခုတည်းမှာပဲ Modules တွေခွဲပြီး အဲ့ ​Modules အချင်းချင်း စကားပြောတာမျိုး ဖိုဒါခွဲတာမျိုး တွေ ထင်နေကြပါတယ်။ ဒါမှမဟုတ် ထပ် အဆင့်မြင့်သွားရင် တော့ API calls တွေပါ ခွဲပြီး Mono framework instance နှစ်ခု လုပ်ရင် လုပ်ထားမယ် ပြီး ရင် Micro ဆိုအော် တော့တာပဲ။ ဟုတ်တော့ဟုတ်ပါတယ်။

ဒါပေမယ့် Micro ရဲ့ အနှစ်သာရ မဟုတ်သေးပါဘူူူး။ Persistent layers တွေကို သာ Modular/Cluster လုပ်ပါ။ Mono သုံးလို့ရပါသေးတယ်။ Persistent နဲ့ Logic Layer ကြားမှာ Middleware တွေထည့်ထား ပေးပြီး Replicate လုပ်လို့ရအောင် လုပ်ထားလိုက်ပါ။

Runtime ပါတာမျိုးတွေ ကို config တွေ ကောင်းကောင်းထိုင်ပါ။ များသောအားဖြင့် runner တွေ router တွေ တော်တော်များများက runtime heavy ပါ။ အဲ့လို Persistent နဲ့ခွဲထားမှ တခြား တစ်ခု ကို upgrade လုပ်နေရင် အသစ်တစ်ခု run ထားပြီး Down Time 0 ဖြစ်အောင် လုပ်လို့ရမှာ။ လုပ်ဖူးလား အဲ့ဒါမျိုး ?

Instagram တို့ GitHub တို့ အခြား VAS features တွေ Update လုပ်ရင် အဲ့လိုလုပ်တယ်။ Main Feature ဖြစ်တဲ့ git ops တွေ ပုံတင်တာတွေ ရော ဘယ်တော့မှ အကျမခံဘူး။ အစားထိုး run ထားတယ်။ အားလုံး automagic ဆန်အောင် real micro က လုပ်ပေးနိုင်ပါတယ်။

ဒါတင်ပဲလားဆိုတော့ အခုအဲ့ထက်ကြမ်းတာတွေလာပါပြီ Hardware Level မှာ Micro လို့ရပြီ။

BARE METAL

Engineering Talents တွေ နောက်ပိုင်း အရမ်းများ လာတော့ လူတွေက runtime တွေ နောက်ထိသွား စဉ်းစားနေကြပြီ။ OS နောက်ကွယ်မှာ ဘာရှိလည်း ဘယ်လိုုထပ်ပြီးတော့ Optimize လုပ်လို့ရမလဲပေါ့။ VOIP stack တွေ TCP/IP Networking Stack တွေမှာ ဆို သုံးတောင်သုံးနေပြီ Hardware Specific Functions တွေ Voice Packet Propagators တွေ Layer2 translators တွေ အများကြီး။

ဘာလို့ Service တွေက မလုပ်ကြတာလည်း?

ကိုယ့်ကိုကို မေးပြီး ရှာလိုက်တော့ အရင်ကတည်းက သိတဲ့ Nix ကို ပြန်စမ်း ဖြစ်တယ်။ Atomic Upgrades ရတယ်။ OS snapshots မဟုတ်ဘူးနော် ။ ဒါက ပိုကြမ်းတယ်။ Ops သမားတွေ ကြည့်သင့် တယ်။

နောက်တစ်ခု အမိုက်ဆုံးက CLIVE။ ဒီပိုစ့် ရေးတာ ကိုက ဒီ Software ကို မှတ်မိအောင် လို့ရေးတာ။ မေ့သွားမဆိုးလို့။ သူက OS layer မရှိတော့ဘူး။ Software ကို Deps တွေနဲ့ အတူ သူက Compile လုပ်မယ်။ Network ဆို Socket ပါလာမယ် အကယ်လို Web Server လိုမျိုး Run မယ်ဆိုရင်ပေါ့။ Pipe တွေ IO တွေ ရှိသေးတယ်။ ဖိုင်တွေ IO ​တွေ လုပ်လို့ရသေးတယ် ။ ဒါပေမယ့် လုံးဝ OS အဆင့် ရောက် တဲ့ထိ Higher Level Abstractions တွေမပါတော့ဘူး ။ အရမ်းပေါ့ အရမ်း မြန် အဲ့ဒါမျိုး။ Security ကလည်း DSL ဆန်ဆန် လုပ်ရတာ ခေါင်းမစားတော့ဘူး။

Query ခေါ်ရင် channels တွေသွားမယ်။ Web route တွေဆို Network Interface နဲ့ ချိတ်ထားတဲ့ Channel ပေါ့။ Disk IO အတွက် IO Pipe တစ်ခု ရှိမယ်။ ဖိုင်ရေးတာ တစ်ခု ဖတ်တာတစ်ခု ကူးတာ တစ်ခု ဖြတ်တာတစ်ခု ထားလို့တောင်ရသေးတယ် race မှာ ကြောက်ရင်။ စမ်းကြည့် ပါ။

Hardware ပေါ်မှာ Micro Dance လို့ရပါတယ်။ Real World Project ပြီးရင် Update လုပ်ပေးပါဦးမယ်။

original post = https://medium.com/@talnet_/baremetal-service-stack-aka-nos-82facab2dd21

ကျေးဇူးတင်ပါတယ် / တင်အောင်လင်း