Well-Architected — cloud নকশার স্তম্ভ, multi-cloud আর lock-in

১ · অ্যাপ চলছে মানেই নকশা ভালো নয়

একটি কাল্পনিক অনলাইন বাজার অ্যাপের কথা ভাবুন। দুই বছর ধরে ভালোই চলছে। Dashboard সবুজ, বিল সহনীয়, গ্রাহকও খুশি। তারপর ঈদের সেলের রাতে একটি availability zone-এ সমস্যা হলো। অ্যাপের সব কিছু ছিল সেই একটি zone-এ। দল তখন প্রথমবার backup থেকে restore চেষ্টা করল, আর দেখল প্রক্রিয়াটি কেউ আগে করেনি। ছয় ঘণ্টা বিক্রি বন্ধ।

এখানে কোনো code-এর bug ছিল না। দুর্বলতা ছিল নকশায়, আর সেটি দুই বছর ধরে চুপচাপ ছিল। সুস্থ অবস্থায় দুর্বল নকশা আর ভালো নকশা দেখতে একই। পার্থক্য ধরা পড়ে চাপের দিনে। তাই চাপ আসার আগে নকশাকে প্রশ্ন করতে হয়। সেই প্রশ্নের গোছানো তালিকাই Well-Architected framework.

এই পর্বটি আগের অনেক পর্বকে এক জায়গায় আনে। Availability-র হিসাব পর্ব ০৫, backup আর RTO পর্ব ২৪, governance পর্ব ৩৫, SLO পর্ব ৬৬, capacity পর্ব ৬৮. আর খরচের দিক পর্ব ৭২ ও পর্ব ৭৩-এ এসেছে। Well-Architected নতুন প্রযুক্তি শেখায় না। সে জিজ্ঞেস করে, এই শেখা জিনিসগুলো আপনার নকশায় আছে তো?

২ · ছয়টি স্তম্ভ, আর তিন provider-এর মিল

বাড়ির ছাদ দাঁড়িয়ে থাকে কয়েকটি থামের ওপর। একটি থাম দুর্বল হলে অন্য থাম যত মোটাই হোক, ছাদ নিরাপদ নয়। এই ছবি থেকেই pillar বা স্তম্ভ শব্দটি এসেছে। প্রতিটি স্তম্ভ নকশার একটি প্রশ্নের দিক।

তিন বড় provider-এর কাঠামো খুব কাছাকাছি। শব্দে সামান্য পার্থক্য, চিন্তায় প্রায় নেই। নিচের ছকটি লেখার সময়ের ধারণা; নাম ও সংখ্যা বদলাতে পারে, তাই দলিল মিলিয়ে নিন।

বিশেষ কাজের জন্য lens, আর তৈরি নকশা

Serverless, machine learning বা SaaS-এর নিজস্ব প্রশ্ন থাকে। AWS এদের বলে lens: একই স্তম্ভ, কিন্তু সেই ধরনের কাজের জন্য বাড়তি প্রশ্ন। আরেকটি দরকারি জিনিস reference architecture: কোনো সাধারণ সমস্যার পরীক্ষিত নকশা, যেমন “তিন-স্তরের web অ্যাপ”।

Reference architecture হলো রান্নাঘরের রেসিপি খাতা। শুরু করার ভালো জায়গা, কিন্তু আপনার অতিথি, চুলা আর বাজেট সে জানে না। অনেক নকশা বড় প্রতিষ্ঠানের চাপ ধরে আঁকা। ছোট দল হুবহু নকল করলে জটিলতা আর বিল দুটোই বাড়ে। নকল করার আগে দেখুন, প্রতিটি বাক্স কোন সমস্যা মেটাচ্ছে, আর সেই সমস্যা আপনার আছে কি না।

৩ · স্তম্ভের টানাপোড়েন: সব একসাথে সর্বোচ্চ হয় না

নতুনরা প্রায়ই ভাবেন, সব স্তম্ভে পূর্ণ নম্বর পাওয়াই লক্ষ্য। তা নয়। প্রতিটি উন্নতির একটি দাম আছে, আর সেই দাম প্রায়ই আরেকটি স্তম্ভ থেকে কাটা যায়। এই লেনদেনের নাম trade-off.

ভালো নকশা মানে সেরা trade-off নয়, লিখিত trade-off রাখা। ছয় মাস পরে কেউ জিজ্ঞেস করবে, “এক region কেন?” উত্তর যদি হয়, “হিসাব করেছিলাম, ঘণ্টার ক্ষতি কম, তাই”, সেটি সিদ্ধান্ত। উত্তর যদি হয়, “কেউ ভাবেনি”, সেটি দুর্ঘটনা। এই কারণ লিখে রাখার ছোট দলিলের নাম architecture decision record বা ADR. Michael Nygard ২০১১ সালের একটি লেখায় এই ধারণাটি জনপ্রিয় করেন।

৪ · Review মানে প্রশ্ন আর প্রমাণ, নম্বর নয়

Architecture review কোনো audit নয়। AWS-এর দলিলেও একে দোষ খোঁজার বদলে খোলা আলোচনা হিসেবেই বর্ণনা করা হয়। যাঁরা সিস্টেম বানিয়েছেন আর চালান, তাঁরা বসেন। উদ্দেশ্য ঝুঁকি খুঁজে পাওয়া, কাউকে ধরা নয়। ভালো প্রশ্নের তিনটি গুণ:

• প্রমাণ চায়। “Backup আছে?” দুর্বল প্রশ্ন। “সর্বশেষ কবে restore করেছেন, কত সময় লেগেছিল?” ভালো প্রশ্ন।
• ব্যর্থতার কথা বলে। “এই zone না থাকলে কী হবে?” উত্তর শুনলেই single point of failure দেখা যায়।
• দায়িত্ব জিজ্ঞেস করে। “রাত ২টায় এটি ভাঙলে কে জানবে, আর কী করবে?”

Yes/no উত্তর থেকে একটি finding পাওয়া যায়, অর্থাৎ নকশার একটি নথিবদ্ধ দুর্বলতা। AWS-এর Well-Architected Tool এদের high ও medium ঝুঁকিতে ভাগ করে। আমরা একটি সহজ পদ্ধতি নিই: impact × likelihood, দুটোই ১ থেকে ৫. নিচের সিমুলেটর আমাদের কাল্পনিক অ্যাপের ১৩টি উত্তর নিয়ে কাজ করছে। উত্তর বদলে আবার চালিয়ে দেখুন।

// Pillar review: yes/no answers become a risk-ordered list. Sample data, ASSUMED.
// risk = impact x likelihood (1 to 5 each). It orders the work; it is not a grade.
const answers = [ // [pillar, question, yes?, impact, likelihood]
  ["reliability", "Restore tested this quarter?", false, 5, 4],
  ["reliability", "Database survives a zone loss?", false, 5, 3],
  ["reliability", "App runs in 2+ zones?", false, 4, 3],
  ["security", "No shared admin login?", false, 5, 3],
  ["security", "Secrets kept outside the code?", true, 5, 2],
  ["security", "Database has no public address?", true, 5, 2],
  ["operations", "Deploys are automated?", true, 3, 3],
  ["operations", "Runbook for the top 3 alerts?", false, 3, 3],
  ["performance", "Load tested at peak?", false, 3, 3],
  ["performance", "Static files served by a CDN?", true, 2, 2],
  ["cost", "Every resource tagged?", false, 2, 4],
  ["cost", "Budget alert set?", true, 3, 2],
  ["sustainability", "Dev servers stop at night?", false, 1, 4],
];
const risk = a => a[3] * a[4];
const open = answers.filter(a => !a[2]).sort((x, y) => risk(y) - risk(x) || y[3] - x[3]);
const level = r => (r >= 15 ? "HIGH" : r >= 8 ? "MED " : "LOW ");
for (const p of [...new Set(answers.map(a => a[0]))]) {
  const all = answers.filter(a => a[0] === p), no = open.filter(a => a[0] === p);
  const sum = no.reduce((s, a) => s + risk(a), 0);
  console.log(p.padEnd(15), `yes ${all.length - no.length}/${all.length}`, ` open risk ${sum}`);
}
console.log("\nOrdered findings:");
for (const a of open) console.log(String(risk(a)).padStart(3), level(risk(a)), a[1]);
const pct = yes => Math.round(100 * yes / answers.length);
const yes = answers.length - open.length;
const after = rest => (rest.length ? risk(rest[0]) : 0);
console.log(`\nYes score now: ${pct(yes)}%, top open risk ${after(open)}`);
console.log(`Fix 3 easiest: ${pct(yes + 3)}%, top open risk ${after(open.slice(0, -3))}`);
console.log(`Fix 3 riskiest: ${pct(yes + 3)}%, top open risk ${after(open.slice(3))}`);

reliability     yes 0/3  open risk 47
security        yes 2/3  open risk 15
...
 20 HIGH Restore tested this quarter?
 15 HIGH Database survives a zone loss?
 15 HIGH No shared admin login?
...
Yes score now: 38%, top open risk 20
Fix 3 easiest: 62%, top open risk 20
Fix 3 riskiest: 62%, top open risk 12

Review-এর ফল টিকিটে না গেলে কয়েক সপ্তাহে হারিয়ে যায়। অনেক দল তাই checklist-টি সাধারণ লেখায় রাখে, যাতে Git-এ বদল দেখা যায়। ছোট একটি shell কাজ দিয়ে সেখান থেকেই সারাংশ বের করা যায়। নিচের block-এ নমুনা ফাইল heredoc দিয়ে তৈরি হচ্ছে।

#!/bin/bash
# Summarise a review checklist kept as plain text. Sample data.
set -euo pipefail
export LC_ALL=C
cat > review.csv <<'EOF'
reliability,restore tested,no,20,rafi
reliability,database multi-zone,no,15,rafi
reliability,app in 2+ zones,no,12,mitu
security,no shared admin,no,15,sadia
security,secrets outside code,yes,10,sadia
operations,deploys automated,yes,9,mitu
operations,runbook for alerts,no,9,mitu
performance,load tested,no,9,tanvir
cost,all resources tagged,no,8,tanvir
cost,budget alert,yes,6,tanvir
EOF

echo "== answers =="
cut -d, -f3 review.csv | sort | uniq -c

echo "== open risk per pillar =="
awk -F, '$3 == "no" { n[$1]++; r[$1] += $4 }
  END { for (p in n) printf "%3d %-12s %d open\n", r[p], p, n[p] }' review.csv |
  sort -k1,1nr -k2,2

echo "== fix first (risk >= 15) =="
awk -F, '$3 == "no" && $4 >= 15 { print $4, $5 ": " $2 }' review.csv | sort -k1,1nr -k2,2

echo "== work per owner =="
awk -F, '$3 == "no" { print $5 }' review.csv | sort | uniq -c | sort -k1,1nr -k2,2

== answers ==
      7 no
      3 yes
== open risk per pillar ==
 47 reliability  3 open
 15 security     1 open
...
== fix first (risk >= 15) ==
20 rafi: restore tested
15 rafi: database multi-zone
15 sadia: no shared admin
== work per owner ==
      2 mitu
      2 rafi
      2 tanvir
      1 sadia

৫ · একটি তিন-স্তরের অ্যাপের পূর্ণ review

এবার আমাদের কাল্পনিক অনলাইন বাজার অ্যাপ। এটি একটি three-tier নকশা: web স্তর (২টি VM), app স্তর (২টি VM), data স্তর (একটি managed database). সব কিছু একই zone-এ। মাসিক বিল ধরে নিই $১০,০০০, অর্থাৎ বছরে $১,২০,০০০. ব্যবসার লক্ষ্য: সেবা মাসে ৯৯.৯% সময় পাওয়া যাবে, ডেটা হারানো চলবে সর্বোচ্চ ১৫ মিনিটের, আর RTO ৬০ মিনিট।

লক্ষ করুন, sustainability-র ঝুঁকি কম হলেও কাজটি সহজ, আর খরচও কমায়। ক্রম ঝুঁকি দিয়ে ঠিক হয়, কিন্তু সস্তা আর সহজ কাজ পাশাপাশি সেরে ফেলা যায়। শুধু সেটিকে অগ্রগতি ভেবে ভুল করবেন না।

নিচের stepper-এ তালিকার এক নম্বর finding-টি প্রশ্ন থেকে বন্ধ হওয়া পর্যন্ত নেওয়া হয়েছে। খেয়াল করুন, fix করতে গিয়েই একটি নতুন সত্য বেরিয়ে আসে।

৬ · আগে multi-AZ, multi-region কখন লাভের

বিদ্যুৎ চলে গেলে বাড়িতে IPS কাজ দেয়। পুরো এলাকায় ফিডার নষ্ট হলে সেটি কয়েক ঘণ্টা চলে। পুরো শহর অন্ধকার হলে দরকার অন্য শহরের ব্যবস্থা। প্রতিটি ধাপে সুরক্ষা বাড়ে, দামও অনেক বাড়ে। Cloud-এ এই ধাপগুলোর নাম failure domain: যা একসাথে ভাঙতে পারে।

Multi-AZ প্রথম ধাপ, কারণ zone-গুলো কাছাকাছি। Synchronous replication চলে, RPO প্রায় শূন্য, আর managed database-এ সাধারণত একটি setting-এই কাজটি হয়। Zone-গুলোর মাঝে ডেটা আনা-নেওয়ার ফি লাগতে পারে। তবে multi-AZ সব ঠেকায় না। কেউ ভুলে table মুছলে সেই মুছে ফেলাও মুহূর্তে standby-তে পৌঁছে যায়। সেজন্য backup আলাদা বিষয়।

Multi-region অন্য জগৎ। দূরত্বের কারণে replication সাধারণত asynchronous, তাই failover-এ শেষের কিছু ডেটা হারাতে পারে। DNS, secret, config, quota সবই দুই জায়গায় মেলাতে হয়। আর data residency-র নিয়ম থাকলে দ্বিতীয় region বেছে নেওয়াও সহজ নয়। Multi-region যুক্তিসঙ্গত হয় চারটি ক্ষেত্রে: চুক্তি বা নিয়ন্ত্রকের শর্ত আছে; ব্যবহারকারী দূরে দূরে, তাই latency কমাতে হবে; region হারানোর ক্ষতি সত্যিই বিশাল; অথবা RTO এত কম যে backup থেকে ফেরা যায় না।

Copy যোগ করলে ঝুঁকি গুণ হয়, এই হিসাব কেন ভুল

পর্ব ০৫-এ দেখেছেন, স্বাধীন copy-র downtime গুণ হয়। যেমন দুটি copy-র প্রতিটি ০.২% সময় বন্ধ থাকলে দুটি একসাথে বন্ধ থাকার সম্ভাবনা ০.০০২ × ০.০০২ = ০.০০০০০৪. এটি “স্বাধীন” ধরে হিসাব। বাস্তবে একটি খারাপ deploy, একটি ভুল config বা মেয়াদ-উত্তীর্ণ certificate সব copy-কে একসাথে ফেলে দেয়। এটিই correlated failure.

Reliability engineering-এ একে ধরার একটি সরল উপায় আছে, beta-factor model নামে। ধরুন প্রতিটি copy-র downtime-এর অংশ u, copy-র সংখ্যা n, আর b হলো সেই অংশ যা সবার একসাথে ঘটে। তাহলে:

প্রথম পদ একসাথে পড়ার ঝুঁকি, যা copy বাড়িয়ে কমে না। দ্বিতীয় পদ স্বাধীন ব্যর্থতা, যা copy বাড়লে দ্রুত কমে। তৃতীয় পদ ops আমরা যোগ করেছি: জটিলতা থেকে আসা বাড়তি ঝুঁকি, যেমন ভুল failover. উদাহরণ: u = ০.২%, n = ৩, b = ০.১ হলে প্রথম পদ ০.০০০২, দ্বিতীয় পদ (০.০০১৮)³ ≈ ০.০০০০০০০০৬. মোট U প্রায় পুরোটাই প্রথম পদ, অর্থাৎ ৯৯.৯৮%. স্বাধীন ধরলে ৯৯.৯৯৯৯৯৯%-এর বেশি পাওয়া যেত, যা কল্পনা।

// Four designs: availability and yearly cost, with a correlated-failure factor b.
// ALL numbers are ASSUMED, for teaching. Model: U = b*u + ((1-b)*u)^n + ops
const HOURS = 8760, BILL = 120000, LOSS = 5000; // base bill $/year, outage $/hour
const designs = [ // name, copies n, copy downtime share u, b, ops risk, bill x, people $
  ["single-AZ", 1, 0.002, 0, 0, 1.0, 0],
  ["multi-AZ", 3, 0.002, 0.10, 0, 1.5, 0],
  ["multi-region", 2, 0.0002, 0.20, 0.00002, 2.2, 30000],
  ["multi-cloud", 2, 0.0002, 0.10, 0.0001, 2.6, 150000],
];
const unavail = (n, u, b, ops) => b * u + ((1 - b) * u) ** n + ops;
const rows = designs.map(([name, n, u, b, ops, x, people]) => {
  const U = unavail(n, u, b, ops), h = U * HOURS, spend = BILL * x + people;
  return { name, A: 100 * (1 - U), h, spend, loss: h * LOSS, total: spend + h * LOSS };
});
console.log("design        avail%   down h/yr   spend $   outage $    total $");
for (const r of rows) console.log(r.name.padEnd(13), r.A.toFixed(4), r.h.toFixed(2).padStart(8),
  Math.round(r.spend).toString().padStart(10), Math.round(r.loss).toString().padStart(9),
  Math.round(r.total).toString().padStart(10));
console.log("\nOutage $/hour at which the next step pays for itself:");
const ladder = [[0, 1], [1, 2], [1, 3]];
for (const [a, b] of ladder) {
  const be = (rows[b].spend - rows[a].spend) / (rows[a].h - rows[b].h);
  console.log(` ${rows[a].name} -> ${rows[b].name}: $${Math.round(be)}`);
}
console.log("\nMore correlation (b) shrinks the gain from extra copies:");
for (const b of [0, 0.1, 0.3, 0.5, 1]) {
  const az = unavail(3, 0.002, b, 0), reg = unavail(2, 0.0002, b, 0.00002);
  console.log(` b=${b.toFixed(1)}  multi-AZ ${(az * HOURS).toFixed(2)} h/yr`,
    ` multi-region ${(reg * HOURS).toFixed(2)} h/yr`);
}
console.log("\nIf multi-cloud ops risk were 0:",
  (100 * (1 - unavail(2, 0.0002, 0.10, 0))).toFixed(4) + "%");

design        avail%   down h/yr   spend $   outage $    total $
single-AZ     99.8000    17.52     120000     87600     207600
multi-AZ      99.9800     1.75     180000      8760     188760
multi-region  99.9940     0.53     294000      2629     296629
multi-cloud   99.9880     1.05     462000      5257     467257

Outage $/hour at which the next step pays for itself:
 single-AZ -> multi-AZ: $3805
 multi-AZ -> multi-region: $92968
 multi-AZ -> multi-cloud: $402531

More correlation (b) shrinks the gain from extra copies:
 b=0.0  multi-AZ 0.00 h/yr  multi-region 0.18 h/yr
 b=0.1  multi-AZ 1.75 h/yr  multi-region 0.35 h/yr
 b=0.3  multi-AZ 5.26 h/yr  multi-region 0.70 h/yr
 b=0.5  multi-AZ 8.76 h/yr  multi-region 1.05 h/yr
 b=1.0  multi-AZ 17.52 h/yr  multi-region 1.93 h/yr

If multi-cloud ops risk were 0: 99.9980%

এবার একই সংখ্যা দিয়ে cost আর reliability-র সিদ্ধান্তটি ধাপে ধাপে দেখুন।

৭ · Multi-cloud: কারণ আর আসল দাম

পর্ব ০৩-এ দুটি জিনিস আলাদা করেছিলাম। Portfolio multi-cloud: এক কাজ এক provider-এ, আরেক কাজ অন্য provider-এ। এটি সাধারণ আর তুলনামূলক সহজ। Spanning multi-cloud: একটিই কাজ দুই provider-জুড়ে চলে বা মুহূর্তে সরে যেতে পারে। Multi-cloud নিয়ে তর্কের প্রায় সবটাই এই দ্বিতীয়টি নিয়ে।

আসল খরচ লুকিয়ে থাকে চারটি জায়গায়। ডেটা: egress ফি আর দুই ধরনের database-এর মধ্যে replication. ধরুন প্রতি মাসে ২০ TB ডেটা অন্য cloud-এ যায়, ধরে নিই $০.০৫ প্রতি GB: ২০,০০০ × ০.০৫ = মাসে $১,০০০, বছরে $১২,০০০. মানুষ: দুই provider-এর IAM, network, নিরাপত্তা, on-call. সেবার গভীরতা: দুই provider-এ মিলে এমন সাধারণ সেবাই ব্যবহার করা যায়, তাই প্রতিটির সেরা অংশ হাতছাড়া হয়। দুর্বলতম অংশ: DNS, identity provider, CI/CD আর আপনার নিজের code দুই পাশেই এক, তাই সেগুলো ভাঙলে দুই cloud-ই একসাথে পড়ে।

৮ · Lock-in-এর স্তর, abstraction-এর দাম আর exit plan

ভাড়া বাড়িতে আপনি নিজের টাকায় রান্নাঘরে দেয়াল-ঘেঁষা আলমারি বানালেন। রান্না সহজ হলো, প্রতিদিন সময় বাঁচল। কিন্তু বাড়ি ছাড়লে আলমারি নেওয়া যাবে না। এতে আলমারি বানানো ভুল ছিল না; এর দাম কত, জেনে নেওয়াটাই বুদ্ধির কাজ। Vendor lock-in-ও তাই। Lock-in কোনো পাপ নয়, এটি একটি খরচ, যা সরার দিনে দিতে হয়।

Abstraction-এর দাম

Lock-in কমানোর সহজ উত্তর শোনা যায়: সব provider-এর সামনে নিজের একটি স্তর বসান, হয়ে যান cloud-agnostic. শুনতে ভালো, কিন্তু এই স্তরের চারটি দাম আছে। সবচেয়ে ছোট সাধারণ অংশেই আটকে যেতে হয়। স্তরটি নিজে বানাতে আর চালাতে হয়। প্রতি provider-এর নতুন সুবিধা দেরিতে আসে। আর নিচের পার্থক্য ঠিকই বাইরে ফুটে বের হয়, যাকে বলে leaky abstraction: দুই database-এর transaction-এর আচরণ এক API-তে ঢাকা পড়ে না।

তাই সব জায়গায় সমান abstraction না করে যুক্তিসঙ্গত জায়গায় করুন। Container, Kubernetes, PostgreSQL-সামঞ্জস্য, OpenTelemetry আর IaC তুলনামূলক কম দামে অনেকটা portability দেয়। আপনার ব্যবসার code-এ provider-এর SDK সরাসরি না ডেকে একটি ছোট adapter রাখা প্রায়ই সস্তা বিমা। কিন্তু Terraform-এর code কখনো “provider বদলালেই চলবে” না; প্রতিটি resource আলাদা, পর্ব ৫২-এ দেখেছেন।

// Rough exit estimate: what would leaving this provider cost? ALL numbers ASSUMED.
const P = { perGB: 0.05, gbps: 1, util: 0.7, personMonth: 3000, trainPerHead: 2000,
  team: 6, parallelMonths: 3, monthlyBill: 10000, buffer: 0.3 };
function exitCost(dataTB, rewritePM) {
  const gb = dataTB * 1000;                      // decimal: 1 TB = 1000 GB
  const data = gb * P.perGB;
  const days = (gb * 1e9 * 8) / (P.gbps * 1e9 * P.util) / 86400;
  const rewrite = rewritePM * P.personMonth;
  const training = P.team * P.trainPerHead;
  const parallel = P.parallelMonths * P.monthlyBill;
  const total = (data + rewrite + training + parallel) * (1 + P.buffer);
  return { data, days, rewrite, training, parallel, total };
}
const show = (name, c) => console.log(name.padEnd(20), `data $${c.data}`,
  ` rewrite $${c.rewrite}`, ` total $${Math.round(c.total)}`);
const heavy = exitCost(50, 60), portable = exitCost(50, 18);
show("deep managed use", heavy);
show("portable design", portable);
console.log(`training $${heavy.training}, parallel run $${heavy.parallel}, buffer 30%`);

console.log("\nData size against one 1 Gbps link at 70%:");
for (const tb of [5, 50, 500, 5000]) {
  const c = exitCost(tb, 60);
  console.log(String(tb).padStart(5), "TB:", `$${c.data}`.padEnd(9),
    `${c.days.toFixed(1)} days,`, `${(100 * c.data / c.total).toFixed(1)}% of the total`);
}
const saved = heavy.total - portable.total, abstraction = 36000; // $ per year, ASSUMED
console.log(`\nPortability saves $${Math.round(saved)} if you ever leave.`);
console.log(`It costs $${abstraction} every year. Break-even chance of leaving:`,
  `${(100 * abstraction / saved).toFixed(1)}% a year`);
console.log("At a 5% yearly chance, expected saving:", `$${Math.round(0.05 * saved)} a year`);

deep managed use     data $2500  rewrite $180000  total $291850
portable design      data $2500  rewrite $54000  total $128050
training $12000, parallel run $30000, buffer 30%

Data size against one 1 Gbps link at 70%:
    5 TB: $250      0.7 days, 0.1% of the total
   50 TB: $2500     6.6 days, 0.9% of the total
  500 TB: $25000    66.1 days, 7.8% of the total
 5000 TB: $250000   661.4 days, 40.7% of the total

Portability saves $163800 if you ever leave.
It costs $36000 every year. Break-even chance of leaving: 22.0% a year
At a 5% yearly chance, expected saving: $8190 a year

Exit plan: বেরোনোর পথ লিখে রাখা

Exit plan মানে সত্যিই চলে যাওয়ার সিদ্ধান্ত নয়। এটি অগ্নিনির্বাপণের মহড়ার মতো: আশা করি লাগবে না, কিন্তু পথ জানা আছে। একটি ভালো exit plan এক-দুই পাতার, আর এতে থাকে:

• কারণের তালিকা: কোন ঘটনায় এই plan চালু হবে, যেমন দাম হঠাৎ বাড়া, নিয়ন্ত্রকের নির্দেশ, বা সেবা বন্ধ।
• ডেটার মানচিত্র: কী ডেটা কোথায়, কত বড়, কোন format-এ বের করা যায়। Backup-এর একটি কপি provider-স্বাধীন format-এ রাখা গেলে ভালো।
• নির্ভরতার তালিকা: কোন সেবার বিকল্প কী, আর কোনটি বদলাতে কত person-month.
• সময় আর দাম: উপরের মতো হিসাব, বছরে একবার হালনাগাদ।
• মহড়া: অন্তত ডেটা এক ধাপ বের করে অন্য জায়গায় খুলে দেখা। পরীক্ষা না করা plan শুধু আশা।

৯ · Sustainability আর carbon, সংক্ষেপে

ডেটা সেন্টার বিদ্যুৎ আর ঠান্ডা করার ব্যবস্থায় চলে। Sustainability স্তম্ভের প্রশ্ন সহজ: একই কাজ কম শক্তিতে করা যায়? খরচের সাথে এর মিল অনেক, কারণ অলস server বন্ধ করলে টাকা আর বিদ্যুৎ দুটোই বাঁচে। ছবির তীর E সেটিই দেখায়।

• Provider-এর দিক: PUE হলো ডেটা সেন্টারের মোট বিদ্যুৎ ÷ IT যন্ত্রের বিদ্যুৎ। মান ১.০-এর যত কাছে, cooling-এর মতো বাড়তি খরচ তত কম।
• গ্রাহকের দিক: rightsizing, autoscaling, অদরকারি ডেটা মোছা, কম চলা dev পরিবেশ বন্ধ, দক্ষ code. ব্যাচের কাজ দিনের যে সময়ে সস্তা বা পরিষ্কার বিদ্যুৎ থাকে তখন চালানো যায়।
• মাপ: Carbon footprint হিসাব করতে বিদ্যুতের সাথে carbon intensity গুণ করতে হয়। বিদ্যুৎ-উৎস দেশ ও সময়ভেদে আলাদা। তাই region বদলালেও সংখ্যা বদলাতে পারে।

তিন বড় provider-ই গ্রাহকের জন্য carbon হিসাবের কিছু সরঞ্জাম দেয়। সেগুলোর পদ্ধতি, দেরি ও ব্যাপ্তি এক নয়, তাই provider-ভেদে তুলনা সাবধানে করুন। “১০০% নবায়নযোগ্য” জাতীয় দাবিও প্রায়ই বছরের হিসাব বা সনদ কেনার ভিত্তিতে হয়; প্রতি মুহূর্তের সবুজ বিদ্যুৎ বোঝায় না। এই ক্ষেত্রের নিয়ম আর হিসাব দ্রুত বদলাচ্ছে, তাই দাবিগুলো যাচাই করে নিন।

১০ · AI-এর যুগে নকশা review

AI খুব দ্রুত একটি review-র খসড়া দিতে পারে, আর সেটি পড়তেও সুন্দর লাগে। সমস্যা হলো, সে আপনার SLO, ঘণ্টার ক্ষতি, দলের আকার বা চুক্তি জানে না। তাই সে প্রায়ই “সেরা অনুশীলন” বলে সবচেয়ে দামি নকশা দেয়। Cloud-এর সাধারণ ভুলগুলোও আসে: * অনুমতি, 0.0.0.0/0 খোলা port, public storage, code-এ secret, latest tag, মুছে যাওয়া API version, আর বানানো flag ও resource argument. সাথে যোগ হয়: নিজে থেকে multi-region-এর পরামর্শ, স্বাধীন ধরে availability গুণ, egress বাদ দেওয়া, ভুল SLA সংখ্যা, আর সতর্কতা ছাড়া terraform destroy, kubectl delete বা rm -rf.

AI-এর review হাতে পেলে যাচাইয়ের চেকলিস্ট

• প্রতিটি সংখ্যার উৎস দেখেছি: হিসাব, দলিল, না অনুমান
• Availability-র হিসাবে correlated failure ধরা হয়েছে
• SLA, দাম ও সীমা provider-এর বর্তমান পাতায় মিলিয়েছি
• Fix-এর code আগে --dry-run বা terraform plan দিয়ে দেখেছি, diff পড়েছি
• অনুমতি, খোলা port আর public storage আলাদা করে পড়েছি
• Throwaway পরিবেশে পরীক্ষা করেছি, budget alert রেখেছি, শেষে মুছেছি
• Prompt-এ কোনো secret বা আসল account id দিইনি