Cloud native နဲ့ DevOps

Cloud native tooling support တွေအားကောင်းလာခြင်းက ကျွန်တော်တို့ကို လေ့လာစရာတွေ ပိုပေးသလိုဖြစ်ပြီး မပြီးဆုံးနိုင်တဲ့ ခရီးတခုလို ခံစားရစေတယ်။ ဒါပေမယ့် တဖက်မှာ ဒါကို ကျွန်တော်တို့မျိုးဆက်ရဲ့ ကံကောင်းခြင်းလို့လည်း မြင်လို့ရနိုင်တယ်။ တကယ်တော့ cloud native tooling တွေလို့ categorize လုပ်ကြတဲ့ CNCF အောက်က software တွေက cloud နဲ့သိပ်မဆိုင်လှပါဘူး။ cloud ကနောက်ကွယ်ကနေ အကြီးအကျယ် တွန်းပေးခဲ့တဲ့ အရွေ့ကြီးဖြစ်ခဲ့ပေမယ့် ဒီ cloud native tooling တွေဆိုတာ software engineering ရဲ့တဆစ်ချိုး DevOps ဦးမော့လာရာက ပေါ်ထွက်လာတဲ့ အသီးအပွင့်ဖြစ်တယ်။

Software ဆိုတာ တကြိမ်ရေး၊ အကြိမ်ကြိမ်ဖတ်၊ တသက်လုံးသုံးလို့ ပြောကြတယ်မလား။ ၃ ခုထဲမှာ အဲဒီတကြိမ်တည်းရေးရတဲ့ အဆင့်ကပဲ လက်အဝင်ဆုံးနဲ့ planning လုပ်ရတာ အကြီးဆုံး ဖြစ်တဲ့အတွက် software project တွေမှာ development phase ကိုပဲ အများဆုံး ​အာရုံစိုက်ဖြစ်ကြတယ်။ ရေးလို့ပြီးပြီ၊ QA pass ဖြစ်ပြီဆိုတဲ့ software တွေကို Linux admin တွေက တာဝန်ယူပြီး ဆက် run သွားပေးနိုင်မယ်လို့ပဲ နှစ်ပေါင်းများစွာ ရိုးရိုးလေး တွေးခဲ့ကြတယ်။ organization တခုမှာ virtual machine 3 ခု၊ software 2 မျိုး၊ database 3 လုံးနဲ့ load balancer 1 ခုပဲရှိမယ်ဆိုရင် ဒါကပြဿနာမဟုတ်ပါဘူး။ ဒါပေမယ့် software တွေ ဒါဇင်နဲ့ချီပြီး user တွေသန်းနဲ့ချီလာရင်တော့ ဒီ system ကြီးကို ချောချောမွတ်မွတ်နဲ့ ဆက် run နိုင်ဖို့ ခေါင်းတွေ အများကြီး ထပ်လိုလာတယ်။ ဒါက အပေါ်ယံပြဿနာပဲ ရှိသေးတယ်။ software ကိုရေးတဲ့သူနဲ့ run တဲ့သူနှစ်ဖက်ရဲ့ ရည်မှန်းချက်တွေ မတူခြင်းက organization ရဲ့တိုးတက်မှုကို နှောင့်နှေးစေသလို system ကိုအားနည်းစေဖို့ အခွင့်အလမ်းတွေလည်း အများကြီး ပိုဖန်တီးပေးတယ်။

ဒီပြသာနာကို ဖြေရှင်းဖို့ ကနဦး စဥ်းစားခဲ့တဲ့ ပုံစံက software operation ကို manual လုပ်မယ့်အစား software နဲ့ပဲလုပ်ဖို့ဖြစ်တယ်။ စဥ်းစားကြည့်တော့လည်း ကျွန်တော်တို့က ဝက်မွေးနေတာမဟုတ်၊ မန်ကျည်းပင်စိုက်နေတာလည်း မဟုတ်ပဲ software နဲ့ပဲအသက်မွေး၊ software တွေရေးနေကြတဲ့ industry ပဲကိုး။ ဒီတော့ software တွေကို manage လုပ်မယ့် operational ဖက်ခြမ်းကိုပါ ဘာကြောင့် software နဲ့ extend မလုပ်နိုင်ရမှာလဲ။

ဒီ model ကိုအသက်သွင်းဖို့ဆိုရင် အပြောင်းအလဲ ၂ ခုလုပ်ဖို့လိုတယ်။ ပထမက operation ​နဲ့ development နှစ်ဖက်စလုံးမှာ ဘုံရည်မှန်းချက်တခုတည်းရှိဖို့ ပြုပြင်ရမယ်။ operation ကို 100% failure ကင်းစင်ရင် တော်တယ်လို့ ချီးကျူးဖို့ မလုပ်ရသလို developer တွေကိုလည်း feature အသစ်များများ ရေးနိုင်လေ တော်လေလေလို့ မမြှောက်ပေးသင့်ဘူး။ အဲဒီအစား ကျွန်တော်တို့ရဲ့ software service တွေနဲ့ပတ်သက်ပြီး customer တွေဆီ အာမခံထားတဲ့ uptime, performance စတဲ့ကိန်းဂဏန်း (တနည်း SLA) တွေကို buffer တခုခွာ internal objective (SLO) အဖြစ်ထားပြီးတဲ့နောက်မှာ အပိုထွက်လာတဲ့ error budget ကို development ကရော operation ကပါ ​အမှားလုပ်ခွင့်ရှိတဲ့ အတိုင်းအတာအဖြစ် ခွင့်ပြုပေးဖို့လိုတယ်။

ဒုတိယအချက်က operation team အနေနဲ့ automated script တွေကို သူ့ဟာသူ automatic အလုပ်လုပ်စေနိုင်မယ့် software မျိုးတွေတည်ဆောက်ဖို့ လိုတယ်။ လူပါဝင်စရာမလိုပဲ automatic အလုပ်လုပ်စေဖို့အတွက်ဆိုရင် အရေးအကြီးဆုံးနဲ့ မဖြစ်မနေ အလိုအပ်ဆုံးက system ကိုရှုထောင့်ပေါင်းစုံကနေ monitoring လုပ်ဖို့ဖြစ်တယ်။ ဒီအတွက် ကျွန်တော်တို့ရဲ့ application တွေကို လိုအပ်တဲ့ metric တွေကောက်နိုင်အောင် ရေးထားရမယ်။ ဒါက လွယ်သလားလို့မေးရင် မခက်ပါဘူး။ ဒါပေမယ့် ထောင့်စေ့ဖို့လိုမယ်။ request timing, downstream latency, error rate စတဲ့ traffic အုပ်စု၊ CPU, disk usage နဲ့ memory usage စတဲ့ resource consumption အုပ်စု၊ TCP receive window, bandwidth, RTT, retransmit စတဲ့ network အုပ်စုစသဖြင့် ထောင့်ပေါင်းစုံက metric တွေကိုထုတ် aggregate လုပ်၊ threshold ကျော်ရင် Discord တို့၊ Slack တို့ကနေ notification ဝင်လာအောင်ရေးထားဖို့ဆိုတာ လွယ်လှတဲ့ကိစ္စမဟုတ်ပါဘူး။ cloud native tooling ရဲ့အခန်းကဏ္ဍက ဒီကစတာပဲ။

• metric တွေကို application ကနေ code အနည်းဆုံးနဲ့ ကောက်နိုင်အောင် အသင့်ပြင်ထားပေးတဲ့ otel library တွေရှိတယ်။
• traffic metric တွေအတွက် Istio, Linkerd စတဲ့ mesh တွေရှိတယ်။
• distributed tracing အတွက် Zipkin, Jaeger စသဖြင့်ရှိတယ်။
• application ကထုတ်တဲ့ log တွေကိုစုပေးဖို့ Promtail, Fluentbit နဲ့ Filebeat တို့လို logging agent တွေရှိတယ်။
• ဒီ log တွေကို analysis လုပ်ပြီး လေ့လာအဖြေရှာ insight ထုတ်လို့ရမယ့် Loki, Elasticsearch စတဲ့ logging server တွေရှိတယ်။
• ကိုယ်ရေးတဲ့ application တွေ၊ ကိုယ်မရေးထားတဲ့ software တွေက ထုတ်ပေးတဲ့ metric တွေကို စုပေးဖို့ Prometheus ရှိတယ်။
• incident တွေဖြစ်တဲ့အခါ Slack, Discord စသဖြင့် ကိုယ်လိုချင်တဲ့ platform ကို alert တွေပို့ပေးဖို့ Alert Manager ရှိတယ်။
• ရလာတဲ့ data နဲ့ insight ပေါင်းစုံကို ကဏ္ဍအလိုက် ပြန်ခွဲပြီး Bar တွေ၊ Graph တွေနဲ့ visualize လုပ်ဖို့ Grafana ရှိတယ်။
• နောက် code ကိုရေးနေတဲ့ development phase မှာတင် error တွေ၊ vulnerability တွေကို စစ်ထားနိုင်ဖို့လိုတယ်။ ဒီအတွက် static analysis နဲ့ code quality လုပ်နိုင်အောင် Synk, SonarQube စသဖြင့်ရှိတယ်။
• configuration နဲ့ metadata scanning အတွက် trivvy ရှိတယ်။
• ဒါတွေကို code checkout တိုင်းမှာလုပ်ဖို့ Tekton, GitHub Action, Jenkins စတဲ့ CI/CD software တွေရှိတယ်။
• error budget ကိုဖြေးဖြေးချင်း ချွေသုံးဖို့ဆိုရင် အရေးကြီးတာတခုက change management ပဲ။ အဲတော့ rollout တွေကို big bang rollout တွေမဟုတ်ပဲ progressive ဖြစ်အောင် အဆင့်ဆင့် တားထားရမယ်။ ဒီအတွက် Flagger, Argo Rollouts စတာတွေရှိတယ်။
• နောက်ပြီး deployment မှာ error တွေတွေ့တဲ့အခါ rollback, roll forward တွေကို အလိုအလျောက် အလွယ်တကူ လုပ်နိုင်အောင်လည်း ပြင်ထားရမယ်။ ဒီအတွက် Argo CD, Flux စသဖြင့်ရှိတယ်။
• system တွေက immutable ဖြစ်ရမယ်။ ကိုယ့်ဟာကိုယ် self healing နဲ့ scaling လုပ်နိုင်စွမ်းရှိဖို့ လုပ်ထားရမယ်။ ဘာလို့လဲဆိုတော့ လူသားတွေ ပါဝင်ပတ်သက်ရတဲ့နေရာတိုင်းက နှောင့်နှေးဖို့နဲ့ အမှားပါဖို့ ယိုပေါက်တွေကို လက်ယပ်ခေါ်သလို ဖြစ်နေတယ်။ ဒီအတွက် containerization အတွက် Docker, Podman နဲ့ orchestration အတွက် Kubernetes လို platform တွေကို သုံးနိုင်တယ်။
• software ရဲ့ demand ကိုနားလည်ပြီး capacity အလုံအလောက်ရှိအောင် ကြိုပြင်ထားရမယ်။ လိုအပ်လာရင် resource တွေကို အလိုအလျောက် ချဲ့နိုင်ချုံ့နိုင်အောင် ပြင်ဆင်ထားရမယ်။ ဒီအတွက် Cluster Autoscaler, Karpenter စသဖြင့်ရှိတယ်။
• နောက် infrastructure level provisioning လုပ်တဲ့အခါမှာလည်း AWS, GCP စတဲ့ cloud vendor တွေရဲ့ API ကိုတည်ပြီး အစအဆုံး software ရေးရမယ့်အစား Pulumi, Terraform, Open Tofu စသဖြင့် သုံးနိုင်တယ်။

ဒီ tool တွေက software operation ကို software နဲ့ပဲလုပ်ဖို့ စပြောင်းလဲခဲ့ကြတဲ့ ဆယ်စုနှစ် ၂ ခုစာ အတွေ့အကြုံတွေကနေ ပေါက်ဖွားလာတာဖြစ်တယ်။ အစမှာ ပြောခဲ့သလိုပဲ။ အခုလိုမျိုး cloud native tooling support တွေပိုပိုအားကောင်းလာခြင်းက ကျွန်တော်တို့ကို လေ့လာစရာတွေ ပိုပေးသလိုဖြစ်ပြီး မပြီးဆုံးနိုင်တဲ့ ခရီးတခုလို ခံစားရစေတယ်ဆိုပေမယ့် တချိန်တည်းမှာပဲ ဒါက အခုမျိုးဆက်ရဲ့ ကံကောင်းခြင်းလည်း ဖြစ်နေတယ်။ ရင့်ကျက်နေပြီဖြစ်တဲ့ framework နဲ့ ecosystem အပေါ်အဆင်သင့် အထိုင်ချပြီး efficient ဖြစ် reliable ဖြစ်တဲ့ system တွေကို ခပ်မြန်မြန်ပဲ ဆောက်လို့ရသွားစေတာ၊ microservice တွေဒါဇင်ချီတဲ့ system ကြီးတွေကို git ဆီ push လိုက်ရုံလေးနဲ့ production ဆီအထစ်အငေါ့မရှိ တန်းရောက်သွားတာ ဒါတွေက လွန်ခဲ့တဲ့ အနှစ် ၂၀ တုန်းကဆိုရင် စိတ်ကူးယဥ် ပုံပြင်အဆင့်ပဲ ရှိခဲ့သေးသကိုးလေ။