Lesson 130 — Advanced

Portability, Lock-in & Migration

Platform adopt karna aasaan hai, usmein phansa rehna mushkil. Is lesson mein hum kya portable hai kya nahi, abstraction layer kaise lagate hain, lock-in ki asli cost kya hai, aur migration ko kaise ek evaluation exercise mein badalte hain — catalog lag, deprecation aur parallel running ke saath.

Portability kya hai aur kyun matter karti hai

Funda: portability koi cheez nahi, ek property hai — har layer ki. Prompts hamesha portable lagte hain, par managed knowledge base, agent graph aur platform-specific APIs nahi. Ye farq pehle likh lo, migration ke waqt nahi.

Kya travel karta hai, kya nahi

portable (zyada tar):
  prompts + system instructions -> text hai, copy-paste
  eval suites + golden datasets  -> tumhara data hai
  application code (agar wrapper)
  business logic + filters

NOT portable (ya mehnga):
  platform SDK calls (direct)    -> request format alag
  managed indexes / knowledge bases -> re-ingest + re-tune
  agent definitions / workflows  -> platform-specific graph
  guardrail configurations       -> rule syntax alag
  identity + network setup (IaC) -> cloud-specific code

• Prompts portable hain, behaviour nahi: prompt text chala gaya, par model ke saath uska response pattern alag ho sakta hai — migration ke baad phir se tune karna padta hai.
• Evals hi tumhare hain: isliye migration ko evaluation exercise karo — sabse portable asset tumhara golden set hai, wahi naye platform ka bridge hai.
• Managed indexes: vectors dobara banenge hi, par tuning (chunk size, rerank config, filters) apne aap transfer nahi hoti.
• IaC bhi cloud-specific hai: identity aur network ka code cloud ke saath jaata hai — migration mein ye bhi chhota refactor nahi hai.

Abstraction layer — wrapper jo provider ko chhupaye

# Tumhara client wrapper — app isko hi bulata hai
class ModelClient:
    def __init__(self, cfg):
        self.provider = cfg["provider"]   # "platform-a" | "platform-b"
        self.model = cfg["model"]

    def complete(self, messages, **params):
        if self.provider == "platform-a":
            return self._via_platform_a(messages, params)
        return self._via_platform_b(messages, params)

# app code: client.complete(msgs)   <- kabhi SDK seedha nahi
# provider swap = config change, rewrite nahi

• Wrapper ka shape: ek request/response format jo app jaanta hai, aur adapters jo usse har provider ke format mein badalte hain.
• Kya wrapper mein na daalo: provider-specific features (special tools, unique modalities) ko wrapper ke through force mat karo — wo call sites ko provider-aware banata hai, aur wahi hidden coupling hai.
• Thin rakho: wrapper sirf translate kare, business logic nahi. Moti wrapper = doosri framework ban gayi.
• Gateway = built-in abstraction: kai providers hain toh gateway hi wrapper ka kaam kar sakta hai — phir wrapper sirf gateway format tak simit ho jaata hai.

Lock-in ki asli cost — sirf price nahi

Log lock-in ko sirf "mehnga renewal" samajhte hain. Asli costs chaar alag hain — aur negotiate karte waqt bhi yahi chaar matter karte hain:

• Model availability: tumhara favourite model kal catalog se gaya — naya model quality drop laya, tuning dobara.
• Feature pace: provider naye features apne timeline pe deta hai; tumhari roadmap uske saath chalti hai ya rukti hai.
• Negotiating position: exit mushkil ho toh renewal par discount kamzor padta hai — "hum chale jayenge" dikhna chahiye, hona nahi.
• Proving a new platform safe: migration sirf call swap nahi — security review, eval runs, load test. Ye switching cost ka sabse bada hidden part hai.

Migration = evaluation exercise

# Migration ka eval-first flow
baseline = run_eval_suite(golden_set, current_platform)   # BEFORE

new_client = ModelClient(cfg_new)
candidate = run_eval_suite(golden_set, new_client)         # DURING

compare(baseline, candidate)  # category-wise, sirf average nahi
# threshold pass? -> shadow traffic -> cutover

after = run_eval_suite(golden_set, live_platform)          # AFTER
# rollback plan cutover se pehle likha hua — baad mein nahi

• Before/During/After teeno run: baseline bina move kaise judge karoge? Har phase ka same golden set, same scorer.
• Per-category dekho: average same reh gaya par ek category gir gayi — aggregate chhupa deta hai. Category-wise diff hi asli review hai.
• Shadow traffic: cutover se pehle real traffic ka copy naye platform pe chalao — latency aur errors live dekho, users ko dikhe bina.
• Rollback plan pehle likho: kya signal par wapas jaoge, config kya hoga — incident ke beech mein socha nahi jaata.

Catalog lag aur platform-side deprecation

• Catalog lag: managed catalogs frontier models turant nahi le aate — validation, compliance, integration ka time lagta hai. Naye model ki zarurat ho toh pehle check karo, tumhare required region mein available hai bhi ya nahi.
• Deprecation apne schedule pe: platform version retire karta hai, notice period wo decide karta hai. "Kal tak chalega" wala assumption hi outage hai.
• Pinning karo: model id/version explicitly pin karo, auto-latest pe mat chalao — warna ek din bina badle code alag model par chal raha hoga.
• Notice process: official channels (console, email, status feed) ka owner assign karo — notice miss hua toh emergency ban jaata hai.

deprecation handling ka pattern:
  1. versions pin karo (explicit id, kabhi "latest" nahi)
  2. notice channels ke liye owner assign
  3. upcoming retirement -> eval set pe naya version chalao
  4. quality drop dikha -> prompt/tuning fix, warna fallback model
  5. cut date se pehle cutover + rollback plan ready

catalog lag ka rule: region + availability pehle check,
model selection uske baad — ulta mat karo

Do platforms parallel mein — aur multi-cloud ka honest hisaab

# Parallel running: gateway se route karo
routes:
  - match: { region: "required-region" }
    target: platform-a
  - match: { capability: "long-context" }
    target: platform-b
  - default: platform-a
    failover: platform-b
# do platforms = do eval runs, do security reviews, do teams ka knowledge

• Parallel tab: workload justified kare — region restriction, capacity backup, ya negotiation leverage. Warna do platforms = do bills aur do operations.
• Multi-cloud kya khareedta hai: resilience (ek cloud down toh doosra) aur leverage (negotiation mein option dikhta hai).
• Multi-cloud kya bechta hai: duplicated evaluation, duplicated security review aur duplicated operational knowledge — teeno real engineering time hain.
• Honest framing: "hum multi-cloud hain" bolne se pehle poochho — doosre cloud par hamara DR drill kab hua? Kabhi nahi toh resilience sirf paper par hai.

Exercise

Common mistakes

• Portability baad mein sochna: 6 mahine seedha SDK ke baad wrapper bolna sab refactor ban jaata hai. Fix: abstraction + evals adoption ke din se — wrapper chhota, golden set pehle se.
• Average metric se migration compare karna: Average same, par ek category chupke se gir gayi — users wahi bhugtenge. Fix: category-wise diff, phir threshold, phir shadow traffic.
• Auto-latest model par chalna: Bina badle code ek din alag model par chal raha hai — regression ka guarantee. Fix: explicit version pinning aur deprecation notice ka owner.
• Multi-cloud ko bina DR drill ke resilience proof samajhna: Do clouds configure kar liye par failover kabhi test hi nahi hua. Fix: parallel running ka har path (fallback, region route) scheduled drill se verify karo.

flat (platform) ka saman:
  suitcase  -> prompts, evals, app code (portable)
  built-in  -> managed KB, agent graph (chhodna padega)
  notice date -> deprecation timeline (fix hai)
rule: inventory pehle, packing baad mein, nahi toh regret