Platform Engineering: Internal Developer Platform کیسے بنائیں

spinny:~/writing $ vim platform-engineering-internal-developer-platform.md

1~
2جیسے جیسے سافٹ ویئر سسٹمز زیادہ پیچیدہ ہوتے جاتے ہیں  -  مائیکرو سروسز، Kubernetes، ملٹی کلاؤڈ، CI/CD پائپ لائنز، آبزرویبلٹی اسٹیکس  -  ڈویلپرز انفراسٹرکچر پر زیادہ وقت اور مصنوعات بنانے پر کم وقت خرچ کر رہے ہیں۔ **Platform Engineering** ایک داخلی پلیٹ فارم بنا کر اس مسئلے کو حل کرتا ہے جو پیچیدگی کو تجریدی بناتا ہے اور ڈویلپرز کو تیزی سے شپ کرنے کے لیے سیلف سروس ٹولز فراہم کرتا ہے۔
3~
4Gartner پیشگوئی کرتا ہے کہ 2027 تک، **80% سافٹ ویئر انجینئرنگ تنظیمیں** پلیٹ فارم ٹیمیں قائم کریں گی۔ اس گائیڈ میں، ہم جانیں گے کہ Platform Engineering کیا ہے، یہ کیوں اہم ہے، اور شروع سے Internal Developer Platform کیسے بنائیں۔
5~
6## Platform Engineering کیا ہے؟
7~
8Platform Engineering ٹول چینز اور ورک فلوز ڈیزائن اور بنانے کا شعبہ ہے جو سافٹ ویئر انجینئرنگ تنظیموں کے لیے سیلف سروس صلاحیتیں فعال کرتا ہے۔ آؤٹ پٹ ایک **Internal Developer Platform (IDP)** ہے  -  ایک تہہ جو ڈویلپرز اور انفراسٹرکچر کے درمیان ہوتی ہے۔
9~
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17~
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24~
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31~
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43~
44### Platform Engineering بمقابلہ DevOps
45~
46Platform Engineering DevOps کا متبادل نہیں ہے  -  یہ اگلا ارتقاء ہے۔ DevOps نے کہا "تم بناؤ، تم چلاؤ۔" Platform Engineering کہتا ہے "ہم بنانا اور چلانا آسان بنا دیں گے۔"
47~
48| پہلو | DevOps | Platform Engineering |
49|-------|--------|---------------------|
50| **توجہ** | ثقافت اور عمل | مصنوعات اور سیلف سروس |
51| **نقطہ نظر** | ہر ٹیم انفرا کا انتظام کرتی ہے | پلیٹ فارم ٹیم انفرا کو تجریدی بناتی ہے |
52| **ذہنی بوجھ** | زیادہ (ہر ٹیم سب کچھ سیکھتی ہے) | کم (گولڈن پاتھز فراہم کیے جاتے ہیں) |
53| **آؤٹ پٹ** | CI/CD پائپ لائنز، IaC اسکرپٹس | Internal Developer Platform |
54| **صارفین** | تمام انجینئرنگ | پلیٹ فارم ٹیم انجینئرنگ کی خدمت کرتی ہے |
55~
56## Platform Engineering کیوں اہم ہے
57~
58### ذہنی بوجھ کا مسئلہ
59~
60ایک عام جدید تنظیم میں، ایک ڈویلپر کو سمجھنا ہوتا ہے:
61~
62- Git ورک فلوز اور برانچنگ حکمت عملیاں
63- CI/CD پائپ لائن کنفیگریشن
64- کنٹینر بلڈنگ اور رجسٹری مینجمنٹ
65- Kubernetes مینیفیسٹس اور Helm Charts
66- کلاؤڈ پرووائیڈر سروسز (AWS/GCP/Azure)
67- نیٹ ورکنگ، DNS، TLS سرٹیفکیٹس
68- مانیٹرنگ، لاگنگ، الرٹنگ سیٹ اپ
69- ڈیٹا بیس پروویژننگ اور مائیگریشنز
70- سیکیورٹی پالیسیاں اور تعمیل
71~
72یہ ایک بہت بڑا ذہنی بوجھ ہے جو اصل مصنوعہ سے توجہ ہٹاتا ہے۔
73~
74### گولڈن پاتھ
75~
76Platform Engineering **گولڈن پاتھز** کا تصور متعارف کراتا ہے  -  عام کاموں کے لیے رائے رکھنے والے، اچھی طرح معاونت شدہ، اور دستاویزی راستے۔ گولڈن پاتھ لازمی نہیں ہے؛ ڈویلپرز *ہٹ سکتے ہیں*، لیکن پلیٹ فارم صحیح چیز کو آسان چیز بناتا ہے۔
77~
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88~
89**نئی مائیکرو سروس بنانے کے لیے گولڈن پاتھ کی مثال:**
901. ڈویلپر پورٹل میں "نئی بیک اینڈ سروس" منتخب کرتا ہے
912. زبان/فریم ورک چنتا ہے (Node.js، Go، Python)
923. پلیٹ فارم خود بخود بناتا ہے: Git ریپوزٹری، CI/CD پائپ لائن، Kubernetes نیم اسپیس، مانیٹرنگ ڈیش بورڈز، اور الرٹ رولز
934. ڈویلپر ریپوزٹری کلون کرتا ہے اور فوراً کوڈنگ شروع کرتا ہے
94~
95## Internal Developer Platform بنانا
96~
97### تہہ 1: Developer Portal
98~
99پورٹل ڈویلپرز کے لیے واحد داخلی نقطہ ہے۔ سب سے مقبول اوپن سورس آپشن **Backstage** ہے (Spotify نے بنایا، اب CNCF پروجیکٹ)۔
100~
101اہم خصوصیات:
102- **سروس کیٹلاگ**: ہر سروس، اس کا مالک، دستاویزات، اور انحصار
103- **سافٹ ویئر ٹیمپلیٹس**: بہترین عمل کے ساتھ نئی سروسز کے لیے اسکیفولڈنگ
104- **ٹیک ڈاکس**: کوڈ کے طور پر دستاویزات، رینڈر شدہ اور تلاش کے قابل
105- **پلگ ان ایکو سسٹم**: حسب ضرورت فعالیت کے ساتھ توسیع پذیر
106~
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127~
128### تہہ 2: انفراسٹرکچر تجرید
129~
130ڈویلپرز کو براہ راست Terraform یا Kubernetes YAML نہیں لکھنا چاہیے۔ پلیٹ فارم کو تجریدات فراہم کرنے چاہیئں۔
131~
132**ٹولز:**
133- **Crossplane**: Kubernetes-مقامی انفراسٹرکچر پروویژننگ
134- **Terraform ماڈیولز کے ساتھ**: پہلے سے بنائے گئے، جانچے ہوئے انفراسٹرکچر ماڈیولز
135- **Pulumi**: حقیقی کوڈ کے طور پر انفراسٹرکچر (TypeScript، Python، Go)
136~
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149~
150RDS پیرامیٹرز، VPC سب نیٹس، سیکیورٹی گروپس، اور بیک اپ پالیسیاں کنفیگر کرنے کی بجائے، ڈویلپر صرف `size: small` اور `backup: daily` بتاتا ہے۔ پلیٹ فارم باقی سنبھالتا ہے۔
151~
152### تہہ 3: CI/CD معیاری بنانا
153~
154CI/CD کو معیاری بنائیں تاکہ ٹیمیں اپنی اپنی پائپ لائنز نہ بنائیں۔
155~
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163~
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172~
173**اہم عمل:**
174- مشترکہ CI/CD ٹیمپلیٹس جو ٹیمیں شامل کرتی ہیں (کاپی نہیں)
175- خودکار سیکیورٹی اسکیننگ (SAST، ڈیپنڈنسی آڈٹ)
176- معیاری ڈیپلائمنٹ حکمت عملیاں (canary، blue/green)
177- ناکام ہیلتھ چیکس پر خودکار رول بیک
178~
179### تہہ 4: آبزرویبلٹی
180~
181پہلے سے کنفیگر شدہ مانیٹرنگ تاکہ ڈویلپرز کو ڈیش بورڈز اور الرٹس تیار ملیں۔
182~
183- **میٹرکس**: Prometheus + Grafana فی سروس معیاری ڈیش بورڈز کے ساتھ
184- **لاگنگ**: مرکزی جمع کے ساتھ ساختی لاگنگ (Loki، ELK)
185- **ٹریسنگ**: OpenTelemetry کے ساتھ تقسیم شدہ ٹریسنگ
186- **الرٹنگ**: معقول ڈیفالٹس کے ساتھ PagerDuty/Opsgenie انضمام
187~
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199~
200## کامیابی کی پیمائش
201~
202آپ کیسے جانیں گے کہ آپ کا پلیٹ فارم کام کر رہا ہے؟ یہ میٹرکس ٹریک کریں:
203~
204### DORA میٹرکس
205- **ڈیپلائمنٹ فریکوئنسی**: کوڈ کتنی بار پروڈکشن تک پہنچتا ہے
206- **تبدیلیوں کے لیے لیڈ ٹائم**: کمٹ سے پروڈکشن تک کا وقت
207- **تبدیلی کی ناکامی کی شرح**: ناکامی کا سبب بننے والی ڈیپلائمنٹس کا فیصد
208- **اوسط بحالی کا وقت**: واقعے کے بعد سروس بحال کرنے کا وقت
209~
210### پلیٹ فارم مخصوص میٹرکس
211- **پہلی ڈیپلائی تک وقت**: "نئی سروس" سے پہلی پروڈکشن ڈیپلائی تک کتنا وقت
212- **ڈویلپر اطمینان (NPS)**: اپنے صارفین کا باقاعدگی سے سروے کریں
213- **سیلف سروس تناسب**: ٹکٹوں کے بغیر ہینڈل ہونے والی انفراسٹرکچر درخواستوں کا %
214- **گولڈن پاتھ اپنانا**: تجویز کردہ راستے کی پیروی کرنے والی سروسز کا %
215~
216## عام غلطیاں
217~
218### 1. بہت جلد بہت زیادہ بنانا
219سب سے بڑے درد کے نقطے سے شروع کریں، عظیم وژن سے نہیں۔ اگر ڈیپلائمنٹس تکلیف دہ ہیں، وہاں سے شروع کریں۔ اگر پروویژننگ میں ہفتے لگتے ہیں، وہاں سے شروع کریں۔
220~
221### 2. پلیٹ فارم کو مصنوعہ کے طور پر نہ سمجھنا
222پلیٹ فارم ٹیم کو پروڈکٹ مینیجر، صارف تحقیق، اور فیڈ بیک لوپس کی ضرورت ہے۔ ڈویلپرز آپ کے گاہک ہیں  -  ان کی ضروریات سمجھیں۔
223~
224### 3. راغب کرنے کی بجائے لازمی کرنا
225بہترین پلیٹ فارمز رضاکارانہ طور پر اپنائے جاتے ہیں کیونکہ وہ ڈویلپرز کی زندگی آسان بناتے ہیں۔ اگر آپ کو استعمال لازمی کرنا پڑے، تو آپ کا پلیٹ فارم کافی اچھا نہیں ہے۔
226~
227### 4. ڈویلپر تجربے کو نظرانداز کرنا
228خراب UX والا پلیٹ فارم استعمال نہیں ہوگا۔ واضح دستاویزات، مددگار ایرر میسجز، اور تیز فیڈ بیک لوپس میں سرمایہ کاری کریں۔
229~
230## شروع کیسے کریں
231~
232اپنا پہلا IDP بنانے کے لیے عملی روڈ میپ:
233~
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239~
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243~
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247~
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251~
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256~
257### کم سے کم قابل عمل پلیٹ فارم
258~
2591. **سروس کیٹلاگ** (Backstage)  -  جانیں کیا موجود ہے اور کس کا ہے
2602. **ایک سروس ٹیمپلیٹ**  -  آپ کی سب سے عام سروس قسم کے لیے گولڈن پاتھ
2613. **معیاری CI/CD**  -  مشترکہ پائپ لائن جو ٹیمیں شامل کرتی ہیں
2624. **بنیادی دستاویزات**  -  پلیٹ فارم کیسے استعمال کریں، مدد کہاں ملے گی
263~
264آپ یہ MVP 2-3 انجینئرز کی ٹیم کے ساتھ 2-3 ماہ میں بنا سکتے ہیں۔
265~
266## نتیجہ
267~
268Platform Engineering پہلے دن سے مکمل پلیٹ فارم بنانے کے بارے میں نہیں ہے۔ یہ ڈویلپرز پر ذہنی بوجھ کو بتدریج کم کرنے کے بارے میں ہے تاکہ وہ مصنوعات بنانے پر توجہ مرکوز کر سکیں۔ چھوٹے سے شروع کریں، اثر ناپیں، اور ڈویلپر فیڈ بیک کی بنیاد پر دہرائیں۔
269~
270جو تنظیمیں Platform Engineering میں سرمایہ کاری کرتی ہیں ان کے پاس نمایاں مسابقتی فائدہ ہوگا: تیز ڈیلیوری، خوش ڈویلپرز، اور زیادہ قابل اعتماد سسٹمز۔
271~
272**وسائل:**
273- [Team Topologies](https://teamtopologies.com/)  -  وہ کتاب جس نے پلیٹ فارم ٹیموں کو مقبول بنایا
274- [Backstage](https://backstage.io/)  -  Spotify کا اوپن سورس ڈویلپر پورٹل
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  کمیونٹی تعریف اور بہترین عمل
276- [platformengineering.org](https://platformengineering.org/)  -  کمیونٹی، تقریبات، اور وسائل
277~

NORMAL · platform-engineering-internal-developer-platform.md [readonly]277 lines · :q to close

2جیسے جیسے سافٹ ویئر سسٹمز زیادہ پیچیدہ ہوتے جاتے ہیں - مائیکرو سروسز، Kubernetes، ملٹی کلاؤڈ، CI/CD پائپ لائنز، آبزرویبلٹی اسٹیکس - ڈویلپرز انفراسٹرکچر پر زیادہ وقت اور مصنوعات بنانے پر کم وقت خرچ کر رہے ہیں۔ **Platform Engineering** ایک داخلی پلیٹ فارم بنا کر اس مسئلے کو حل کرتا ہے جو پیچیدگی کو تجریدی بناتا ہے اور ڈویلپرز کو تیزی سے شپ کرنے کے لیے سیلف سروس ٹولز فراہم کرتا ہے۔

4Gartner پیشگوئی کرتا ہے کہ 2027 تک، **80% سافٹ ویئر انجینئرنگ تنظیمیں** پلیٹ فارم ٹیمیں قائم کریں گی۔ اس گائیڈ میں، ہم جانیں گے کہ Platform Engineering کیا ہے، یہ کیوں اہم ہے، اور شروع سے Internal Developer Platform کیسے بنائیں۔

6## Platform Engineering کیا ہے؟

8Platform Engineering ٹول چینز اور ورک فلوز ڈیزائن اور بنانے کا شعبہ ہے جو سافٹ ویئر انجینئرنگ تنظیموں کے لیے سیلف سروس صلاحیتیں فعال کرتا ہے۔ آؤٹ پٹ ایک **Internal Developer Platform (IDP)** ہے - ایک تہہ جو ڈویلپرز اور انفراسٹرکچر کے درمیان ہوتی ہے۔

10```mermaid

11graph TD

12 subgraph "Developers"

13 D1[Frontend Team]

14 D2[Backend Team]

15 D3[Data Team]

16 end

17~

18 subgraph "Internal Developer Platform"

19 Portal[Developer Portal]

20 Templates[Service Templates]

21 CICD[CI/CD Pipelines]

22 Infra[Infrastructure Abstraction]

23 end

24~

25 subgraph "Infrastructure"

26 K8s[Kubernetes]

27 Cloud[Cloud Services]

28 DB[Databases]

29 Monitor[Monitoring]

30 end

31~

32 D1 --> Portal

33 D2 --> Portal

34 D3 --> Portal

35 Portal --> Templates

36 Portal --> CICD

37 Portal --> Infra

38 Infra --> K8s

39 Infra --> Cloud

40 Infra --> DB

41 CICD --> Monitor

42```

43~

44### Platform Engineering بمقابلہ DevOps

45~

46Platform Engineering DevOps کا متبادل نہیں ہے - یہ اگلا ارتقاء ہے۔ DevOps نے کہا "تم بناؤ، تم چلاؤ۔" Platform Engineering کہتا ہے "ہم بنانا اور چلانا آسان بنا دیں گے۔"

47~

48| پہلو | DevOps | Platform Engineering |

49|-------|--------|---------------------|

50| **توجہ** | ثقافت اور عمل | مصنوعات اور سیلف سروس |

51| **نقطہ نظر** | ہر ٹیم انفرا کا انتظام کرتی ہے | پلیٹ فارم ٹیم انفرا کو تجریدی بناتی ہے |

52| **ذہنی بوجھ** | زیادہ (ہر ٹیم سب کچھ سیکھتی ہے) | کم (گولڈن پاتھز فراہم کیے جاتے ہیں) |

53| **آؤٹ پٹ** | CI/CD پائپ لائنز، IaC اسکرپٹس | Internal Developer Platform |

54| **صارفین** | تمام انجینئرنگ | پلیٹ فارم ٹیم انجینئرنگ کی خدمت کرتی ہے |

55~

56## Platform Engineering کیوں اہم ہے

57~

58### ذہنی بوجھ کا مسئلہ

59~

60ایک عام جدید تنظیم میں، ایک ڈویلپر کو سمجھنا ہوتا ہے:

61~

62- Git ورک فلوز اور برانچنگ حکمت عملیاں

63- CI/CD پائپ لائن کنفیگریشن

64- کنٹینر بلڈنگ اور رجسٹری مینجمنٹ

65- Kubernetes مینیفیسٹس اور Helm Charts

66- کلاؤڈ پرووائیڈر سروسز (AWS/GCP/Azure)

67- نیٹ ورکنگ، DNS، TLS سرٹیفکیٹس

68- مانیٹرنگ، لاگنگ، الرٹنگ سیٹ اپ

69- ڈیٹا بیس پروویژننگ اور مائیگریشنز

70- سیکیورٹی پالیسیاں اور تعمیل

71~

72یہ ایک بہت بڑا ذہنی بوجھ ہے جو اصل مصنوعہ سے توجہ ہٹاتا ہے۔

73~

74### گولڈن پاتھ

75~

76Platform Engineering **گولڈن پاتھز** کا تصور متعارف کراتا ہے - عام کاموں کے لیے رائے رکھنے والے، اچھی طرح معاونت شدہ، اور دستاویزی راستے۔ گولڈن پاتھ لازمی نہیں ہے؛ ڈویلپرز *ہٹ سکتے ہیں*، لیکن پلیٹ فارم صحیح چیز کو آسان چیز بناتا ہے۔

77~

78```mermaid

79flowchart LR

80 Dev[Developer] -- "Create new service" --> Portal[Portal]

81 Portal -- "Select template" --> Template[Service Template]

82 Template -- "Auto-provision" --> Repo[Git Repository]

83 Template --> Pipeline[CI/CD Pipeline]

84 Template --> Infra[Kubernetes Namespace]

85 Template --> Monitor[Dashboards + Alerts]

86 Repo --> Ready[Ready to Code!]

87```

88~

89**نئی مائیکرو سروس بنانے کے لیے گولڈن پاتھ کی مثال:**

901. ڈویلپر پورٹل میں "نئی بیک اینڈ سروس" منتخب کرتا ہے

912. زبان/فریم ورک چنتا ہے (Node.js، Go، Python)

923. پلیٹ فارم خود بخود بناتا ہے: Git ریپوزٹری، CI/CD پائپ لائن، Kubernetes نیم اسپیس، مانیٹرنگ ڈیش بورڈز، اور الرٹ رولز

934. ڈویلپر ریپوزٹری کلون کرتا ہے اور فوراً کوڈنگ شروع کرتا ہے

94~

95## Internal Developer Platform بنانا

96~

97### تہہ 1: Developer Portal

98~

99پورٹل ڈویلپرز کے لیے واحد داخلی نقطہ ہے۔ سب سے مقبول اوپن سورس آپشن **Backstage** ہے (Spotify نے بنایا، اب CNCF پروجیکٹ)۔

100~

101اہم خصوصیات:

102- **سروس کیٹلاگ**: ہر سروس، اس کا مالک، دستاویزات، اور انحصار

103- **سافٹ ویئر ٹیمپلیٹس**: بہترین عمل کے ساتھ نئی سروسز کے لیے اسکیفولڈنگ

104- **ٹیک ڈاکس**: کوڈ کے طور پر دستاویزات، رینڈر شدہ اور تلاش کے قابل

105- **پلگ ان ایکو سسٹم**: حسب ضرورت فعالیت کے ساتھ توسیع پذیر

106~

107```yaml

108# backstage/catalog-info.yaml

109apiVersion: backstage.io/v1alpha1

110kind: Component

111metadata:

112 name: user-service

113 description: Manages user accounts and authentication

114 annotations:

115 github.com/project-slug: myorg/user-service

116 backstage.io/techdocs-ref: dir:.

117spec:

118 type: service

119 lifecycle: production

120 owner: team-auth

121 system: identity-platform

122 dependsOn:

123 - resource:postgresql-main

124 providesApis:

125 - user-api

126```

127~

128### تہہ 2: انفراسٹرکچر تجرید

129~

130ڈویلپرز کو براہ راست Terraform یا Kubernetes YAML نہیں لکھنا چاہیے۔ پلیٹ فارم کو تجریدات فراہم کرنے چاہیئں۔

131~

132**ٹولز:**

133- **Crossplane**: Kubernetes-مقامی انفراسٹرکچر پروویژننگ

134- **Terraform ماڈیولز کے ساتھ**: پہلے سے بنائے گئے، جانچے ہوئے انفراسٹرکچر ماڈیولز

135- **Pulumi**: حقیقی کوڈ کے طور پر انفراسٹرکچر (TypeScript، Python، Go)

136~

137```yaml

138# Example: Crossplane composition for a database

139apiVersion: database.example.com/v1

140kind: PostgreSQLInstance

141metadata:

142 name: user-db

143spec:

144 size: small # Abstraction: small = 2 vCPU, 4GB RAM

145 version: "16"

146 backup: daily

147 team: auth-team

148```

149~

150RDS پیرامیٹرز، VPC سب نیٹس، سیکیورٹی گروپس، اور بیک اپ پالیسیاں کنفیگر کرنے کی بجائے، ڈویلپر صرف `size: small` اور `backup: daily` بتاتا ہے۔ پلیٹ فارم باقی سنبھالتا ہے۔

151~

152### تہہ 3: CI/CD معیاری بنانا

153~

154CI/CD کو معیاری بنائیں تاکہ ٹیمیں اپنی اپنی پائپ لائنز نہ بنائیں۔

155~

156```yaml

157# .github/workflows/platform-ci.yml

158# Teams just include the shared workflow

159name: Build and Deploy

160on:

161 push:

162 branches: [main]

163~

164jobs:

165 pipeline:

166 uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2

167 with:

168 language: node

169 deploy-target: production

170 secrets: inherit

171```

172~

173**اہم عمل:**

174- مشترکہ CI/CD ٹیمپلیٹس جو ٹیمیں شامل کرتی ہیں (کاپی نہیں)

175- خودکار سیکیورٹی اسکیننگ (SAST، ڈیپنڈنسی آڈٹ)

176- معیاری ڈیپلائمنٹ حکمت عملیاں (canary، blue/green)

177- ناکام ہیلتھ چیکس پر خودکار رول بیک

178~

179### تہہ 4: آبزرویبلٹی

180~

181پہلے سے کنفیگر شدہ مانیٹرنگ تاکہ ڈویلپرز کو ڈیش بورڈز اور الرٹس تیار ملیں۔

182~

183- **میٹرکس**: Prometheus + Grafana فی سروس معیاری ڈیش بورڈز کے ساتھ

184- **لاگنگ**: مرکزی جمع کے ساتھ ساختی لاگنگ (Loki، ELK)

185- **ٹریسنگ**: OpenTelemetry کے ساتھ تقسیم شدہ ٹریسنگ

186- **الرٹنگ**: معقول ڈیفالٹس کے ساتھ PagerDuty/Opsgenie انضمام

187~

188```mermaid

189graph LR

190 Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]

191 Collector --> Prometheus[Prometheus]

192 Collector --> Loki[Loki]

193 Collector --> Tempo[Tempo]

194 Prometheus --> Grafana[Grafana Dashboards]

195 Loki --> Grafana

196 Tempo --> Grafana

197 Grafana --> PagerDuty[PagerDuty Alerts]

198```

199~

200## کامیابی کی پیمائش

201~

202آپ کیسے جانیں گے کہ آپ کا پلیٹ فارم کام کر رہا ہے؟ یہ میٹرکس ٹریک کریں:

203~

204### DORA میٹرکس

205- **ڈیپلائمنٹ فریکوئنسی**: کوڈ کتنی بار پروڈکشن تک پہنچتا ہے

206- **تبدیلیوں کے لیے لیڈ ٹائم**: کمٹ سے پروڈکشن تک کا وقت

207- **تبدیلی کی ناکامی کی شرح**: ناکامی کا سبب بننے والی ڈیپلائمنٹس کا فیصد

208- **اوسط بحالی کا وقت**: واقعے کے بعد سروس بحال کرنے کا وقت

209~

210### پلیٹ فارم مخصوص میٹرکس

211- **پہلی ڈیپلائی تک وقت**: "نئی سروس" سے پہلی پروڈکشن ڈیپلائی تک کتنا وقت

212- **ڈویلپر اطمینان (NPS)**: اپنے صارفین کا باقاعدگی سے سروے کریں

213- **سیلف سروس تناسب**: ٹکٹوں کے بغیر ہینڈل ہونے والی انفراسٹرکچر درخواستوں کا %

214- **گولڈن پاتھ اپنانا**: تجویز کردہ راستے کی پیروی کرنے والی سروسز کا %

215~

216## عام غلطیاں

217~

218### 1. بہت جلد بہت زیادہ بنانا

219سب سے بڑے درد کے نقطے سے شروع کریں، عظیم وژن سے نہیں۔ اگر ڈیپلائمنٹس تکلیف دہ ہیں، وہاں سے شروع کریں۔ اگر پروویژننگ میں ہفتے لگتے ہیں، وہاں سے شروع کریں۔

220~

221### 2. پلیٹ فارم کو مصنوعہ کے طور پر نہ سمجھنا

222پلیٹ فارم ٹیم کو پروڈکٹ مینیجر، صارف تحقیق، اور فیڈ بیک لوپس کی ضرورت ہے۔ ڈویلپرز آپ کے گاہک ہیں - ان کی ضروریات سمجھیں۔

223~

224### 3. راغب کرنے کی بجائے لازمی کرنا

225بہترین پلیٹ فارمز رضاکارانہ طور پر اپنائے جاتے ہیں کیونکہ وہ ڈویلپرز کی زندگی آسان بناتے ہیں۔ اگر آپ کو استعمال لازمی کرنا پڑے، تو آپ کا پلیٹ فارم کافی اچھا نہیں ہے۔

226~

227### 4. ڈویلپر تجربے کو نظرانداز کرنا

228خراب UX والا پلیٹ فارم استعمال نہیں ہوگا۔ واضح دستاویزات، مددگار ایرر میسجز، اور تیز فیڈ بیک لوپس میں سرمایہ کاری کریں۔

229~

230## شروع کیسے کریں

231~

232اپنا پہلا IDP بنانے کے لیے عملی روڈ میپ:

233~

234```mermaid

235flowchart TD

236 A[Month 1-2: Discovery] --> B[Month 3-4: MVP]

237 B --> C[Month 5-6: Iterate]

238 C --> D[Month 7+: Scale]

239~

240 A --> A1[Interview developers]

241 A --> A2[Map pain points]

242 A --> A3[Choose first golden path]

243~

244 B --> B1[Deploy Backstage]

245 B --> B2[First service template]

246 B --> B3[Standardized CI/CD]

247~

248 C --> C1[Gather feedback]

249 C --> C2[Add infrastructure abstraction]

250 C --> C3[Improve docs and onboarding]

251~

252 D --> D1[More templates and golden paths]

253 D --> D2[Self-service infrastructure]

254 D --> D3[Advanced observability]

255```

256~

257### کم سے کم قابل عمل پلیٹ فارم

258~

2591. **سروس کیٹلاگ** (Backstage) - جانیں کیا موجود ہے اور کس کا ہے

2602. **ایک سروس ٹیمپلیٹ** - آپ کی سب سے عام سروس قسم کے لیے گولڈن پاتھ

2613. **معیاری CI/CD** - مشترکہ پائپ لائن جو ٹیمیں شامل کرتی ہیں

2624. **بنیادی دستاویزات** - پلیٹ فارم کیسے استعمال کریں، مدد کہاں ملے گی

263~

264آپ یہ MVP 2-3 انجینئرز کی ٹیم کے ساتھ 2-3 ماہ میں بنا سکتے ہیں۔

265~

266## نتیجہ

267~

268Platform Engineering پہلے دن سے مکمل پلیٹ فارم بنانے کے بارے میں نہیں ہے۔ یہ ڈویلپرز پر ذہنی بوجھ کو بتدریج کم کرنے کے بارے میں ہے تاکہ وہ مصنوعات بنانے پر توجہ مرکوز کر سکیں۔ چھوٹے سے شروع کریں، اثر ناپیں، اور ڈویلپر فیڈ بیک کی بنیاد پر دہرائیں۔

269~

270جو تنظیمیں Platform Engineering میں سرمایہ کاری کرتی ہیں ان کے پاس نمایاں مسابقتی فائدہ ہوگا: تیز ڈیلیوری، خوش ڈویلپرز، اور زیادہ قابل اعتماد سسٹمز۔

271~

272**وسائل:**

273- [Team Topologies](https://teamtopologies.com/) - وہ کتاب جس نے پلیٹ فارم ٹیموں کو مقبول بنایا

274- [Backstage](https://backstage.io/) - Spotify کا اوپن سورس ڈویلپر پورٹل

275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/) - کمیونٹی تعریف اور بہترین عمل

276- [platformengineering.org](https://platformengineering.org/) - کمیونٹی، تقریبات، اور وسائل

277~