اعتماد DevOps مستمر منذ عقد من الزمن ولا تظهر عليه أي علامات على التباطؤ. في استطلاع تجربة المطورين لعام 2024 الذي أجرته شركة Forrester، أشار 87% من المطورين إلى أن مؤسساتهم قد اعتمدت بالفعل ممارسات DevOps أو خططت للقيام بذلك في العام المقبل.
ولكن بالنسبة للعديد من المؤسسات، فقد كان توسيع نطاق ممارسات DevOps الخاصة بها أمرًا ضروريًا كانت معقدةباهظة الثمن، وفي النهاية، غير كافية لتقديم القيمة التي توقعها القادة. تبدأ هذه المؤسسات بنهج شعبي لاعتماد DevOps، حيث يقوم كل فريق باختيار سلسلة أدواته بنفسه، وإنشاء أفضل ممارساته وغرس معرفته المؤسسية.
يخبرنا عملاء Forrester أن هذا النهج القائم على الفريق ينهار على نطاق واسع. فهو يخلق العديد من المشاكل بقدر ما يحلها، ولا يقدم النتائج التي كان يتوقعها المديرون التنفيذيون.
على سبيل المثال، تسبب سلاسل الأدوات المخصصة صداعًا. إن المؤسسات التي اتبعت هذا النهج أصبحت الآن مثقلة بعدد كبير جدًا من سلاسل الأدوات الفريدة، والتي تتطلب كل منها رعاية من قبل نفس المطورين الذين من المفترض أن يقوموا ببناء منتجات تركز على العملاء. تتطلب سلاسل الأدوات هذه أيضًا أتمتة فريدة من نوعها، وإنشاء معرفة مؤسسية محاصرة، والمساهمة في انتشار الأدوات والحد من أي فرصة لتسعير أدوات DevOps بكميات كبيرة.
كل هذه العوامل تسبب صداعًا لقادة تكنولوجيا المعلومات الذين يحاولون تقليل النفقات العامة مع تحسين الإنتاجية والكفاءة.
تدرك العديد من المؤسسات الآن أن تحسين تجربة المطورين يزيد من الكفاءة عن طريق إزالة العوائق التي تعترض عملية التطوير. ومن بين هذه العوائق التبديل غير الضروري للسياق، مما يكسر تركيز المطورين ويقلل التدفق.
تعمل أدوات التشغيل الآلي المنفصلة وأنظمة التسجيل المتعددة والمنصات المتعددة على إبطاء المطورين من خلال إجبارهم على لعب الحجلة باستخدام العديد من الأدوات. بدون وجود نظام أساسي مشترك باعتباره العمود الفقري، عندما يقوم المطورون بتغيير المشاريع، فقد يخضعون لإجراءات تأهيل جديدة تمامًا للوصول إلى المستودعات وتنفيذ طلب السحب الأول الخاص بهم.
ويتسبب الافتقار إلى الممارسات الموحدة في حدوث مشكلات تتعلق بالحوكمة أيضًا. وبدون اتباع نهج قياسي في تسليم البرامج، سينتهي بك الأمر إلى تطبيق حوكمة مخصصة بشكل مختلف اعتمادًا على سلسلة الأدوات. يؤدي هذا إلى إنشاء حواجز ثقة بين المطورين وفرق حوكمة المؤسسة، ويمكن أن يضيف إشرافًا يدويًا وإجراءات روتينية تؤدي إلى إبطاء العمليات، ويعمل ضد الجهود المبذولة لتحسين الإنتاجية والكفاءة على نطاق واسع.
هناك مشكلة أخرى يواجهها مطورو البرامج وهي أن كتالوج خدمات تكنولوجيا المعلومات التقليدية يمثل حلاً ثقيل الوزن. تمتلك العديد من المؤسسات بوابات خدمات منذ سنوات، ترتكز على ممارسات إدارة تكنولوجيا المعلومات وخدمات المؤسسات وتعتمد على منتجات مثل ServiceNow أو Atlassian’s Jira Service Management أو BMC Helix.
تظل هذه الأدوات قائمة لأنها غالبًا ما تخدم مستخدمين غير تقنيين ويمكن الاستفادة منها بواسطة مؤسسات البنية التحتية التقليدية للحصول على عروض التذاكر. ومع ذلك، يجد المطورون أن عمليات شراء التذاكر بطيئة للغاية وغير مستجيبة، وهذا هو سبب ظهور سوق للتذاكر المخصصة منصات المطورين الداخليين (IDPs).
منصة متدرجة للخدمات
توفر IDPs إطارًا لإنشاء منصة لتكنولوجيا المعلومات حيث يمكن تعريف الخدمات وأتمتتها وعرضها عبر المؤسسة.
تتضمن أمثلة خدمات تكنولوجيا المعلومات التي يمكن دمجها في IDP تخصيص جزء جديد من البنية التحتية، مثل جهاز افتراضي جديد، أو إنشاء خط أنابيب للتكامل المستمر الآلي/التسليم المستمر (CI/CD) لإنشاء التعليمات البرمجية وتسليمها، أو إنشاء السقالات لمشروع خدمة صغيرة جديد باستخدام أفضل الممارسات التنظيمية.
توفر منصات المطورين الداخلية إطار عمل لإنشاء منصة لتكنولوجيا المعلومات حيث يمكن تعريف الخدمات وأتمتتها وعرضها عبر المؤسسة
فوريستر
يقوم IDPs بتسهيل الإدارة والوصول إلى أتمتة الخدمة من خلال توفير إطار لإدارة وكشف الأتمتة على نطاق واسع.
يمكن للنازحين توفير رؤية للأدوات والأطر. إحدى ميزات IDPs هي بطاقات الأداء، التي توفر معلومات حول الأداء الفني والتجاري للتكنولوجيات. وهذا يساعد المطورين على اتخاذ القرار الصحيح عندما يواجهون أطر عمل متعددة، كما يمنح القادة نظرة ثاقبة حول اعتمادها.
يصبح اعتماد الأدوات الجديدة واضحًا للقيادة، كما هو الحال مع التخلي عن التقنيات القديمة، مما يمكّن القادة من إهمال المكونات القديمة وإزالتها عندما يكون ذلك منطقيًا بالنسبة للشركة.
على مستوى عالٍ، يمكن للنازحين داخليًا أن يلعبوا دورًا مشابهًا للمنصة التقليدية كخدمة (PaaS) من خلال توفير طبقة تجريد لخدمات البنية التحتية لتكنولوجيا المعلومات. ومع ذلك، في حين أن العديد من تطبيقات PaaS تحتوي على طبقات تجريد غير شفافة، فإن IDPs توفر طبقة شفافة عبر ملفات تعريف الخدمة التي تمكن المطورين ومهندسي البنية التحتية من عرض آليات التجريد الأساسية وإعادة استخدامها وتحسينها.
يحتاج منشئو المنصات إلى فهم هذه الاختلافات لتحديد النموذج التجريدي الذي سيخدم احتياجاتهم بشكل أفضل.
هناك عدة أسباب لاعتماده. سبوتيفي يتمتع بسمعة طيبة في العمليات الهندسية التحويلية. تبنت العديد من المنظمات نموذج Spotify الشهير الآن، والذي يضم الفرق والقبائل والنقابات. إن وجود Backstage في CNCF يضمن الحوكمة ومجتمع صحي من المساهمين والمتبنين. يدعم عدد متزايد من موردي أدوات DevOps التجارية المكونات الإضافية Backstage. والأهم من ذلك، نظرًا لأنه مفتوح المصدر، فإن Backstage مجاني للمطورين لتنزيله وتجربته، مما يزيد من الاهتمام بالمنصات بشكل عام.
قبل الالتزام بـ IDP، يجب على قادة تكنولوجيا المعلومات إنشاء حالة عمل مقنعة تحدد الفوائد التي سيجلبها IDP إلى المنظمة وكيف سيتم قياسها
فوريستر
لقد افترضت العديد من الفرق، أو كانت تأمل، أن تكون Backstage عبارة عن منصة جاهزة للاستخدام، ولكن سرعان ما أصبحت غارقة في تعقيدها. وقد خلق هذا فرصة لموفري البرامج التجارية لتمييز عروضهم عن Backstage. يدعي مقدمو الأدوات التجارية هؤلاء أن منتجاتهم أسهل في البدء، ولديها منحنى تعليمي أقل وتوفر مزايا تكنولوجية لـ Backstage، مثل توفير طبقة تنسيق الخدمة.
يقدم Spotify أيضًا Backstage كاشتراك تجاري مدفوع يتضمن دعم المنتج والمكونات الإضافية الإضافية وقدرات عدم استخدام التعليمات البرمجية لمساعدة الشركات على البدء بشكل أسرع وبثقة أكبر. ويرى المستخدمون هذه الإضافات التجارية، مثل Soundcheck (وهو مكون إضافي يساعد الفرق على تصور فحوصات الجودة والأمن والموثوقية على الخدمات)، كقيمة مضافة.
قبل الالتزام بـ IDP، توصي Forrester قادة تكنولوجيا المعلومات ببناء حالة عمل مقنعة تحدد الفوائد التي سيجلبها IDP إلى المؤسسة وكيف سيتم قياسها. إن تطوير خطة عمل شاملة سيضمن التوافق بين أصحاب المصلحة الذين يمولون مبادرة المنصة والمسؤولين عن إنشائها.
لقد وجدت شركة Forrester أن كل شركة IDP ومستخدم نهائي تقريبًا نجح في إنشاء IDP بدأ صغيرًا من خلال بناء إثبات المفهوم (PoC). يمكن أن يستغرق التنفيذ الأول عدة أسابيع إلى أشهر.
توصي شركة Forrester بأن يقوم قادة تكنولوجيا المعلومات أولاً بتحديد فريق متعاون ويدرك فائدة نهج IDP. بعد ذلك، قم ببناء إثبات المفهوم (PoC) حول عدد قليل من الاحتياجات الأساسية للأعضاء أثناء التعامل معهم للحصول على اقتراحات إضافية وحتى مساهماتهم الخاصة لتحسين IDP. يمكن البناء على هذا النهج واستخدامه كنقطة انطلاق للفرق الأخرى لمواصلة تنمية IDP بطريقة مستدامة.
