မိတ်ဆက်

စာတစ်စောင်လုံး ဖတ်ပြီးတော့ အချိန် မကုန်ရလေအောင် စာတိုလေးနဲ့ နှုတ်ဆက်လိုက်ပါတယ်။ ကျွန်တော် ကတော့ တင်အောင်လင်းပါ။ သတင်း အချက်အလက် ထုတ်ကုန်တွေကို တည်ဆောက်တဲ့ နည်းပညာသမား တစ်ယောက်ဖြစ်ပါတယ်။ ယခုသုံးသပ်တင်ပြထားတဲ့ စာစုလေးဟာ နည်းပညာ ပိုင်း (Technical) ပိိုဆန်တဲ့ အတွက် IT သမား တွေ ၊ ကွန်ပျူတာ နည်းပညာကို Academic လေ့လာလိုက်စား နေတဲ့ ကျောင်းသား ကျောင်းသူ တွေ ၊ နည်းပညာ ဆိုင်ရာ ဝန်ဆောင်မှုု ပေးနေသော Business သမားတွေ အတွက် အထောက်် အကူူဖြစ်််​စေမှာပါ။

ရာဇဝင်အကျဉ်း

တကိုယ်ရည်သုံး ကွန်ပျူတာတွေ ပေါ်ထွက်လာတာဟာ 2019 မှာ နှစ်လေးဆယ်ကျော် လာပြီဖြစ်ပါတယ်။ အင်တာနက်လို (Global Computer Network) တွေကို သုံးစွဲသူ များပြားလာတဲ့အတွက် နည်းပညာရဲ့ အရေးပါမှုဟာ အင်မတန််ကြီးထွား လာခဲ့ပြီး အသစ်အသစ်သော နည်းပညာများ နှင့် နည်းပညာရှင်များ ပေါ်ထွန်းလာကာ အခု ဆိုရင် Cloud Computing Era လို့ ခေါ်ဆိုလို့ရအောင် အရာရာဟာ တိမ်တွေထဲမှာ ချိတ်ဆက် တွက်ချက်နေသလို မြန်ဆန် လာခဲ့ပြီဖြစ်ပါတယ်။

ကွန်ပျူတာ တွေဟာ လုပ်ဆောင်ချက်​ (Functions) မြောက်မြားစွာကို တစ်ပြိုင်တည်းမှာ (Concurrent) လျင်လျင်မြန်မြန် လုပ်ဆောင်နိုင်တဲ့ အတွက် သတင်းအချက်အလက်တွေ သယ်ယူ ပို့ဆောင် Transport သိမ်းဆည်းရာ တွင် အလွန်သက်သာလွယ်ကူ (Efficient) စေပါတယ်။ ၂၀၁၂ နောက်ပိိုင်း နောက်ပိုင်း ကွန်ပျူတာ Chips တွေ ဟာ Form ပုံစံ သေးငယ်လာပြီး စွမ်းဆောင်ရည် ကြီးမားလာကာ စွမ်းအင်သုံးဆွဲမှု အရမ်းသက်သာ လာတာ ကြောင့် Cloud Computing ရဲ့ အစ ဖြစ်တဲ့ Data Center တွေကို Private/Public အဖွဲ့အစည်းတွေ ဟာ အများအပြား တည်ဆောက်လာကြပါတယ်။ 

နောက်ပိုင်း Business Support Software (BSS) လုပ်ငန်းသုံး ဆော့ဝဲတွေ ကို ကွန်ပျူတာ ထဲတွင် သုံးဆွဲယုံတင်မက လုပ်ငန်းတွင်း သို့မဟုတ် လုပ်ငန်းခွဲများ ဆိုင်ခွဲများ ကြား တွင် ချိတ်ဆက် သုံးဆွဲ လာ​ရာ ၎င်းဆော့ဝဲ တွေကို တပ်ဆင်သုံးဆွဲရန် Computing Units ဆော့ဝဲ လုပ်ဆောင်မှုဝန်ဆောင် ပေးသော ကွန်ပျူတာ တွေရဲ့ လိုအပ်ချက် များပြားလာပါတယ်။ ထိုကဲ့သို့ ကွန်ပျူတာဆာဗာ Servers တွေကို ဝန်ဆောင်မှု ပေးသူတွေကို ကနဦး ခေတ်မှာ Hosting Providers တွေလို့ခေါ်ခဲ့ကြပါတယ်။

Providers ( for example, Media Temple, HostGator) တွေက သုံးဆွဲသူတွေ အတွက် များသော အားဖြင့် Static Informations (Web pages and directories) တွေကိုသိမ်းထားပေးပြီး နောက်မှာ Databases တွေနဲ့ ချိတ်ပေးတာပါပဲ။  Providers တွေအနေနဲ့ Public IP Addresses တွေကို Customers တွေငှားရမ်း ထားတဲ့ Servers နဲ့ ချိတ်ဆက်ပေးပြီး စွမ်းအင်နှင့် ကွန်ယက်ချိတ်ဆက်မှု ကို 24/7  ပေးထားခြင်းဖြင့် ဝန်ဆောင်မှုပေးပါတယ်။ သင့် Organization သို့မဟုတ် သင့် လုပ်ငန်းသုံး အချက်အလက် တွေကို ၎င်း Providers တွေမှာ တင်ထားခြင်းအားဖြင့် Public IP သို့မဟုတ် Private Tunnels တွေနဲ့ ချိတ်ဆက်သုံးဆွဲနိုင်မှာဖြစ်ပါတယ်။

သုံးသပ်ချက် အမြင်

BSS တွေ အရမ်း တွင်ကျယ် လာတာနဲ့ အမျှ SME တွေကစလို့ Banks တွေ Large Corporations တွေဟာ Cloud ( Private or Public ) Data Centers တွေ ဝန်ဆောင်မှု တွေကို မှီခိုလာရပါတယ်။ ဆော့ဝဲဲဲ ရေးသား သူတွေ ဝန်ဆောင်မှု ပေးသူတွေကို သုံးဆွဲသူတွေက ယနေ့ ခေတ်မှာ​ Cloud ချိတ်ဆက်သုံးဆွဲ ဖို့ တောင်းဆိုလာ ကြတာ မဆန်းပါဘူး။ အဓိကက ဝန်ဆောင်မှုပေးသူ တွေ နည်းပညာ ရှင်တွေက Ready ဖြစ်ပြီလား?

ယခုနှစ် ၂၀၁၇ ကနေ ၂၀၁၈ အထိ ပြည်တွင်း ဆော့ဝဲ ရေးသားသူတွေဟာ Cloud ကိုု Value Added Service (VAS) အနေနဲ့ စတင်ထည့်သွင်း ဝန်ဆောင်လာတာကို တော့တွေ့ရပါတယ်။ ဒါပေမယ့် Core Feature သို့မဟုတ် အားသာချက် အနေနဲ့ ထဲထဲဝင်ဝင် သုံးလာတာ တော့ မတွေ့ရသေးပါဘူး။ ငွေစစ်လို့တော့ရမယ် ငွေဖြည့် ငွေထုတ်တော့ လုပ်လို့မရသေးတာမျိုး။ Mobile Banking ဆိုပြီး ဘာမှသုံးစားမရတာမျိုး။ အခုတော့ တော်တော်လေး ကောင်းလာပါပြီ။ SAP လိို MS office 365 လို Trust နဲ့ Liability မြင့်တဲ့ ဆော့ဝဲ ဝန်ဆောင်ပေးသူတွေ ဝင်ရောက်လာတော့ ပြည်တွင်း လုပ်ငန်းရှင်တွေလည်း အနည်းနဲ့ အများ ယှဉ် ပြိုင်ဖို့ ကြိုးစားလာတာကို တွေ့ရတယ် ဒါပေမယ့် အားမရသေးပါဘူး။  Infrastructure နဲ့ User က အဆင်သင့်ပါ။ အင်တာနက် တွေ စျေးပေါ်လာပြီး Service Availability လဲမြင့်မားလာတာ တွေ့ရတယ်။ သိသိသာသာကို မြင့်မားလာတယ် ဒါပေမယ့် တစ်ချို့ နာမည်ကြီး Service တွေ ဘာလို့ ကျကျ နေတာလဲ ဆိုတာတော့ စဉ်းစားစရာပဲ။ Public DC တွေဖြစ်တဲ့ True DC, Huawei Cloud, Azure နဲ့ AWS လို Local Player တွေ Global Player တွေဝင်ရောက်လာ တာကိုလည်း အားရစရာ တွေ့ရပါတယ်။

ဒါပေမယ့် ဘာ့ကြောင့် Cloud ပေါ်တက်ရတာ ခက်နေပါသနည်း။ များသောအားဖြင့် မြန်မာပြည်မှာဖြစ်နေကြ နည်းပညာ အခက်အခဲ Infrastructure အခက်အခဲတော့ မဟုတ်တော့ပါဘူး။ အားလုံးဟာ Public Knowledge ပါ။ AWS လို Global Provider ကအခုဆိုရင် Certificate တွေပေး ပြီးတော့ Knowledge ကို အလကား သွားပြီး သူတို့ Documentation Website မှာသွားလေ့လာလို့ရပါတယ်။ အဓိကကတော့ နည်းပညာသမား Experts နဲ့ Architects တွေရှားတာပါ။ လွန်ခဲ့တဲ့ သုံးနှစ် လေးနှစ်က မိုဘိုင်း App လေးရေး API server လေး Run တာနဲ့ တော့မရတော့ပါဘူး။

ကျွန်တော့ အမြင်တော့ Cloud Architects တွေ Experts တွေ ပေါ်လာရမယ် ပြီးတော့ ကောင်းလာရမယ်။ နဂိုရှိပြီးသား နည်းပညာသမားတွေလည်း Cloud Oriented Architect တွေ ကို Aciquistions လုပ်လာရမယ်။ ကိုယ့်ရဲ့ဆောဝဲလ် စတည်ဆောက်ကတည်းက Network Application တစ်ခု ဆောက်သလို Defensive Procedures တွေနဲ့ Data Objects တွေကို Persistent/Non-Persistent State တွေသုံးပြီးတော့ တည်ဆောက်ရမယ်။ အရင်လို အကုန်လုံး SQL ထဲပစ်ထည့်လို့မရတော့ပါဘူး။ ဆိုတော့ အားလုံး Awareness လေးနဲနဲပိုလာမယ်။ ကိုယ်တည်ဆောက်တဲ့ Software ဝန်ဆောင်မှု တိမ်ပေါ်ရောက်မယ် မကောင်းဘူးလား? Customers တွေ Users တွေယုံကြည်ရတဲ့ High Availability ဝန်ဆောင်မှုတွေ ထည့် မပေးချင်ဘူးလား? Ok, Industry-Wide ဘယ်လို ချဉ်းကပ် ကြမလည်းဆိုတာ ကျွန်တော့်် အမြင်နဲ့ ဆွေးနွေးကြည့် ချင်တယ်။

အ​ခြေခံ နည်းပညာ

Cloud လို့ပြောလိုက်ရင် Networks အကြောင်းနည်းနည်းပါမယ်။ Virtual Private Cloud  (VPC) ဆိုတဲ့ Term ကိုသဘောကျတယ်။ အရာရာကို Hardcore Network Topology လုပ်ကြည့် စရာ မလိုပဲ Logical Connections တွေနဲ့ Service တွေတည်ဆောက်လို့ရတယ် ။ ဒါပေမယ့် Basic DNS နဲ့ Subnetting ကို တော့နားလည်စေချင်တယ်။

ဆော့ဝဲ သမား Dev တော်တော်များများကလည်းခက်တယ်။ OOP တို့ TDD တို့သာ အချိန်ပေး လေ့လာရင် လေ့လာမယ်  Network ကိုတော့ အရေးမလုပ်ချင် ကြဘူး။ ရပါတယ် အကယ်လို့ ကိုယ့် Team မှာ Ops တစ်ယောက်ပါရင် ဒါကို သူ လေ့လာပါလိမ့်မယ်။ ဒါပေမယ် ကိုယ်က တော့ Awareness လေးနဲနဲရှိစေချင်တယ်။  အဲ့လိုသာ ရှိလိုက်မယ် ဆိုရင် REST လိုဟာ မျိုးကို သုံးနေရာကနေ RPC(GRPC) လို ProtoBuf လိုဟာမျိုးတွေကို လေ့လာချင်လာမယ်  သုံးချင်လာမယ်။  Defensive Programming ကို Over-does တော့မဟုတ်ဘူး နဲနဲတော့လုပ်စေချင်တယ်။ ဘာ ကိုဆိုလိုလဲသိချင်ရင် ဒီ Article လေးဖတ်ကြည့်ပါ။ RPC လို tech ကို acquisition လုပ်ချင်ရင် Google က Team တွေဘယ်လိုလုပ်လဲ လေ့လာလို့ရတယ်။ အရမ်း ကို တော်တယ်လို့ကိုယ့်ကိုကိုထင်ရင်  Cosmos လို BlockChain က Client App တွေ Tindermint နဲ့ ဘယ်လိုစကားပြောလည်း ကြည့်ကြည့် လို့ရတယ်။ Anyway ကိုယ့် Dev life-cycle ထဲမှာ အသိလေး ဝင်သွားရင် Pro-actively လုပ်လာပါလိမ့်မယ်။ နောင်ကျရင် ဒီ Skilllsတွေဟာ REST လိုမျိုး ​JD ထဲပါလာတော့မှာပါ။ သိပ်မကြာပါဘူး အလွန်ဆုံး သုံးလေးနှစ်ပေါ့။

Ops တွေအနေ နဲ့ကလည်း အရင် ကလို Xen တို့ ESXi တို့ ကို ကောင်းကောင်းကိုင်တွယ် နေရာကနေ Containers တွေ Storage Services တွေ နည်းပညာ တွေ လေ့လာသင့်တယ်။ Inframagic လို့ ခေါ်လို့ရအောင် Self-healing Infra တွေ မဆောက်ချင်ဘူးလား။ Kubernetes ဆိုတာ နတ်မင်းကြီးမဟုတ်ပါဘူး။ အခြေခံ Containerization ကနေ စစ လေ့လာမယ် ဆိုရင် တစ်ဖြည်းဖြည်းချင်း acquisition လုပ်လို့ရပါတယ်။ ပြီးတော့ ကိုယ့် Team ကို On-board ပါလာအောင် လုပ်ဖို့ဆိုရင် ကိုယ်တိုင် ကူညီပြီး Dev တွေကို Setup လုပ်ပေးပါ။ ပြီးရင် Team lead ကို Benefits တွေပြော ပေးပါ။ ဒါက Ideal Infra ပါ။ ကိုယ့်နည်းကိုယ့် ဟန် နဲ့ Retro သွားမယ် ဆိုလည်း သွားလို့ရပါတယ်။  Anything that works ပါ။  ဒါပေမယ့် Scale-out သို့မဟုတ် Scale-up Strategy တော့ ရှိသင့်ပါတယ်။ Redentency ကိုအနည်းဆုံးတော့ Proxy Server တွေ မှာထားပါ။ DNS round-robin တွေလည်းသုံးလို့ရတယ်။ ဒါပေမယ့် server တစ်ခု ဒေါင်းလို့ အကုန် ရပ်လိုက်ရတယ်ဆိုတာတော့ သိပ်မမိုက်ဘူး။ ဘယ် Provider ပဲသုံးသုံး​ ကိုယ့်ဟာကိုယ်ပဲ host host အနည်းဆုံး Planning လေးတော့ လုပ်ပါ။  စာအုပ်ထဲ ဟိုခြစ် ဒီခြစ် လဲရပါတယ်။ ကိုယ်နားလည်ပြီးရော။  အဲ Team Lead က Plan ပေးပါဆိုရင်တော့ ကောင်းကောင်းမွန်မွန်လုပ်ပေးလိုက်ပါ။ Alien လက်ရေးတွေနဲ့ တော့မလုပ်နဲ့ပေါ့။ 

ဝန်ဆောင်မှု ပေးသူတွေ ရောင်းသူ တွေအနေနဲ့ကလည်း​ QoS(Quality of Service) ကို အနည်းနဲ့အများသိသင့်တယ်။ Technical Term နဲ့ မဟုတ်ရင်တောင် Layman Term နဲ့ ကိုယ့်ဝန်ဆောင်မှုကို Promote ဘယ်လိုလုပ်သင့်သလဲဆိုတာ အမြဲတွေးနေရမယ်။ ဒါမှ ကိုယ့် Team က ထည့်ပေး လိုက်တဲ့ Value ကို ကိုယ့် Customer က Appreciate ဖြစ်မှာ ဖြစ်ပါတယ်။ Customer Appreciation means more sales? ဥပမာ ဆိုရင် ဆိုင်ရှင် တစ်ယောက်က ဆိုပါတော့ Daily Sale ကို အခု ချုပ်မယ်ဆို Manual ချုပ်ရမယ်။ အရောင်း ပိတ်အောင် စောင့်ရမယ်။ Team က App တစ်ခု ပေးလိုက်တယ် ကြိုက်တဲ့ အချိန် ကြိုက်တဲ့ နေရာ က Sale Audit လို့ရမယ်။ ချုပ်လို့ရမယ်။ ဒါမျိုး ကို Cloud ပေါ်တင်လိုက်မှ ချုပ်လို့ရတယ်။ အချက်အလက်က မှန်မယ် ဆိုတာ မျိုး။ Value Added ဖြစ်မဖြစ် မေးခွန်းထက် Smart ဖြစ်မဖြစ် အရင်ပြော။ အရမ်း Critical ကျတာမျိုး ဆေးရုံလို စားသောက်ဆိုင်လို နေရာမျိုးတွေမှာ Value Added မဟုတ်တော့ဘူး Feature ဖြစ်သွားတာမျိုး။ ဒါကိို ပိုတွေး ပိုရေး ပိုပြောစေချင်တယ်။ ဒါမှ နောက်က လုပ်ပေးရတဲ့ Team ကလဲ IT(ငအ) တွေမဖြစ်မှာ။

ချဉ်းကပ်ပုုံ

အရမ်း Technical မဆန် လို့ စိတ်ပျက်သွားမယ််််််််ထင်တယ်။ ရေးတုန်းကတော့ မိုးလောက်ကြီးတွေ ရေးမလို့ပါပဲ။ ဒါပေမယ့် ရေးရင်းနဲ့ ပုုုုတ် လောက်ပဲ ဖြစ်သွားတယ်။ ချဉ်းကပ်ကျတော့မယ် ဆိုတော့ အားလုံးပစ်ချ ပြီး Cloud ဟဲ့ဆိုတာမျိုး မဖြစ်စေချင်လို့ Approach ကိုသုံးသပ်ချင်တာ။

Dev တွေအတွက် အဓိကကတော့ Business Logic တွေဘယ်မှာ ထားမလည်း ဆိုပြီး တိုင်ပတ်တာပဲ။ ဆာဗာ ပေါ်ထား လိုက်ရင် Software က​ အင်တာနက်မရှိရင် သုံးမရတော့တာမျိုး။ အကောင်းဆုံးနဲ့ ခက်တဲ့ နည်းလမ်းကတော့ နှစ်ခြမ်း ခွဲလိုက်ပါ။ Instant Feedback ပြန်ပေးရမယ့် Logic တွေကို Software မှာ ပဲ Local လုပ်ပါ။  Actors တွေကို ဖြစ်နိုင်သမျှ မစောင့်ရ အောင် Localized လုပ်ပါ။ မတက် သာတဲ့အဆုံး Cache ပါ။ Sync ပါ။  Caching ကခက်ပါတယ် Computing ရဲ့ One of the Holy Grails ပဲ။ ဆိုတော့ အနည်းဆုံး Sync Logic ကို Actor နဲ့ ရှင်းပါစေ။ Actor က Sync ကို စောင့်နေရတာမျိုး မဖြစ်စေချင်ပါဘူး။ UX အရ အရာရာ ဟာ မြန်နေပါစေ။ Cloud လုပ်လိုက်လို့ နှေးသွားတယ်ဆိုရင် မဟုတ်သေးပါဘူး ။ Cloud အပြစ်မဟုတ်ပါဘူး အဲ့ဒါ သင့် အပြစ်ပါ။ ကြိုက်တာလေး တစ်ခု သိမ်းထားတာ ရှိတယ် ဖတ်ကြည့်ပါ။

Ops တွေ ကတော့ အသစ်စ တည်ဆောက်တယ်ဆို လွယ်ပါတယ်။ အရာရာ ကို Redentent လုပ်မယ််ဆိုရင်တော့ မဟုတ်သေးပါဘူး။ ရှိပြီးသားကို Migrate မယ်ဆိုရင်တော့ Plan ပါပြီးတော့ Service တွေကို Containerized လိုက်တယ်ဆိုလည်း Storage ကတော့ Raid နေတုန်းပါပဲ။ အဲ့ဒါကို မှတ်ထားပါ။ Raid fail ရင် all fail ပါတယ်။ S3 bucket လိုဟာမျိုးသုံးတယ်ဆိုရင်တော့ တစ်မျိုးပေါ့။ ဒါပေမယ့် Service Source ကတော့ အနည်းဆုံး Mounted FS ကလာဦးမယ်ထင်ပါတယ်။ ဒါပေမယ့် Fundamental တွေကို အရမ်းတော့ မပစ်ခါပါနဲ့။ Kubernetes လို့ရပါတယ် ဒါပေမယ့် cluster nodes တွေကတော့ ရိုးရိုး VPS တွေပါပဲ။ ကျန်းမာရေး ဂရုစိုက်ပါ။ ELK လိုဟာမျိုး ကို အရမ်း fancy တယ်ထင်လည်း NMS တစ်ခုခုတော့သုံးပါ။ ကျမှ မထပါနဲ့။ ကျလည်း အိပ်နေလို့ရအောင် ထွင်ပါ။

ရောင်းတဲ့ လူတွေအနေနဲ့ကတော့ QoS မကောင်းသေးလည်း စိတ်မပျက်ပါနဲ့။ အဓိကက Team ကို မ Blame ပါနဲ့။ Constructive Feedback ပေးပါ။ Timeline တောင်းပါ။ အချိန် နေ့ရက် နာရီ အတိအကျ တောင်းပါ။ Team က မပေးနိုင်ရင် is on them ပါ။ ကိုယ်က ကိုယ့် SLA သို့မဟုတ် ကြေညာထဲမှာ ပေးထားတဲ့ အတိုင်း အတတ်နိုင်ဆုံး ဖြစ်အောင် Information ကူးသန်းပေးပါ။  ရောင်းသူ ဝန်ဆောင်သူ ဖြစ်တဲ့အတွက် ကတိနဲ့ စကားတော့ တည်အောင် နောက်က Implementations လိုက်ပေးပါ။ Team ကို Clear message ပေးပါ။ Team Lead ကပြန် ပြီး Feedback ပါလိမ့်မယ်။  Team ကို Customer နဲ့ စကားပြောတာမျိုး ပေးမလုပ်ပါနဲ့ ။ နှစ်ဖက်လုံးက Frustruction မြင့် နေပါပြီ။ ကြားထဲက နေ Damage Control လုပ်ပါ။ Japanese Battle Ship Yamato DMC လိုမျိုးတောင် နစ်သွားပါသေးတယ်။ ဆိုတော့ Internal ကိုယုံကြည်ပါ အားပေးပါ။ မတတ်သာရင်တော့ Management ကို တိုက်ရိုက် Feedback ပေးပါ။ အားလုံး အလုပ်လုပ်နေတာပါ ဆော့နေတာမဟုတ်ပါဘူး။ 

လေ့လာစရာ

ygncode.com ကို လာဖတ်ပါ။ ကိုစကြာ က ကောင်းတာလေး တွေရေးလွန်းလို့ ကိုယ်ကိုတိုင်လည်း စိတ်ပါပြီးလာရေးဖြစ်တာပါ။ အပိုတွေ မပြောဘူး ဒီမှာ လိုတာလေးတွေပဲ ပြောကြပါမယ်။ ကိုးကားတွေလည်း လင်ခ့် တွေ ထည့်ပေးထားပါတယ်။ ပြီးတော့ အမြဲလိုလို Hardcore လေ့လာနေရတာ ကောင်းပါတယ်။ ငယ်သေးတယ်ဆိုရင်ပေါ့ ။ ဒါပေမယ့် နောက်ပိုင်််း ခြစ်ထုတ်ပြီး အလေ့ အကျင့် နဲ့ Learn ရတာကို ပို သဘော ကျလာပါတယ်။ တခြား Coding နဲ့ မဆိုင်တာလေး တွေ လည်း လုပ်ရင်းပေါ့။

DEV တွေအတွက် Practice လုပ်မယ်ဆိုရင် ဒါလေးလုပ်ကြည့်ပါ။ Go အခြေခံရှိရင် ကောင်းပါတယ်။ မရှိလည်း Pick-up လိုက်ပေါ့။ သေမယ့် ဆေးတွေမှ မဟုတ်ပဲ။

Microservices in Go

https://medium.com/seek-blog/microservices-in-go-2fc1570f6800

Architect တွေကတော့ ဒါလေး ကောင်းတယ် ထင်တာပဲ။ ကိုယ့် အမြင်နဲ့ ကိုယ် ဖတ်ကြည့်ပါ။ လိုက်လုပ်ရမယ် ဆိုတာမျိုးတော့မဟုတ်ပါဘူး။

Building microservices in 2019 and beyond

https://www.atlassian.com/continuous-delivery/microservices/building-microservices

အဆုံးထိ ရောက်လာတယ် ဆို တော်တော် လေး စိတ်ရှည်တဲ့လူပဲ ဖြစ်တဲ့အတွက် ကျေးဇူး တင်စကားလေး တော့ ပြောပါရစေ။ ထပ်မံဆွေး နွေးလိုတာရှိရင် @talnetd နဲ့ twitter ဒါမှမဟုတ် telegram မှာ လာ ပြောလို့ရပါတယ်။ အားရင် ပြန်ပြောပါ့မယ်။ မအားရင်တော့ Sorry ပါ။

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