အနားမသပ်နိုင် သေးတဲ့ Infrastructure as Code (IaC) – အပိုင်း(၁)

ကိုယ်တိုင်က အလုပ်ခွင်မှာ coding နဲ့ နေ့စဉ်ထိတွေ့ရမဟုတ်ပေမယ့်လည်း automation အတွက် scripts တွေရေးလိုက်၊​ python code လေးတွေကိုမဖြစ်စလောက်ရေးကြည့်လိုက်၊ module အလွယ်တကူရှိရင် Ansible နဲ့ကောက်ပြီးတော့ pipeline တွေပြင်ကြည့် စမ်းကြည့်လိုက်လောက်နဲ့ စာရေးသူစလိုက်တာ အခုဆိုရင် ပြဿနာတစ်ခုဖြေရှင်းတော့မယ်ဆို coding language တစ်ခုခုနဲ့ ဘယ်လိုမျိုးဖြေရှင်းလိုက်ရင် ဖြင့်ကောင်းလိုက်မလဲ ဆိုတဲ့ထိပါပဲ။ Coding ဆိုင်ရာတိုးတက်မှုတွေရှိလို့ကောင်းတဲ့အချက်တွေရှိသော်လည်း၊ language တစ်ခုတစ်ခုကိုလိုက်ရတာ syntax ကိုနားလည်အောင်ကြိုးစားရတာမှာ အချိန်တွေအများကြီးကုန်ပါတယ်။ Programming အခြေခံ basic ကနေ၊ intermediate လောက်ထိ အတန်အသင့်နားလည် ထားသော်လည်း မထိတွေ့တာကြာတော့ အကုန်လုံးလည်းမေ့သလောက်ရှိနေတော့ ပြန်ပြီးတူးဖော်ရတာတွေအများကြီးဖြစ်လာပါတယ်။ ၁၀တန်းအောင်ပြီး computer programming ဆိုတာကြီးကို အိမ်ကအတင်းသွားတက်ခိုင်းလို့ C programming ကို အပြာရောင် screen ကြီးပေါ်မှာ code တွေကို ရေးခဲ့ compile လုပ်ခဲ့ဘူးတာတော့ အထင်းသားမှတ်မိနေပါသေးတယ်။ သင်ပေးတဲ့ ဆရာကကြိုးစားပြီးသင်သော်လည်း၊ သင်ယူသူဖြစ်တဲ့ စာရေးသူမှာတော့ စိတ်မပါတော့ အတတ်မမြန် အလုပ်မဖြစ်ခဲ့ပါဘူး။ သို့သော်… လိုအပ်တဲ့အခြေခံ ကြမ်းခင်း သဘောမျိုး လေ့လာခွင့်ရခဲ့တော့ အဲ့ဒီတုန်းကထင်သလောက် မဆိုးဘူးလို့ ဆိုရမှာပါ။ အပင်ပန်းခံပြီးတော့ သင်ပေးတဲ့ အဲ့ဒီတုန်းကဆရာကို အများကြီးကျေးဇူးတင်ရမယ့် သဘောပါလေ။ သူ့ကြောင့်လည်း စာရေးသူနဲ့ ဝမ်းကွဲ ညီအကိုနှစ်ယောက် programming ကို ကျွဲပါးစောင်းတီးဘဝ ကနေပြီးတော့ အရသာခံတတ်သိတတ်တဲ့ထိ သင်ယူလေ့လာခွင့်ရခဲ့ ကြပါတယ်။ လပိုင်းသာသာ သင်ယူလေ့လာခဲ့ကြသည့်တိုင်အောင် အခြေခံလောက်ကို တတ်တယ်လို့ဆိုကြပါတော့။

အဲ့ဒီကနေမှ ကောလိပ်နဲ့ တက္ကသိုလ်ရောက်တော့ နောက်တခါ C++, Perl, C# တို့အပြင်၊ VBA (Visual Basic for Applications) ကို Micrsoft Office 2007 မှာ project အတွက် အများကြီးရေးခဲ့ ရပါတယ်။ ဒီ့အပြင် frontend မှာသုံးတဲ့ HTML နဲ့ CSS ကိုလည်း အနည်းငယ်ထပ်ပြီး လေ့လာရတယ်။ Database အပိုင်းမှာလည်း Microsoft SQL Database လို platform တွေမှာ project ကြီးသုံးခု လေးခုလောက် လုပ်ရတယ်လို့ မှတ်မိပါတယ်။ နောင်တခါ တက္ကသိုလ်တက်ရင်း ကောလိပ်မှာ အချိန်ပိုင်းစာပြန်သင်တော့ Perl ကို ဘာသာရပ်တစ်ခုအနေနဲ့ ပြန်လည်သင်ကြားပို့ချခဲ့ရတယ်။ Coding နဲ့ ပတ်သတ်ပြီးရှိတဲ့ အတွေ့အကြုံ ဒါအကုန်ပါပဲ။ ရံဖန်ရံခါ အိမ်က home lab မှာ ဖြစ်ဖြစ်၊ အလုပ်အတွက်လိုအပ်တဲ့ အချို့သောအရာတွေကို batch, bash နောက်ပြီးတော့ powershell လိုမျိုး scripts တွေကိုတော့ ရေးဖြစ်ပါတယ်။ လိုမှလိုသလို ဟိုရှာဒီရှာနဲ့ ရေးခြင်းမျိုးသာဖြစ်ပါတယ်။ လိုရင်းက စာရေးသူဟာ coding သမားမဟုတ်ပါဘူး၊ သို့သော်အခုနောက်ပိုင်းမှာတော့ coding/programming language တွေတစ်ခုပြီးတစ်ခု လေ့လာသင်ယူဖို့ ကြိုးစားနေပါတယ်။ လက်ရှိမှာတော့ အလုပ်ခွင်မှာ automation အတွက်တော်တော်လေး အဆင်ပြေတဲ့ python ကိုလေ့လာဖြစ်သလို၊ လက်တွေ့မှာလည်း လိုရင်လိုသလောက် အသုံးချနိုင်တဲ့ အထိပါပဲ။ နောက်ပြီးတော့ ဆက်လက်လေ့လာချင်တဲ့ language သုံးခု လေးခုလောက် ရှိပါတယ်။ Golang, Javascript နဲ့ Ruby တွေပါ။ အလုံးစုံ အကုန်လုံးနီးပါး မသိတောင်မှ အလုပ်ခွင်မှာ အသုံးပြုလို့ရတဲ့ အထိတော့ လေ့လာသင်ယူလိုပါတယ်။ Web framework မှာဆိုလည်း Django, Flask နဲ့ Bootstrap လိုမျိုး python တို့၊ javascript တို့နဲ့တွဲပြီးတော့ အသုံးပြုနိုင်မယ့် framework တွေကို လက်ရှိမှာစိတ်ဝင်စားနေပါတယ်။ လက်ရှိအနေအထားမှာ စာရေးသူရဲ့ သွားလိုတဲ့ လမ်းကြောင်းမို့ အနည်းငယ်သိစေလိုတာမျိုးပါ။

တခါပြန်ကြည့်လိုက်ရင်… ကိုယ်တိုင်က network systems engineer ယောင်ယောင် အောက်ခြေတန်းစား အလုပ်နဲ့ အသက်မွေးရတာကြောင့် နေတိုင်းလုပ်ရတာနဲ့ သင်ယူလိုစိတ် ဖြစ်နေတာတွေဟာ နည်းနည်းလေး အံချော်သယောင်ယောင် ဖြစ်လာပါတယ်။ သို့သော်… Site Reliability Engineer (SRE) တို့၊ DevOps တို့ လိုမျိုး culture နဲ့ practice တွေကို ကိုယ်တိုင်က အားကျမိနေတော့ အဆင်သင့်သလိုလိုရှိ နေပြန်တယ်။ စာရေးသူအနေနဲ့တော့ တခါတလေ ဆင်ခေါင်းကို ခွေးချီသလိုများ ဖြစ်နေမလားလို့ ခြေတုံချတုံ ဖြစ်တာလည်း ခဏခဏပါ။ သင်ယူနိုင်စွမ်း ရှိသမျှတော့ သင်ယူကြည့်ရတာပေါ့။ ဒီလိုနဲ့ ပြီးသွား ပြီလာဆိုတော့ Docker သိရမယ်၊ K8s သိရမယ်၊ Ngnix သိရမယ်၊ Cloud Native တွေသိရမယ်၊ SQL သိရမယ်၊ Git သိရမယ်၊ CI/CD pipeline သိရမယ်၊ ဟိုဟာလည်း သိရမယ်၊ ဒီဟာလည်း သိရမယ်ဆိုတဲ့ နည်းပညာခေတ်ကြီးထဲမှာမို့ အရှုံးမပေး လိုပါ။ စာသုံးလို့ ရတာတွေအကုန်လုံးကို စာရေးသူ စားသုံးချင်ပါတယ်။ တကယ်သိချင်တဲ့ စိတ် drive နဲ့ ဖြစ်ချင်တဲ့ စိတ် passion တော့ အဆက်မပြတ်လိုတာတော့ အမှန်ပါ။ အခုနောက်တခါ… Infrastructure as Code (IaC) တဲ့လာပြန်ပါပြီ။ စာရေးသူ IaC ကို စမြည်းကြည့် စစမ်းကြည့်ရင်းနဲ့ အရသာတွေ့ရပြန်၊ စာသုံးရပြန်ပါပြီ။ စိတ်ဝင်စားဖို့ကောင်းတဲ့ topic မို့ IaC အကြောင်းကို အနည်းငယ် စပြီးတော့ မိတ်ဆက်လိုက်ရအောင်ဗျာ။

Infrastructure as Code (IaC) မိတ်ဆက်

IaC အကြောင်းကို မပြောခင်မှာ အရင်ဆုံးနားလည်ထားရမယ့်အရာက SRE/DevOps culture ဖြစ်တည်လာပုံဖြစ်ပါတယ်။ အရင်က post တစ်ခုမှာလည်း Dev နဲ့ Ops team နှစ်ခုရဲ့ အားပြိုင်မှုနဲ့ Dev ဘက်က သူတို့နေ့စဉ်ကြုံတွေ့နေရတဲ့ အခြေအနေတစ်ခုကို ဘယ်လိုမျိုးဖြေရှင်းမလဲ ဆိုတာကနေပြီးတော့ စလိုက်တာအခုဆိုရင် IaC နဲ့ ပတ်သတ်ပြီးတော့ အသုံးပြုလို့ရတဲ့ tools တွေအများကြီးရှိနေပါပြီ။ ပထမဆုံး Dev ဘက်က ပြဿနာကို ကြည့်လိုက်ရအောင်။ Ops ဘက်ကနေ့စဉ်နဲ့ အမျှ uptime နဲ့ stability အတွက် change management တစ်ခုကို ဘယ်လိုမျိုး အတင်းအကျပ် control လုပ်မလဲဆိုတာနဲ့ ထိန်းချုပ်တဲ့ environment မှာအလုပ်ဖြစ်အောင် လုပ်ရတဲ့ အနေအထားမှာပါ။ တဘက်မှာကတော့ Dev တွေဟာ resource ကိုလိုချင်ရင် လိုတဲ့အချိန်မှာ အချိန်မနှောင်းပဲနဲ့ ချက်ချင်း ရချင်တဲ့ သဘောသဘာဝရှိပါတယ်။ ထားပါတော့… Dev တွေဟာ application တစ်ခုကိုစပြီးတော့ ရေးလိုက်ပြီဆိုတာနဲ့ ရေးဖို့အတွက် dev environment တစ်ခုလိုပါတယ်။ Application တစ်ခုရဲ့ သဘာဝပေါ်မှာမူတည်ပြီးတော့ local machine မှာ dev environment တစ်ခုကို တည်ဆောက်ပြီးတော့ build တစ်ခုကို လုပ်လို့ရသလို၊ အချို့သော server-side application တွေမှာတော့ dev environment ကို ပိုပြီးတော့ ပြည့်စုံတဲ့ hypervisor တစ်ခုကို အသုံးပြုပြီးတော့ virtualization မှာ စမ်းသပ်တာပိုပြီးတော့ အလုပ်ဖြစ်နိုင်ပါတယ်။ ဒီအတွက် သူတို့လိုအပ်တဲ့ server တစ်ခုရဲ့ spec တွေကို Ops ရဲ့ ticketing system မှာသွားပြီးတော့ မှာယူရပါတယ်။

Ops ဘက်ကအလုပ်ကို ခပ်မြန်မြန်လုပ်တတ်တဲ့ သဘောသဘာဝရှိရင်တောင်မှ VM ကို deploy လုပ်တဲ့အခါ၊ configure လုပ်တဲ့အခါမှာ manual process ဖြစ်တဲ့အတွက် VM အလုံးရေပေါ်မှာမူတည်ပြီးတော့ အချိန်အားဖြင့် ၂ရက်ကနေ ၃ရက်လောက်ထိကြာတတ်ပါတယ်။ ဒါ့အပြင်…တစ်ယောက်နဲ့ တစ်ယောက် email/messaging လုပ်တဲ့အခါမှာ နားလည်မှုတွေ အများကြီးထပ်ပြီးတော့ လွဲမှားနိုင်ပါတယ်။ ဆိုလိုချင်တာက အချိန်တွေအများကြီးကုန်ပြီးတော့ အလွှဲအချော်တွေလည်း ဖြစ်နိုင်ချေအများကြီး ရှိတာမို့ ဒီ workflow ဟာအလုပ်တော်တော်လေးကို မဖြစ်တဲ့ သဘောပါ။ နောက်တခါ Dev နဲ့ Ops နှစ်ခုကြားမှာသုံးလို့ ရတဲ့ documentation တစ်ခုကို ဘယ်သူက ဖန်တီးမလဲဆိုတာက နောက်ပြဿနာတစ်ခုပါ။ Documentation ဆိုတဲ့နေရာမှာ Dev ဘက်ကရော၊ Ops ဘက်ကရော မှတ်တမ်းတင်ရမှာပါ။ နှစ်ဘက်လုံးက documentation ဘက်မှာ အားနည်းတယ်ဆိုရင်တော့ နောက်တခါမှာ ပြင်ဆင်စရာ ထပ်ပေါင်းထည့်စရာ တွေရှိလာတဲ့အချိန် ဘယ်ပေါ်မှာ အခြေခံပြီးတော့ design reference လုပ်ရမလဲ ဆိုတာထည့်သွင်း စဉ်းစား ကြည့်လိုက်ရင် တော်တော်လေးကို ကြောက်ဖို့ကောင်းတဲ့ chaos engineering production environment တစ်ခုဖြစ်လာမှာပါ။ ဒီကိစ္စက သေးသေးမွှားမွှား မဟုတ်ပါ။ Dev ဘက်ကရော၊ Ops ဘက်ကရော သေချာသဘောပေါက်တဲ့ အခြေခံပြဿနာ တရပ်ပါ။

ဒီလိုအထက်က ဖြစ်လာမယ့် ပြဿနာတွေကိုဖြေရှင်းဖို့ရာ အတွက် dev သမားတွေက abstraction layer တစ်ခုကို ဖန်တီးဖို့ရာဖြစ်လာပါတော့တယ်။ အဲ့ဒီ abstraction layer အဓိကအားဖြင့် အခြေခံကျကျလိုအပ်ချက် သုံးခုကိုဖြေရှင်းဖို့ ကြိုးစားထားပါတယ်။ ပထမတစ်ခု configuration drift ဆိုတဲ့ dev environment ကို setup လုပ်တုန်းသုံးထားတဲ့ systems configuration ဟာ test environment ကို တည်ဆောက်တဲ့အခါမှာ ထင်ဟပ်မှုမရှိတာကိုပြောတာပါ။ sysadmin တွေဆိုရင် ဒီလိုအနေအထားမျိုး system upgrade လုပ်တဲ့အခါနဲ့ system migration လုပ်တဲ့ အခါတွေမှာ အမြဲကြုံတတ်တဲ့ အခြေအနေတခုပါ။ ပြောရတာလွယ်သလောက် လက်တွေ့မှာ ပူထူပြီးတော့ troubleshooting အတွက်လည်း အများကြီး အခက်တွေ့ရပါတယ်။ ဒုတိယတစ်ခုက mutable infrastructure ကနေပြီးတော့ immutable infrastructure ဖြစ်အောင်လုပ်ဖို့ အတွက်ပါ။ ပြောချင်တာ… mutable approach မှာဆို dev ကပဲဖြစ်ဖြစ် ops ကပဲဖြစ်ဖြစ် လိုအပ်တဲ့အရာတစ်ခု ပြင်ဆင်ဖို့ဆိုရင် ဘယ်သူကိုမှလည်း communicate မလုပ်ပဲနဲ့ ad-hoc ပြင်တတ်ပါတယ်။ change management တစ်ခုနဲ့ ထိန်းချုပ်နိုင်သော်လည်း သေးသေးမွှားမွှား ပြင်ဆင်ရမယ့်ဟာ မျိုးဆိုဘယ်သူမဆို change management process ကိုဖြတ်သန်းဖို့ အတော်လေးကို ဝန်လေးပါတယ်။ ဒီတော့ immutable approach ဟာဘယ်လိုမျိုးလည်းဆိုတာ နည်းနည်းသွားကြည့်လိုက်ရအောင်။ System တစ်ခု environment တစ်ခုကို provision လုပ်ပြီးသွားတိုင်းမှာ အဲ့ဒီဟာကို ad-hoc ပြင်ဆင်လို့ မရအောင်လို့ workflow ကို ပြောင်းလိုက်ရပါ့မယ်။ deployment တစ်ခုလုပ်တိုင်း version control ကိုထည့်သွင်း အသုံးပြုဖို့လိုပါပြီ။ Documentation နဲ့ manual deployment process နှစ်ခုလုံးဟာ အဲ့ဒီလိုမျိုး version control လုပ်ဖို့ရာအတွက် ဘယ်လိုမှ အဆင်မပြေနိုင်ပါဘူး။ overhead တွေများလွန်းလှပါတယ်။ ဒီအပိုင်းမှာ နည်းပညာဆိုင်ရာ အနုပညာဖြစ်တဲ့ git ဆိုတဲ့ version control ကိုသုံးပြီး deploy မလုပ်ခင်မှာ ကြိုတင် plan နိုင်တဲ့ အစွမ်းရဖို့လိုပါတယ်။ ပြီးရင် လိုသလောက် resource နဲ့ spec configuration တွေကို command တစ်ခုတည်းနဲ့ အလွယ်တကူဖန်တီး နိုင်ရပါ့မယ်။ နောက်တခါ scale up/down နဲ့ tear down ကိုလည်း အလွယ်တကူလုပ်နိုင်ဖို့လည်း လိုပါတယ်။ ဒီလိုဆိုရင်ဖြင့် environment တစ်ခုမှာ ပြောင်းချင်ပြင်ချင်ရင်တော့ လက်ရှိ version ကို tear down လုပ်ပြီးတော့ လိုအပ်တာကို code ထဲမှာပြင်ထည့်ပြီးတော့ နောက် version တစ်ခုအနေနဲ့ environment တစ်ခုလုံးကို deploy လုပ်ဖို့ရာအတွက် မခက်တော့ပါဘူး။ “လှလိုက်တာနော်…” လို့ပဲ စာရေးသူစိတ်ထဲမှာ တွေးတွေးပြီးတော့ ပြုံးရပါတော့တယ်။ နောက်ဆုံးတစ်ခုက idempotence ပါ။ ဒီတစ်ခုကတော့ programming မှာသုံးတဲ့ အသုံးအနှုံးတစ်ခုဖြစ်ပါတယ်။ idempotence ဖြစ်တယ်ဆိုတဲ့ အဓိပ္ပာယ်က ဘယ်နှခေါက် program တစ်ခု၊ function တစ်ခုကို run တိုင်းမပြောင်းလဲတဲ့ ရလဒ်တစ်ခုကိုရတဲ့ အခြေအနေတရပ်ကို ဆိုလိုခြင်းပါ။ IaC မှာတော့ idempotence ဖြစ်တယ်ဆိုတာ deploy လုပ်ထားတဲ့ environment setup တစ်ခုရဲ့ state ဟာဘယ်နှစ်ခါ deploy ပြန်လုပ်လုပ် consistent ဖြစ်ပြီး တစ်ခုတည်းသော state ကိုသာ ထိန်းသိမ်းထားနိုင်ရပါ့မယ်။ ဒါကြောင့် IaC မှာကိုယ်ဘာလုပ်ချင်သလဲပေါ်မှာမူတည်ပြီးတော့ desired state တစ်ခုကို ပေးရပါတယ်။ Terraform မှာ state ဟာတော်တော်လေးကို အရေးပါတဲ့ အရာတစ်ခုပါ။ ဒီလိုဆိုရင် configuration drift မဖြစ်အောင်ရယ်၊ immutable infrastructure တစ်ခုက code နဲ့ git လိုမျိုး version control ပေါင်းစပ်ပြီးတော့သုံးလို့ရအောင်ရယ်၊ နောက်ဆုံး idempotence ဆိုတဲ့ အနေအထားတစ်ခုဖြစ်ဖို့ရယ် ကိုအကြောင်းပြုပြီးတော့ IaC ဆိုတာဖြစ်လာပါတော့တယ်။ DevOps ဘက်မှာ စည်းကမ်းရှိတဲ့ engineer တွေ ထိန်းသိမ်းတဲ့ infrastructure ဆိုရင်တော့ code ထဲမှာ ရှင်းလင်းတဲ့ documentation ကိုပါထည့်သွင်း နိုင်ပါတယ်။ ဒီ့အတွက် documentation system သီးသန့်ရှိစရာလည်း မလိုတော့ပြန်ပါဘူး။ Software Development Life Cycle (SDLC) ကိုပါနားလည်ထားတဲ့ DevOps ဆိုရင်တော့ code တွေကို ဘယ်လိုမျိုး ထိန်းသိမ်းရမလဲ ဆိုတာအပြင် လက်တွေ့မှာ CI/CD pipeline တစ်ခုကို တည်ဆောက်ယူပြီးတော့ code testing နဲ့ review process ကိုပါ automation လုပ်နိုင်ပြန်တယ်။ ပြောမယ်ဆိုရင်တော့ sky is the limit ပါ။ ကိုယ်ချဲ့ကား တွေးခေါ်နိုင်သလောက် ကိုယ်ရဲ့ workflow တွေကိုထပ်တိုး ဖြည့်လို့ ရနိုင်ပါတယ်။

ဟုတ်ပြီ… IaC ကိုဘာကြောင့် စခဲ့တယ်၊ ဘယ်လိုသဘောသဘာဝ ရှိတယ်ဆိုတာကိုသိပြီးတဲ့နောက်မှာ ဘယ်လိုသုံးနိုင်သလဲ၊ code ကိုရေးတဲ့အခါမှာ ဘယ်ပုံဘယ်နည်းရေးနိုင်သလဲဆိုတာကို အနည်းသွားကြည့်လိုက်အောင်။ အကြမ်းအားဖြင့် ရေးပုံရေးနည်း ပေါ်မှာမူတည်ပြီးတော့ code တွေဖွဲ့စည်းပုံ နှစ်မျိုးရှိပါတယ်။ တစ်ခုက imperative ဆိုတဲ့ နည်းဖြစ်ပြီးတော့၊ နောက်တစ်ခုက declarative ဆိုတဲ့ နည်းဆိုပြီး ရှိပါတယ်။ ပထမတစ်ခုဖြစ်တဲ့ imperative မှာတော့ ကိုယ်သုံး မယ့် CLI မှာမူတည်ပြီးတော့ ဘာကဘယ်လိုမျိုး လုပ်ချင်သလဲဆိုတာကို အသေးစိတ် သေသေချာချာ ရေးချရပါတယ်။ ဒီတစ်ခုဟာ ကိုယ်တည်ဆောက်မယ့် environment သိပ်မကြီးဘူး၊ သိပ်ပြီး dynamic မဖြစ်ဘူး၊ သို့သော် ခဏခဏပြန်သုံးလို့ ရနိုင်တဲ့ setup တွေအတွက် အဆင်ပြေပါ။ နောက်ပိုင်း environment ကလည်း ကြီးလာတယ်၊ workflow တွေဟာလည်း ရှုပ်ထွေးတဲ့ ဟာမျိုးဖြစ်လာရင်တော့ scale-able (scale up/scale down/tear down)မဖြစ်တော့ပြန်ပါဘူး။ ဒီ့အတွက် declarative ဆိုတဲ့ code တည်ဆောက်ပုံကို သုံးကြရပါတယ်။ Desired state တွေကို တစ်ခုချင်းစီသိတယ်ဆိုရင် ကိုဘာလုပ်ချင်သလဲဆိုတာကို abstraction layer တစ်ခုကို ပြောလိုက်တာနဲ့ support ဖြစ်တဲ့ library/module ရှိရင်ရှိသလောက် idempotence concept ကိုအသုံးချပြီးတော့ ကိုယ့်ရဲ့ code တွေကို infrastructure အတွက်တည်ဆောက် နိုင်ပါပြီ။ ဥပမာပြောရရင် imperative ဟာကိုယ်ပိုင်ကား ဝယ်စီးသလိုမျိုးပဲ ခရီးတစ်ခုကိုသွားချင်ရင် ကိုယ်တိုင်လမ်းရှာ၊ ကိုယ်တိုင်မောင်း၊ ကားပျက်လို့ ပြင်ရရင်လည်း ကိုယ့်စရိတ်နဲ့ ကိုယ်ပြင်ရတဲ့ သဘောပါ။ ကားထဲမှာပါလာတဲ့ audio နဲ့ sound system ကိုမကြိုက်လို့ ရှိရင် ကိုယ်ကြိုက်တဲ့ဟာနဲ့ ကောက်ပြီးတော့ ပြောင်းထည့်နိုင်တယ်။ ဘယ်သူ့ကိုမှ တိုင်ပင်စရာမလိုပါဘူး။ Declarative ဆိုတာကတော့ Grab ကိုမှာပြီးတော့ ခရီးတစ်ခုကို A ကနေ B ကိုသွားမယ်လို့ ပြောလိုက်တာနဲ့ တက်ပြီးတော့ စီးရုံပါပဲ။ ကိုယ်တိုင်မောင်းစရာ မလိုဘူး။ ဘယ်ကနေ ဘယ်လမ်းရွေးပြီး သွားရမယ်ဆိုတာလည်း ပူစရာမရှိဘူး။ အကုန်လုံးအဆင်သင့် ဖြစ်လို့ ပိုပြီးတော့ အဆင်ပြေတဲ့ သဘောရှိပါတယ်။ လက်ရှိ IaC မှာသုံးတဲ့ tool-set တွေ တော်တော်များများ ကတော့ declarative တွေပါ။ နောက်အပိုင်းမှာတော့ IaC tool-chain တွေကို လက်တွေ့မှာဘယ်လိုမျိုး အသုံးချနိုင်သလဲဆိုတာ use case တွေနဲ့ ဆက်ရှင်းလိုပါတယ်။ စိတ်ဝင်စားဖို့ကောင်းပါ။ စိတ်လှုပ်ရှားဖို့ကောင်းပါတယ်။ ဒီ အပိုင်းကိုတော့ ဒီလောက်နဲ့ပဲ ရပ်လိုက်ပါ့မယ်။