تحديث التطبيقات: نهج التقييم السريع

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

يُعَد تطوير وجهة نظر حول تصنيف محفظة التطبيقات بأكملها أمرًا ضروريًا من أجل القيام بما يلي:

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

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

فيما يلي توزيع نموذجي عالي المستوى لتصنيفات التطبيقات الموزعة مع تعريف كل منها:

• إعادة الهيكلة/التحديث إلى السحابة الأصلية: 5 إلى 15% وتشمل التطبيقات عالية القيمة والحيوية للمهام أو للأعمال. تتم إعادة هيكلة هذه التطبيقات أو إعادة كتابتها لتصبح تطبيقات سحابية أصلية / قائمة على منهجية 12 عاملًا. يوفر هذا التوزيع أعلى قيمة للأعمال، حيث يصبح التطبيق أكثر مرونة وقابلية للتوسع ومتاحًا بشكل كبير، ولكن بتكلفة مرتفعة. وبالتالي، يجب اختيار هذه التطبيقات بحكمة، حيث إنها تمثِّل استثمارات استراتيجية عادةً ما تكون بملايين الدولارات لكل تطبيق. 
• التحويل إلى حاويات: 50 إلى 60% وتشمل أغلب تطبيقات Java وبعض تطبيقات Windows. يتم تحويل هذه التطبيقات إلى حاويات لتعمل داخل حاوية Kubernetes، ويفضَّل تشغيلها على Red Hat OpenShift. توفِّر التطبيقات المحوِّلة إلى حاويات أفضل عائد على الاستثمار مقارنةً بين تكلفة تحويلها إلى حاويات والفائدة الإجمالية المتحققة منها.
• الترحيل: 30 إلى 40% وتشمل تطبيقات COTS وبعض تطبيقات Windows وبعض التطبيقات "الغريبة" التي تعمل دون نظام تشغيل أو على أجهزة افتراضية. تتَّبِع هذه التطبيقات نمط "الرفع والنقل" مع تعديل قليل أو دون أي تعديل في الأكواد لنقلها إلى السحابة. أنماط الترحيل الأكثر شيوعًا هي أنماط الترحيل الفعلية إلى الافتراضية ومن الافتراضية إلى الافتراضية.
• الاحتفاظ بالحالة الحالية: أقل من 10% وتشمل تطبيقات سطح المكتب، وتطبيقات الأجهزة المحمولة (باستثناء الواجهة الخلفية)، والتطبيقات الموجودة بالفعل في السحابة (خاصةً SaaS، رغم أن بعض التطبيقات السحابية يمكن نقلها إلى سحابة أكثر ملاءمة).

لاحِظ أن هذه التصنيفات تختلف عن أطر تصنيف التطبيقات الأخرى، مثل نموذج Gartner 7 Rs، لكنها توفِّر طريقة أبسط وأكثر وضوحًا لتصنيف المحفظة، مع تحديد التطبيقات التي ستساهم في تحقيق أكبر قيمة تحويلية - وهي التطبيقات التي ستتم إعادة هيكلتها ووضعها في حاويات:

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

التطبيقات التجارية الجاهزة (COTS)

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

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

تطبيقات SaaS أو التطبيقات التي تم نقلها بالفعل إلى السحابة

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

التطبيقات الحرجة للمهام/التطبيقات الحرجة للأعمال

يجب النظر في إعادة هيكلة أو تحديث التطبيقات الحرجة للمهام أو الأعمال لتصبح تطبيقات سحابية أصلية / وفق منهجية العوامل الـ 12، إذ إنها ستجني أكبر فائدة من تكلفة إعادة الهيكلة العالية.

من هذه المجموعة من التطبيقات، حدِّد التطبيقات التي:

• لديها مستوى عالٍ من نشاط التغيير أو تراكم كبير من المهام، وستستفيد من أن تصبح أكثر مرونة.
• لا تلبي حاليًا احتياجات الأعمال، وستستفيد من إعادة تصورها لتعكس عملية أعمال حديثة أو تجربة مستخدم محسَّنة.

تمثِّل هذه الفئة عادةً ما لا يزيد عن 5 إلى 15% من المحفظة بأكملها. بالنسبة إلى محفظة مكونة من 500 تطبيق، فإن هذا يعني إعادة كتابة ما بين 25 إلى 75 تطبيقًا في غضون ثلاث إلى خمس سنوات - وهو رقم كبير يمثِّل جهدًا هائلًا في التطوير وتكلفة هائلة!

تطبيقات Java

تُعد تطبيقات Java من أبرز المرشحين للتحويل إلى حاويات. أي تطبيق يعمل على خادم تطبيقات JavaEE (مثل WAS أو WebLogic أو JBoss أو Tomcat، وغيرها) يجب أن يكون قابلًا للتحويل إلى حاويات بمجهود نسبيًا قليل. الافتراض الرئيسي هو أن الحد الأدنى فقط سيتم القيام به لتحويل التطبيق إلى حاويات - بينما ترقية أو نقل البرمجيات الوسيطة (مثل نقل قاعدة بيانات علائقية إلى قاعدة بيانات سحابية أصلية، أو الانتقال من MQ إلى Kafka) خارج نطاق هذا التحويل. ومع ذلك، تجب ترقية مسار CI/CD لإنتاج الحاويات والاستفادة من الميزات الأساسية لمنصة OpenShift.

تطبيقات Windows

تحتوي تطبيقات Windows على خيارين للتحويل إلى حاويات:

• التشغيل داخل حاويات Linux، والتي عادةً ما تكون أعباء عمل .Net CORE‎.
• التشغيل في حاويات Windows، والتي أصبحت متاحة في OpenShift V4.6.

بشكل عام، معايير اتخاذ القرار لتطبيقات Windows هي كما يلي:

• نقل .Net CORE‎ إلى حاويات Linux
• نقل تطبيقات Windows المخصصة المكتوبة بواسطة NET. أو VB أو C أو #C إلى حاويات Windows.

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

جميع التطبيقات الأخرى - الترحيل

سيتم عادةً ترحيل جميع التطبيقات الأخرى إلى السحابة، مع كون النمط الأكثر شيوعًا هو من الأجهزة الفعلية إلى الأجهزة الافتراضية أو من الأجهزة الافتراضية إلى الأجهزة الافتراضية لمعظم أعباء العمل الموزعة. تتطلب التقنيات “الغريبة” أو غير الشائعة اهتمامًا أكبر، إذ قد لا تتوفر منطقة هبوط جاهزة في السحابة. عادة ما يمكن لأحمال التشغيل iSeries وpSeries الانتقال إلى Power Systems Virtual Server في IBM Cloud. قد تتطلب أعباء العمل الأخرى أجهزة خاصة ليتم تشغيلها في منطقة CoLo بمراكز بيانات IBM Cloud، إذا كان ذلك ممكنًا (مثل Unisys وTandem Nonstop وغيرها).

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

• تحسين التطبيقات على بصمتها التكنولوجية الحالية لتقليل تكاليف الحوسبة والتشغيل (ترقيات المحوِّل البرمجي، وكفاءة الترميز، وما إلى ذلك).
• تحديث/تحويل التطبيقات الموجودة في مكانها، ومواصلة التشغيل على منصة IBM Z (z/OS أو Linux on Z).
• تحديث/تحويل التطبيقات لتشغيلها في البيئة السحابية الموزعة.
• الاستفادة والوصول إلى أصول تطبيقات الكمبيوتر المركزي من التطبيقات الموزعة الأخرى بشكل أفضل.
• إخلاء مركز البيانات المحلي بالكامل، بما في ذلك أعباء عمل الكمبيوتر المركزي.

ستساعد الإجابات عن هذه الأسئلة بعد ذلك على تحديد القرارات المستهدفة، مثل ما يلي:

• تحديث التطبيق ليعمل Linux on Z.
• تحديث التطبيق ليعمل على Linux بمعمارية x86 في السحابة.
• إعادة هيكلة التطبيق بتقنيته الحالية (المنصة ولغة البرمجة) لتعزيز الكفاءة التشغيلية.
• تحويل الخدمات الأساسية لتصبح متاحة كواجهات برمجة تطبيقات (APIs).

بالنسبة إلى أعباء العمل التي ستبقى على الكمبيوتر المركزي، تجب الإجابة عن أسئلة تتعلق بمكان استضافة الكمبيوتر المركزي:

• الاحتفاظ به في مركز البيانات المحلي.
• الانتقال إلى مرفق IBM Cloud Co-Lo.
• الانتقال إلى IBM Z كخدمة مُدارة تقدِّمها إحدى شركات التكامل النظامية العالمية.

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

يوضِّح الشكل التالي مثالًا لمخرجات تقييم سريع لتحديث التطبيقات في سياق إعداد مقترح لتحديث السحابة. لقد كانت القدرة على تطوير وجهة نظر واضحة وسريعة حول مجموعة تطبيقات العميل عامل تمييز رئيسيًا في منهجيتنا:

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