🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧭 धडा 01 — platforms का: प्रत्येक शिक्षिका स्वतःचा वर्ग-संच बनवते

📍 तुम्ही इथे आहात: 12 पैकी धडा 01 · पुढे: lesson-02-platform-as-product

📦 या ब्रँचमध्ये काय आहे

हा संपूर्ण कोर्स ज्या समस्येबद्दल आहे ती. शाळा वाढते आहे. प्रत्येक नव्या शिक्षिकेला एक वर्गखोली लागते: बाके, projector, कुलूप, वेळापत्रकातला तास, प्रथमोपचार पेटी. आज प्रत्येक शिक्षिका आपला संच स्वतः बनवते, किंवा सुविधा कार्यालयाला विनंती लिहून रांगेत वाट पाहते. हा कोर्स त्या दिवसाबद्दल आहे जेव्हा सुविधा कार्यालय रांग असलेला counter न राहता एक service बनते: तयार संच, एक catalogue आणि एक बांधलेली वाट. software च्या भाषेत: internal developer platform (IDP) बनवणारी एक platform team. संपूर्ण कोर्सभर तुम्ही वापराल अशा खऱ्या files:

idp/office.py — भाग 1: cognitive load, ticket queue, त्रासांचा क्रम, scaffolder आणि catalog
idp/selfserve.py — भाग 2: quotas, preview environments, pipeline templates, secrets आणि config
idp/guard.py — भाग 3: policy, scorecards, DORA आणि portal पान
idp/demo.py — प्रत्येक धडा एक छोटा program म्हणून (python3 idp/demo.py <section>; sections: why product goldenpath catalog selfservice previews pipelines secrets policy scorecards measure portal)
idp/test_idp.py — कार्यालयाच्या नियमांवर 12 तपासण्या
demo-output.txt — निरोगी run काय छापतो

🎒 सुरू करण्याआधी: तुम्हाला फक्त Python 3 लागते, दुसरे काही नाही — cloud account नाही, pip install नाही. Package चे नाव idp आहे, platform नाही, कारण platform हा Python standard-library चा module आहे आणि त्या नावाचे folder तो लपवून टाकेल. idp/ मधले सगळे एक शिकवण्याचे मॉडेल आहे: ते मोजते, तपासते आणि नावे देते, पण खरे काहीही बनवत नाही. खऱ्या account वर असे लिहिलेल्या commands ना खरी tools (Backstage, Terraform, kubectl …) लागतात आणि त्यांना पैसे लागू शकतात.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

कतरिना ही विज्ञानाची नवी शिक्षिका आहे. पहिल्या दिवशी तिला एक वर्गखोली हवी आहे.

तिला कोणीच ती देत नाही. तिला बाके शोधावी लागतात. 🪑 projector च्या socket साठी electrician ला विचारावे लागते. किल्लीसाठी कुलूपवाल्याला विचारावे लागते. 🔑 तासासाठी वेळापत्रक लिपिकाला विचारावे लागते. प्रथमोपचार पेटीसाठी परिचारिकेला विचारावे लागते. प्रत्येकाकडे एक फॉर्म आहे. प्रत्येक फॉर्म एका ढिगात जातो.

ऐश्वर्या, गणित विभागाची प्रमुख, हे सगळे दहा वर्षांपूर्वी करून बसली होती. तिला त्यातले बरेचसे आठवते. पण ती प्रत्येक शुक्रवारी शिकवण्याऐवजी आपला projector दुरुस्त करण्यात घालवते.

सुविधा कार्यालयात एकच लिपिक आहे, दीपिका. रोज पाच शिक्षिका तिला लिहितात. ती रोज चार विनंत्या पूर्ण करू शकते. म्हणून रोज एक फॉर्म ढिगात जास्त वाट पाहतो. एका महिन्यानंतर, नव्या शिक्षिकेला साध्या किल्लीसाठी दिवसेंदिवस थांबावे लागते.

मग शाळेला एक कल्पना सुचते. कार्यालयाकडे तयार वर्ग-संच असले तर? 📦 बाके, socket, कुलूप आणि प्रथमोपचार पेटी, सगळे एकत्र, तपासलेले, सगळ्यांसाठी सारखे. शिक्षिका फळीवरून एक संच उचलते. ती अजूनही आपले धडे स्वतः शिकवते, आणि अजूनही आपली खोली स्वतः सांभाळते. फक्त तिला आधी खोली बांधावी लागत नाही.

🗺️ आकृती

flowchart LR
    subgraph before["😩 before: every teacher alone"]
      t1["👩‍🏫 Katrina<br/>14 concerns to handle"] --> q["📥 the office's ticket pile<br/>5 in, 4 out, every day"]
      q --> w["⏳ wait: 0 days on day 1,<br/>4 days on day 20"]
    end
    subgraph after["🛤️ after: the facilities office"]
      t2["👩‍🏫 Katrina<br/>keeps 4: code, tests,<br/>alerts, on-call"] --> k["📦 10 ready kits<br/>Dockerfile, CI, Terraform,<br/>IAM, DNS + TLS …"]
      k --> s["🏫 a classroom (service)<br/>the same day"]
    end

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/platform-engineering/lesson-diagrams.html#l01

❓ काय

Cognitive load — आपले काम करण्यासाठी एका team ला डोक्यात किती ठेवावे लागते ते. ही कल्पना मानसशास्त्रातून आली आणि Team Topologies या पुस्तकाने (Matthew Skelton आणि Manuel Pais, 2019) ती software teams पर्यंत आणली. ज्या team ला Kubernetes, IAM, Terraform, DNS आणि TLS आणि स्वतःचे product समजून घ्यावे लागते, तिच्याकडे product साठी कमी जागा उरते.
"You build it, you run it" — Werner Vogels (Amazon चे CTO), 2006 मध्ये: जी team service लिहिते तीच ती production मध्ये चालवते. यामुळे teams ना लवकर feedback मिळतो. पण जेव्हा प्रत्येक team ला ती ज्यावर चालते ते प्रत्येक tool सुद्धा बनवावे लागते, तेव्हा परिणाम म्हणजे थकवा: दहा teams त्याच समस्या दहा थोड्या वेगळ्या पद्धतींनी सोडवतात.
Ticket queue — जुने मॉडेल: एक मध्यवर्ती operations team विनंत्या घेते ("कृपया एक database बनवा") आणि त्या हाताने करते, आधी आलेले आधी. जेव्हा विनंत्या पूर्ण होण्यापेक्षा जास्त वेगाने येतात, तेव्हा रांग रोज वाढते आणि वाटही वाढते. (हे साधे queueing आहे: येणाऱ्या विनंत्या क्षमतेपेक्षा जास्त राहिल्या तर रांग कधीच कमी होत नाही.)
Platform team — अशी team जिचे ग्राहक इतर teams आहेत. Team Topologies इतरांना stream-aligned teams म्हणते (त्या product देतात) आणि म्हणते की platform ने त्यांचा cognitive load कमी करायला हवा.
Internal developer platform (IDP) — platform team देत असलेल्या self-service tools, templates आणि services चा संच. CNCF Platforms White Paper (2023) त्याचे वर्णन interfaces (portal, CLI, templates, APIs) मधून दिलेल्या capabilities (infrastructure, delivery, observability, security …) असे करते.
Undifferentiated work — असे काम जे प्रत्येक team ला करावे लागते पण जे त्यांच्या product ला वेगळे बनवत नाही: दहावी Dockerfile, दहावी CI file, दहावा alert route लिहिणे. हेच काम कार्यालय आपल्या हाती घेते.

🤔 का

कारण वाढणारी शाळा दोन्ही भिंतींवर एकाच वेळी आदळते. प्रत्येक शिक्षिकेने आपली खोली स्वतः बांधली तर प्रत्येकीला वेळ लागतो, आणि सगळ्या खोल्या वेगळ्या असतात — त्यामुळे कोणीच कोणाला मदत करू शकत नाही. एकाच लिपिकाने प्रत्येक खोली हाताने बांधली तर तो लिपिकच bottleneck बनतो. Platform हा तिसरा मार्ग आहे: कार्यालय संच एकदाच, चांगले बनवते, आणि शिक्षिका स्वतःची मदत स्वतः करतात. Service ची मालकी अजूनही team कडेच असते ("you build it, you run it" कायम राहते) — फक्त ती ज्या जमिनीवर उभी आहे ती पुन्हा पुन्हा शोधून काढणे थांबवते.

🔧 कसे (या repo मध्ये)

idp/office.py मधले cognitive_load(concerns, kits) एक service चालू करण्याच्या 14 CONCERNS ची विभागणी करते: team काय ठेवते आणि OFFICE_KITS काय सांभाळते. ticket_queue(arrivals_per_day, capacity_per_day) ही आधी आलेले आधी अशी रांग आहे: रोज नवीन tickets येतात, कार्यालय त्यातली जास्तीत जास्त capacity पूर्ण करते, आणि ते प्रत्येक पूर्ण झालेल्या ticket ची वाट (दिवसांत) आणि अजून किती वाट पाहत आहेत ते परत देते. idp/demo.py मधले why() रोज 5 विनंत्यांचे 20 कामाचे दिवस, 4 च्या capacity ने चालवते.

🧪 करून पाहा

python3 idp/demo.py why
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from office import ticket_queue, cognitive_load, CONCERNS, OFFICE_KITS
for cap in (4, 5, 6):
    waits, left = ticket_queue([5] * 20, cap)
    print(f"office does {cap}/day → average wait {sum(waits) / len(waits):.1f} days · longest {max(waits)} · still waiting {left}")
waits, left = ticket_queue([5] * 10 + [8] * 5 + [5] * 5, 5)
print(f"a busy week (8/day) with capacity 5 → longest wait {max(waits)} days · still waiting {left} at the end")
team, kits = cognitive_load(CONCERNS, OFFICE_KITS - {"backups"})
print(f"no backups kit → the team keeps {len(team)}: {team}")
EOF
python3 idp/test_idp.py

✅ तपासा — तुम्हाला काय दिसायला हवे

why हे छापते:

── to open one classroom (ship one service) a teacher's team must handle 14 concerns alone
   with the facilities office: the team keeps 4 (application code, tests, alerts, on-call for the service)
── the ticket queue: 5 requests a day, the office finishes 4 a day, for 20 working days
   finished 80 · still waiting 20 · average wait 2.0 days
   a ticket finished on day 1 waited 0 days · one finished on day 20 waited 4 days — the line grows by 1 every day

तुमचा snippet हे छापतो:

office does 4/day → average wait 2.0 days · longest 4 · still waiting 20
office does 5/day → average wait 0.0 days · longest 0 · still waiting 0
office does 6/day → average wait 0.0 days · longest 0 · still waiting 0
a busy week (8/day) with capacity 5 → longest wait 3 days · still waiting 15 at the end
no backups kit → the team keeps 5: ['application code', 'tests', 'alerts', 'backups', 'on-call for the service']

Tests शेवटी 12/12 passed छापतात.

🏁 तुम्ही आत्ताच काय सिद्ध केले

Capacity 5 असताना रांग कधीच तयार होत नाही. Capacity 4 असताना — रोज फक्त एक विनंती कमी — रांग रोज एकने वाढते आणि कधीच सावरत नाही. रोज 8 चा एक गर्दीचा आठवडा गर्दी संपल्यानंतरही 15 tickets वाट पाहत ठेवतो. जास्त लिपिक नेमल्याने भिंत पुढे सरकते; ती नाहीशी होत नाही, कारण शाळेबरोबर विनंत्याही वाढतात. Self-service रांगच काढून टाकते. आणि कार्यालय जो संच देत नाही तो परत team वर येऊन पडतो (वर backups).

📏 शिकवण्याचे मॉडेल: या रांगेत येणाऱ्या विनंत्या आणि capacity ठरलेल्या आहेत. खऱ्या विनंत्या अचानक झुंडीने येतात, त्यामुळे वाट या मॉडेलपेक्षा जास्त वाईट होते, चांगली नाही.

⚠️ नेहमीच्या चुका

कोणी त्रास मोजण्याआधीच, fashion आहे म्हणून platform बनवणे
platform team जी छान फॉर्म असलेली एक नवी ticket queue बनते
"आता production platform च्या मालकीचे आहे" — service आणि तिचा on-call अजूनही team च्याच मालकीचा आहे
सगळे लपवणे: ज्या संचाच्या आत teams पाहू किंवा बदलू शकत नाहीत तो सापळा बनतो
सगळ्यांवर एकच संच लादणे, खरोखर वेगळी गरज असलेल्या team वरही

🏭 प्रत्यक्ष वापरात

काहीही बनवण्याआधी, तुमच्याकडे आधीच असलेली रांग मोजा. खऱ्या account वर, बहुतेक ticket systems विनंत्या export करू शकतात; पहिल्या नजरेसाठी फक्त तीन columns लागतात:

# tickets.csv: created,resolved,type   (from Jira, ServiceNow, GitHub issues …)
python3 -c "
import csv, datetime as d, statistics as s, collections as c
rows = list(csv.DictReader(open('tickets.csv')))
wait = c.defaultdict(list)
for r in rows:
    t = d.datetime.fromisoformat
    wait[r['type']].append((t(r['resolved']) - t(r['created'])).days)
for k, v in sorted(wait.items(), key=lambda kv: -len(kv[1])):
    print(f'{k:<20} {len(v):>4} tickets · median wait {s.median(v)} days')
"

त्या यादीत सर्वात वर असलेले प्रकार — "new database", "new repo", "DNS record", "firewall change" — हेच आधी बनवायचे संच आहेत.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: platform चे समर्थन तो काढून टाकत असलेली वाट आणि पुनरावृत्तीचे काम यावरून होते. सुरू करण्याआधी दोन्ही लिहून ठेवा, म्हणजे नंतर कार्यालयाचा उपयोग झाला का हे तुम्ही दाखवू शकाल (धडा 11).

⏭️ पुढे

तुम्हाला का हे माहीत आहे. पुढचा प्रश्न आहे आधी काय बनवायचे — आणि त्याचे उत्तर कार्यालयाकडून नाही, तर शिक्षिकांकडून येते.

git checkout lesson-02-platform-as-product

🧭 Lesson 01 — Why platforms: every teacher building her own classroom kit

📍 You are here: Lesson 01 of 12 · Next: lesson-02-platform-as-product

📦 What's in this branch

The problem this whole course is about. The school is growing. Every new teacher needs a classroom: desks, a projector, a lock, a timetable slot, a first-aid box. Today every teacher builds her own kit, or writes a request to the facilities office and waits in line. This course is about the day the facilities office stops being a counter with a queue and becomes a service: ready kits, a catalogue and a paved path. In software words: a platform team building an internal developer platform (IDP). Real files you will use all the way through:

idp/office.py — part 1: cognitive load, the ticket queue, pain ranking, the scaffolder and the catalog
idp/selfserve.py — part 2: quotas, preview environments, pipeline templates, secrets and config
idp/guard.py — part 3: policy, scorecards, DORA and the portal page
idp/demo.py — every lesson as a small program (python3 idp/demo.py <section>; sections: why product goldenpath catalog selfservice previews pipelines secrets policy scorecards measure portal)
idp/test_idp.py — 12 checks on the office's rules
demo-output.txt — what a healthy run prints

🎒 Before you start: you need Python 3 and nothing else — no cloud account, no pip install. The package is called idp, not platform, because platform is a Python standard-library module and a folder with that name would hide it. Everything in idp/ is a teaching model: it counts, checks and names things, and creates nothing real. Commands marked on a real account need real tools (Backstage, Terraform, kubectl …) and can cost money.

🧒 Explain like I'm 5

Katrina is a new science teacher. On her first day she needs a classroom.

Nobody gives her one. She has to find desks. 🪑 Ask the electrician for a projector socket. Ask the locksmith for a key. 🔑 Ask the timetable clerk for a slot. Ask the nurse for a first-aid box. Each person has a form. Each form goes into a pile.

Aishwarya, the head of maths, did all this ten years ago. She remembers most of it. But she spends every Friday fixing her own projector instead of teaching.

The facilities office has one clerk, Dipika. Five teachers write to her each day. She can finish four requests a day. So every day one more form waits in the pile. After a month, a new teacher waits days for a simple key.

Then the school has an idea. What if the office had ready classroom kits? 📦 Desks, socket, lock and first-aid box, all in one, tested, the same for everybody. A teacher takes one from the shelf. She still teaches her own lessons, and she still looks after her own room. She just does not have to build the room first.

🗺️ Diagram

flowchart LR
    subgraph before["😩 before: every teacher alone"]
      t1["👩‍🏫 Katrina<br/>14 concerns to handle"] --> q["📥 the office's ticket pile<br/>5 in, 4 out, every day"]
      q --> w["⏳ wait: 0 days on day 1,<br/>4 days on day 20"]
    end
    subgraph after["🛤️ after: the facilities office"]
      t2["👩‍🏫 Katrina<br/>keeps 4: code, tests,<br/>alerts, on-call"] --> k["📦 10 ready kits<br/>Dockerfile, CI, Terraform,<br/>IAM, DNS + TLS …"]
      k --> s["🏫 a classroom (service)<br/>the same day"]
    end

🗺️ Drawn version + a lab: https://school-edh.pages.dev/platform-engineering/lesson-diagrams.html#l01

❓ What

Cognitive load — how much a team must hold in its head to do its work. The idea comes from psychology and was brought to software teams by the book Team Topologies (Matthew Skelton and Manuel Pais, 2019). A team that must understand Kubernetes, IAM, Terraform, DNS and TLS and its own product has less room left for the product.
"You build it, you run it" — Werner Vogels (Amazon's CTO) in 2006: the team that writes a service also operates it in production. It gives teams fast feedback. But when each team must also build every tool it runs on, the result is fatigue: ten teams solving the same problems ten slightly different ways.
The ticket queue — the old model: a central operations team receives requests ("please create a database") and does them by hand, first come, first served. When requests arrive faster than they are done, the line grows every day and so does the wait. (That is basic queueing: if arrivals stay above capacity, the line never shrinks.)
Platform team — a team whose customers are the other teams. Team Topologies calls the others stream-aligned teams (they deliver the product) and says the platform should reduce their cognitive load.
Internal developer platform (IDP) — the set of self-service tools, templates and services the platform team offers. The CNCF Platforms White Paper (2023) describes it as capabilities (infrastructure, delivery, observability, security …) offered through interfaces (a portal, a CLI, templates, APIs).
Undifferentiated work — work every team must do but that does not make their product different: writing the tenth Dockerfile, the tenth CI file, the tenth alert route. That is what the office takes over.

🤔 Why

Because a growing school hits both walls at once. If every teacher builds her own room, each one is slow, and all the rooms are different — so nobody can help anybody. If one clerk builds every room by hand, the clerk becomes the bottleneck. A platform is the third way: the office builds the kits once, well, and teachers help themselves. The team still owns its service ("you build it, you run it" stays) — it just stops re-inventing the ground it stands on.

🔧 How (in this repo)

cognitive_load(concerns, kits) in idp/office.py splits the 14 CONCERNS of shipping one service into what the team keeps and what OFFICE_KITS covers. ticket_queue(arrivals_per_day, capacity_per_day) is a first-come, first-served line: each day new tickets join, the office finishes up to capacity of them, and it returns the wait (in days) of every finished ticket plus how many are still waiting. why() in idp/demo.py runs 20 working days of 5 requests a day with a capacity of 4.

🧪 Try it

python3 idp/demo.py why
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from office import ticket_queue, cognitive_load, CONCERNS, OFFICE_KITS
for cap in (4, 5, 6):
    waits, left = ticket_queue([5] * 20, cap)
    print(f"office does {cap}/day → average wait {sum(waits) / len(waits):.1f} days · longest {max(waits)} · still waiting {left}")
waits, left = ticket_queue([5] * 10 + [8] * 5 + [5] * 5, 5)
print(f"a busy week (8/day) with capacity 5 → longest wait {max(waits)} days · still waiting {left} at the end")
team, kits = cognitive_load(CONCERNS, OFFICE_KITS - {"backups"})
print(f"no backups kit → the team keeps {len(team)}: {team}")
EOF
python3 idp/test_idp.py

✅ Verify — what you should see

why prints:

── to open one classroom (ship one service) a teacher's team must handle 14 concerns alone
   with the facilities office: the team keeps 4 (application code, tests, alerts, on-call for the service)
── the ticket queue: 5 requests a day, the office finishes 4 a day, for 20 working days
   finished 80 · still waiting 20 · average wait 2.0 days
   a ticket finished on day 1 waited 0 days · one finished on day 20 waited 4 days — the line grows by 1 every day

Your snippet prints:

office does 4/day → average wait 2.0 days · longest 4 · still waiting 20
office does 5/day → average wait 0.0 days · longest 0 · still waiting 0
office does 6/day → average wait 0.0 days · longest 0 · still waiting 0
a busy week (8/day) with capacity 5 → longest wait 3 days · still waiting 15 at the end
no backups kit → the team keeps 5: ['application code', 'tests', 'alerts', 'backups', 'on-call for the service']

The tests end with 12/12 passed.

🏁 What you just proved

With capacity 5 the line never forms. With capacity 4 — one request a day short — the line grows by one every day and never recovers. One busy week at 8 a day leaves 15 tickets waiting even after the rush ends. Hiring more clerks moves the wall; it does not remove it, because requests grow with the school. Self-service removes the line itself. And every kit the office does not offer lands back on the team (backups above).

📏 Teaching model: this queue has fixed arrivals and fixed capacity. Real request streams are bursty, which makes waits worse than this model shows, not better.

⚠️ Common mistakes

building a platform because it is fashionable, before anyone has measured the pain
a platform team that becomes a new ticket queue with a nicer form
"the platform owns production now" — the team still owns its service and its on-call
hiding everything: a kit teams cannot see into or change becomes a trap
forcing one kit on everybody, including the team with a truly different need

🏭 In production

Before you build anything, measure the queue you already have. On a real account, most ticket systems can export requests; a first look needs only three columns:

# tickets.csv: created,resolved,type   (from Jira, ServiceNow, GitHub issues …)
python3 -c "
import csv, datetime as d, statistics as s, collections as c
rows = list(csv.DictReader(open('tickets.csv')))
wait = c.defaultdict(list)
for r in rows:
    t = d.datetime.fromisoformat
    wait[r['type']].append((t(r['resolved']) - t(r['created'])).days)
for k, v in sorted(wait.items(), key=lambda kv: -len(kv[1])):
    print(f'{k:<20} {len(v):>4} tickets · median wait {s.median(v)} days')
"

The types at the top of that list — "new database", "new repo", "DNS record", "firewall change" — are the first kits to build.

🏭 Why this matters in production: a platform is justified by the wait and the repeated work it removes. Write both down before you start, so you can show later whether the office helped (lesson 11).

⏭️ Next

You know why. The next question is what to build first — and the answer comes from the teachers, not from the office.

git checkout lesson-02-platform-as-product

← Course homeall lessons Next →platform as product

This page is the lesson's README from the lesson-01-why-platforms branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.