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

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

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

Platform Engineering کیا ہے؟

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

Platform Engineering بمقابلہ DevOps

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

Platform Engineering کیوں اہم ہے

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

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

• Git ورک فلوز اور برانچنگ حکمت عملیاں
• CI/CD پائپ لائن کنفیگریشن
• کنٹینر بلڈنگ اور رجسٹری مینجمنٹ
• Kubernetes مینیفیسٹس اور Helm Charts
• کلاؤڈ پرووائیڈر سروسز (AWS/GCP/Azure)
• نیٹ ورکنگ، DNS، TLS سرٹیفکیٹس
• مانیٹرنگ، لاگنگ، الرٹنگ سیٹ اپ
• ڈیٹا بیس پروویژننگ اور مائیگریشنز
• سیکیورٹی پالیسیاں اور تعمیل

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

گولڈن پاتھ

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

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

1. ڈویلپر پورٹل میں "نئی بیک اینڈ سروس" منتخب کرتا ہے
2. زبان/فریم ورک چنتا ہے (Node.js، Go، Python)
3. پلیٹ فارم خود بخود بناتا ہے: Git ریپوزٹری، CI/CD پائپ لائن، Kubernetes نیم اسپیس، مانیٹرنگ ڈیش بورڈز، اور الرٹ رولز
4. ڈویلپر ریپوزٹری کلون کرتا ہے اور فوراً کوڈنگ شروع کرتا ہے

Internal Developer Platform بنانا

تہہ 1: Developer Portal

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

اہم خصوصیات:

• سروس کیٹلاگ: ہر سروس، اس کا مالک، دستاویزات، اور انحصار
• سافٹ ویئر ٹیمپلیٹس: بہترین عمل کے ساتھ نئی سروسز کے لیے اسکیفولڈنگ
• ٹیک ڈاکس: کوڈ کے طور پر دستاویزات، رینڈر شدہ اور تلاش کے قابل
• پلگ ان ایکو سسٹم: حسب ضرورت فعالیت کے ساتھ توسیع پذیر

# backstage/catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: user-service
  description: Manages user accounts and authentication
  annotations:
    github.com/project-slug: myorg/user-service
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: team-auth
  system: identity-platform
  dependsOn:
    - resource:postgresql-main
  providesApis:
    - user-api

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

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

ٹولز:

• Crossplane: Kubernetes-مقامی انفراسٹرکچر پروویژننگ
• Terraform ماڈیولز کے ساتھ: پہلے سے بنائے گئے، جانچے ہوئے انفراسٹرکچر ماڈیولز
• Pulumi: حقیقی کوڈ کے طور پر انفراسٹرکچر (TypeScript، Python، Go)

# Example: Crossplane composition for a database
apiVersion: database.example.com/v1
kind: PostgreSQLInstance
metadata:
  name: user-db
spec:
  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
  version: "16"
  backup: daily
  team: auth-team

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

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

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

# .github/workflows/platform-ci.yml
# Teams just include the shared workflow
name: Build and Deploy
on:
  push:
    branches: [main]

jobs:
  pipeline:
    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
    with:
      language: node
      deploy-target: production
    secrets: inherit

اہم عمل:

• مشترکہ CI/CD ٹیمپلیٹس جو ٹیمیں شامل کرتی ہیں (کاپی نہیں)
• خودکار سیکیورٹی اسکیننگ (SAST، ڈیپنڈنسی آڈٹ)
• معیاری ڈیپلائمنٹ حکمت عملیاں (canary، blue/green)
• ناکام ہیلتھ چیکس پر خودکار رول بیک

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

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

• میٹرکس: Prometheus + Grafana فی سروس معیاری ڈیش بورڈز کے ساتھ
• لاگنگ: مرکزی جمع کے ساتھ ساختی لاگنگ (Loki، ELK)
• ٹریسنگ: OpenTelemetry کے ساتھ تقسیم شدہ ٹریسنگ
• الرٹنگ: معقول ڈیفالٹس کے ساتھ PagerDuty/Opsgenie انضمام

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

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

DORA میٹرکس

• ڈیپلائمنٹ فریکوئنسی: کوڈ کتنی بار پروڈکشن تک پہنچتا ہے
• تبدیلیوں کے لیے لیڈ ٹائم: کمٹ سے پروڈکشن تک کا وقت
• تبدیلی کی ناکامی کی شرح: ناکامی کا سبب بننے والی ڈیپلائمنٹس کا فیصد
• اوسط بحالی کا وقت: واقعے کے بعد سروس بحال کرنے کا وقت

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

• پہلی ڈیپلائی تک وقت: "نئی سروس" سے پہلی پروڈکشن ڈیپلائی تک کتنا وقت
• ڈویلپر اطمینان (NPS): اپنے صارفین کا باقاعدگی سے سروے کریں
• سیلف سروس تناسب: ٹکٹوں کے بغیر ہینڈل ہونے والی انفراسٹرکچر درخواستوں کا %
• گولڈن پاتھ اپنانا: تجویز کردہ راستے کی پیروی کرنے والی سروسز کا %

عام غلطیاں

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

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

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

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

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

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

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

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

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

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

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

1. سروس کیٹلاگ (Backstage) - جانیں کیا موجود ہے اور کس کا ہے
2. ایک سروس ٹیمپلیٹ - آپ کی سب سے عام سروس قسم کے لیے گولڈن پاتھ
3. معیاری CI/CD - مشترکہ پائپ لائن جو ٹیمیں شامل کرتی ہیں
4. بنیادی دستاویزات - پلیٹ فارم کیسے استعمال کریں، مدد کہاں ملے گی

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

نتیجہ

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

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

وسائل:

• Team Topologies - وہ کتاب جس نے پلیٹ فارم ٹیموں کو مقبول بنایا
• Backstage - Spotify کا اوپن سورس ڈویلپر پورٹل
• CNCF Platforms White Paper - کمیونٹی تعریف اور بہترین عمل
• platformengineering.org - کمیونٹی، تقریبات، اور وسائل