هندسة المنصات وتجربة المطورين

البناء مقابل الشراء لمكونات المنصة

18 دقيقة الدرس 9 من 28

البناء مقابل الشراء لمكونات المنصة

كل فريق هندسة منصة يواجه في نهاية المطاف نفس مفترق الطرق: هل نُدمج مشروعاً مفتوح المصدر من CNCF، أم نشتري منتجاً تجارياً كخدمة، أم نبني القدرة بأنفسنا؟ على نطاق واسع، تتكرر هذه القرارات عشرات المرات — لكتالوج الخدمات، وإدارة الأسرار، والتسليم التدريجي، وبوابات المطورين، وتوزيع التكاليف. المهندسون الذين يجيبون عليها بشكل خاطئ يحرقون ملايين الدولارات وسنوات من جهود الهندسة، أو كليهما. أما الذين يجيبون عليها بشكل صحيح فيبنون منصات تتضاعف قيمتها مع الوقت.

يمنحك هذا الدرس إطاراً منظماً للتنقل في مشهد CNCF — الذي يضم أكثر من 170 مشروعاً موزّعة على 18 فئة بحلول عام 2025 — دون الغرق في شلل الاختيار. ينطبق هذا الإطار بالتساوي على مشاريع CNCF Graduated، والأدوات التجارية (Harness وHumanitec وPort وCortex)، والبناء الداخلي الكامل.

مشهد CNCF ليس كتالوج تسوّق

الخطأ الكلاسيكي هو التعامل مع مشهد CNCF باعتباره مصفوفة ميزات تُقارن عموداً بعمود. المشهد هو تصنيف للمشكلات المحلولة، وليس توصية بمنتج. مشروع Graduated كـArgo CD أُثبت في الإنتاج في آلاف الشركات؛ أما مشروع Sandbox فهو بحث تجريبي. مستويات النضج بالغة الأهمية: Graduated (مراجعة TOC صارمة، أدلة تبني إنتاجي، تدقيقات أمنية) ← Incubating (تبني متنامٍ، حوكمة محايدة من البائعين) ← Sandbox (مرحلة مبكرة، خطر تقلّب واجهات عالٍ).

كشف CNCF Annual Survey 2024 أن 84% من المستجيبين يشغّلون Kubernetes في الإنتاج، لكن المنظمة المتوسطة تستخدم فعلياً 7–10 مشاريع CNCF فقط. الفجوة بين 170+ مشروعاً متاحاً و~10 مستخدَمة هي المكان الذي تعيش فيه الحكمة الجيدة للمنصات. يجب أن يكون ضغط الانتقاء صارماً.

إطار القرار: أربعة محاور

قيّم كل مكوّن في المنصة على هذه المحاور الأربعة قبل اتخاذ القرار:

  • التمييز التنافسي: هل تُميّز هذه القدرة أعمالك؟ إذا كانت الإجابة نعم، ابنِها. لا تكسب أي شركة ميزة تنافسية من CI جاهز. لكن بوابة مطورين مخصصة ومتكاملة بعمق مع أدواتك الداخلية هي ميزة تمييزية حقيقية.
  • العبء التشغيلي: كيف يبدو اليوم الثاني؟ تشغيل Kafka وVault وخلفية تتبع موزّع داخلياً يتطلب وقت SRE مخصصاً. البديل كخدمة (Confluent وHCP Vault وHoneycomb) ينقل هذا العبء إلى البائع. احسب بصدق: موظفان بـ200 ألف دولار لكل منهما لتشغيل أداة مقابل 240 ألف دولار سنوياً كخدمة لا يمثّل توفيراً.
  • النضج والإقفال: مشاريع CNCF Graduated ذات واجهات برمجة محايدة من البائعين (OTel وPrometheus وFlux) تحمل مخاطر إقفال منخفضة. خدمة SaaS مملوكة بلا واجهة تصدير هي فخ. OpenTelemetry النموذج المثالي: أدوات مرة واحدة، إرسال إلى أي خلفية. تحسّن للمعايير المفتوحة في طبقة الأدوات حتى عند الشراء في طبقة التخزين والتصوير.
  • تعقيد التكامل: هل يمكنك ربط هذا في مساراتك الذهبية القائمة بتكلفة منخفضة؟ أداة تتطلب مشغّلاً مخصصاً ونطاق اسم مخصصاً لكل مستأجر وخطاف قبول مخصصاً هي تكلفة تكامل باهظة. وازن هذا مقابل البناء.
Build vs Buy vs Open Source decision matrix Platform Component Decision Matrix Differentiating? YES NO High operational burden? YES NO Thin Wrapper over CNCF Graduated e.g. Custom ArgoCD UX Build In-House Full ownership e.g. Custom IDP Portal Mature CNCF / OSS exists? YES NO Adopt CNCF Prefer Graduated e.g. Prometheus, Flux Buy SaaS / Commercial Open standards preferred e.g. Honeycomb, Port Always Evaluate: Lock-in Risk + Total Cost of Ownership (TCO) Prefer open standards at instrumentation layer (OTel, Prometheus scrape, OIDC, S3-compatible APIs)
مصفوفة قرار اختيار مكوّنات المنصة: التمييز التنافسي والعبء التشغيلي يقودان محور البناء مقابل الشراء؛ مخاطر الإقفال والتكلفة الإجمالية تنطبق عالمياً.

تقييم مشهد CNCF دون الغرق

مع وجود أكثر من 170 مشروعاً، يعدّ التصفية المنظّمة أمراً لا غنى عنه. طبّق هذه الطبقات بالترتيب:

  1. المشكلة أولاً، المشروع ثانياً. عرّف المشكلة في جملة واحدة ("نحتاج تطبيق السياسات عند القبول لأحمال عمل Kubernetes") قبل فتح المشهد. هذا يمنع الجاذبية نحو المشاريع المثيرة للاهتمام لكن غير ذات الصلة.
  2. بوابة النضج. ابدأ من Graduated. إن لم يناسب شيء، انظر في Incubating. لا ينبغي أن تدخل مشاريع Sandbox في تقييمك إلا إذا كانت لديك القدرة للمساهمة في المشروع المصدري وتقبّل تقلّب واجهات البرمجة الملحوظ.
  3. إشارة التبني. تحقق من مسار نجوم GitHub (وليس الذروة)، وإشارات مسح مستخدمي CNCF، وكثافة محادثات المؤتمرات في الـ12 شهراً الأخيرة. مشروع Graduated بتراجع في سرعة طلبات الدمج هو إشارة تحذير.
  4. ملاءمة نموذج التهديد. بعض الأدوات لديها أنماط فشل معروفة على نطاقك. Jaeger يعمل بشكل ممتاز حتى ~100 ألف أثر في الثانية؛ بعد ذلك، تتوسع Tempo أو الخلفيات التجارية بشكل أفضل. تحقق من الصمود أمام حمل الـp95 لديك.
  5. الحوكمة وتنوّع البائعين. المشروع الذي يُسيطر عليه بائع واحد يحمل مخاطر الاستحواذ أو الهجر. تحقق من توزيع أعضاء TOC ونسبة الالتزامات ذات صاحب عمل واحد في الستة أشهر الأخيرة.
استخدم CNCF Technology Radar (يُنشر مرتين سنوياً) كمرجّح عند التعادل بين مشروعين يحلّان نفس المشكلة. يعكس التجربة التشغيلية لعشرات المستخدمين على نطاق واسع — ليس مثالياً لكنه اعتقاد أساسي قوي. رادار 2024 نقل Argo CD وCrossplane إلى "Adopt"، وTetragon إلى "Trial"، وعدة مشاريع جدولة Sandbox إلى "Assess".

سكريبت تقييم عملي: تصنيف مشروع مرشّح

عندما يصل مشروع CNCF مرشّح إلى القائمة المختصرة، شغّل هذا التقييم قبل الالتزام بجهد هندسي لإثبات المفهوم:

#!/usr/bin/env bash # cncf-eval.sh — quick due-diligence script for a CNCF candidate project # Usage: ./cncf-eval.sh <github-org> <repo> # Requires: gh CLI, jq, curl ORG=$1 REPO=$2 BASE="https://api.github.com/repos/${ORG}/${REPO}" echo "=== CNCF Project Due Diligence: ${ORG}/${REPO} ===" # 1. Maturity indicators STARS=$(curl -sf "${BASE}" | jq '.stargazers_count') FORKS=$(curl -sf "${BASE}" | jq '.forks_count') OPEN_ISSUES=$(curl -sf "${BASE}" | jq '.open_issues_count') echo "Stars: ${STARS} | Forks: ${FORKS} | Open Issues: ${OPEN_ISSUES}" # 2. Release cadence (last 5 releases) echo "--- Recent releases ---" gh release list --repo "${ORG}/${REPO}" --limit 5 # 3. Contributor diversity (unique orgs in last 90 days) echo "--- Top contributor orgs (proxy for vendor diversity) ---" gh api "repos/${ORG}/${REPO}/contributors?per_page=30" \ | jq -r '.[].login' \ | xargs -I{} gh api users/{} \ | jq -r '.company // "unknown"' \ | sort | uniq -c | sort -rn | head -10 # 4. Security posture echo "--- Open CVEs / security advisories ---" gh api "repos/${ORG}/${REPO}/security-advisories" \ | jq '[.[] | select(.state=="published")] | length' # 5. Helm chart availability (prefer official) helm search hub "${REPO}" --output json | jq '.[0:3] | .[] | {name,version,description}' echo "=== Evaluation complete. Score manually on: maturity, ops burden, lock-in, integration cost ==="

بعد السكريبت، نفّذ اختباراً لمدة ساعتين: شغّله محلياً مقابل حمل عمل تمثيلي، أدخل فشلاً واقعياً واحداً (اقتل حجرة القائد، أو أنهِك حداً للموارد)، وراقب سلوك الاستعادة. تخطَّ هذا وستكتشف نمط الفشل في الإنتاج الساعة الثانية صباحاً.

التكلفة الإجمالية للملكية: الحساب الصادق

أكبر خطأ في البناء مقابل الشراء هو حساب تكلفة الترخيص فقط مقابل تقدير البناء. تكلفة ملكية واقعية لأداة CNCF تشغّلها بنفسك تشمل:

  • التكامل الأولي: تثبيت المشغّل، وRBAC، وربط المسارات الذهبية، والمراقبة، والتوثيق. النطاق النموذجي: 1–4 أسابيع مهندس.
  • العمليات الجارية: الترقيات (مشغّلو Kubernetes يتأخرون بـ1–3 إصدارات رئيسية عادةً)، والاستجابة للحوادث، وتخطيط السعة. خصّص 0.1–0.3 FTE لكل مكوّن غير بسيط.
  • ضريبة الترقية: ترقية عنقود Kubernetes غالباً تتطلب ترقيات منسّقة لـ10–15 مكوّناً في المنصة. عند 3 ترقيات للعنقود سنوياً ويومي مهندس لكل مكوّن، تتراكم بسرعة.
  • تكلفة الفرصة البديلة: كل أسبوع مهندس يُقضى في تشغيل بنية تحتية للمنصة هو أسبوع لم يُنفق في بناء قدرات موجّهة للمنتج.
نمط مضاد شائع في الشركات الناشئة المتنامية هو تشغيل مكدّس مراقبة كامل مُستضاف ذاتياً (Prometheus وLoki وTempo وGrafana) قبل أن يمتلك التنظيم الهندسي نضج SRE الكافي لصيانته. عندما يُقتل مُدخِل Loki بسبب نفاد الذاكرة الساعة الثالثة صباحاً ولا أحد يعرف كيف يستعيد حالة المُضغِّط، فإن التكلفة ليست فاتورة AWS — بل هي ثقة المطوّرين. إذا توقفت منصة المراقبة أثناء حادث، فأنت أعمى تماماً في اللحظة التي تهم فيها الرؤية أكثر من أي وقت آخر. حتى تمتلك SRE منصة مخصصة، اشترِ خلفية المراقبة.

توجيه بمكوّن بمكوّن (الافتراضيات الافتراضية لعام 2025)

لمجالات قدرات المنصة الشائعة، إليك توافق الشركات الكبرى الحالي على محور البناء مقابل الشراء، استناداً لاستطلاعات تبني CNCF والتجربة الإنتاجية على نطاق واسع:

  • GitOps / CD: تبنّ CNCF. Argo CD (Graduated) أو Flux (Graduated). لا أداة تجارية تنافس بشكل ذي معنى في هذه الطبقة. شغّلها بثقة.
  • إدارة الأسرار: اشترِ أو تبنّ CNCF Graduated. HashiCorp Vault (مفتوح المصدر جزئياً، مرخّص الآن بـBSL) منتشر على نطاق واسع؛ HCP Vault يقلّل عبء العمليات بـ~70%. للشركات الأصغر من 50 مهنداً، HCP Vault هو الخيار الصحيح دائماً تقريباً.
  • كتالوج الخدمات / بوابة المطورين: ابدأ بـBackstage (CNCF Incubating)، فكّر في التجاري إذا كانت طاقة العمليات محدودة. Port وCortex وRoadie (Backstage مستضاف) يقللان عبء صيانة مكوّنات Backstage بشكل ملحوظ. يتطلب Backstage هندسة TypeScript جارية للبقاء محدّثاً.
  • التسليم التدريجي: تبنّ CNCF. Argo Rollouts أو Flagger (Graduated/Incubating) مُثبتان في الإنتاج على نطاق واسع. Flagger + Linkerd مزيج أنيق بشكل خاص.
  • تطبيق السياسات: تبنّ CNCF. OPA/Gatekeeper أو Kyverno (كلاهما Graduated). Kyverno أقل احتكاكاً لفرق المنصة الجديدة على Rego.
  • خلفية المراقبة: اشترِ أقل من 500 مهندس؛ شغّل ذاتياً أعلاه. Honeycomb وGrafana Cloud وDatadog تستحق التكلفة على نطاق الشركات الناشئة. فوق 500 مهندس، تُفضّل تكلفة الملكية تشغيل مكدّس Grafana + VictoriaMetrics أو Thanos ذاتياً.
  • أوركسترا المنصة (العمود الفقري لـIDP): تجنّب البناء المخصص الكامل قبل 200 مهندس. التكلفة الهندسية لـIDP جاهز للإنتاج من الصفر هي 3–5 مهندسين كبار لمدة 12+ شهراً. ابدأ بـBackstage + Crossplane واستثمر في الأدوات المخصصة فقط حيث تفشل تلك الأدوات فعلياً في متطلباتك.
# Crossplane — install and configure an AWS provider composition (self-service DB pattern) # Shows the "adopt CNCF" path for infrastructure provisioning # Install Crossplane into the platform cluster helm repo add crossplane-stable https://charts.crossplane.io/stable helm install crossplane crossplane-stable/crossplane \ --namespace crossplane-system --create-namespace \ --set args='{"--enable-composition-revisions"}' \ --version 1.16.0 # Install the AWS provider kubectl apply -f - <<EOF apiVersion: pkg.crossplane.io/v1 kind: Provider metadata: name: provider-aws-rds spec: package: xpkg.upbound.io/upbound/provider-aws-rds:v1.14.0 EOF # Wait for provider to become healthy kubectl wait provider/provider-aws-rds --for=condition=Healthy --timeout=120s # Verify composition readiness kubectl get crossplane # NAME INSTALLED HEALTHY PACKAGE # provider-aws-rds True True ... # Now apply a PostgresDatabase custom resource (as seen in Lesson 2) # kubectl apply -f orders-db.yaml # kubectl get postgresdb orders-db -w

فخ الحوكمة: عندما تتغير رخص المصدر المفتوح

إعادة ترخيص HashiCorp إلى BSL في 2023 (Terraform وVault وConsul تنتقل من MPL 2.0 إلى Business Source License) كانت حدثاً فارقاً لهندسة المنصات. أثبتت أن مشاريع مفتوحة المصدر ناضجة ومُتبنّاة على نطاق واسع يمكن أن تغيّر شروط ترخيصها بطرق تؤثر على الاستخدام التجاري. OpenTofu (فرع CNCF Sandbox من Terraform) ظهر كاستجابة المجتمع. الدرس لفرق المنصة: راجع ترخيص كل مكوّن غير CNCF في مكدّسك سنوياً. افضّل Apache 2.0 أو MIT للمكوّنات الأساسية. عندما تظهر رخصة BSL أو SSPL، قيّم نظام بيئة الفروع فوراً — لا تنتظر حتى التجديد.

احتفظ بـفاتورة مواد المنصة (PBOM): قائمة بإصدارات لكل مكوّن في IDP، ورخصته، ومستوى نضج CNCF الخاص به، والمهندس المسؤول عن الترقيات، وتاريخ آخر تدقيق أمني. خزّنها في كتالوج الخدمات (صفحة Backstage TechDocs أو ملف platform-bom.yaml في مستودع GitOps). راجعها في مراجعة المنصة الربعية. هذا المُخرج الوحيد الذي يفصل فرق المنصات الناضجة عن الفرق التي تكتشف أن إحدى التبعيات الحرجة غير مُصانة خلال حادث.