Platform engineering — internal developer platform আর golden path

১ · সমস্যা: প্রতিটি দল একই pipeline আবার বানাচ্ছে

ঢাকার একটি কাল্পনিক সফটওয়্যার প্রতিষ্ঠান ধরি, নাম ক-সফট। শুরুতে ১০ জন প্রকৌশলী, একটি product, একটি pipeline. যিনি pipeline লিখেছেন, তিনি পাশের টেবিলেই বসেন। কিছু ভাঙলে নাম ধরে ডাকলেই চলে।

তিন বছর পর ক-সফটে ১০০ জন, ১৪টি দল, প্রায় ৯০টি service. এখন প্রতিটি দলকে নিজে থেকে জানতে হয় Dockerfile, pipeline, Kubernetes manifest, IAM role, secret, Terraform, dashboard আর alert. ছয়টি দল ছয় রকম pipeline লিখেছে। একটি দলে image scan আছে, অন্য দলে নেই। নতুন service খুলতে দুই সপ্তাহ লাগে। অথচ এর একটি কাজও গ্রাহকের চোখে পড়ে না।

এই চাপের নাম cognitive load, যা পর্ব ৭-এ দেখেছেন: একটি দলকে একসাথে কতটা জিনিস মাথায় রাখতে হয়। মনোবিজ্ঞানী John Sweller ১৯৮৮ সালে এই তত্ত্ব দাঁড় করান, আর Team Topologies (২০১৯) একে দলের নকশায় আনে। সহজ করে তিন ভাগ:

Platform-এর লক্ষ্য extraneous অংশটি কমানো, যাতে germane অংশে মাথা খাটানো যায়। আগের পর্বগুলোতে আপনি pipeline (পর্ব ৫৭), GitOps (পর্ব ৬০) আর DevSecOps (পর্ব ৬১) পড়েছেন। সব জিনিস একসাথে প্রতিটি দলের ঘাড়ে চাপালে তা-ই সমস্যা হয়ে দাঁড়ায়। এই পর্বের প্রশ্ন: এত ভালো চর্চা দলগুলোর মাথায় না চাপিয়ে তাদের হাতে পৌঁছাবে কীভাবে?

২ · Platform একটি পণ্য, আর গ্রাহক আপনার ডেভেলপাররা

Platform engineering মানে ডেভেলপারদের জন্য ভেতরের self-service সেবা পণ্যের মতো বানানো ও চালানো। Platform team সেই কাজটি করে। Evan Bottcher ২০১৮ সালে martinfowler.com-এ একটি বহুল উদ্ধৃত সংজ্ঞা দেন, যার সারকথা: platform হলো self-service API, tool, সেবা, জ্ঞান আর সহায়তার ভিত্তি, যা আকর্ষণীয় একটি ভেতরের পণ্য হিসেবে সাজানো।

সংজ্ঞার শেষ শব্দটিই আসল: পণ্য। Platform as a product মানে এই নয় যে আপনি এটি বিক্রি করবেন। মানে হলো, পণ্য বানাতে যা যা করতে হয়, এখানেও তাই করতে হবে:

নামের গোলমাল পরিষ্কার করা দরকার। “Platform” শব্দটি অনেক অর্থে চলে, আর লেখকভেদে সীমারেখা আলাদা।

৩ · Internal developer platform-এর ভেতরে কী থাকে

Internal developer platform (IDP) কোনো একটি software নয়। এটি কয়েকটি tool আর API-র একটি সাজানো ব্যবস্থা। চারটি ধারণা মনে রাখুন:

• Self-service: মানুষকে অনুরোধ না করে নিজেই পাওয়া। ATM থেকে টাকা তোলার মতো, ব্যাংকের কাউন্টারে লাইন দেওয়ার মতো নয়।
• Golden path: সবচেয়ে প্রচলিত কাজের জন্য আগে থেকে তৈরি, সমর্থিত পথ। Spotify “golden path” আর Netflix “paved road” শব্দ ব্যবহার করে বলে পরিচিত। মূল ভাব এক: নিরাপদ পথটিকেই সবচেয়ে সহজ পথ করা।
• Software template: নতুন service-এর ছাঁচ। রান্নাঘরের রেসিপি খাতার মতো, যেখানে উপকরণের পরিমাণ শুধু বসিয়ে দিতে হয়।
• Service catalog: সব service-এর তালিকা, মালিকের নাম আর নির্ভরতাসহ। রাত দুইটায় কোনো service ভাঙলে “এটি কার?” প্রশ্নের উত্তর এখানে।

নিচের ছবিতে স্তরগুলো দেখুন। ওপর থেকে নিচে নামলে নিয়ন্ত্রণ বাড়ে, কিন্তু জটিলতাও বাড়ে। ডেভেলপার ওপরের স্তরে থাকেন, আর জটিলতা নিচের স্তরে ঢাকা থাকে।

Backstage: একটি পরিচিত portal

Backstage Spotify-র ভেতরে তৈরি হয়। ২০২০ সালে এটি open source হয় আর একই বছর CNCF-তে যায়। এর স্তর (maturity) সময়ের সাথে বদলায়, তাই বর্তমান অবস্থা CNCF-এর পাতায় দেখুন। ধারণাগতভাবে এতে আছে software catalog, software template, প্রযুক্তিগত documentation আর plugin ব্যবস্থা।

গুরুত্বপূর্ণ কথা হলো, Backstage একটি প্রস্তুত পণ্য নয়, portal বানানোর framework. এটি নিজে deployment করে না, অন্য tool-কে ডাকে। প্রতিটি service-এর repository-তে একটি ছোট ফাইল catalog-কে পরিচয় দেয়:

উদাহরণ (পড়ার জন্য, এখানে চালানো হয়নি):

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: order-api
  description: Takes and tracks customer orders
spec:
  type: service
  lifecycle: production
  owner: team-orders
  dependsOn:
    - resource:default/orders-db

নিচের ইঞ্জিন: Terraform, Crossplane আর Kubernetes

Portal শুধু দরজা। Cloud-এ আসল কাজ করে নিচের স্তর, আর সেখানে আপনার পরিচিত tool-ই আছে:

• Terraform module (পর্ব ৫৪): Platform দল একটি যাচাই করা module লেখে, ডেভেলপার তিনটি input দেন। অনুরোধ এলে pipeline terraform plan আর apply চালায়। State আর plan review-এর নিয়ম আগের মতোই থাকে।
• Crossplane: Kubernetes-এর CRD দিয়ে নিজের API বানানোর উপায় (পর্ব ৫০)। Reconcile loop cloud resource-কে অবিরাম মিলিয়ে রাখে। Platform দল ঠিক করে ছোট একটি অনুরোধ নিচে কোন কোন resource হবে।
• Kubernetes: ভিত্তি, শেষ গন্তব্য নয়। Kubernetes-এর নিজের documentation বলে এটি developer platform বানানোর উপকরণ দেয়, সর্বাঙ্গীণ PaaS নয়।

যেমন, একটি প্রতিষ্ঠান নিজের API এভাবে নকশা করতে পারে। নিচের Database kind কোনো tool-এর নিজস্ব নয়, এটি একটি কাল্পনিক ভেতরের API:

উদাহরণ (কাল্পনিক CRD, এখানে চালানো হয়নি):

apiVersion: platform.example.com/v1alpha1
kind: Database
metadata:
  name: orders-db
  namespace: team-orders
spec:
  engine: postgres
  size: small
  environment: staging

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

৪ · Golden path: নতুন service ২০ মিনিটে

ক-সফটের ডেলিভারি দল একটি নতুন service চায়: order-api. নিচের stepper-এ একই কাজ দুটি পথে পাশাপাশি চলছে। সব সময় অনুমিত, তবে চিত্রটি বহু প্রতিষ্ঠানে পরিচিত।

খেয়াল করুন, golden path নিরাপত্তা পর্যালোচনা বাদ দেয়নি। পর্যালোচনা হয়েছে একবার, template-এর ওপর। প্রতিটি service-এ আলাদা করে নয়। এটিই বড় কৌশল: নিয়ম মানা কাজটি মানুষের মনে রাখার ওপর না রেখে ছাঁচের ভেতরে ঢুকিয়ে দেওয়া।

Template কীভাবে ফাইল বানায়

Scaffolding মানে template আর input থেকে নতুন প্রকল্পের শুরুর ফাইল তৈরি করা। ভেতরে জাদু নেই: input যাচাই, কয়েকটি মান হিসাব, তারপর ফাঁকা ঘর পূরণ। নিচের ছোট generator চালান। Input বদলে দেখুন কোনটি গৃহীত হয় আর কোনটি ফিরে আসে।

// A tiny service scaffold generator: template + inputs -> files. Nothing is really created.
const TEMPLATE = {
  "catalog-info.yaml": "kind: Component\nmetadata:\n  name: {{name}}\nspec:\n  owner: {{owner}}\n  lifecycle: {{lifecycle}}",
  "deploy/values.yaml": "image: registry.example.com/{{name}}:v0.1.0\nport: {{port}}\nreplicas: {{replicas}}",
  ".ci/pipeline.yaml": "uses: platform/pipelines/node@v3\nservice: {{name}}",
};
const OWNERS = ["team-orders", "team-delivery"], TIERS = ["critical", "normal", "experiment"];

function validate(i) {
  const bad = [];
  if (!/^[a-z][a-z0-9-]{2,30}$/.test(i.name)) bad.push(`name "${i.name}": use lowercase, digits, -`);
  if (!OWNERS.includes(i.owner)) bad.push(`owner "${i.owner}": must be a known team`);
  if (i.port < 1024 || i.port > 65535) bad.push(`port ${i.port}: non-root needs 1024-65535`);
  if (!TIERS.includes(i.tier)) bad.push(`tier "${i.tier}": unknown`);
  return bad;
}
function render(text, vars) {
  return text.replace(/\{\{(\w+)\}\}/g, (m, key) => {
    if (!(key in vars)) throw new Error("template needs " + key);
    return vars[key];
  });
}
function scaffold(input) {
  console.log(`--- request: ${input.name} ---`);
  const bad = validate(input);
  if (bad.length) { bad.forEach(b => console.log("  REJECTED " + b)); return; }
  const vars = { ...input, replicas: input.tier === "critical" ? 3 : input.tier === "normal" ? 2 : 1,
    lifecycle: input.tier === "experiment" ? "experimental" : "production" };
  for (const [file, text] of Object.entries(TEMPLATE))
    console.log(`# ${file}\n${render(text, vars)}`);
}

scaffold({ name: "order-api", owner: "team-orders", port: 8080, tier: "critical" });
scaffold({ name: "Order_API", owner: "rafi", port: 80, tier: "critical" });

--- request: order-api ---
# catalog-info.yaml
kind: Component
metadata:
  name: order-api
spec:
  owner: team-orders
  lifecycle: production
# deploy/values.yaml
image: registry.example.com/order-api:v0.1.0
port: 8080
replicas: 3
# .ci/pipeline.yaml
uses: platform/pipelines/node@v3
service: order-api
--- request: Order_API ---
  REJECTED name "Order_API": use lowercase, digits, -
  REJECTED owner "rafi": must be a known team
  REJECTED port 80: non-root needs 1024-65535

Backstage-এ এই কাজটি একটি YAML-এ লেখা থাকে। Form, ফাইল তৈরি, Git-এ পাঠানো আর catalog-এ নিবন্ধন, চারটিই এখানে দেখা যায়। Git-এ কোড পাঠাতে একটি integration আগে থেকে সেট করা লাগে।

উদাহরণ (পড়ার জন্য, এখানে চালানো হয়নি, action-এর নাম version-ভেদে আলাদা হতে পারে):

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: node-service
  title: Node.js service
spec:
  owner: group:default/platform
  type: service
  parameters:
    - title: Service details
      required: [name, owner]
      properties:
        name:
          title: Name
          type: string
          pattern: '^[a-z][a-z0-9-]{2,30}$'
        owner:
          title: Owner team
          type: string
  steps:
    - id: fetch
      name: Fill the skeleton
      action: fetch:template
      input:
        url: ./skeleton
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      name: Create the repository
      action: publish:github
      input:
        repoUrl: github.com?owner=example-org&repo=${{ parameters.name }}
        description: Service from the golden path
    - id: register
      name: Add to the catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml

৫ · Escape hatch: পথের বাইরে যাওয়ার নিয়ম

পাকা রাস্তা সব গ্রামে যায় না। কোথাও কাঁচা পথ ধরতে হয়। সরকার সেই পথ বন্ধ করে না, তবে সেখানে নিজের দায়িত্বে যেতে হয়, আর ট্রাফিক আইন তখনও বহাল থাকে। Golden path-এর escape hatch ঠিক এমন।

একটি ভালো platform তিনটি জিনিস আলাদা রাখে: কী সহজ করে দেওয়া হয়েছে (template), কী নিজে করা যায় (escape hatch), আর কী কোনোভাবেই ভাঙা যায় না (guardrail, পর্ব ৩৫)। নিচে একটি কাল্পনিক ছবি-খোঁজা দলকে দেখুন, যাদের GPU লাগবে।

৬ · পাতলা platform আর X-as-a-Service

নতুন platform দলের সবচেয়ে সাধারণ ভুল হলো প্রথম দিনেই বিশাল নকশা। Team Topologies বই এর বিপরীতে একটি ধারণা দেয়: thinnest viable platform (TVP). মানে, দলগুলোকে এগিয়ে নিতে যতটুকু না হলেই নয়, ঠিক ততটুকু। বইটির মতে, শুরুতে এটি একটি wiki পাতাও হতে পারে, যেখানে লেখা আছে কোন cloud সেবা কীভাবে ব্যবহার করতে হবে।

এখানে “পাতলা” মানে দুর্বল নয়। মানে হলো, নিজে কম বানানো। Cloud-এর managed সেবা যতটা পারে করুক, আর platform শুধু সেটুকু যোগ করুক যা আপনার প্রতিষ্ঠানে আলাদা। Platform যত মোটা, রক্ষণাবেক্ষণের বোঝাও তত বড়।

দল কীভাবে কথা বলবে

Team Topologies তিন ধরনের মিথস্ক্রিয়া বর্ণনা করে। পর্ব ৭-এ দলের ধরন দেখেছেন, এখানে দলগুলোর সম্পর্ক দেখুন।

X-as-a-Service মানে অন্য দলের সাথে কথা বন্ধ করা নয়। মানে হলো, স্বাভাবিক কাজের জন্য কথার দরকার না হওয়া। বিদ্যুৎ বিলের মতো: প্রতিবার সুইচ চাপার আগে আপনি বিদ্যুৎ অফিসে ফোন করেন না। তবে নতুন লাইন বা গোলযোগে যোগাযোগের পথ খোলা থাকে। মিথস্ক্রিয়ার ধরনও বদলায়: একটি pilot দলের সাথে collaboration থেকে শুরু, তারপর ধীরে X-as-a-Service.

৭ · লাভ হচ্ছে কি: toil, onboarding আর payback

Platform দল বিনামূল্যে আসে না। তাই হিসাব দরকার। Toil (পর্ব ৭) কতটা কমল, নতুন মানুষ কত দ্রুত কাজে নামলেন, নতুন service কত সহজে হলো। এখানে টাকা নয়, ঘণ্টায় হিসাব করি, কারণ বেতন প্রতিষ্ঠানভেদে আলাদা।

পূর্ণ সমাধান, ক-সফট ৩০ জনে। ধরি T = ৬০ ঘণ্টা, c = ০.৫, H = ৪, h = ৮০ − ২৪ = ৫৬ ঘণ্টা, S = ৩, s = ১২০ − ৮ = ১১২ ঘণ্টা।

• Toil: ৩০ × ৬০ × ০.৫ = ৯০০ ঘণ্টা
• Onboarding: ৪ × ৫৬ = ২২৪ ঘণ্টা
• নতুন service: ৩ × ১১২ = ৩৩৬ ঘণ্টা
• মোট F = ১,৪৬০ ঘণ্টা, আর ১,৪৬০ ÷ ৪৮০ ≈ ৩.০৪ জন

অর্থাৎ ১০০% ব্যবহার হলেও ৩ জনের বেশি দল খরচ তুলতে পারবে না। বাস্তবে ব্যবহার ধীরে বাড়ে, প্রথম কয়েকটি Q-তে সাশ্রয় প্রায় শূন্য। নিচের simulator ১২টি Q-র হিসাব দেখায়। adopt মানে কতটা কাজ platform-এ এসেছে, reach মানে platform F-এর কতটা ধরতে পারে।

// Does a platform team pay back? Every number is ASSUMED, and the unit is hours, not money.
const QUARTER = 480;                     // one engineer, one quarter: 40 h x 12 weeks
const TOIL = 60, CUT = 0.5;              // toil per engineer per quarter; share a platform removes
const HIRE = 80 - 24, SERVICE = 120 - 8; // hours saved per new hire, per new service
const SLOW = [0, 0.1, 0.3, 0.5, 0.7, 0.8, 0.85, 0.9, 0.9, 0.9, 0.9, 0.9]; // share of work on it
const FAST = [0.2, 0.5, 0.7, 0.8, 0.85, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9]; // thin ships sooner

function run(name, s) {
  let net = 0, payback = "never in 12 quarters", rows = [];
  for (let q = 0; q < 12; q++) {
    const eng = s.eng + s.grow * q;
    const full = (eng * TOIL * CUT + s.hires * HIRE + s.services * SERVICE) * s.reach;
    const saved = Math.round(s.adopt[q] * full), cost = s.people * QUARTER;
    net += saved - cost;
    if (net >= 0 && payback.startsWith("never")) payback = "Q" + (q + 1);
    rows.push(`  Q${q + 1}: eng ${eng}, saved ${saved}, cost ${cost}, running total ${net}`);
  }
  console.log(`${name}: payback ${payback}, 12-quarter total ${net} h`);
  if (s.show) console.log(rows.join("\n"));
}

run("A. 10 eng, 1 person", { eng: 10, grow: 0, hires: 1, services: 1, people: 1, reach: 1, adopt: SLOW });
run("B. 30 eng, team of 4", { eng: 30, grow: 2, hires: 4, services: 3, people: 4, reach: 1, adopt: SLOW });
run("C. 30 eng, thin, 1 person", { eng: 30, grow: 2, hires: 4, services: 3, people: 1, reach: 0.6, adopt: FAST });
run("D. 100 eng, team of 6", { eng: 100, grow: 4, hires: 12, services: 8, people: 6, reach: 1, adopt: SLOW, show: true });

A. 10 eng, 1 person: payback never in 12 quarters, 12-quarter total -2134 h
B. 30 eng, team of 4: payback never in 12 quarters, 12-quarter total -8449 h
C. 30 eng, thin, 1 person: payback Q4, 12-quarter total 4522 h
D. 100 eng, team of 6: payback Q9, 12-quarter total 7393 h
  Q1: eng 100, saved 0, cost 2880, running total -2880
  Q2: eng 104, saved 469, cost 2880, running total -5291
  Q3: eng 108, saved 1442, cost 2880, running total -6729
  Q4: eng 112, saved 2464, cost 2880, running total -7145
  Q5: eng 116, saved 3534, cost 2880, running total -6491
  Q6: eng 120, saved 4134, cost 2880, running total -5237
  Q7: eng 124, saved 4495, cost 2880, running total -3622
  Q8: eng 128, saved 4867, cost 2880, running total -1635
  Q9: eng 132, saved 4975, cost 2880, running total 460
  Q10: eng 136, saved 5083, cost 2880, running total 2663
  Q11: eng 140, saved 5191, cost 2880, running total 4974
  Q12: eng 144, saved 5299, cost 2880, running total 7393

৮ · Adoption আর পরিমাপ: জোর করলে কী হয়

Adoption rate মানে কত দল সত্যিই platform ব্যবহার করছে। Payback-এর হিসাবে এটিই সবচেয়ে বড় চলক। স্বাভাবিক লোভ আসে: “সবাইকে বাধ্য করি!” নিচের মডেলে ৪০টি দল, ১২টি Q. একটি বীজ-ভিত্তিক (seeded) random generator ব্যবহার হয়েছে, তাই প্রতিবার একই ফল। ভালো পণ্য হলে দলগুলো একে অন্যের মুখে শুনে আসে। বাধ্য করলে কিছু দল শুধু কাগজে যোগ দেয়, কিন্তু নিজের পুরোনো script চালিয়ে যায়।

// Adoption over 12 quarters for 40 teams. A seeded model, not data from any company.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0;
  let t = Math.imul(a ^ (a >>> 15), 1 | a); t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const TEAMS = 40, QUARTERS = 12;

// quality 0..1: how much better the path feels. mandateAt: quarter of the order, or 0.
function simulate(quality, mandateAt, seed) {
  const rnd = mulberry32(seed), state = new Array(TEAMS).fill("own"), out = [];
  for (let q = 1; q <= QUARTERS; q++) {
    const real = state.filter(s => s === "real").length;
    const pull = (0.05 + 0.7 * real / TEAMS) * quality;   // word of mouth needs a good product
    state.forEach((s, i) => {
      if (s === "own" && rnd() < pull) state[i] = "real";
      else if (s === "own" && q === mandateAt) state[i] = rnd() < quality ? "real" : "paper";
      else if (s === "paper" && rnd() < pull / 2) state[i] = "real";
    });
    const r = state.filter(s => s === "real").length;
    out.push({ real: r, paper: state.filter(s => s === "paper").length });
  }
  return out;
}

const pad = v => String(v).padStart(3);
const good = simulate(0.9, 0, 7), weak = simulate(0.35, 0, 7), forced = simulate(0.35, 4, 7);
console.log("real use out of 40 teams; forced column = real + on-paper-only");
console.log("  Q | voluntary,good | voluntary,weak | forced,weak");
for (let q = 0; q < QUARTERS; q++)
  console.log(`${pad(q + 1)} |${pad(good[q].real).padStart(15)} |${pad(weak[q].real).padStart(15)} | ${pad(forced[q].real)} + ${forced[q].paper}`);

const last = forced[QUARTERS - 1], bar = n => "#".repeat(n).padEnd(TEAMS, ".");
console.log("reported  " + bar(last.real + last.paper) + " " + (last.real + last.paper));
console.log("real use  " + bar(last.real) + " " + last.real);

real use out of 40 teams; forced column = real + on-paper-only
  Q | voluntary,good | voluntary,weak | forced,weak
  1 |              2 |              1 |   1 + 0
  2 |              5 |              3 |   3 + 0
  3 |              8 |              6 |   6 + 0
  4 |             13 |              8 |  12 + 28
  5 |             14 |              8 |  12 + 28
  6 |             16 |              8 |  12 + 28
  7 |             21 |              8 |  13 + 27
  8 |             26 |             11 |  14 + 26
  9 |             32 |             14 |  16 + 24
 10 |             37 |             17 |  16 + 24
 11 |             38 |             18 |  16 + 24
 12 |             40 |             20 |  18 + 22
reported  ######################################## 40
real use  ##################...................... 18

কী মাপবেন

একটি মাত্র সংখ্যায় platform-এর বিচার হয় না। চারটি স্তরে দেখুন, আর শুরুর দিনের সংখ্যা লিখে রাখুন। শুরুর সংখ্যা না থাকলে উন্নতি প্রমাণ করা যায় না।

DORA এখনকার delivery দেখায়, কিন্তু ডেভেলপারের অভিজ্ঞতা পুরো দেখায় না। SPACE (Forsgren ও সহলেখকরা, ACM Queue, ২০২১) বলে, উৎপাদনশীলতা একটি সংখ্যা নয়। এর পাঁচটি দিক হলো Satisfaction, Performance, Activity, Communication আর Efficiency. পরামর্শ হলো, অন্তত তিনটি দিক থেকে মাপুন। শুধু commit গুনলে মানুষ commit-ই বাড়াবে।

৯ · কখন দরকার নেই, build না buy, আর তিন বড় ঝুঁকি

ক-সফট ১০ থেকে ১০০ জনে বাড়ল। প্রতিটি আকারে সিদ্ধান্ত আলাদা। আগের অংশের F সূত্রই এখানে কাজে লাগছে (T = ৬০, c = ০.৫, h = ৫৬, s = ১১২)। সংখ্যাগুলো উদাহরণ, কোনো সর্বজনীন অনুপাত নয়।

ছোট প্রতিষ্ঠানের সরল নিয়ম: platform দল গঠনের আগে দেখুন, একটি PaaS, একটি monolith বা অল্প কয়েকটি service, আর একটি ভাগ করা pipeline দিয়ে কাজ চলে কি না। Kubernetes আর portal নিজেই বোঝা যোগ করে। কয়েকটি সংকেত দেখা গেলে ভাবুন: একই প্রশ্ন বারবার আসছে, নতুন service খুলতে সপ্তাহ লাগছে, নিরাপত্তার মান দলভেদে আলাদা, নতুন লোকের কাজে নামতে মাসখানেক লাগছে।

Build না buy

সাধারণ পরামর্শ: যা আপনাকে বাজারে আলাদা করে না, তা নিজে বানাবেন না। আর লাইসেন্স ফি শূন্য হলেও open source বিনামূল্যে নয়, কারণ মানুষের সময় লাগে। দাম, লাইসেন্স আর সুবিধা বদলায়, তাই প্রতিটি পথ নিজের হিসাবে যাচাই করুন।

তিন বড় ঝুঁকি

আরও দুটি ঝুঁকি মনে রাখুন। প্রথমত, platform নিজেই একক ব্যর্থতার বিন্দু হয়ে উঠতে পারে: pipeline বন্ধ মানে সবার deployment বন্ধ। তাই platform-এরও SLO, on-call আর runbook লাগে। দ্বিতীয়ত, প্রতিটি নতুন আবরণ নতুন শেখার বোঝা। ভুল abstraction ডেভেলপারের cognitive load না কমিয়ে উল্টো বাড়াতে পারে।

১০ · AI-এর যুগে platform: ভালো ছাঁচ, নাকি দ্রুত ছড়ানো ভুল

AI দিয়ে template বা Terraform module লেখা খুব দ্রুত। কিন্তু মনে রাখুন, template-এর ভুল একটি জায়গায় থাকে না। একটি ভুল প্রতিটি নতুন service-এ কপি হয়। Golden path যে শক্তিতে ভালো চর্চা ছড়ায়, একই শক্তিতে ভুলও ছড়ায়। তাই platform কোডে AI-এর খসড়া আরও কড়াভাবে পড়তে হবে।

Platform-এ AI-এর খসড়া মানার আগে

• terraform plan বা --dry-run দেখেছি, আর diff লাইন ধরে পড়েছি
• Template থেকে একটি নমুনা service বানিয়ে throwaway পরিবেশে চালিয়েছি, আর পরে মুছে দিয়েছি
• * permission, 0.0.0.0/0, public storage, hardcoded secret আর latest নেই
• প্রতিটি action, flag আর API version official docs-এ মিলিয়েছি
• Budget alert চালু আছে, আর প্রস্তাবিত ব্যবস্থার খরচ হিসাব করেছি
• Prompt-এ কোনো secret, key বা আসল account id দিইনি
• Template বদলালে আগের service-গুলোর কী হবে, তা ভেবে দেখেছি