أدوات تقييم الهجرة إلى السحابة

أدوات تقييم ترحيل البيانات إلى السحابة: لماذا لا يمثل اكتشاف البنية التحتية سوى نصف المهمة

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

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

قم بتقييم الكود الخاص بك قبل نقله

SMART TS XL يرسم هذا المخطط كل تبعية، وعنصر معيق، ومرشح لإعادة الهيكلة عبر محفظة تطبيقاتك الكاملة.

المزيد من المعلومات

ما هو تقييم الانتقال إلى الحوسبة السحابية؟

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

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

بُعد التقييمما يجيب عليهالأدوات الأساسية
البنية التحتيةما هي الخوادم والأجهزة الافتراضية والخدمات الموجودة؟ وما هي أنماط استخدامها؟Azure Migrate، AWS Application Discovery، Google Migration Center
رمز التطبيقهل الكود متوافق مع بيئات الحوسبة السحابية؟ ما الذي يجب تغييره؟أبرز أحداث فريق التمثيل، SMART TS XLتحديث تطبيقات CloudPilot وGitHub Copilot
البياناتما هي أحجام البيانات الموجودة؟ أين توجد البيانات؟ ما مدى تعقيد عملية الترحيل وقيود الامتثال؟خدمة ترحيل قواعد البيانات AWS، خدمة ترحيل قواعد البيانات Azure، ستريم
الأمن والامتثالما هي المتطلبات التنظيمية المطبقة؟ ما هي الثغرات الأمنية الموجودة؟ ما هي التغييرات المطلوبة في إدارة الهوية والوصول والتشفير؟مركز أمان AWS، وMicrosoft Defender for Cloud، وPrisma Cloud
التكلفة والتكلفة الإجمالية للملكيةما هي التكلفة الكاملة للهجرة والتكلفة الإجمالية للملكية بعد الهجرة؟حاسبة أسعار AWS، حاسبة التكلفة الإجمالية للملكية في Azure، تكلفة البنية التحتية، قابلية Apptio السحابية

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

الأبعاد الخمسة لتقييم الهجرة إلى الحوسبة السحابية

تقييم البنية التحتية

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

تعمل أدوات مثل Azure Migrate أو غيرها من المنتجات على أتمتة اكتشاف مكونات وتكوينات أحمال العمل. تقلل هذه الأدوات من الجهد اليدوي وتوفر جمع بيانات متسق عبر بيئتك، على الرغم من أنها قد تغفل عن بعض التبعيات غير الموثقة.

Azure Migrate هو المعيار للمؤسسات التي تنتقل إلى Azure. يقوم باكتشاف بيئات VMware vSphere وHyper-V والخوادم الفعلية بدون الحاجة إلى وكيل، ويقدم تقييمات الجاهزية وتوصيات الحجم المناسب القائمة على الأداء وتقديرات التكلفة قبل نقل أي عبء عمل.

تؤدي خدمة ترحيل تطبيقات AWS (MGN) وخدمة اكتشاف تطبيقات AWS وظيفة مماثلة لأهداف AWS. تجمع خدمة الاكتشاف بيانات التكوين والأداء المحلية من خلال جمع البيانات بدون وكيل أو باستخدام وكيل مثبت محليًا.

يوفر مركز ترحيل جوجل اكتشافًا وتقييمًا موحدًا لعمليات ترحيل جوجل كلاود، حيث يجمع بين جرد الأصول وتحليل التبعية ونمذجة التكلفة الإجمالية للملكية في وحدة تحكم واحدة.

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

تقييم رمز التطبيق

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

يكشف تقييم كود التطبيق عن أربع فئات من المشاكل التي لا يستطيع فحص البنية التحتية اكتشافها:

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

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

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

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

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

تتخصص CloudPilot في التقييم التفصيلي لجاهزية السحابة مع تسجيل التوافق وإنشاء خارطة طريق للهجرة عبر JavaScript و Python و Node.js و Go.

يجمع GitHub Copilot App Modernization بين إمكانيات تقييم AppCAT الخاصة بـ CAST ومعالجة التعليمات البرمجية بمساعدة الذكاء الاصطناعي لأحمال العمل .NET و Java على وجه التحديد.

بالنسبة لبيئات المؤسسات التي تشمل لغات برمجة مثل COBOL وJCL وPL/I وRPG وغيرها من لغات الحواسيب المركزية إلى جانب التقنيات الحديثة، فإن هذه الأدوات غير كافية. يتطلب تقييم كود التطبيقات للأنظمة القديمة فئة مختلفة تمامًا من الأدوات.

تقييم البيانات

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

الأسئلة الرئيسية التي يجب أن يجيب عنها تقييم البيانات:

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

توافق المخطط : هل تدعم خدمة قاعدة البيانات المستهدفة نفس ميزات المخطط وأنواع البيانات والإجراءات المخزنة التي تدعمها قاعدة البيانات المصدر؟ تتطلب بنيات PL/SQL الخاصة بأوراكل تحويلًا قبل الترحيل إلى PostgreSQL أو بديل سحابي أصلي.

سيادة البيانات والامتثال : أين يجب أن تُخزَّن البيانات قانونيًا؟ قد تقيّد لوائح حماية البيانات العامة (GDPR) وقانون قابلية نقل التأمين الصحي والمساءلة (HIPAA) ومعيار أمان بيانات صناعة بطاقات الدفع (PCI-DSS) واللوائح الخاصة بالقطاعات، المناطق السحابية التي يمكنها استضافة فئات بيانات محددة.

ترابط التطبيق : ما مدى ترابط كود التطبيق مع مخطط قاعدة البيانات المحدد؟ قد يتطلب تغيير المخطط، الذي يبدو بسيطًا من الناحية التقنية، تغييرات واسعة النطاق في كود التطبيق لاستيعابه.

تدعم خدمة ترحيل قواعد البيانات AWS وخدمة ترحيل قواعد البيانات Azure النسخ المتماثل المستمر مع الحد الأدنى من وقت التوقف لعمليات الترحيل المتجانسة (من Oracle إلى Oracle، ومن SQL Server إلى SQL Server) وتحويل المخطط لعمليات الترحيل غير المتجانسة (من Oracle إلى PostgreSQL، ومن SQL Server إلى Aurora).

يوفر كل من Striim و Attunity تدفق البيانات في الوقت الفعلي وتكرارها لسيناريوهات الترحيل عالية التوافر حيث يكون توقف قاعدة البيانات غير مقبول.

تقييم الأمن والامتثال

يقوم تقييم الأمان برسم خريطة الوضع الأمني ​​الحالي لكل عبء عمل ويحدد التغييرات المطلوبة لتلبية معايير أمان السحابة وأطر الامتثال ومبادئ بنية الثقة الصفرية.

يجب أن يشمل تقييم الأبعاد الأمنية ما يلي:

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

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

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

مواءمة إطار الامتثال : لكل قطاع خاضع للتنظيم متطلبات امتثال محددة تتوافق مع إعدادات سحابية معينة. تتطلب أحمال عمل قانون HIPAA خيارات تكوين محددة فيما يتعلق بالتخزين وتسجيل الوصول والتشفير. يتطلب معيار PCI-DSS تجزئة الشبكة التي يجب تنفيذها بشكل مختلف في شبكة VPC السحابية عنها في البنية التحتية للشبكة المادية.

يوفر Microsoft Defender for Cloud تقييمًا لوضع الأمان وتقييمًا للامتثال لمعايير CIS و NIST و PCI-DSS وغيرها من الأطر لأحمال عمل Azure.

يوفر كل من Prisma Cloud (Palo Alto Networks) و AWS Security Hub تقييمًا أمنيًا مكافئًا متعدد السحابات ومراقبة للامتثال.

تقييم التكلفة والتكلفة الإجمالية للملكية

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

يشمل التقييم الكامل للتكلفة الإجمالية للملكية ما يلي:

تكاليف البنية التحتية السحابية : تشمل تكاليف الحوسبة والتخزين والشبكات والخدمات المُدارة في بيئة السحابة المستهدفة. ويُعدّ تحديد الحجم الأمثل بناءً على بيانات الاستخدام الفعلية (وليس السعة المُخصصة) هو الفرق بين التقديرات الدقيقة والتقديرات المبالغ فيها.

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

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

تغييرات في نموذج التشغيل : يتم استبدال فرق العمليات المحلية التي تدير الأجهزة المادية بفرق عمليات سحابية تدير الخدمات السحابية. وتتغير المهارات والأدوات وعدد الموظفين.

تكاليف التدريب والانتقال : تتحمل الفرق التي تتعلم منصات الحوسبة السحابية الجديدة ونماذج النشر الجديدة والإجراءات التشغيلية الجديدة تكاليف الإنتاجية أثناء عملية الانتقال.

تُغطي حاسبات أسعار AWS وحاسبات التكلفة الإجمالية للملكية لـ Azure وحاسبات أسعار Google Cloud تكلفة البنية التحتية السحابية. يوفر Infracost تقديرًا للتكلفة مُدمجًا في مسارات IaC، مما يُنتج تقديرات التكلفة كجزء من عملية التكامل المستمر/التسليم المستمر (CI/CD). توفر Apptio Cloudability وأدوات FinOps المماثلة رؤية مستمرة للتكلفة بعد الترحيل.

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

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

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

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

تقييم ترحيل الأنظمة القديمة والأنظمة المركزية إلى الحوسبة السحابية

صُممت أدوات تقييم ترحيل الحوسبة السحابية القياسية للبنية التحتية الحديثة: الأجهزة الافتراضية، والحاويات، والخدمات المصغرة، والتطبيقات السحابية الأصلية. لكنها لا تعمل بكفاءة، أو تعمل بشكل ضعيف للغاية، مع أحمال العمل على الحواسيب المركزية، وبرامج COBOL التي تعمل على نظام IBM z/OS، وتدفقات مهام JCL التي تدير المعالجة الدفعية، وتطبيقات PL/I التي تتعامل مع المعاملات المالية، وبرامج RPG المدمجة في أنظمة AS/400.

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

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

مقارنة أدوات تقييم ترحيل البيانات إلى الحوسبة السحابية

يوضح الجدول أدناه أدوات تقييم ترحيل السحابة الرئيسية وأبعاد التقييم التي تتناولها وأفضل سيناريو يناسبها.

أداةطبقة التقييمالهدف السحابيأفضل ل
ترحيل Azureالبنية التحتيةAzureاكتشاف الأجهزة الافتراضية والخوادم، وتحديد الحجم الأمثل، وتقدير تكلفة Azure
خدمة اكتشاف تطبيقات AWSالبنية التحتيةAWSاكتشاف الخوادم المحلية لعمليات نقل البيانات إلى AWS
مركز هجرة جوجلالبنية التحتيةGCPجرد الأصول والتكلفة الإجمالية للملكية لعمليات نقل البيانات إلى منصة جوجل السحابية
أبرز أحداث الفيلمرمز التطبيقمتعدد السحابةتقييم جاهزية الكود على مستوى المحفظة عبر اللغات
كلاود بايلوترمز التطبيقمتعدد السحابةتحليل توافق مفصل للغات Python وJS وNode.js وGo
SMART TS XLكود التطبيق + تعيين التبعياتمتعدد السحابةتحليل المحافظ باستخدام لغات البرمجة COBOL وJCL والحواسيب المركزية واللغات المتعددة
أوس دي إم إسالبياناتAWSترحيل قاعدة البيانات مع تحويل المخطط
خدمة ترحيل قاعدة بيانات AzureالبياناتAzureترحيل SQL Server وMySQL وPostgreSQL إلى Azure
ستريمالبياناتمتعدد السحابةالنسخ المتماثل في الوقت الفعلي لترحيل البيانات بدون توقف
مايكروسوفت المدافع للسحابةالأمن والحمايةAzure / السحابة المتعددةتقييم الوضع الأمني ​​والامتثال
بريزما كلاودالأمن والحمايةمتعدد السحابةإدارة حماية البيانات والامتثال عبر AWS وAzure وGCP
إنفراكوستالتكلفةمتعدد السحابةتقدير التكلفة المتكامل مع البنية التحتية كبرنامج في خطوط أنابيب التكامل المستمر/التسليم المستمر
Apptio Cloudabilityالتكلفةمتعدد السحابةإدارة التكاليف المالية والتشغيلية وإدارة تكاليف الحوسبة السحابية المستمرة
كورنت سورباسالبنية التحتية + التطبيقمتعدد السحابةالاكتشاف والتقييم وتنسيق عمليات الترحيل باستخدام الذكاء الاصطناعي

كيفية SMART TS XL يقوم بتقييم كود التطبيق للهجرة إلى السحابة

SMART TS XL يتناول هذا الأمر طبقة تقييم كود التطبيق التي لا تستطيع أدوات البنية التحتية الوصول إليها، وتحديداً بالنسبة لبيئات المؤسسات والبيئات القديمة حيث تمتد محفظة التطبيقات عبر لغات ومنصات وأجيال تقنية متعددة.

بالنسبة لبرنامج ترحيل يتضمن برامج COBOL، وتدفقات وظائف JCL، وخدمات Java، وخطوط أنابيب Python، ومخططات SQL، SMART TS XL يبني نموذج تبعية موحدًا عبر جميعها في وقت واحد. قبل أن يقرر فريق الترحيل ما الذي يجب إعادة استضافته، وما الذي يجب إعادة هيكلته، وما الذي يجب إيقافه، SMART TS XL على ما يلي:

جرد كامل للبرنامج : كل برنامج مصدر، ودفتر نسخ، وإجراء، ومخطط عبر كل لغة في البيئة، الجرد الفعلي، وليس الجرد الموثق، والذي يختلف عادةً بنسبة 20-30٪ في البيئات القديمة.

رسم خرائط التبعيات بين اللغات : تتيح هذه الخاصية تتبع كيفية اتصال برنامج COBOL بمخطط DB2 الذي يستعلم عنه خدمة Java، والذي بدوره يغذي مسار Python الذي ينتج مخرجات تستهلكها واجهة React حديثة. تحدد سلسلة التبعيات هذه تسلسل الترحيل، حيث يجب ترحيل المكونات ذات التبعيات الكثيرة بعد أن تصبح تبعياتها جاهزة.

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

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

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

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

ما الذي يجب أن ينتج عن تقييم شامل للهجرة إلى السحابة؟

لا تكون قيمة التقييم إلا بقدر ما يُتيحه من قرارات. ينبغي أن يُنتج تقييم شامل لعملية نقل البيانات إلى الحوسبة السحابية خمسة مخرجات تُحدد مجتمعةً برنامج النقل:

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

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

تقدير التكلفة الإجمالية للهجرة : الجهد الهندسي، وتكاليف أدوات الهجرة، وتكاليف التشغيل المتوازي المؤقت، وتكاليف التدريب، وليس فقط الفروقات في تكلفة البنية التحتية.

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

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

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