عرضت يوجينيا بيرجمان وهاجن تونيز كيفية تحولهما من التفكير في المشروع إلى التفكير في المنتج بعد أن تجاوزت منصتهما الاستخدام الفردي للفريق في KubeCon & CloudNativeCon Europe. وكانت القيود التي شعروا بها مع منصتهم هي عمليات التسليم لمرة واحدة، والافتقار إلى رؤية المنتج، وحلقات ردود الفعل الضعيفة. لقد انتقلوا نحو بنية تحتية ذاتية الخدمة تعتمد على واجهة برمجة التطبيقات ومتعددة المستأجرين مع ملكية أكثر وضوحًا وتجريدًا أفضل.
ذكر بيرجمان أن دورة تطوير النظام الأساسي الخاصة بهم تم تنظيمها حول التخطيط السنوي للمشروع. يبدأ العمل عادةً بتحديد النطاق مقدمًا، وتخصيص الميزانية، ومعالم التسليم المحددة. تم التعامل مع كل مبادرة على أنها مشروع ذو بداية ونهاية واضحتين، وتم قياس النجاح من خلال ما إذا كانت قد تم تنفيذها من حيث النطاق والوقت والمعالم:
لقد نجح هذا بشكل جيد عندما دعم النظام الأساسي خدمة واحدة للمؤسسة التي قدمت منتج بث الألعاب. مع مرور الوقت، تطورت منصتنا لدعم فرق داخلية متعددة ذات احتياجات مختلفة. وقد أدى ذلك إلى تغيير جذري في طبيعة النظام.
ذكر بيرجمان العديد من القيود التي شعروا بها في منصتهم:
- تم التعامل مع كل تحسن على أنه تسليم لمرة واحدة
- وأدى ذلك إلى تراكم القدرات التي كانت تتنافس في الأولوية مع عنصر التسليم التالي
- لم يكن لدى المنصة تعريف واضح للمنتج
وقال بيرجمان إنهم كانوا يقدمون خدماتهم بشكل مستمر، ولكنهم لم يحسنوا دائمًا سهولة الاستخدام أو تماسك المنصة ككل. كانت حلقات ردود الفعل داخلية في المقام الأول، وتركزت على أداء العدو السريع (السرعة، والإكمال، والجودة)، مع القليل من التحقق من الصحة من مستخدمي النظام الأساسي الفعلي. تم تحسين النظام للاكتمال وليس للقيمة طويلة المدى.
وأوضح تونيز، مستلهمًا مزيجًا من التأثير الخارجي والتفكير الداخلي، تحولهم من نهج المشروع إلى نهج المنتج:
كان لدينا أقران في وقت مبكر يقدمون التفكير النظمي والتفكير في المنتج – مستمدين من أنظمة بيئية مثل Prometheus وGrafana – وبدأنا داخليًا في التعامل مع مواد مثل Project to Product وThe Phoenix Project، حيث تعرفنا على العديد من نقاط الضعف لدينا.
وقال تونيس إن هذا أدى إلى ظهور مجتمع صغير من الممارسة بين المهندسين المعماريين وكبار المهندسين، حيث ناقشوا هذه الأفكار واستكشفوا البدائل لنموذجنا الحالي.
مع مرور الوقت، تطورت منصة المطورين الخاصة بهم بشكل ملحوظ. وأوضح تونيز أنه لم يكن منصة واحدة موحدة أبدًا، بل كان عبارة عن مجموعة من الإمكانات التي نمت بشكل عضوي حول ممارسات Kubernetes وGitOps:
في وقت مبكر، تركزت المنصة حول عمليات النشر المستندة إلى Helm، والموارد على نطاق الاسم، وسير العمل المعتمد على GitLab، حيث تم دمج الفرق من خلال نموذج IDP داخلي وعملت إلى حد كبير ضمن مجموعات مشتركة. لقد نجح هذا بشكل جيد في توحيد تسليم التطبيقات، ولكن تم تحسينه بشكل أساسي لفرق الخدمة الفردية ولم يعالج بشكل كامل احتياجات المستأجرين المتعددين أو احتياجات البنية التحتية الأكثر تعقيدًا.
ومع توسع نظامهم البيئي، خاصة مع تقديم الخدمات السحابية العامة مثل AWS، فقد شهدوا تحولًا طبيعيًا في التوقعات، حيث أصبحت الفرق أكثر اعتيادًا على البنية التحتية للخدمة الذاتية ونماذج ملكية أكثر وضوحًا. وأوضح تونيس أن هذا سلط الضوء على الفرص المتاحة لهم لتحسين تجربة النظام الأساسي الداخلي، لا سيما في التجريد والتوثيق وفي تمكين فصل أقوى للمخاوف بين مسؤوليات النظام الأساسي والمستهلك:
لقد قمنا بالتطور نحو نموذج منصة أكثر توجهاً نحو المنتج، مع حدود إيجار أكثر وضوحًا، وقدرات خدمة ذاتية محسنة، وواجهات محددة بشكل أفضل لتوفير البنية التحتية وإدارتها.
واليوم، يستثمرون في تجريدات عالية المستوى، مثل بنيات البيئة والمشاريع، وسير العمل المعتمد على واجهة برمجة التطبيقات (API) والذي يتوافق بشكل أوثق مع نماذج مزود الخدمة السحابية. وخلص تونيس إلى أن هذه رحلة مستمرة، ولكن الاتجاه واضح: التحرك نحو منصة أكثر قابلية للتطوير وتركز على المستخدم ومنفصلة تعمل على تمكين الفرق مع الحفاظ على الاتساق والحوكمة عبر المؤسسة.
أجرت InfoQ مقابلة مع يوجينيا بيرجمان وهاجن تونيس حول التغيير إلى نهج المنتج لمنصتهم.
InfoQ: ما الذي ألهمك للتغيير من نهج المشروع إلى نهج المنتج؟
يوجينيا بيرجمان: لم يكن التحول مدفوعا بقرار واحد، بل بمجموعة من الإشارات التي لم يعد بوسعنا تجاهلها. لاحظنا أن:
- استمرت الأعمال المتراكمة في النمو على الرغم من التسليم المستمر
- كانت الفرق تعمل حول المنصة بدلاً من استخدامها
- لم نتمكن من الإجابة بوضوح عما إذا كان ما بنيناه قيد الاستخدام بالفعل
- لم نتمكن دائمًا من الإجابة عما إذا كنا ندعم إمكانات معينة أو ما إذا كانت جزءًا من عرض منصتنا
وفي الوقت نفسه، أدركنا أننا لم نعد نقدم البنية التحتية فحسب، بل أصبحنا نقدم الإمكانات للعملاء الداخليين. وهذا يتطلب نهجا مختلفا:
- من تقديم الميزات → إلى حل مشاكل المستخدم
- من النطاق الثابت → إلى خرائط الطريق المبنية على الفرضيات
- من مقاييس الإخراج → إلى إشارات الاعتماد وسهولة الاستخدام
وبهذا المعنى، فإن الانتقال إلى نهج المنتج لم يكن مبادرة تحول بقدر ما كان تكيفًا ضروريًا مع الحجم.
هاجن تونيس: جاء التحول أيضًا من الشكوك الطويلة الأمد تجاه سكروم. ورغم تقديري لبنيتها، إلا أنها فشلت في كثير من الأحيان في تحقيق نتائج حقيقية أو خلق البيئة المناسبة للفرق. بدا التفكير في المنتج وكأنه طريق نحو توافق أفضل بين العمل الهندسي وقيمة المستخدم وتجربة الفريق.
InfoQ: كيف تبدو منصة المطورين الخاصة بك؟
بيرجمان: على مستوى عالٍ، يتصرف النظام الأساسي للمطورين لدينا كمزود سحابي داخلي.
ويكشف عن إمكانات البنية التحتية مثل مجموعات Kubernetes والتخزين والشبكات وخدمات النظام الأساسي الداعمة. يتم توفير هذه الإمكانات من خلال واجهات الخدمة الذاتية، وذلك باستخدام أنماط Kubernetes الأصلية في المقام الأول مثل واجهات برمجة التطبيقات والموارد المخصصة.
من وجهة نظر المطور، الهدف هو:
- توفير البنية التحتية كرمز
- دمج قدرات النظام الأساسي مباشرة في سير العمل
- وتجنب التنسيق اليدوي أو العمليات القائمة على التذاكر
داخليًا، يتم تنظيم النظام الأساسي حول فصل الاهتمامات بين مستويات الخدمة والتحكم والإدارة، مع كتل بناء قابلة للتركيب تلخص البنية التحتية الأساسية، والعقود التي تحدد واجهات مستقرة بين الطبقات.
