إعادة المهارات للمستقبل: لماذا يحتاج المطورون ومحترفو البنية التحتية إلى الخروج من مناطق الراحة الخاصة بهم

Matthew Finio: كيف تتغير العلاقة بين المطورين والمتخصصين في البنية التحتية؟

Miha Kralj: لقد تغيرت مهنة التطوير بأكملها مع بزوغ فجر "كل شيء معرف بالبرمجيات" – الشبكات المعرفة بالبرمجيات، التخزين المعرف بالبرمجيات، الحوسبة المعرفة بالبرمجيات.

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

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

إنه مثل كتاب Who Moved My Cheese — لا يشعر أي من الطرفين بالراحة إذا كان قادماً من العالم التقليدي القديم. الأجيال الشابة التي نشأت مع Gmail و YouTube، تعيش في هذا العالم الجديد المشترك. لكن الأشخاص الذين أتوا من جانب البنية التحتية التقليدية أو جانب التطوير يواجهون صعوبة لأنهم لم يتعلموا الجانب الآخر في السنوات الأولى من حياتهم المهنية.

MF: إذن، يجب على كل من المطورين والعاملين في مجال البنية التحتية إعادة التفكير في أوصافهم الوظيفية؟

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

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

MF: لقد ذكرت Terraform. ما هي بعض مفاهيم البنية التحتية الأخرى التي يحتاج المطورون إلى تعلمها؟

MK: كثيرًا ما يفتقر المطورون إلى الفهم الدقيق لكيفية عمل البنية التحتية الكامنة وما الذي يمكن اعتباره دائمًا وما الذي يمكن أن يكون مؤقتًا.

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

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

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

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

أنت تفكر، "أوه، مرحباً، هذا عام 2025، أيها العجوز، اجلس! العالم الحديث مختلف تمامًا. ليس لديك أي فكرة!" حسنًا، لقد بنينا هذا العالم الحديث، ونحن هنا لمساعدة المطورين الجدد والقائمين على البنية التحتية الجديدة على استخدامه بأكبر قدر ممكن من الكفاءة.

MF: هل يمكنك وصف بعض الطرق التي يمكن للمطورين من خلالها استخدام أدوات البنية التحتية كتعليمات برمجية لتحسين سير عملهم؟

MK: نعم. خير مثال على ذلك هو كيف يمكن للمطور إنشاء سير عمل مناسب لتعليماته البرمجية ليتم اختبارها تلقائيًا ثم تجميعها وتغليفها كلما قام بإنشاء جزء من التعليمات البرمجية وقام بتسليمه إلى مستودع. لا ينبغي أن يحتاج المطورون إلى شخص ما في البنية التحتية للقيام بذلك نيابة عنهم. إنشاء نص YAML جيد على GitHub هو مهمة "البنية التحتية كرمز" يمكن لكل مطور تحسينها لجعل هذه العملية فعالة قدر الإمكان.

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

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

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

MF: ما هي الأشياء المحددة التي يجب أن يفهمها متخصصو البنية التحتية حول تطوير التطبيقات اليوم؟

MK: البنية التحتية كرمز—IaC—تعني حرفياً أن العاملين في البنية التحتية أصبحوا مبرمجين. يتم تعريف البنية التحتية باستخدام النصوص البرمجية والبيانات والكود، مما يعني أن النص البرمجي أو كود البنية التحتية يحتاج إلى المرور بنفس دورة حياة تطوير البرمجيات مثل أي كود يكتبه المطورون:

• يجب توثيقها بشكل صحيح.
• يجب أن يتم تخزينها بشكل صحيح في مستودع.
• يجب أن يتم إصدارها بشكل صحيح.

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

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

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

MF: إذا كانت إعادة اكتساب المهارات وتطويرها يمثلان تحديًا كبيرًا، فكيف ينبغي لمتخصصي البنية التحتية مواكبة اتجاهات التنمية والتقنيات الحديثة؟

MK: حسنًا، لم يعد هناك أشخاص متخصصون في البنية التحتية وأشخاص متخصصون في التطوير، كل ذلك انهار معًا في مجال واحد. إنهم جميعا يتعلمون تلك الاتجاهات الجديدة—التغييرات في دورة حياة تطوير البرامج وخاصة التغييرات الآن مع الذكاء الاصطناعي.

بينما ننتقل إلى نوع من التطوير المعتمد على الذكاء الاصطناعي بشكل أصلي، يحتاج كل من المتخصصين في البنية التحتية ومطوري التطبيقات إلى تعلمه. الجميع يعاني من تأثير الخوف من فوات الأوان (FOMO) ويعتقدون أنهم متأخرون بالفعل. لقد تعلموا للتو كيفية هندسة المطالبات، والآن يُقال لهم إنهم بحاجة إلى تعلم كيفية كتابة الوكلاء على Semantic Kernel أو ما شابه ذلك.

يحتاج الناس إلى مساعدة بعضهم البعض، وعليهم إيجاد التوازن الصحيح. كم من الوقت يجب قضاؤه للبقاء على اطلاع دائم ومعرفة أنك لا تزال متفوقًا؟ لقد كانت 5%، والآن أصبحت 10%. الذكاء الاصطناعي التوليدي يساعد. لكن هذه النسبة بين مقدار الوقت الذي تحتاجه للتعلم مقابل مقدار الوقت الذي تطبق فيه ذلك وتصنع شيئًا يوفر قيمة تجارية أو قيمة لتقنية المعلومات، تميل أكثر فأكثر نحو التعلم.

MF: وقبل أن نختتم، ما هي بعض الأشياء الرئيسية التي يجب على المطورين ومتخصصي البنية التحتية وضعها في الاعتبار بشأن التطبيقات الحديثة؟

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

لذلك، ما يحتاج محترفو البنية التحتية إلى التفكير فيه هو أن يصبحوا مطوري برامج. والأمر نفسه بالنسبة لمطوري البرامج، فهم بحاجة إلى أن يصبحوا متخصصين في البنية التحتية.

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