هندسة منصات المطورين الداخلية على Azure: بناء الأساس

By Mirko Peters · 2026-08-13

مرحباً بكم من جديد في المدونة المرافقة للبودكاست! في هذا التعمّق اليوم، نتوسع في موضوع يهيمن على النقاشات المعمارية في قطاع التقنية: منصات المطورين الداخلية، أو IDPs. إذا استمعتم إلى أحدث حلقة لدينا، فأنتم تعلمون أننا تطرقنا إلى كيف أن الحمل المعرفي يقوّض سرعة المطورين بصمت. اليوم نخطو خطوة أبعد، ونتناول كيفية بناء منصة IDP قوية وقابلة للتوسع وآمنة بشكل أصيل على Microsoft Azure، مستفيدين من نماذج

Automatically translated with AI from the original post. Read the English original

Titelbild: Architecting Internal Developer Platforms on Azure: Building the Foundation

تواجه مؤسسات الهندسة الحديثة مفارقة. نمنح المطورين قوة غير مسبوقة عبر السحابة، ومع ذلك نُغرقهم في تعقيد تشغيلي. يقضون وقتاً أطول في التعامل مع طبولوجيا الشبكات، وإعدادات إدارة الهوية والوصول، وخطوط النشر، مما يقضونه في كتابة منطق الأعمال. تحل منصة IDP هذه المشكلة بالعمل كطبقة تجريد منتقاة. فهي لا تقيّد المطورين، بل تمكّنهم عبر توفير مسارات ذهبية توصلهم إلى بيئة الإنتاج بسرعة وأمان. دعونا نستعرض كيفية هندسة هذا الأساس على Azure.

مقدمة إلى منصات المطورين الداخلية على Azure

قبل الغوص في التفاصيل التقنية لخدمات Azure، دعونا نحدد ما هي منصة IDP فعلاً، ولماذا يُعد Azure مؤهلاً بشكل فريد لاستضافتها. منصة IDP ليست برنامجاً واحداً تشتريه جاهزاً من الرف. إنها مجموعة مُنتجة من الأدوات والخدمات وسير عمل البنية التحتية الداخلية، مجمّعة في بوابة متماسكة للمطورين. تقع بينكم وبين البنية التحتية السحابية الأساسية، فتترجم نوايا المطورين عالية المستوى إلى موارد سحابية آمنة ومتوافقة وجاهزة للإنتاج.

يوفر Azure منظومة واسعة من العناصر الأساسية بمستوى المؤسسات. ومع ذلك، فإن عرض هذه العناصر الخام مباشرة على المطورين يؤدي غالباً إلى انحراف الإعدادات، وثغرات أمنية، وموارد يتيمة. ومن خلال هندسة منصة IDP على Azure، يستطيع مهندسو المنصات تغليف هذه الخدمات الأصلية في قوالب موحدة ومُوجَّهة. وهذا يعني أن المطور يمكنه طلب بيئة خدمة مصغرة مكتملة الإعداد مع قاعدة بيانات وطبقة تخزين مؤقت مرفقة، دون الحاجة إلى درجة الماجستير في شبكات Azure أو التحكم في الوصول القائم على الأدوار.

الركائز الأساسية لمنصة IDP حديثة

عند تصميم منصتكم، يجب أن ترتكز قراراتكم على أربع ركائز أساسية: الخدمة الذاتية، والمسارات الذهبية، والتجريد، وحواجز الحماية. من دون هذه الركائز، قد تتحول منصتكم بسهولة إلى مجرد نظام آخر للتذاكر أو صفحة wiki غير موثقة.

الخدمة الذاتية دون أعباء تشغيلية

الخدمة الذاتية هي القلب النابض لأي منصة IDP. في الإعداد التقليدي، عندما يحتاج المطور إلى بيئة تجهيز جديدة أو نسخة من Cosmos DB، يفتح تذكرة في Jira، ثم ينتظر مراجعة فريق المنصة، ثم ينتظر فريق العمليات للتجهيز، ويأمل أن يطابق الإعداد بيئة الإنتاج. تقوم منصة IDP على Azure بأتمتة دورة الحياة هذه بالكامل. فعبر بوابة مركزية، يستطيع المطورون تشغيل سير عمل الخدمة الذاتية التي تجهّز الموارد في دقائق، مما يقلل بشكل كبير من زمن التسليم للتغييرات.

المسارات الذهبية وطبقات التجريد

المسارات الذهبية هي طرق مُوجَّهة ومدعومة لإنجاز المهام داخل مؤسستكم. فهي لا تُزيل المرونة؛ بل تُزيل الاحتكاك. وبتجريد تعقيد Azure الكامن خلف ملفات إعداد بسيطة، مثل بيان تطبيق واحد، يستطيع المطورون التصريح بما يريدون نشره، بينما تتولى منصة IDP كيفية نشره على Azure.

الاستفادة من خدمات Azure للبنية التحتية الأصيلة

بناء منصة IDP على Azure يعني اختيار الخدمات الأساسية المناسبة للتعامل مع الحوسبة والتخزين والشبكات والهوية. دعونا نرى كيف يمكنكم ربط متطلبات المنصة بخدمات Azure الأصيلة.

إدارة الهوية والوصول باستخدام Microsoft Entra ID

يبدأ الأمان من الهوية. تعمل Microsoft Entra ID (المعروفة سابقًا باسم Azure Active Directory) كعمود فقري أمني لمنصة IDP لديك. من خلال دمج بوابة المنصة مع Entra ID، يمكنك فرض تسجيل الدخول الموحد (SSO) وربط مجموعات المطورين بإمكانات محددة في المنصة. ومن خلال استخدام الهويات المُدارة في Azure (Azure Managed Identities)، يمكن للتطبيقات المنشورة الوصول بأمان إلى موارد Azure الأخرى، مثل Azure Key Vault أو Azure SQL، دون تضمين بيانات الاعتماد بشكل صريح في ملفات الإعداد أو المستودعات.

تجريدات البيانات والتخزين

تحتاج التطبيقات إلى البيانات، لكن لا ينبغي لفرق المنصة أن تضطر إلى إنشاء قواعد البيانات يدويًا في كل مرة تبدأ فيها فرقة مشروعًا جديدًا. يمكنك استخدام Azure Service Operator for Kubernetes أو قوالب Azure Resource Manager (ARM) ضمن سير عمل ذاتي الخدمة لتوفير الخدمات المُدارة مثل Azure Database for PostgreSQL وAzure Cosmos DB وAzure Cache for Redis عند الطلب. تضمن منصة IDP أن تُجهَّز قواعد البيانات هذه مع تشفير البيانات أثناء التخزين، وقواعد جدار الحماية المناسبة، والنسخ الاحتياطي التلقائي مفعّلًا افتراضيًا.

استراتيجيات الحاويات والتنسيق

الحاويات هي اللغة المشتركة للتطبيقات الحديثة السحابية الأصلية. ولا غنى عن توحيد طريقة تغليف التطبيقات وتشغيلها لنجاح منصة IDP.

Azure Kubernetes Service كمحرك حوسبة

بالنسبة لمعظم المؤسسات الحديثة، تعمل Azure Kubernetes Service (AKS) كمحرك الحوسبة الرئيسي لمنصة IDP. توفر AKS القابلية للتوسع والنقل والقدرات التنسيقية اللازمة لتشغيل الخدمات المصغّرة على نطاق واسع. ومع ذلك، لا ينبغي أن يضطر المطورون إلى كتابة ملفات YAML الخام لـ Kubernetes. يجب أن تُخفي منصة IDP تعقيدات وحدات التحكم في Ingress وسياسات الشبكة ومطالبات وحدات التخزين الدائمة خلف تجريدات عالية المستوى لأعباء العمل.

سجلات الحاويات وأمن سلسلة التوريد

تتكامل Azure Container Registry (ACR) بسلاسة مع AKS وتشكل جزءًا حاسمًا من استراتيجية الحاويات لديك. يجب أن تؤتمت منصة IDP المسار من إيداع الشيفرة حتى بناء صورة الحاوية، مستفيدةً من أدوات مثل Microsoft Defender for Containers لفحص الصور بحثًا عن الثغرات الأمنية قبل أن تصل إلى أي مجموعة. ومن خلال دمج ACR في سير عمل المنصة، تضمن ألا يُنشر إلى بيئات الإنتاج إلا الصور الموثوقة والمفحوصة.

مبادئ البنية التحتية كشيفرة في هندسة المنصات

البنية التحتية كشيفرة (IaC) أمر لا مفر منه عند بناء منصة IDP. يجب تعريف كل جزء من البنية التحتية التي تديرها المنصة، وتخزينه تحت التحكم بالإصدارات، ونشره عبر خطوط أنابيب مؤتمتة.

اختيار أدوات IaC في منظومة Azure

تدعم Azure مجموعة واسعة من أدوات IaC. Bicep هي لغة المجال المحدد من Microsoft لنشر موارد Azure بشكل تصريحي، وتتميز بصياغة أنظف من قوالب ARM التقليدية مع دعم أصلي لميزات Azure. وبدلًا من ذلك، تُعتمد Terraform (أو OpenTofu) على نطاق واسع في البيئات متعددة السحابات والبيئات المؤسسية. وأيًّا كانت الأداة التي تختارها، ينبغي أن تُجرّد منصة IDP المطورين من هذه النصوص البرمجية، فتنفذها خلف الكواليس عند الموافقة على طلب التجهيز.

إدارة الحالة والتصميم المعياري

للحفاظ على قابلية صيانة المنصة، ابنِ مكتبة من وحدات البنية التحتية القابلة لإعادة الاستخدام. على سبيل المثال، أنشئ وحدة قياسية باسم "web-api-module" تجمع نشر App Service أو AKS مع قاعدة بيانات مرتبطة ومثيل مراقبة. خزّن حالة IaC بأمان في حسابات Azure Storage مع تفعيل إصدارات الكائنات الثنائية (blob versioning)، لضمان أن يحافظ فريق هندسة المنصات على سجل تدقيق موثوق لجميع تغييرات البنية التحتية عبر الاشتراكات.

تضمين ضوابط الأمان والامتثال

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

Azure Policy كأداة فرض مؤتمتة

تُعد Azure Policy خير معين لك عند تصميم ضوابط المنصة. فبدلًا من تدقيق الموارد يدويًا، يمكنك استخدام Azure Policy لفرض معايير المؤسسة تلقائيًا، مثل تقييد إنشاء الموارد بمناطق Azure محددة، أو اشتراط التشفير على جميع حسابات التخزين، أو فرض علامات شبكية معينة. وإذا حاول مطور تجهيز مورد يخالف هذه النهج، تكتشف منصة IDP ذلك أثناء مرحلة التحقق، وتقدم ملاحظات فورية.

إدارة الأسرار والتكامل مع Key Vault

تُعدّ الأسرار المكتوبة بشكل ثابت في التعليمات البرمجية ثغرةً أمنية متكررة. ينبغي أن تفرض منصة IDP الخاصة بك إدارة آمنة للأسرار افتراضيًا. ادمج Azure Key Vault في مسارات النشر لديك بحيث يتم حقن أسرار التطبيقات ومفاتيح واجهات البرمجة وسلاسل الاتصال بأمان في وقت التشغيل، مع إبقائها بعيدة تمامًا عن أنظار المطورين ومستودعات التحكم في المصدر.

بناء بوابة المطورين ذاتية الخدمة

يجب جمع كل هذه العناصر الأساسية، أي الهوية والحوسبة وIaC والأمان، في لوحة عرض موحّدة واحدة: بوابة المطورين. وهذه هي واجهة المستخدم لمنصة IDP الخاصة بك.

اعتماد Backstage للبوابات المتمحورة حول Azure

أصبحت أُطر العمل مفتوحة المصدر مثل Backstage من Spotify المعيارَ الفعلي لبناء بوابات المطورين. يتيح Backstage إنشاء كتالوج للبرمجيات وإدارة القوالب (المعروفة باسم قوالب البرمجيات) ودمج الإضافات. يمكنك بناء إضافات مخصصة لـ Backstage تتواصل مباشرةً مع واجهات برمجة تطبيقات Azure، فيتيح ذلك للمطورين إنشاء موارد Azure ومراقبة صحة الخدمات وتتبع مسارات النشر، كل ذلك من لوحة معلومات واحدة.

تصميم تجربة مطور بديهية

عند تصميم البوابة، عامِل مطوريك كعملاء. يجب أن تكون تجربة الاستخدام خالية من العوائق. ينبغي للمطور أن يتمكن من الوصول إلى البوابة، واختيار قالب "Microservice with SQL Backend"، وتعبئة نموذج بسيط يتضمن اسم الخدمة وفريق المالك، ثم النقر على إرسال. وخلال دقائق، ينبغي لمنصة IDP أن تُجهّز البنية التحتية في Azure، وتُنشئ مستودع GitHub مع الشيفرة الأساسية، وتهيّئ مسار CI/CD، وتسجّل الخدمة في الكتالوج الداخلي.

قياس النجاح والخطوات التالية

بناء منصة IDP ليس مشروعًا له تاريخ انتهاء محدد، بل هو رحلة منتج مستمرة. وبمجرد أن تصبح منصتك جاهزة للعمل، تحتاج إلى قياس أثرها لتبرير الاستثمار فيها وتحسين تجربة المطورين باستمرار.

أهم المقاييس للمتابعة

ركّز على المقاييس التي تعكس سرعة المطورين واستقرار المنصة. تتبّع الزمن اللازم لأول مرحلة "Hello World" للمطورين الجدد الذين ينضمون إلى الشركة، وتكرار عمليات النشر، ومعدل فشل التغييرات، ومتوسط زمن الاستعادة (MTTR). إضافةً إلى ذلك، أجرِ استطلاعات دورية لرضا المطورين لتحديد مواطن الاحتكاك التي ما تزال قائمة في مسارات العمل داخل منصتك.

إلى أين تتجه من هنا

ابدأ بخطوات صغيرة. لا تحاول بناء منصة مؤسسية ضخمة من اليوم الأول. اختر حالة استخدام واحدة، كتوحيد عمليات نشر الحاويات أو أتمتة توفير قواعد البيانات مثلًا، وابنِ حولها منصةً بالحد الأدنى من الإمكانات القابلة للاستخدام. اجمع الملاحظات من الفرق الأولى التي تتبنى المنصة، وحسّن مساراتك الذهبية باستمرار، ووسّع إمكانات منصتك تدريجيًا عبر المؤسسة.

بتصميم منصة المطورين الداخلية لديك على Azure بشكل أصيل، فأنت لا تكتفي بأتمتة عمليات النشر، بل تبني محرّكًا لنمو هندسي مستدام. شكرًا لقراءتك، ولا تُفوّت الاستماع إلى حلقة البودكاست للحصول على نقاش صوتي أعمق حول هذا الموضوع. أتمنى لك بناءً موفقًا!