Vendor Lock-In နှင့် Multi-Cloud

နားလည်ထားရမယ့် အချက်

Vendor lock-in ဆိုသည်မှာ provider တစ်ခု၏ ပိုင်ဆိုင်ပြီး portable မဖြစ်သော feature — proprietary managed service, platform-specific API, ထိုvendor တစ်ခုတည်းသာ support သော query language extension — အပေါ်တွင် တည်ဆောက်ခြင်းကြောင့် နောက်ပိုင်း provider ပြောင်းလဲရန် ခက်ခဲလာခြင်းဖြစ်သည်, အကြောင်းမှာ အဆိုပါအပိုင်းများကို ပြန်တည်ဆောက်ရမည်ဖြစ်သောကြောင့်ဖြစ်သည်။

Lock-in သည် အလိုအလျောက် ဆိုးသည်မဟုတ်ပါ။ ၎င်းသည် tradeoff တစ်ခုဖြစ်သည် — proprietary feature များသည် platform တစ်ခုကို မြန်ဆန်၊ အဆင်ပြေစေသော အကြောင်းရင်းအမှန်ဖြစ်တတ်ပြီး portability လျော့ချခြင်းဖြင့် ဒါကို ဖိုးဆောင်ခြင်းသည် team သေးငယ်တစ်ခုအတွက် အထူးသဖြင့် အလွန်ကျိုးကြောင်းညီသော deal ဖြစ်နိုင်သည်။

Multi-cloud ဆိုသည်မှာ provider တစ်ခုထက်ပိုသော ရည်ရွယ်ချက်ရှိစွာ အသုံးပြုခြင်းဖြစ်ပြီး organization အချို့သည် provider တစ်ခု outage အန္တရာယ်ကာကွယ်ရန်၊ ဈေးနှုန်း negotiate လုပ်ရန် အားသာချက်ရရန်၊ regulatory (သို့) geopolitical risk ဖြန့်ကျက်ရန် စသော အကြောင်းရင်းအစစ်များဖြင့် ၎င်းကို ကျင့်သုံးကြသည်။

• Console နှင့် billing system များစွာ သင်ယူရန်
• Credential နှင့် permission များစွာ လုံခြုံအောင် ထိန်းသိမ်းရန်
• Monitoring setup များစွာ တသမတ်တည်း ထားရှိရန်
• Provider တစ်ခုထက်ပိုသော quirk များကို ကျွမ်းကျင်ရမည့် engineer များ လိုအပ်ခြင်း

Middle path တစ်ခု သိထားစရာရှိသည် — standard SQL ကို proprietary query dialect အစား၊ container ကို fully proprietary compute format အစား၊ တွင်ကျယ်စွာ support ထားသော API ကို vendor-only API အစား သင့်လျော်သည့်နေရာတွင် အသုံးပြုခြင်းသည် provider အများအပြားပေါ်တွင် တစ်ပြိုင်နက် run ခြင်းရဲ့ operational cost အပြည့်အစုံကို မကုန်ကျစေဘဲ lock-in risk ကို အဓိပ္ပာယ်ရှိစွာ လျော့ချပေးသည်။

Vendor Lock-In

Provider တစ်ခု၏ proprietary, non-portable feature များအပေါ် တည်ဆောက်ထားခြင်းကြောင့် နောက်ပိုင်း ထိုfeature များကို ပြန်တည်ဆောက်ခြင်းမပြုဘဲ အခြား provider သို့ ပြောင်းရွှေ့ရန် ခက်ခဲသောအခြေအနေ

PORTABILITY SPECTRUM
--------------------
HIGHLY PROPRIETARY                                FULLY PORTABLE
      |------------------------------------------------|
  vendor-only APIs        standard SQL, containers,
  proprietary DB engine    widely-supported APIs,
  proprietary queue        standard protocols

SINGLE PROVIDER (simple, but more locked in)
  [ one console ] [ one billing ] [ one skillset ]

MULTI-CLOUD (more portable, but more complex)
  [console A][console B]  [billing A][billing B]
  [team must know both providers' quirks]

Standard tech within ONE provider often buys most of the
portability benefit without paying multi-cloud's full cost.

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

Major cloud တစ်ခုပေါ်တွင် တည်ဆောက်နေသော team တစ်ခုသည် ထို cloud ၏ proprietary serverless database, proprietary message queue, proprietary authentication service တို့ကို app တစ်ခုလုံးတွင် အသုံးပြုသည်။ အစိတ်အပိုင်းတိုင်းက အတူတကွ အလုပ်လုပ်ရန် ဒီဇိုင်းထုတ်ထားသောကြောင့် မြန်ဆန်စွာ ပို့ဆောင်နိုင်သော်လည်း ဈေးနှုန်း ဆိုးရွားစွာ ပြောင်းလဲပါက (သို့) အရေးကြီး feature တစ်ခု deprecate လုပ်ခံရပါက migration လုပ်ခြင်းက connection string တစ်ခုတည်း ပြောင်းရုံမက backend အများစုကို ပြန်ရေးရမည်ဖြစ်သည်။

ဒါကို cloud တူညီသော်လည်း proprietary database variant အစား standard Postgres ကို၊ proprietary message-queue protocol အစား widely supported protocol ကို၊ cloud-specific authentication service အစား portable authentication library ကို ရွေးချယ်သော team တစ်ခုနှင့် နှိုင်းယှဉ်ပါ။ Integration နက်နဲမှု နည်းနိုင်ပြီး setup အလုပ်ပိုနိုင်သော်လည်း နောက်ပိုင်း cloud ပြောင်းရန် logic ပြန်ရေးမည့်အစား connection ပြန်ညွှန်းရုံသာ လိုအပ်လိမ့်မည်။

Team နှစ်ခုလုံးသည် ဒီရွေးချယ်မှုပြုလုပ်ရန် multi-cloud လိုအပ်သည်မဟုတ်ပါ — portability အကျိုးကျေးဇူးသည် provider တစ်ခုတည်းအတွင်း standard technology ရွေးချယ်ခြင်းမှ လာသည်ဖြစ်ပြီး ၎င်းသည် provider နှစ်ခုကို ထပ်တူ run ခြင်းထက် ကုန်ကျစရိတ် များစွာ နည်းသည်။

Multi-cloud အစစ်ကိုမူ compliance, contractual redundancy, outage-cost calculation အစစ်ကဲ့သို့ တိကျသော၊ အမည်ရှိသော requirement တစ်ခုက operational weight ထပ်တိုးလာခြင်းကို ကျိုးကြောင်းညီစေမှသာ သုံးစွဲပါ။

• Vendor lock-in သည် proprietary feature အသုံးပြုခြင်းရဲ့ tradeoff တစ်ခုဖြစ်ပြီး အလိုအလျောက် ဆိုးသည်မဟုတ်ပါ
• Multi-cloud သည် resilience/negotiating power အတွက် အခါအားလျော်စွာ တန်ဖိုးရှိသော်လည်း operational complexity ထပ်တိုးစေပြီး project သေးငယ်အများစုအတွက် default ရွေးချယ်မှု မဟုတ်ပါ
• Standard technology (SQL, container, standard API) ကို အသုံးပြုခြင်းသည် multi-cloud တစ်ခုလုံး မလိုအပ်ဘဲ lock-in risk ကို လျော့ချပေးနိုင်သည်

အတူတူ စမ်းရေးကြည့်မယ်

function assessLockInRisk(features) {
  // features: [{ name: "...", type: "proprietary" | "standard" }, ...]
  const proprietary = features.filter(f => f.type === "proprietary");
  const standard = features.filter(f => f.type === "standard");
  const total = features.length || 1;
  const score = Math.round((proprietary.length / total) * 100);

  let level;
  if (score >= 70) level = "high";
  else if (score >= 30) level = "moderate";
  else level = "low";

  return {
    lockInScore: score,
    level,
    proprietaryFeatures: proprietary.map(f => f.name),
    standardFeatures: standard.map(f => f.name),
  };
}

const highLockInProject = [
  { name: "proprietary serverless database", type: "proprietary" },
  { name: "proprietary message queue", type: "proprietary" },
  { name: "proprietary auth service", type: "proprietary" },
  { name: "standard object storage API", type: "standard" },
];

const lowLockInProject = [
  { name: "standard Postgres", type: "standard" },
  { name: "container-based compute", type: "standard" },
  { name: "vendor-specific CDN config", type: "proprietary" },
  { name: "standard REST API gateway", type: "standard" },
];

console.log("High lock-in project:", assessLockInRisk(highLockInProject));
console.log("Low lock-in project:", assessLockInRisk(lowLockInProject));

High lock-in project: lockInScore 75, level 'high'
Low lock-in project: lockInScore 25, level 'low'

Wikipedia: Vendor lock-in — Cloud Providers & Platforms