ချိတ်ဆက်ထားသော ထုတ်ကုန်များကို အတိုင်းအတာတစ်ခုအထိ- ပလက်ဖောင်းအလွှာသည် သင်၏ အကြီးမားဆုံး အင်ဂျင်နီယာပိုင်ဆိုင်မှု သို့မဟုတ် တာဝန်ယူမှု ဖြစ်လာရသည့် အကြောင်းရင်း

ချိတ်ဆက်ထားသော ထုတ်ကုန်တစ်ခုသည် ၎င်းနှင့်ပတ်သက်သည့် အင်ဂျင်နီယာပိုင်းဆိုင်ရာများ မပြီးပြတ်မီ အချိန်အတော်ကြာအောင် ပြီးစီးသွားပုံပေါ်နိုင်သည်။ ပုံစံငယ်သည် တည်ငြိမ်ပြီး ဒေတာများသည် cloud သို့ ရောက်ရှိကာ အက်ပ်သည် မှန်ကန်သောတန်ဖိုးများကို ပြသပြီး ပထမအသုတ် စက်ပစ္စည်းများသည် အသုံးပြုသူများ၏ လက်ထဲတွင် ရှိနှင့်ပြီးဖြစ်သည်။ ထိုအချိန်တွင် အဖွဲ့သည် စက်ပစ္စည်းတိုင်းကို တစ်ဦးချင်းစီ သိရှိနိုင်လောက်အောင် backend သည် ရိုးရှင်းနေနိုင်သေးသည်။ ပံ့ပိုးပေးခြင်းကို script ဖြင့် ကိုင်တွယ်နိုင်ပြီး၊ configuration ပြောင်းလဲမှုများကို ကိုယ်တိုင်ပြုလုပ်နိုင်ပြီး တစ်စုံတစ်ခု ပျက်ကွက်ပါက အင်ဂျင်နီယာတစ်ဦးသည် ပြဿနာကို တိုက်ရိုက်ခြေရာခံနိုင်သည်။

ထို့နောက် ၎င်းသည် လက်တွေ့ကမ္ဘာတွင် စတင်နေထိုင်ရမည်ဖြစ်သည်။ ဒုတိယအကြိမ် ဟာ့ဒ်ဝဲပြင်ဆင်မှုတစ်ခု ပေါ်လာသည်။ အချို့ဖောက်သည်များသည် ပထမပြင်ဆင်မှုကို အသုံးပြုနေကြဆဲဖြစ်သည်။ Firmware ဗားရှင်းများ ကွဲပြားလာပါသည်။ မတူညီသောဖောက်သည် သို့မဟုတ် ဈေးကွက်အတွက် ပြင်ဆင်မှုအသစ်တစ်ခု လိုအပ်သော်လည်း၊ စက်ပစ္စည်းဟောင်းများသည် အပ်ဒိတ်များနှင့် ပံ့ပိုးမှုများ လိုအပ်နေဆဲဖြစ်သည်။

ဘာမှ ပျက်ယွင်းနေတာမျိုး မရှိပါဘူး။ စက်ပစ္စည်းရဲ့ နောက်ကွယ်က ဆော့ဖ်ဝဲဟာ သူ့ရဲ့ကိုယ်ပိုင် သက်တမ်းစက်ဝန်းကို ရရှိသွားပါပြီ။

အဲဒီအကူးအပြောင်းက လွတ်သွားလွယ်ပါတယ်၊ ဘာလို့လဲဆိုတော့ prototype က ကောင်းကောင်းအလုပ်လုပ်နိုင်လို့ပါ။ ဒါပေမယ့် တူညီတဲ့ physical product ရဲ့ version အများအပြားကို field မှာ အတူတွဲအသုံးပြုရတဲ့အခါ backend က hardware ရဲ့ infrastructure သက်သက် မဟုတ်တော့ပါဘူး။ product architecture ရဲ့ အစိတ်အပိုင်းတစ်ခု ဖြစ်လာပါတယ်။

အလုပ်လုပ်နိုင်သော ချိတ်ဆက်ထားသော prototype သည် တိုးချဲ့နိုင်သော ထုတ်ကုန်တစ်ခု မဟုတ်သေးပါ။

ပုံစံငယ်တစ်ခုတွင် အရေးကြီးသောအလုပ်တစ်ခုရှိသည်- စနစ်သည် အဆုံးမှအဆုံးအလုပ်လုပ်ကြောင်း သက်သေပြပါ။ စက်ပစ္စည်းသည် ၎င်း၏အဓိကလုပ်ဆောင်ချက်ကို လုပ်ဆောင်သည်၊ firmware သည် backend နှင့် ဆက်သွယ်သည်၊ telemetry သည် ၎င်းလိုအပ်သည့်နေရာသို့ ရောက်ရှိသည်၊ command များသည် ပြန်လာသည့်ခရီးစဉ်ကို ပြုလုပ်သည်၊ နှင့် မိုဘိုင်း သို့မဟုတ် ဝဘ် interface သည် လုပ်ဆောင်နိုင်စွမ်းကို အသုံးပြုသူထံ ဖော်ထုတ်ပေးသည်။

၎င်းက များသောအားဖြင့် သက်သေမပြနိုင်ခဲ့သည်မှာ တူညီသောစနစ်သည် ကွဲပြားမှုကို မည်မျှကောင်းမွန်စွာ ကိုင်တွယ်ဖြေရှင်းသည်ဆိုသည့်အချက်ဖြစ်သည်။

ပထမဆုံး စက်ပစ္စည်း နှစ်ဆယ်စလုံးသည် တူညီသော firmware ကို အသုံးပြုနိုင်ပြီး၊ တူညီသော hardware ပြင်ဆင်မှုတွင် တည်ဆောက်နိုင်ပြီး၊ တူညီသော အင်ဂျင်နီယာများမှ configure လုပ်နိုင်သည်။ ထိုအဆင့်တွင်၊ manual registration၊ တိုက်ရိုက် configuration ပြောင်းလဲမှုများ သို့မဟုတ် onboarding script ငယ်တစ်ခုသည် လုံးဝကျိုးကြောင်းဆီလျော်နိုင်ပါသည်။ ထုတ်ကုန်သည် ၎င်းကိုယ်တိုင် သက်သေပြနိုင်ခြင်းမပြုမီ ထုတ်လုပ်မှုအဆင့် tooling များကို တည်ဆောက်ခြင်းသည် စောလွန်းနေနိုင်သည်။

စကေးသည် ပြဿနာကို ပြောင်းလဲစေသည်။ စက်ပစ္စည်းများသည် အော့ဖ်လိုင်းဖြစ်နေပြီး၊ အစားထိုးခံရပြီး၊ မတူညီသော firmware ကို အသုံးပြုကာ မတူညီသော ဖောက်သည်များ၏ ပြင်ဆင်သတ်မှတ်မှုများ လိုအပ်ပါသည်။ ပံ့ပိုးမှုသည် မှန်ကန်စွာ ပံ့ပိုးပေးခြင်း မရှိသော ယူနစ်တစ်ခုနှင့် မှားယွင်းစွာ ပြင်ဆင်သတ်မှတ်ခြင်း သို့မဟုတ် အလွယ်တကူ ဆက်သွယ်၍မရသော ယူနစ်ကို ခွဲခြားသိမြင်ရန် လိုအပ်ပါသည်။

ပုံစံငယ်အကြွေးသည် မကြာခဏ ဤနည်းဖြင့် စတင်လေ့ရှိသည်- မှားယွင်းသော ဆုံးဖြတ်ချက်ဖြင့် မဟုတ်ဘဲ ထုတ်ကုန် ရွေ့လျားပြီးနောက်တွင် တည်ရှိနေသော ယာယီဆုံးဖြတ်ချက်ဖြင့် စတင်လေ့ရှိသည်။ ထိုအသွင်ကူးပြောင်းမှုကို မြင်တွေ့ရန် အတင်းအကျပ် တွန်းအားပေးသည့် ပထမဆုံးအရာများထဲမှ တစ်ခုမှာ ဟာ့ဒ်ဝဲကိုယ်တိုင်ဖြစ်သည်။ ပြင်ဆင်မှုအသစ်သည် အဟောင်းကို အစားထိုးရုံသာမက ၎င်းနှင့်အတူ အတူယှဉ်တွဲတည်ရှိရမည်။

ဟာ့ဒ်ဝဲပြင်ဆင်မှုတိုင်းသည် ဆော့ဖ်ဝဲသက်တမ်းစက်ဝန်းပြဿနာကို ဖန်တီးပေးသည်

ဟာ့ဒ်ဝဲပြင်ဆင်မှုအသစ်တစ်ခုသည် အဟောင်းကို သန့်ရှင်းစွာအစားထိုးရန် ရှားရှားပါးပါးသာ ရောက်ရှိလာလေ့ရှိသည်။ လက်တွေ့တွင် ဗားရှင်းနှစ်ခုစလုံးသည် လက်တွေ့တွင် ရှိနေတတ်ပြီး တစ်ခါတစ်ရံတွင် နှစ်ပေါင်းများစွာ ရှိနေသည်။ အကူးအပြောင်းအသုတ်တစ်ခု၊ firmware ဌာနခွဲအနည်းငယ်နှင့် ဖောက်သည်တစ်ဦးချင်းစီအတွက် သီးသန့်ဖွဲ့စည်းမှုများ ထည့်သွင်းလိုက်သောအခါ၊ အစုအဖွဲ့သည် မူရင်းထုတ်ကုန်မော်ဒယ်က အကြံပြုထားသည်ထက် ပိုမိုကွဲပြားလာပါသည်။

ဆော့ဖ်ဝဲလ်အလွှာသည် ယူနစ်တိုင်းကို መልእክት “ကိရိယာ” တစ်ခုအဖြစ် မသတ်မှတ်နိုင်တော့ပါ။ ၎င်းတွင် ထိုယူနစ်တစ်ခုသည် ဘာလုပ်နိုင်သည်ကို သိရှိရန် လိုအပ်ပါသည်။

ပြန်လည်ပြင်ဆင်ထားသော board သည် မတူညီသော sensor၊ ဆက်သွယ်ရေး module သို့မဟုတ် controller ကို အသုံးပြုနိုင်သည်။ နောက်ဆုံးထွက် version အတွက် အကျုံးဝင်သော command ကို ယခင် version မှ support မလုပ်နိုင်ပါ။ Calibration တန်ဖိုးများ ပြောင်းလဲနိုင်သည်။ Configuration ကန့်သတ်ချက်များ ပြောင်းလဲနိုင်သည်။ မျိုးဆက်တစ်ခုအတွက် သင့်လျော်သော firmware package သည် အခြားမျိုးဆက်တစ်ခုအတွက် မလုံခြုံပါ။

ရုပ်ပိုင်းဆိုင်ရာ ထုတ်ကုန်အင်ဂျင်နီယာများသည် ဤနည်းအတိုင်း လုပ်ဆောင်နေကြပြီဖြစ်သည်။ တူညီလုနီးပါးပုံပေါက်သော အစိတ်အပိုင်းနှစ်ခုသည် ၎င်းတို့၏ ပြင်ဆင်မှုများ၊ ခံနိုင်ရည်များ သို့မဟုတ် သတ်မှတ်ချက်များ ကွဲပြားပါက အပြန်အလှန်လဲလှယ်၍မရပါ။ ချိတ်ဆက်ထားသော ထုတ်ကုန်များသည် ဆော့ဖ်ဝဲလ်ဘက်တွင် တူညီသောပြဿနာကို ဖန်တီးပေးသည်- ပလက်ဖောင်းသည် ၎င်းပြောဆိုနေသော ရုပ်ပိုင်းဆိုင်ရာ ထုတ်ကုန်၏ မည်သည့်ဗားရှင်းနှင့် သက်ဆိုင်သည်နှင့် မည်သည့်စည်းမျဉ်းများ သက်ရောက်သည်ကို နားလည်ရန် ယုံကြည်စိတ်ချရသော နည်းလမ်းတစ်ခု လိုအပ်ပါသည်။

ပထမအကြိမ်ပြင်ဆင်မှုတွင် ချိန်ညှိမှုလုပ်ငန်းစဉ်တစ်ခုကို အသုံးပြုပြီး ဒုတိယအကြိမ်ပြင်ဆင်မှုတွင် အာရုံခံကိရိယာအသစ်နှင့် မတူညီသော ကန့်သတ်ချက်အစုံကို မိတ်ဆက်ပေးသည့် ထုတ်ကုန်တစ်ခုကို စဉ်းစားကြည့်ပါ။ ဖောက်သည်အတွက် ယူနစ်နှစ်ခုစလုံးသည် ထုတ်ကုန်တစ်ခုတည်းသာ ဖြစ်နိုင်သည်။ ပလက်ဖောင်းအတွက်မူ ၎င်းတို့သည် အတူတူပင် မဖြစ်နိုင်ပါ။

ထိုကွာခြားချက်များကို ရှင်းလင်းစွာ မဖော်ပြပါက၊ ၎င်းတို့သည် အထူးကိစ္စရပ်များအဖြစ် အပလီကေးရှင်းယုတ္တိဗေဒထဲသို့ စိမ့်ဝင်သွားလေ့ရှိသည်။ လုပ်ငန်းစဉ်တစ်ခုသည် serial-number အပိုင်းအခြားကို စစ်ဆေးသည်။ နောက်တစ်ခုသည် hardware ထုတ်လုပ်ရန်အတွက် firmware ဗားရှင်းကို proxy အဖြစ် အသုံးပြုသည်။ တတိယတစ်ခုတွင် ပံ့ပိုးမှုက လယ်ကွင်းတွင် မတူညီသော လုပ်ဆောင်ချက်များရှိသော အဟောင်းအသုတ်တစ်ခုကို ရှာဖွေတွေ့ရှိပြီးနောက် ထည့်သွင်းထားသော exception ပါဝင်သည်။ ဤပြင်ဆင်မှုများထဲမှ တစ်ခုမျှ သီးခြားစီတွင် အထူးအန္တရာယ်များပုံမပေါ်သော်လည်း ၎င်းတို့ပေါင်းစပ်ခြင်းဖြင့် အနာဂတ်ပြောင်းလဲမှုတိုင်းကို ဆင်ခြင်ရန် ပိုမိုခက်ခဲစေသည်။

ဟာ့ဒ်ဝဲအဟောင်းများသည် အချိန်ဇယားအတိုင်း ပျောက်ကွယ်သွားခဲသည်။ ထုတ်ကုန်အဖွဲ့များသည် သဘာဝအတိုင်း အသစ်ဆုံးပြင်ဆင်မှုကို အာရုံစိုက်လေ့ရှိပြီး ဖောက်သည်များသည် အစောပိုင်းဗားရှင်းများကို မျှော်လင့်ထားသည်ထက် များစွာပိုကြာအောင် သိမ်းဆည်းထားလေ့ရှိသည်။ ထို့ကြောင့် ထည့်သွင်းထားသော အခြေခံသည် လက်ရှိအခြေအနေတစ်ခုတည်းတွင် ပေါင်းစည်းသွားလိမ့်မည်ဟု ယူဆမည့်အစား ပလက်ဖောင်းသည် မျိုးဆက်များစွာကို တစ်ပြိုင်နက်တည်း ပံ့ပိုးပေးရန် လိုအပ်ပါသည်။

အဲဒါဖြစ်လာတာနဲ့ hardware ဆင့်ကဲဖြစ်စဉ်နဲ့ software lifecycle management တို့ဟာ ခွဲခြားလို့မရတော့ပါဘူး။ platform အနေနဲ့ device တစ်ခုဘယ်မှာရှိလဲ၊ online ရှိမရှိကိုသာမက ဘာလဲဆိုတာ၊ ဘာတွေလည်ပတ်နိုင်လဲ၊ ဘယ်လို configure လုပ်သင့်လဲ၊ ဘယ်ပြောင်းလဲမှုတွေကို ဘေးကင်းစွာအသုံးချနိုင်လဲဆိုတာကိုပါ သိရှိဖို့ လိုအပ်ပါတယ်။

ထိုမေးခွန်းများထဲမှ တစ်ခုခုကို ယုံကြည်စိတ်ချစွာ ဖြေဆိုနိုင်မီ၊ စက်ပစ္စည်းတစ်ခုစီသည် စနစ်ထဲသို့ တသမတ်တည်း ဝင်ရောက်ရမည်။

Provisioning သည် manual engineering သည် scaling ကို ရပ်တန့်စေသည့်နေရာဖြစ်သည်

fleet သေးငယ်သည့်အခါ provisioning သည် ရိုးရှင်းပုံရသည်- device မှတ်တမ်းတစ်ခု ဖန်တီးပါ၊ serial number တစ်ခု ရိုက်ထည့်ပါ၊ credentials များကို generate လုပ်ပါ၊ unit ကို customer ထံ ခွဲဝေပေးပါ၊ configuration တစ်ခု အသုံးချပါ၊ ထို့နောက် ဆက်လက်လုပ်ဆောင်ပါ။ device အနည်းငယ်အတွက်၊ ဤအရာများထဲမှ အချို့ကို ကိုယ်တိုင်ကိုင်တွယ်ခြင်းသည် မှန်ကန်သောရွေးချယ်မှု ဖြစ်နိုင်သည်။

သို့သော် ထုတ်လုပ်မှုအတိုင်းအတာတွင်၊ ပံ့ပိုးပေးခြင်းသည် device identity၊ credentials၊ ownership၊ configuration နှင့် lifecycle state တို့၏ ဆုံမှတ်တွင် တည်ရှိသည်။ onboarding လုပ်စဉ် အမှားတစ်ခုသည် unit ကို စက်ရုံမှ ထွက်ခွာပြီးနောက် အချိန်ကြာမြင့်စွာ လည်ပတ်ပုံနှင့် ပံ့ပိုးပုံကို ထိခိုက်နိုင်သည်။

spreadsheet တစ်ခုသည် အမှန်တကယ်ထည့်သွင်းထားသည့်အရာနှင့် ကိုက်ညီတော့မည်မဟုတ်ပါ။ အစားထိုးကိရိယာတစ်ခုသည် မှားယွင်းသောအထောက်အထားကို အမွေဆက်ခံခြင်းမရှိဘဲ မှန်ကန်သောဖောက်သည်ဆက်စပ်မှု လိုအပ်ပါသည်။ Factory reset လုပ်ခြင်းသည် လုပ်ငန်းစဉ်တစ်လျှောက် အခြားလမ်းကြောင်းတစ်ခုကို ဖန်တီးပေးသည်။ installer သည် unit တစ်ခုကို မှားယွင်းသောအကောင့်သို့ သတ်မှတ်နိုင်ပြီး ၎င်းသည် အော့ဖ်လိုင်းဖြစ်နေသလား၊ မှားယွင်းစွာပံ့ပိုးပေးထားခြင်း သို့မဟုတ် မှားယွင်းသော configuration ကို သယ်ဆောင်ထားခြင်းရှိမရှိ support ကို ဆုံးဖြတ်ရန်ထားခဲ့နိုင်သည်။

ထိုမေးခွန်းများကို ဖြေဆိုရန် developer သည် database တစ်ခုကို စစ်ဆေးရန် သို့မဟုတ် internal script တစ်ခုကို run ရန် ပုံမှန်လိုအပ်သည်နှင့်တစ်ပြိုင်နက်၊ လုပ်ငန်းစဉ်သည် product နှင့်အတူ scaling ရပ်တန့်သွားပါပြီ။

ထပ်တူကျခြင်းသည် နောက်ထပ်သတိပေးလက္ခဏာတစ်ခုဖြစ်သည်။ ထုတ်ကုန်မျိုးကွဲတစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင် onboarding script၊ configuration tool သို့မဟုတ် installer workflow ကို စတင်ရယူသည်။ ထိုကွာခြားချက်များသည် သေးငယ်ပုံရသော်လည်း အခြေခံတာဝန်မှာ အတူတူပင်ဖြစ်သည်။ Provisioning သည် သတ်မှတ်ထားသော device တစ်ခုနှင့် တွဲထားသော setup task ထက် ပြန်လည်အသုံးပြုနိုင်သော platform infrastructure ဖြစ်လာသည်။

၎င်းသည် ပြန်လည်အသုံးပြုနိုင်ရန် လိုအပ်သည့် တစ်ခုတည်းသော စွမ်းရည် ရှားပါးပါသည်။

ပလက်ဖောင်းအလွှာသည် ပြန်လည်အသုံးပြုနိုင်သော အခြေခံအဆောက်အအုံ ဖြစ်လာသင့်သည်

ထုတ်ကုန်များစွာ သို့မဟုတ် ဟာ့ဒ်ဝဲပြင်ဆင်မှုများသည် အခြေခံလိုအပ်ချက်များ တူညီသည်နှင့်တစ်ပြိုင်နက်၊ အချို့သောဆော့ဖ်ဝဲစွမ်းရည်များသည် ထုတ်ကုန်တစ်ခုချင်းစီအတွက် သီးသန့်မဟုတ်တော့ပါ။ စက်ပစ္စည်းအထောက်အထား၊ ပံ့ပိုးပေးခြင်း၊ ချိတ်ဆက်မှု၊ telemetry၊ firmware ပေးပို့မှု၊ သက်တမ်းစက်ဝန်းအခြေအနေ၊ fleet မြင်နိုင်စွမ်းနှင့် ရောဂါရှာဖွေခြင်းတို့သည် ကောင်းမွန်သော ဥပမာများဖြစ်သည်။ မျိုးကွဲအသစ်တိုင်းအတွက် ၎င်းတို့ကို ပြန်လည်တည်ဆောက်ခြင်းသည် ထုတ်ကုန်ကိုယ်တိုင်ကို ပိုမိုထူးခြားစေခြင်းမရှိစေဘဲ ထိန်းသိမ်းရန် ကုဒ်ပိုမိုများပြားပြီး လည်ပတ်မှုလမ်းကြောင်းများ ပိုမိုဖန်တီးပေးသည်။

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

ပိုမိုရှင်းလင်းသော နယ်နိမိတ်မှာ product layer ကို platform layer မှ ခွဲထုတ်ရန်ဖြစ်သည်။ product layer တွင် device တစ်ခုကို အဖိုးတန်စေသည့် behavior၊ workflows၊ interfaces၊ integrations နှင့် domain logic များ ပါဝင်သည်။ platform layer သည် hardware ပြောင်းလဲသွားသည့်တိုင် တသမတ်တည်းရှိနေသင့်သည့် mechanics များကို ကိုင်တွယ်သည်။

ချိတ်ဆက်ထားသော ထုတ်ကုန်များသည် ၎င်းတို့၏ ပထမဆုံးထုတ်ဝေမှုထက် ကျော်လွန်လာသည်နှင့်အမျှ စက်ပစ္စည်းပံ့ပိုးပေးခြင်း၊ စက်ပစ္စည်းသက်တမ်းစီမံခန့်ခွဲမှု၊ ယာဉ်စုစီမံခန့်ခွဲမှုနှင့် ပံ့ပိုးမှုကိရိယာများသည် တစ်ကြိမ်တည်းသော ပရောဂျက်အသေးစိတ်အချက်အလက်များထက် မျှဝေထားသော အခြေခံအဆောက်အအုံဖြစ်လာသည်။ စီးပွားရေးလုပ်ငန်းများအတွက် IoT PaaS သည် ထုတ်ကုန်များစွာ သို့မဟုတ် ထုတ်ကုန်မျိုးကွဲများတွင် ပြန်လည်အသုံးပြုနိုင်သော ပလက်ဖောင်းအလွှာကို ပံ့ပိုးပေးနိုင်ပြီး၊ စံစက်ပစ္စည်းနှင့် အချက်အလက်စီမံခန့်ခွဲမှုကို ပြန်လည်အသုံးပြုနိုင်သော အဆောက်အဦအုတ်များမှတစ်ဆင့် ကိုင်တွယ်နိုင်သော်လည်း အင်ဂျင်နီယာအဖွဲ့များသည် ၎င်းတို့၏ စိတ်ကြိုက်ကြိုးပမ်းအားထုတ်မှုကို ဟာ့ဒ်ဝဲ၊ လုပ်ငန်းစဉ်များနှင့် အသုံးပြုသူအတွေ့အကြုံများကို အာရုံစိုက်ထားသည်။

အခြေခံအုတ်မြစ်တစ်ခုသည် ထုတ်ကုန်၏ ကွဲပြားမှုများအတွက် နေရာချန်ထားရန် လိုအပ်နေဆဲဖြစ်သည်။ စက်ပစ္စည်းအသစ်တစ်ခုသည် မတူညီသော ဒေတာမော်ဒယ်၊ ဖွဲ့စည်းမှုစီးဆင်းမှု၊ ပေါင်းစပ်မှု သို့မဟုတ် ထိန်းချုပ်မှုယုတ္တိဗေဒ လိုအပ်နိုင်ပြီး ထိုကွဲပြားမှုများကို မိတ်ဆက်ပေးရန် လွယ်ကူသင့်သည်။ ရည်မှန်းချက်မှာ အခြားစက်ပစ္စည်းမှတ်ပုံတင်ခြင်း၊ telemetry pipeline၊ provisioning mechanism သို့မဟုတ် fleet-management tools အစုံတစ်လျှောက် ကွဲပြားမှုတိုင်းကို ဆွဲယူခြင်းမှ ရှောင်ရှားရန်ဖြစ်သည်။

အဖွဲ့သည် ပထမဆုံးထုတ်ကုန်ကို တည်ဆောက်နေစဉ်တွင် ပလက်ဖောင်းသည် အပေါ်ယံကဲ့သို့ ထင်ရပြီး ဒုတိယ သို့မဟုတ် တတိယတွင် ပိုင်ဆိုင်မှုတစ်ခုကဲ့သို့ ထင်ရနိုင်သည်။ ဘုံလည်ပတ်မှုယန္တရားများ နေရာတကျဖြစ်လာသည်နှင့်၊ မျိုးကွဲအသစ်တစ်ခုသည် အဖွဲ့သည် ထိုထုတ်ကုန်၏ ကျန်ရှိသောသက်တမ်းအတွက် ထိန်းသိမ်းရမည့် အခြား backend တစ်ခုဖြင့် ရောက်ရှိလာမည့်အစား အလုပ်လုပ်သော အခြေခံအုတ်မြစ်ကို အမွေဆက်ခံနိုင်သည်။

ထုတ်ကုန်က တကယ်ကွဲပြားတဲ့နေရာမှာ စိတ်ကြိုက်အင်ဂျင်နီယာပညာကို ထိန်းသိမ်းထားပါ

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

Custom effort တွေဟာ device behavior, domain-specific logic, workflows, user experience, specialized integrations နဲ့ product တစ်ခုဟာ physical world နဲ့ interact လုပ်ပုံတွေမှာ ပါဝင်နေဆဲပါ။ ဒါတွေက engineering choices တွေက product တစ်ခုကို တခြား product တစ်ခုထက် အဓိပ္ပါယ်ရှိရှိ ပိုကောင်းအောင် လုပ်နိုင်တဲ့ နယ်ပယ်တွေပါပဲ။

ရှားရှားပါးပါးပဲ အလားတူ ဆက်ဆံမှုမျိုး ထိုက်တန်တာတော့ ပတ်ဝန်းကျင်က လည်ပတ်မှုပိုက်လိုင်းတွေပါပဲ။ တူညီတဲ့ စက်ရဲ့ အခြေခံဗားရှင်းနဲ့ စက်မှုလုပ်ငန်းသုံး ဗားရှင်းဟာ အာရုံခံကိရိယာတွေ၊ ထိန်းချုပ်ကိရိယာတွေနဲ့ အင်တာဖေ့စ်တွေ မတူညီနိုင်ပေမယ့် စက်ပစ္စည်းတွေကို ခွဲခြားသတ်မှတ်ဖို့၊ firmware ဗားရှင်းတွေကို ခြေရာခံဖို့ ဒါမှမဟုတ် fleet တစ်ခုကို စီမံခန့်ခွဲဖို့ သီးခြားနည်းလမ်းတွေ မလိုအပ်သင့်ပါဘူး။

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

အဖွဲ့က ဒုတိယထုတ်ကုန်ကို စတင်လိုက်တဲ့အခါ တကယ့်စမ်းသပ်မှု ရောက်ရှိလာပါတယ်။

ကောင်းမွန်သော ပလက်ဖောင်းတစ်ခုသည် ပထမထုတ်ကုန်ထက် နောက်ထုတ်ကုန်ကို ပိုမိုလွယ်ကူစေသည်

ထုတ်ကုန်နံပါတ်နှစ်သည် ထုတ်ကုန်နံပါတ်တစ်နှင့် အတူတူပင် ပလက်ဖောင်းလုပ်ငန်း လိုအပ်ပါက အမှန်တကယ် ပြန်လည်အသုံးပြုခဲ့သည်မှာ အလွန်နည်းပါးပါသည်။

မူကွဲအသစ်တစ်ခုသည် မပြောင်းလဲသေးသော လည်ပတ်မှုပုံစံ၏ အစိတ်အပိုင်းများဖြစ်သည့် ပံ့ပိုးပေးခြင်းစီးဆင်းမှုများ၊ အထောက်အထား၊ သက်တမ်းစက်ဝန်းယန္တရားများ၊ fleet tools များ၊ firmware လုပ်ငန်းစဉ်များ၊ ပံ့ပိုးမှုမြင်သာမှုနှင့် ဘုံပေါင်းစပ်မှုများတို့ကို အမွေဆက်ခံနိုင်သင့်သည်။ ထို့နောက် အင်ဂျင်နီယာအားထုတ်မှုသည် အခြေခံကို ပြန်လည်တည်ဆောက်မည့်အစား ကွဲပြားခြားနားမှုများ — ဖြစ်နိုင်သည်မှာ sensor package အသစ်၊ အခြားထိန်းချုပ်မှုလုပ်ငန်းစဉ် သို့မဟုတ် ဖောက်သည်သီးသန့်ပေါင်းစပ်မှု — ထဲသို့ ဝင်ရောက်သွားသည်။

ဟာ့ဒ်ဝဲမျိုးဆက်သစ်တစ်ခုက တူညီတဲ့အတွေးအခေါ်ကို ပိုပြီးဖိအားပေးစေပါတယ်။ ယူနစ်ဟောင်းတွေက လက်တွေ့မှာ တက်ကြွနေပေမယ့် ၎င်းရဲ့စွမ်းရည်တွေက သိသိသာသာပြောင်းလဲသွားနိုင်ပါတယ်။ ဖောက်သည်တွေက တစ်ခုတည်းသော ထုတ်ကုန်မိသားစုအဖြစ် မြင်ယောင်နေတဲ့အတွက် အဖွဲ့အနေနဲ့ သီးခြားပလက်ဖောင်း stack နှစ်ခုကို ထိန်းသိမ်းဖို့ ဖိအားမပေးဘဲ ရင့်ကျက်တဲ့ပလက်ဖောင်းတစ်ခုက နှစ်ခုလုံးကို ပံ့ပိုးပေးနိုင်ပါတယ်။

ဤအရာများထဲမှ တစ်ခုမျှ တစ်ခုတည်းသော monolithic backend မလိုအပ်ပါ။ မတူညီသော ထုတ်ကုန်များသည် ရှင်းလင်းသော ဗိသုကာဆိုင်ရာ နယ်နိမိတ်များ လိုအပ်နေဆဲ ဖြစ်နိုင်သည်။ အရေးကြီးသည်မှာ ကောင်းမွန်သော အကြောင်းပြချက်မရှိဘဲ တူညီသော အင်ဂျင်နီယာတာဝန်ကို ဒုတိယအကြိမ် အကောင်အထည်ဖော်ခြင်းကို ရှောင်ရှားရန်ဖြစ်သည်။

အဲဒီအချိန်မှာ ပလက်ဖောင်းဟာ စုပုံနေတဲ့ အထွေထွေအသုံးစရိတ်ထက် ပိုင်ဆိုင်မှုတစ်ခု ဖြစ်လာပါတယ်။ Support မှာ နားလည်ရမယ့် parallel tools နည်းပါးပြီး release တွေက ပိုပြီး တသမတ်တည်းရှိတဲ့ လမ်းကြောင်းတွေကို လိုက်နာကာ တခြား product တစ်ခု ထပ်ထည့်တာက ကုမ္ပဏီက အကန့်အသတ်မရှိ အမွေဆက်ခံတဲ့ တခြား backend တစ်ခုအစား ထိန်းချုပ်ထားတဲ့ extension တစ်ခု ဖြစ်လာပါတယ်။

ပလက်ဖောင်းကို ထုတ်ကုန်ဗိသုကာ၏ အစိတ်အပိုင်းတစ်ခုအဖြစ် သဘောထားပါ

ရုပ်ပိုင်းဆိုင်ရာ ထုတ်ကုန်များကို ပြင်ဆင်မှုများ၊ ဝန်ဆောင်မှုပေးနိုင်မှု၊ ထုတ်လုပ်မှုစွမ်းရည်နှင့် အနာဂတ်ပြောင်းလဲမှုများကို ထည့်သွင်းစဉ်းစား၍ ဒီဇိုင်းထုတ်ထားသည်။ ချိတ်ဆက်ထားသော ထုတ်ကုန်များသည် ဆော့ဖ်ဝဲလ်ဘက်တွင် အလားတူစည်းကမ်းရှိရန် လိုအပ်ပါသည်။

ပထမဆုံး backend က ယာယီဖြစ်နိုင်ပါတယ်။ ပထမဆုံး provisioning script ဒါမှမဟုတ် support tool လည်း အဲဒီလိုပဲ ဖြစ်နိုင်ပါတယ်။ အဲဒါမှာ ဘာမှ မှားယွင်းတာ မရှိပါဘူး။ ထုတ်ကုန်ကိုယ်တိုင်က ဆက်လက်တိုးတက်ပြောင်းလဲနေချိန်မှာ ယာယီ ယန္တရားတွေက တိတ်တဆိတ် အမြဲတမ်း ဗိသုကာပုံစံ ဖြစ်လာတဲ့အခါ ပြဿနာတွေ စတင်ပါတယ်။

အဲဒီအချိန်ရောက်ရင် ချိတ်ဆက်ထားတဲ့ ထုတ်ကုန်ဟာ ဟာ့ဒ်ဝဲ၊ ဖရမ်ဝဲနဲ့ အက်ပ်တစ်ခုသာ မဟုတ်တော့ပါဘူး။ ဒါ့အပြင် စက်ပစ္စည်းတစ်ခုချင်းစီကို ခွဲခြားသတ်မှတ်ပေးတဲ့၊ ၎င်းရဲ့စွမ်းရည်တွေကို နားလည်တဲ့၊ မှန်ကန်သော ဖွဲ့စည်းမှုပုံစံကို အသုံးချတဲ့၊ အပ်ဒိတ်တွေကို ပံ့ပိုးပေးတဲ့၊ ပို့ဆောင်ပြီး နှစ်ပေါင်းများစွာကြာပြီးနောက် အဖွဲ့တွေကို ပြဿနာတွေကို ရှာဖွေဖော်ထုတ်ရာမှာ ကူညီပေးတဲ့ အခြေခံအဆောက်အအုံပေါ်မှာလည်း မူတည်ပါတယ်။

ထိုအလွှာကို ထုတ်ကုန်ဗိသုကာအဖြစ် သတ်မှတ်လိုက်သည်နှင့် ပိုင်းခြားမှုသည် ပိုမိုရှင်းလင်းလာပါသည်- စံမက္ကင်းနစ်များသည် ပြန်လည်အသုံးပြုနိုင်ဆဲဖြစ်ပြီး၊ စိတ်ကြိုက်အလုပ်မှာမူ ထုတ်ကုန် သို့မဟုတ် ထုတ်ကုန်မိသားစုတစ်ခုကို အခြားထုတ်ကုန်တစ်ခုနှင့် အမှန်တကယ်ခွဲခြားသည့်အရာထဲသို့ ဝင်ရောက်ပါသည်။

အခိုင်မာဆုံးပလက်ဖောင်းဆိုတာ ပထမဆုံးချိတ်ဆက်ထားတဲ့ ထုတ်ကုန်ကို ဖြစ်နိုင်စေရုံတင် မဟုတ်ပါဘူး။ အင်ဂျင်နီယာအဖွဲ့အနေနဲ့ backend အသစ်ကို အမြဲအမွေဆက်ခံစရာမလိုဘဲ ဒုတိယ၊ တတိယနဲ့ စတုတ္ထကို တည်ဆောက်နိုင်စေတဲ့ ပလက်ဖောင်းပါပဲ။