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

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

🧰 धडा 05 — Self-service infrastructure: कार्यालयाकडे मागा, लगेच मिळवा

📍 तुम्ही इथे आहात: 12 पैकी धडा 05 · मागे: lesson-04-service-catalog · पुढे: lesson-06-preview-environments

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

धडे 01–04, आणि धडा 02 मधला सर्वात मोठा त्रास: ticket शिवाय database मिळवणे. Team एका ठरलेल्या menu मधून (कार्यालय देत असलेल्या गोष्टींचा catalogue) resource मागते; विनंती team च्या quota शी आणि नावाच्या नियमाशी तपासली जाते; ती बसली तर owner tags सह लगेच provision होते; नाही बसली तर नकार काय करायचे ते सांगतो. idp/selfserve.py मधले OFFERINGS आणि Provisioner, idp/demo.py मधले selfservice().

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

सुविधा कार्यालयाच्या भिंतीवर आता एक मेनू आहे. 📋

लहान कपाट (postgres-small) — 2 फरश्या जागा घेते
मोठे कपाट (postgres-medium) — 4 फरश्या जागा घेते
एक पेटी (bucket) · कप्प्यांची मांडणी (queue)

प्रत्येक विभागाची एक मर्यादा आहे. विज्ञान विभागाला 2 कपाटे, 3 पेट्या, 2 मांडण्या, आणि एकूण 6 फरश्या मिळू शकतात.

कतरिना exam results साठी मोठे कपाट मागवते: ✅ लगेच तयार, "owner: science" अशा लेबलसह. मग lab साठी लहान कपाट: ✅ तयार — आता सगळ्या 6 फरश्या वापरल्या गेल्या. मग तिसरे कपाट: ❌ "विज्ञान विभागाकडे आधीच 2 पैकी 2 कपाटे आहेत — एक परत करा, किंवा मोठी मर्यादा मागा." मग एक "MongoDB wardrobe": ❌ "ते मेनूवर नाही — मेनूवर हे आहे, किंवा आम्हाला ते जोडायला सांगा."

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

🗺️ आकृती

flowchart LR
    k["👩‍🏫 science asks:<br/>postgres-medium results-db"] --> m{"📋 on the menu?"}
    m -->|"no: mongodb"| r1["❌ offered: postgres-small,<br/>postgres-medium, bucket, queue"]
    m -->|"yes"| q{"📏 quota left?<br/>databases 2 · cpu 6"}
    q -->|"no: 3rd database"| r2["❌ 2/2 databases —<br/>delete one or ask for more"]
    q -->|"yes"| p["✅ science-results-db<br/>tags: owner=science,<br/>managed-by=facilities-office"]

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

❓ काय

Self-service — team ला हवे ते एखाद्या व्यक्तीकडे नाही, तर system कडे मागून मिळते. विनंती आपोआप तपासली जाते आणि काही मिनिटांत पूर्ण होते.
Offering (मेनूमधला पदार्थ) — platform आधार देत असलेला resource प्रकार, ज्याचे sizes आणि defaults आधीच ठरलेले असतात: backups चालू, encryption चालू, योग्य network, योग्य tags. Team एका लहान menu मधून निवडते; त्यामागे जे आहे त्याची मालकी कार्यालयाकडे असते.
Quota — प्रत्येक team ची मर्यादा (किती databases, किती CPU). Quotas मुळे self-service सुरक्षित होते: एखादी चूक किंवा बेलगाम script संपूर्ण बजेट खाऊ शकत नाही. Kubernetes मध्ये प्रत्येक namespace साठी built-in ResourceQuota असतो; clouds मध्ये account-level quotas असतात; platform अनेकदा प्रत्येक team साठी स्वतःचे quotas जोडतो.
Abstraction — team "एक medium Postgres" मागते, 40 Terraform resources नाही. हे बनवणारी tools: Terraform modules (काही inputs असलेला पुन्हा वापरता येणारा block), Crossplane (platform स्वतःचा Kubernetes API ठरवतो, जसे PostgreSQLInstance, आणि त्याला खऱ्या cloud resources मध्ये बदलणारी एक Composition), आणि AWS Service Catalog सारखे cloud service catalogs.
Tags / labels — प्रत्येक resource वर owner आणि managed-by असतात, म्हणजे cost reports आणि catalog (धडा 04) ला ते कोणाचे आहे ते कळते.
मार्ग दाखवणारा नकार — scaffolder सारखाच, प्रत्येक "नाही" सोबत पुढची पायरी असते: लहान size, एक काढून टाका, किंवा जास्त मागा.

🤔 का

कारण धडा 01 मधली ticket queue बहुतांशी पुन्हा पुन्हा येणाऱ्या विनंत्यांची होती: "माझ्या service साठी एक Postgres", पुन्हा पुन्हा, प्रत्येक वेळी हाताने, प्रत्येक वेळी थोडी वेगळी. सर्वात सामान्य विनंतीला menu item बनवल्याने वाट आणि फरक दोन्ही नाहीसे होतात. Quotas मुळे खर्च आणि धोका नियंत्रणात ठेवण्यासाठी कार्यालयाला प्रत्येक विनंती तपासावी लागत नाही — नियम ते करतो.

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

idp/selfserve.py मधले OFFERINGS हा menu आहे: प्रत्येक item सांगतो की तो कोणत्या quota मधून मोजला जातो आणि किती CPU वापरतो. Provisioner(quotas) प्रत्येक team चा quota आणि वापर ठेवतो. request(team, kind, name) या क्रमाने तपासते: ते menu वर आहे का, नाव वैध आहे का, team कडे तो quota आहे का, त्यातला एखादा शिल्लक आहे का, पुरेसे CPU शिल्लक आहे का. यश मिळाले की <team>-<name> नावाचा resource owner आणि managed-by tags सह परत मिळतो. ते खरे काहीच बनवत नाही — हे cloud चे नाही, तर निर्णयाचे शिकवण्याचे मॉडेल आहे.

🧪 करून पाहा

python3 idp/demo.py selfservice
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from selfserve import Provisioner
p = Provisioner({"maths": {"databases": 1, "buckets": 1, "queues": 0, "cpu": 2}})
for kind, name in (("postgres-medium", "timetable-db"), ("postgres-small", "timetable-db"), ("queue", "swaps"),
                   ("bucket", "Old_Papers"), ("bucket", "old-papers"), ("bucket", "more-papers")):
    status, out = p.request("maths", kind, name)
    print(f"{kind:<15} {name:<13} → {status}: {out['id'] if status == 'ready' else out}")
print("maths used:", p.used["maths"])
EOF

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

selfservice हे छापते:

── science's quota: 2 databases, 3 buckets, 2 queues, 6 CPU — requests go to the office's catalogue, not a ticket
   postgres-medium results-db    → ready: science-results-db {'owner': 'science', 'managed-by': 'facilities-office'}
   postgres-small  lab-db        → ready: science-lab-db {'owner': 'science', 'managed-by': 'facilities-office'}
   postgres-small  extra-db      → refused: science already uses 2/2 databases — delete one or ask for a bigger quota
   used now: {'databases': 2, 'buckets': 1, 'queues': 1, 'cpu': 6}

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

postgres-medium timetable-db  → refused: postgres-medium needs 4 CPU, maths has 2 of 2 left — pick a smaller size or ask for more
postgres-small  timetable-db  → ready: maths-timetable-db
queue           swaps         → refused: maths has no queues in its quota — ask the office to add some
bucket          Old_Papers    → refused: name 'Old_Papers' — use lowercase letters, digits and dashes
bucket          old-papers    → ready: maths-old-papers
bucket          more-papers   → refused: maths already uses 1/1 buckets — delete one or ask for a bigger quota
maths used: {'databases': 1, 'buckets': 1, 'queues': 0, 'cpu': 2}

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

गणित विभागाला दोन विनंत्यांत आणि शून्य tickets मध्ये दोन resources मिळाले. त्याचे चारही नकार वेगवेगळी पुढची पायरी सांगतात: लहान size निवडा, queues मागा, नाव दुरुस्त करा, एक bucket परत द्या. तीच पहिली विनंती — एक medium database — गणितासाठी (2 CPU) नाकारली गेली पण विज्ञानासाठी (6 CPU) मंजूर झाली: नियम तोच आहे, quota प्रत्येक team चा वेगळा आहे. Lab मध्ये कोणीच कोणत्याही व्यक्तीला विचारले नाही; कार्यालयाचे काम विनंत्या करण्यापासून menu आणि मर्यादा आखण्याकडे सरकले.

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

इतका मोठा menu की तो प्रत्येक cloud setting उघडी करतो — मग तो पुन्हा फक्त cloud console बनतो
"आमचा teams वर विश्वास आहे" म्हणून quotas नाहीत — जोपर्यंत एक loop 400 databases बनवत नाही
फक्त "quota exceeded" म्हणणारे नकार, जास्त मिळवण्याचा कोणताच मार्ग नाही
self-service create आहे पण self-service delete नाही — resources साचत जातात आणि पैसे खातात
owner tags नसलेले resources — bill कोणाचे आहे ते कोणालाच माहीत नसते

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

Crossplane वापरून कार्यालय स्वतःचा API ठरवते. खालचा kind आणि fields कार्यालयाच्या स्वतःच्या CompositeResourceDefinition मधून येतात — ते एक उदाहरण आहे, Crossplane चा built-in प्रकार नाही. खऱ्या cluster वर, team हे apply करेल:

apiVersion: school.example.org/v1alpha1
kind: PostgreSQLInstance          # defined by the facilities office
metadata:
  name: results-db
  namespace: science
spec:
  size: medium                    # the office's Composition maps this to real cloud settings

(Crossplane v1 मध्ये अशा namespaced विनंतीला claim म्हणतात; Crossplane v2 मध्ये composite resources स्वतः namespaced असू शकतात. तुम्ही कोणते version चालवता ते तपासा.) प्रत्येक team ची मर्यादा साधा Kubernetes ResourceQuota असू शकतो:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: science-quota
  namespace: science
spec:
  hard:
    requests.cpu: "6"
    count/postgresqlinstances.school.example.org: "2"

Terraform वापरून, menu item म्हणजे काही inputs असलेला module:

module "results_db" {
  source = "git::https://github.com/school/terraform-modules.git//postgres?ref=v1.4.0"
  name   = "science-results-db"
  size   = "medium"
  owner  = "science"
}

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: दर आठवड्याला अजूनही किती infrastructure tickets येतात ते मोजा. पुन्हा पुन्हा येणारा प्रत्येक विनंती-प्रकार menu item बनण्याचा उमेदवार आहे.

⏭️ पुढे

Teams ना टिकणारे resources मिळू शकतात. पुढे: थोड्या काळाचे resources — प्रत्येक pull request साठी एक संपूर्ण चाचणी environment, जे आपोआप साफ होते.

git checkout lesson-06-preview-environments

🧰 Lesson 05 — Self-service infrastructure: ask the office, get it at once

📍 You are here: Lesson 05 of 12 · Previous: lesson-04-service-catalog · Next: lesson-06-preview-environments

📦 What's in this branch

Lessons 01–04, plus the top pain from lesson 02: getting a database without a ticket. A team asks for a resource from a fixed menu (the office's catalogue of offerings); the request is checked against the team's quota and a naming rule; if it fits, it is provisioned at once with owner tags; if not, the refusal says what to do. OFFERINGS and Provisioner in idp/selfserve.py, selfservice() in idp/demo.py.

🧒 Explain like I'm 5

The facilities office now has a menu on the wall. 📋

small cupboard (postgres-small) — takes 2 floor tiles
big cupboard (postgres-medium) — takes 4 floor tiles
a box (bucket) · a pigeonhole rack (queue)

Every department has an allowance. Science may have 2 cupboards, 3 boxes, 2 racks, and 6 floor tiles in total.

Katrina orders a big cupboard for exam results: ✅ ready at once, with a label "owner: science". Then a small cupboard for the lab: ✅ ready — now all 6 tiles are used. Then a third cupboard: ❌ "Science already has 2 of 2 cupboards — give one back, or ask for a bigger allowance." Then a "MongoDB wardrobe": ❌ "That is not on the menu — here is what is, or ask us to add it."

No forms. No waiting in Dipika's pile. And no department can fill the whole school with cupboards, because the allowance stops it.

🗺️ Diagram

flowchart LR
    k["👩‍🏫 science asks:<br/>postgres-medium results-db"] --> m{"📋 on the menu?"}
    m -->|"no: mongodb"| r1["❌ offered: postgres-small,<br/>postgres-medium, bucket, queue"]
    m -->|"yes"| q{"📏 quota left?<br/>databases 2 · cpu 6"}
    q -->|"no: 3rd database"| r2["❌ 2/2 databases —<br/>delete one or ask for more"]
    q -->|"yes"| p["✅ science-results-db<br/>tags: owner=science,<br/>managed-by=facilities-office"]

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

❓ What

Self-service — a team gets what it needs by asking a system, not a person. The request is checked automatically and done in minutes.
Offering (a menu item) — a resource type the platform supports, with its sizes and defaults already decided: backups on, encryption on, the right network, the right tags. The team chooses from a small menu; the office owns what is behind it.
Quota — a limit per team (how many databases, how much CPU). Quotas make self-service safe: a mistake or a runaway script cannot take the whole budget. Kubernetes has a built-in ResourceQuota per namespace; clouds have account-level quotas; a platform often adds its own per team.
Abstraction — the team asks for "a medium Postgres", not for 40 Terraform resources. Tools that build this: Terraform modules (a reusable block with a few inputs), Crossplane (the platform defines its own Kubernetes API, like PostgreSQLInstance, and a Composition that turns it into real cloud resources), and cloud service catalogs such as AWS Service Catalog.
Tags / labels — every resource carries owner and managed-by, so cost reports and the catalog (lesson 04) know whose it is.
Guarded refusal — like the scaffolder, every "no" carries the next step: a smaller size, delete one, or ask for more.

🤔 Why

Because the ticket queue from lesson 01 was mostly repeat requests: "a Postgres for my service", again and again, done by hand each time, a little differently each time. Turning the most common request into a menu item removes the wait and the differences. Quotas mean the office does not have to review every request to keep costs and risk under control — the rule does it.

🔧 How (in this repo)

OFFERINGS in idp/selfserve.py is the menu: each item says which quota it counts against and how much CPU it uses. Provisioner(quotas) keeps each team's quota and usage. request(team, kind, name) checks, in order: is it on the menu, is the name valid, does the team have any of that quota, is there one left, is there enough CPU left. A success returns a resource named <team>-<name> with owner and managed-by tags. It creates nothing real — it is a teaching model of the decision, not of the cloud.

🧪 Try it

python3 idp/demo.py selfservice
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from selfserve import Provisioner
p = Provisioner({"maths": {"databases": 1, "buckets": 1, "queues": 0, "cpu": 2}})
for kind, name in (("postgres-medium", "timetable-db"), ("postgres-small", "timetable-db"), ("queue", "swaps"),
                   ("bucket", "Old_Papers"), ("bucket", "old-papers"), ("bucket", "more-papers")):
    status, out = p.request("maths", kind, name)
    print(f"{kind:<15} {name:<13} → {status}: {out['id'] if status == 'ready' else out}")
print("maths used:", p.used["maths"])
EOF

✅ Verify — what you should see

selfservice prints:

── science's quota: 2 databases, 3 buckets, 2 queues, 6 CPU — requests go to the office's catalogue, not a ticket
   postgres-medium results-db    → ready: science-results-db {'owner': 'science', 'managed-by': 'facilities-office'}
   postgres-small  lab-db        → ready: science-lab-db {'owner': 'science', 'managed-by': 'facilities-office'}
   postgres-small  extra-db      → refused: science already uses 2/2 databases — delete one or ask for a bigger quota
   used now: {'databases': 2, 'buckets': 1, 'queues': 1, 'cpu': 6}

Your snippet prints:

postgres-medium timetable-db  → refused: postgres-medium needs 4 CPU, maths has 2 of 2 left — pick a smaller size or ask for more
postgres-small  timetable-db  → ready: maths-timetable-db
queue           swaps         → refused: maths has no queues in its quota — ask the office to add some
bucket          Old_Papers    → refused: name 'Old_Papers' — use lowercase letters, digits and dashes
bucket          old-papers    → ready: maths-old-papers
bucket          more-papers   → refused: maths already uses 1/1 buckets — delete one or ask for a bigger quota
maths used: {'databases': 1, 'buckets': 1, 'queues': 0, 'cpu': 2}

🏁 What you just proved

Maths got two resources in two requests and zero tickets. Each of its four refusals says a different next step: pick a smaller size, ask for queues, fix the name, give a bucket back. The same first request — a medium database — was refused for maths (2 CPU) but granted for science (6 CPU): the rule is the same, the quota is per team. Nothing in the lab asked a person; the office's work moved from doing requests to designing the menu and the limits.

⚠️ Common mistakes

a menu so big it exposes every cloud setting — then it is just the cloud console again
no quotas "because we trust teams" — until one loop creates 400 databases
refusals that only say "quota exceeded", with no path to more
self-service create with no self-service delete — resources pile up and cost money
resources without owner tags — nobody knows whose bill it is

🏭 In production

With Crossplane, the office defines its own API. The kind and fields below come from the office's own CompositeResourceDefinition — they are an example, not a built-in Crossplane type. On a real cluster, a team would apply:

apiVersion: school.example.org/v1alpha1
kind: PostgreSQLInstance          # defined by the facilities office
metadata:
  name: results-db
  namespace: science
spec:
  size: medium                    # the office's Composition maps this to real cloud settings

(In Crossplane v1 a namespaced request like this is called a claim; Crossplane v2 lets composite resources themselves be namespaced. Check which version you run.) The per-team limit can be a plain Kubernetes ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: science-quota
  namespace: science
spec:
  hard:
    requests.cpu: "6"
    count/postgresqlinstances.school.example.org: "2"

With Terraform, the menu item is a module with a few inputs:

module "results_db" {
  source = "git::https://github.com/school/terraform-modules.git//postgres?ref=v1.4.0"
  name   = "science-results-db"
  size   = "medium"
  owner  = "science"
}

🏭 Why this matters in production: count how many infrastructure tickets still arrive each week. Every repeat request type is a candidate menu item.

⏭️ Next

Teams can get lasting resources. Next: short-lived ones — a whole trial environment for every pull request, cleaned up by itself.

git checkout lesson-06-preview-environments

← Previousservice catalog Next →preview environments

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