29/11/2021
ဒီနေ့ခေတ် ဘဏ်တွေ IT Infrastructure တည်ဆောက်ရာမှာ ခေတ်အလိုက် ကြုံရတဲ့ အခက်အခဲတွေကျော်ပြီး Cloud Computing ဘက်ဦးတည်လာတဲ့ အကြောင်းဖြစ်ပါတယ်။
အရင်လွန်ခဲ့တဲ့ နှစ် ၃၀ လောက်တုန်းကတော့ ဘဏ်တွေမှာ အဓိကသုံးတာက Mainframe (သို့မဟုတ်) AS400 လို့ခေါ်တဲ့ Mainframe အသေးစား စနစ်တွေ ဖြစ်ပါတယ်။ Mainframe နဲ့သူရဲ့နာမည်ကြီး Green screen terminal တွေဟာ ဒီနေ့အထိ အချို့သော ဘဏ်တွေမှာ သုံးနေတုန်းစဲပါ။
Mainframe ပေါ်မှာ run တဲ့ နောက်ဆုံး OS က z/OS ဖြစ်ပြီး COBOL applications တွေ အသုံးများပါတယ်။(ခုနောက်ပိုင်း Java applications တွေလဲရှိပါတယ်။) Mainframe ရဲ့ အဓိက Database ကတော့ DB2 လို့ခေါ်ပါတယ်။ Mainframe ကို ခုနောက်ပိုင်း သိပ်မသုံးတော့တာက ဈေးအလွန်ကြီးပြီး၊ Application တွေ ဆက်လက်တိုးချဲ့ဖို့(scalable) လုပ်ရတာ ခက်လို့ဖြစ်ပါတယ်။ ဒါပေမဲ့ လုံးဝပျောက်ကွယ်သွားတဲ့ အနေအထားတော့ မရောက်သေးပါဘူး။ ဘာလို့လဲ ဆိုတော့ Mainframe ပေါ်မှာ ဘဏ်အများစု စသုံးတာက Core Banking Systems တွေများပါတယ်။အဲတုန်းကလည်း record တွေ သန်းနဲ့ချီပြီး ထိန်းနိုင်တာဆိုလို့ Mainframe တစ်ခုဘဲ ဈေးကွက်မှာရှိပါတယ်။ ဒီ Mainframe system တွေဟာနောက်ပိုင်း Customers တွေ များလာတာနဲ့အမျှ အလွန်ကြီးမားလာပြီး၊ အခြားသော System တွေ အများကြီးနဲ့ ထပ်ချိတ်ရင်း အလွန်ရှုပ်ထွေးတဲ့ အနေအထား ရောက်လာခဲ့ပါတယ်။ ခုနောက်ပိုင်း Open Systems (Unix, AIX) တွေ ခေတ်မှီလာပြီး record တွေအများကြီး ထိန်းနိုင်တဲ့ အနေအထားရောက်လာပေမဲ့ Mainframe မှ Open System ကိုပြောင်းရတာ အလွန်ခက်လို့ Core Banking Migration Projects တွေဟာ ငွေအရင်းနှီးအလွန်များပြီး အလွန်ရှုပ်ထွေးပါတယ်။
ဒီနေရာမှာ ဘာသင်ခန်းစာယူသင့်လဲ ဆိုတော့ IT system တိုင်းမှာ သူ့ရဲ Tech Refresh Cycle ဆိုတာရှိပါတယ်။ အရင်တုန်းက ကောင်းခဲ့ပေမဲ့ တစ်ချိန်မှာ ရေရှည်ပိုသက်သာမဲ့ အနေအထားတွေ ပေါ်ရင် အဲဒီအခွင့်အရေးကို ယူသင့်ပါတယ်။ ဒီ System တစ်ခုဟာ သုံးလို့ရနေပေမဲ့ သူ့ရဲ Tech Refresh Cycle ပြည့်သွားရင် အဲအချိန်မှာ ဘယ်နည်းပညာတွေ ခေတ်စားနေပြီလဲ လေ့လာပြီး အသစ်လဲဖို့ စဉ်းစားသင့်ပါတယ်။ (ဒီနေရာမှာ IT spending ဟာ company တစ်ခုရဲ့ အကုန်အကျများတဲ့နေရာဖြစ်လို့ သူ့ရဲ့ Cost and Benefits ကို ယှဉ်ကြည့်ပြီး ဆုံးဖြတ်သင့်ပါတယ်။)
Open Systems လို့ခေါ်တဲ့ Unix, AIX, Solaris, Linux နဲ့ Windows Servers တွေ ခုနောက်ပိုင်း အသုံးများလာပါတယ်။ ဒီ system တွေ ပေါ်မှာ run တဲ့ Applications တွေကလည်း Java, C, C++, .Net, PHP, Python စတဲ့ programming languages အများကြီးသုံးလာကြပါတယ်။ Databases တွေကလည်း Oracle, MS SQL and MySQL စတဲ့ Database တွေ အသုံးများပါတယ်။ ခုနောက်ပိုင်း unstructured data တွေကို ထိန်းတဲ့ Mongo DB တို့ Cassandra DB တို့လည်း အသုံးများလာပါပြီ။ ဘယ် Platform (Operation System) ၊ ဘယ် Database သုံးမှာလဲ ဆိုတာ ကိုယ်သုံးမဲ့ Solution ပေါ်မှာမူတည်ပြီး အခြားသော Cost, Overall IT strategy, Regulatory Compliance စတဲ့ အချက်တွေပေါ်မှာလည်း အများကြီးပေါ်မှာ မူတည်ပါတယ်။
ဒီနေရာမှာ ဘဏ် IT အဖွဲ့အစည်း အနေနဲ့ နောက်တစ်ချက်က သတိပြုသင့်တာက ဘဏ်တစ်ခုဟာ Google တို့ Apple တို့လို ခေတ်ရှေ့ပြေး Technology company မဟုတ်လု့ိ ဘဏ်မှာနောက်ဆုံးပေါ် IT နည်းပညာ သုံးတိုင်း ကောင်းတာမဟုတ်ပါဘူး။ ဘဏ်မှာ ဘယ်နည်းပညာ သုံးတယ်၊ ဘယ်လိုမိုက်တယ်ဆိုတာ ဘယ် Customer ကမှ စိတ်မဝင်စားပါဘူး။ Customers တွေအတွက် အရေးကြီးတာက ဒီနည်းပညာရဲ့ ရလဒ်ဖြစ်တဲ့ ဘဏ်လုပ်ငန်း အသုံးပြုရာမှာ ပိုချောမောလာမယ်၊ ကြုံရတဲ့ အခက်အခဲတွေ နည်းပါးလာမယ်ဆိုရင် ဒီနည်းပညာဟာ တကယ်အကျိုးရှိမှာ ဖြစ်ပါတယ်။
IT system တွေတည်ဆောက်ရာမှာ Infrastructure နဲ့ ပတ်သက်ပြီး ဘဏ်တွေ ကြုံရမဲ့ အခက်အခဲတွေကတော့
(၁) အရင်းတုန်းက Infrastructure ပိုင်းမှာ ဒီ severs တွေ ဝယ်ရတာ တပ်ဆင်ရတာဟာ အလွန်အချိန်ကြာပါတယ်။ အထူးသဖြင့်ဘဏ်မှာသုံးတဲ့ server တွေ အကုန်လုံးဟာ security အရေးကြီးတာကြောင့် hardening လို့ခေါ်တဲ့ (sever တစ်ခုလုံး အဘက်ဘက်က လုံခြုံမှုရှိမရှိ စစ်ဆေးတဲ့ စနစ်) process တွေဖြတ်ရတာနဲ့ သေချာသုံးလို့ရတဲ့အဆင့်ကို ရောက်ဖို့ အချိန်အတော်ကြာပါတယ်။ နောက်ပိုင်း Virtual Machine (VM) concept ပေါ်လာတော့ အရင်ကလို applications အသစ်ဆင်ဖို့လိုမှ physical hardware တွေ order မှာသလို တိုက်ရိုက် တွဲစရာမလိုတော့ပါဘူး။ ဒါပေမဲ့ server နဲ့ application ကတော့ တွဲသတ်မှတ် (dedicated) ရတုန်းပါဘဲ။ Infra ကလိုသလို servers တွေကို အလျော့အတင်း လုပ်ဖို့လိုရင် sever down ဖို့လိုတာကြောင့် ထင်အဲလောက် flexible မဖြစ်ပါဘူး။
(၂) နောက်အခက်အခဲ တစ်ခုကတော့ Testing လုပ်ဖို့ Devlopment severs တွေကို အချိန်အကြာ setup လုပ်ရပြီး Testing ပြီးတဲ့ အခါ၊ အဲလို setup တစ်ပုံစံတည်းကို နောက်တစ်ကြိမ် Production လို့ခေါ်တဲ့ တကယ်သုံးမဲ့ severs တွေမှာ နောက်တခါထပ်ပြီး setup လုပ်ရပါတယ်။ ဒီနေရာမှာ ၂ ခါ အချိန်ကုန်ပြီး အကြောင်းမျိုးမျိုးကြောင့် configurations တွေမတူခဲ့ရင် Production မှာမလိုလားတဲ့ ပြဿနာတွေ ကြုံရပါတယ်။
(၃) ဘဏ်တွေမှာ သုံးတဲ့ IT systems တွေဟာ လူတွေရဲ့ ငွေကြေးနဲ့ပတ်သက်တဲ့ data တွေဖြစ်လို့ အလွန်အရေးကြီးပါတယ်။ အဲဒါကြောင့် ဘဏ်တွေဟာ သူ့ရဲ့ data တွေကို data center တစ်ခုမကဘဲ အနည်းဆုံး နေရာ ၂နေရာ ခွဲထားရပါတယ်။ (ဗဟိုဘဏ်ရဲ့ စည်းကမ်းထဲမှာလည်းပါပါတယ်။) အဲလိုခွဲထားမှ data center တစ်ခု မမျှော်လင့်တဲ့ အနေအထားကြောင့် ဆုံးရှုံးခဲ့ရင် နောက် data center တစ်ခုမှ Data Recovery (DR) လုပ်လို့ရမှာ ဖြစ်ပါတယ်။
ဒီလိုအခြေအနေကို ကြိုပြင်ဆင်တဲ့ အနေနဲ့ DR Exercise ဆိုပြီး မကြာ မကြာလုပ်ရပါတယ်။ ဒီနေရာမှာ Production site က severs တွေ down ပြီး DR site က servers တွေ bring up လုပ်ရပါတယ်။ ဒီအခါမှာ Production data နဲ့ DR data တွေဟာ မတူလို့၊ DR testing လုပ်တဲ့အခါ sever configurations, network configurations အနေအထာတွေကွဲလို့ DR applications တွေသေချာ အလုပ်မလုပ်တဲ့ အနေအထားတွေကြုံရပါတယ်။
လွန်ခဲ့တဲ့ ၁၀ နှစ်လောက်ကစပြီး Cloud Computing ရဲ့ IaaS (Infrastructure as a Service) နည်းပညာဟာ ခေတ်စားလာပြီး အထက်က အခက်အခဲတွေကို ဖြေရှင်းပေးနိင်မယ်လို့ ဘဏ်တွေက တဖြည်ဖြည်းလက်ခံလာကြပါတယ်။ အခြားသော PaaS (Platform as a Service) နဲ့ SaaS (Software as a Service) တွေကတော့ ဘဏ်တွေမှာ အသုံးနည်းပါတယ်။
IaaS Cloud Computing ဆိုတာ နားလည်အောင်ပြောရရင် ကိုယ်သုံးတဲ့ severs ဟာ ဘယ် computer လဲဆိုတာ အတိအကျလက်ညိုးထိုးပြလို့မရဘဲ "Cloud" (တိမ်ဆန်ဆန်) Availability Zone နေရာတစ်ခုမှာရှိတယ်လို့ဘဲ ပြောလို့ရပါတယ်။ ဒီသဘောတရားဟာ physical servers တွေနဲ့ သူ့အပေါ်မှာတင်သုံးတဲ့ Applications တွေကို လုံးဝ ခွဲခြားလိုက်တယ်လို့ ပြောလို့ရပါတယ်။ ဥပမာ အရင်တုန်းက ဒီ Application အတွက် sever A နဲ့ server B ဆိုပြီး သုံးဖို့ပေးထားတယ်။ အဲ sever ၂ လုံးဟာ ဒီ Application အတွက်ဘဲရည်ရွယ်တယ် ဆိုင်တယ်ပေါ့။ သူတု့ိပျက်ရင် ဒီ Application down သွားမယ်ဆိုတာ သိသာပါတယ်။
Cloud computing မှာတော့ ဒီ Application ဟာ server ပေါင်း မြောက်မြားစွာထဲ က ၂ လုံးပေါ်မှာရှိပြီး၊ ဘယ် ၂ လုံးလည်းဆိုတာတော့ ပြောရခက်ပါတယ်။ လောလောဆယ်သုံးနေတဲ့ sever ၂ လုံးပျက်သွားရင် အခြား severs ကို auto ကူသွားလို့ Application down တယ်ဆိုတာ မဖြစ်တော့ပါဘူး။
ဘဏ်အတော်များများဟာ Cloud Computing ရဲ့ အကျိုးကို သိပေမဲ့ Customer data တွေဟာ အရမ်းကိုအရေးကြီး လျှို့ဝှက်တော့ အများသုံး Public Cloud တွေဖြစ်တဲ့ Amazon AWS, Google Cloud, Microsoft Azure စတဲ့ services တွေကို သုံးဖို့ security risk များလို့ စိတ်မဝင်စားပါဘူး။ အဲဒါကြောင့် ဘဏ်အတော်များများဟာ Private Cloud လို့ခေါ်တဲ့ သူတို့အတွက် သပ်သပ်တည်ဆောက်ထားတဲ့ Virtual Private Cloud (VPC) services တွေဘဲ သုံးတာများပါတယ်။ VPC ကတော့ အထက်က အခက်အခဲတွေကို ခုလိုဖြေရှင်းပေးပါတယ်။
(၁) Cloud Computing သဘောအရ servers တွေဟာ အချိန်တိုအတွင်းမှာ အသစ်ဖန်းတီးနိုင်ပြီး မလိုအပ်ရင်လည်း ချက်ချင်းဖယ်ပစ်နိုင်ပါတယ်။ ဥပမာ ပြောရရင် VPC ဟာလည်း လိုသလို size စုံခွဲခြမ်းစိတ်ဖြာလို့ရတဲ့ မုန့်လုပ်တဲ့ ဂျုံတုံးကြီးနဲ့တူပါတယ်။ မုန့်အသေးလုပ်ဖို့လိုရင် အသေးတုံးလေးတေ ခွဲပေးလို့ရသလို မုန့်အကြီးကြီးလုပ်ဖို့လိုရင် အကြီးတုံးပေးလို့ရပါတယ်။ ဝိုင်းသုံးနေတဲ့ ဂျုံတုံးကြီးလျော့လာရင် ဂျုံတုံးအသစ်ထပ် ပေါင်းလိုက်ရုံဘဲ။ မလိုရင် ပိုနေတဲ့ ဂျုံတွေကို အရင်အတုံးမှာ ပြန်ပေါင်းလိုက်ပြီး အခြားလိုတဲ့ဘက်ကို ပါသွားမှာ ဖြစ်ပါတယ်။ အဓိက သဘောတရားက ဒီအပိုင်း (sever) ကမှ သူ့အတွက်၊ ဟိုအပိုင်း (another sever)ကမှ ကိုယ့်အတွက် ဆိုတဲ့ သတ်မှတ်ချက် (dedication) မရှိတော့ပါဘူး။ အရင်တုန်းက လနဲ့ချီပြီး တပ်စင်ရတဲ့ severs တွေဟာ ရှိပြီးသားဖြစ်လို့ VPC မှာ နာရီပိုင်းအတွင်း provision လုပ်လို့ရပါတယ်။
(၂) VPC မှာ Application တစ်ခုကို လိုချင်သလို Setup လုပ်ပြီး သူ့ကို ထပ်ငုံထားတဲ့ operating system (OS) ကိုပါ သေတ္တာတစ်လုံးလို ကိုင်တွယ်တဲ့ Dockers တို့ Kubernetes တို့စတဲ့ container (သေတ္တာ) စနစ်နဲ့ ရှိပါတယ်။ အဲဒီတော့ Application တစ်ခုလိုအပ်တဲ့ configurations တွေသေချာလုပ်ပြီးရင် အဲဒီ server container (သေတ္တာ) တစ်ခုလုံးကို မိနစ်ပိုင်းအတွင်း ကူး(clone)လို့ရလို့ testing ပြီးထားတဲ့ container တစ်ခုကို production မှာ ထပ် configurations လုပ်စရာ မလိုဘဲ တန်းသုံးလို့ရပါတယ်။ ဒါကြောင့် အရင်ကလို Test sever မှာ တစ်ခါ၊ production မှာတစ်ခါ၊ ၂ခါ setup လုပ်စရာ မလိုတော့ပါဘူး။
(၃) Cloud Computing မှာ Availability Zone (AZ) လို့ခေါ်တဲ့ servers တွေထားတဲ့ နေရာတွေ Geographical locations အရခွဲထားပါတယ်။ (ဥပမာ တစ်ခုက Yangon မှာ အောက်မြန်မာပြည်အတွက် တစ်ခု၊ Mandalay ကတော့ အထက်မြန်မာပြည်အတွက် စသည်ဖြင့်) အဲဒီတော့ Production AZ site က data တွေကို Data Recovery AZ site သို့ Data replication ဆိုတဲ့ စွမ်းဆောင်ချက်နဲ့ auto ပြောင်းတဲ့ စနစ်ကြောင့် DR testing လုပ်တဲ့အခါ configuration မတူလို့ ဖြစ်တဲ့ ပြဿနာတွေ အလွန်နည်းပါးသွားပါတယ်။
ဘဏ်မဟုတ်တဲ့ အပြင်လုပ်ငန်းတွေမှာတော့ Cloud Computing ရဲ့ IaaS ဟာ Data Center တစ်ခု တည်ဆောက်စရာမလိုဘဲ လိုသလောက်သုံး သုံးသလောက်ပေး ဆိုတဲ့ (Pay-per-use) စနစ်ကြောင့် ခုနောက်ပိုင်း IT Solutions တွေ အများဆုံး သုံးတဲ့စနစ်ဖြစ်လာပါပြီ။
Credit
technologies
