هندسة المنصات: تطور DevOps، وليس بديلاً

تعد هندسة المنصات موضوعًا ساخنًا في تطوير البرامج الحديثة وتسليمها، حيث يدعي البعض أنها بديل لـ DevOps، أو حتى يعلنون أن “DevOps قد مات”.

ولكن وسط هذه الضجة، من المهم أن نفهم أن هندسة المنصات هي في الواقع تطور في تقديم البنية التحتية، وليست بديلاً، مبنية على الفلسفات الأساسية التي تدعم DevOps.

في هذه المقالة، سنلقي نظرة فاحصة على هندسة المنصات. سوف نستكشف ما هو عليه في الواقع، ونحلل بعض مكوناته الأكثر شيوعًا.

في النهاية، ستدرك لماذا تعد هندسة الأنظمة الأساسية مجرد التقدم التالي في تقديم البنية التحتية الحديثة للتطبيقات.

ما هي هندسة المنصات؟

أولاً، دعونا نتحدث عن سيناريو شائع في هندسة البرمجيات الحديثة.

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

يبدو هذا مثالًا مثاليًا لـ DevOps – دمج المطورين والعمليات معًا، أليس كذلك؟ السعادة وقوس قزح.

لسوء الحظ، هذا النهج له مشاكله. يتم تحميل المطورين فجأة بمسؤوليات إضافية مثل العمليات والبنية التحتية والأمن. أدخل الأخطاء والديون الفنية!

على الرغم من أنه من الجيد للمطورين معرفة هذه المجالات، إلا أن الوظيفة الأساسية لمهندس البرمجيات هي هندسة البرمجيات.

يؤدي التورط في إدارة البنية التحتية إلى إبطاء تقديم الميزات الجديدة، وهذا لا يتماشى إلى حد كبير مع فلسفة DevOps.

أدخل هندسة المنصة! يقدم هذا النهج فريقًا مركزيًا يدير البنية التحتية المشتركة لجميع فرق التطوير.

ومن خلال القيام بذلك، يمكن للمطورين التركيز على مهامهم الأساسية، مثل العمل المميز، دون القلق بشأن متاعب إدارة البنية التحتية.

يعتني فريق النظام الأساسي بأي مخاوف تشغيلية وأمنية، ويتأكد من أن البنية التحتية آمنة ومتاحة وقابلة للتطوير، بينما يركز مهندسو البرمجيات على تطبيقاتهم.

إنه سيناريو مربح للجانبين يضمن تسليم الميزات الجديدة بشكل أسرع وجودة أفضل للبرامج بشكل عام.

ما هي مكونات هندسة المنصات؟

1. الأتمتة والبنية التحتية كرمز (IaC)

عندما يتعلق الأمر بإدارة البنية التحتية على نطاق واسع، تعد البنية التحتية كرمز (IaC) أمرًا بالغ الأهمية لفرق هندسة النظام الأساسي.

في الواقع، وبالحجم الذي تتطلبه معظم التطبيقات التي تواجه الإنترنت، فإن IaC يعد عمليًا “أمرًا لا بد منه”.

من المؤكد أن توفير الموارد يدويًا عبر وحدة التحكم يعمل إذا كنت تختبر عددًا قليلاً من عقد الحوسبة، ولكنه لن يقطعها عندما تحتاج إلى توسيع نطاق آلاف العقد أو خفضها استجابة لطلب المستخدم المرن.

إن IaC هو مجرد عنصر واحد من نموذج تشغيلي أوسع. يمكن إعداد Terraform، إحدى أدوات IaC الأكثر شيوعًا، وتشغيلها من محطة عمل واحدة.

ولكن كما هو الحال مع التزويد القائم على النقرات، لن يتم توسيع نطاق هذا النهج.

لحسن الحظ، لدى Terraform الكثير من ميزات الأتمتة التي يمكن استخدامها من خلال البنية التحتية CI/CD. نظرًا لوجود عدد أكبر من مهندسي البرمجيات عادةً مقارنة بمهندسي النظام الأساسي، يحتاج هؤلاء الموجودون في فريق النظام الأساسي إلى تحقيق أقصى استفادة من مواردهم عند الإدارة على نطاق واسع.

يمكن أن يؤدي الفحص الآلي والاختبار والنشر إلى تحسين الموثوقية ووضع أمني أفضل.

2. النقل بالحاويات والتنسيق

تعتبر الحاويات بمثابة تغيير حقيقي لقواعد اللعبة عندما يتعلق الأمر بتطوير البرامج الحديثة. إنها توفر حلاً رائعًا لإنشاء عناصر بناء مستقلة عن النظام الأساسي.

من خلال تجميع التطبيقات والتبعيات في بيئات معزولة، تتأكد الحاويات من أن كل شيء يعمل بشكل متسق عبر مراحل التطوير المختلفة.

يعد هذا أمرًا مهمًا لضمان عمليات نشر مستقرة وموثوقة (والتي تعد أحد العناصر الأساسية لتطوير التطبيقات ذات الاثني عشر عاملًا.

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

تسمح الحاويات للفرق الهندسية بالاقتراب كثيرًا من المثالية للبنيات القابلة للتكرار، مما يعني أن ملف Dockerfile سيبني نفس الحاوية على أي جهاز.

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

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

بالنسبة لفريق هندسة المنصات، الأمر كله يتعلق بالرافعة المالية؛ لقد برز Kubernetes باعتباره الخيار الأفضل لتنسيق الحاويات، وإذا كنت ستدعم أنظمة برمجية متعددة تم إنشاؤها باستخدام الحاويات، فأنت بحاجة إلى نظام أساسي للتنسيق.

3. التكامل المستمر والنشر المستمر (CI/CD)

يعد CI/CD العمود الفقري للأتمتة اللازمة لتقديم البرامج على نطاق واسع.

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

في مجال هندسة الأنظمة الأساسية، يعد CI/CD ضروريًا للحفاظ على منصة البنية التحتية المشتركة محدثة وآمنة وموثوقة.

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

يؤدي ذلك إلى تقليل الاضطرابات التي قد تواجهها فرق التطوير التي تعتمد على النظام الأساسي مع ضمان تحديد أي مشكلات محتملة ومعالجتها في وقت مبكر من عملية التطوير.

بالإضافة إلى ذلك، يمكن لفرق النظام الأساسي توفير نفس عمليات CI/CD لفرق التطوير بسهولة، مما يضمن عدم وجود حاجة إلى إعادة اختراع العجلة لأتمتة النشر.

4. الرصد والملاحظة

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

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

في بيئة النظام الأساسي، تعتبر الأجهزة القوية مهمة لسببين:

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

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

ومع ذلك، مع الأنظمة الموزعة الحديثة مثل تلك الموجودة في النظام الأساسي، لن تحكي هذه المقاييس القصة بأكملها.

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

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

ما هي فوائد هندسة المنصات؟

توفر هندسة المنصات العديد من المزايا للمؤسسات التي تعتمدها. وتمتد هذه الفوائد لتشمل جوانب مختلفة من تطوير البرمجيات وعملياتها، بما في ذلك الاتساق وقابلية التوسع والأمان والتحكم في التكاليف.

دعونا نلقي نظرة فاحصة على بعض الفوائد الرئيسية لهندسة المنصات:

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