الخلاصة

  • تجمع Google Cloud Modernize تقييم التكلفة وتحليل الشيفرة والاعتماديات وأدوات الترحيل ووجهات Google Cloud في حزمة واحدة. ويمكن لـ Agentic Quick Estimator أن يتنبأ بالتكلفة الإجمالية لـ Compute Engine اعتماداً على صادرات جرد VMware وبيانات البنية التحتية.
  • يعتمد التقدير على الأصول المسجلة وأحجام الموارد والمنطقة والتراخيص وافتراضات أخرى. ولا يثبت اكتمال الترحيل أو قبول الإنتاج أو معرفة تكلفة الانتقال كاملة أو تحقق وفورات لدى العميل.
  • الاختبار التجاري سلسلة قابلة للمطابقة: جرد مصدر موثق، ووجهة وافتراضات تكلفة يقرها العميل، وانتقال ناجح، وقبول عبء العمل، ثم مقارنة الفاتورة الفعلية بخط أساس مماثل.

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

تضم الحزمة وعوداً مختلفة لا ينبغي دمجها في ادعاء واحد بالأتمتة. تقول Google إن Agentic Quick Estimator في Migration Center متاح عموماً؛ إذ يستخدم ملفات جرد VMware مثل RVTools ومدخلات البنية التحتية لتوقع التكلفة الإجمالية لبيئة Compute Engine. أما Modernization Hub الجديد فيحلل الشيفرة ويرسم الاعتماديات لتطبيقات Java و.NET والأنظمة المركزية. في المقابل، ما زال وكيل الترحيل EKS-to-GKE في معاينة عامة، وتصفه Google بأنه ينفذ الاكتشاف وترجمة بيانات Kubernetes ومواءمة التخزين والشبكات مع إبقاء بوابات للموافقة البشرية. لكل أداة مرحلة مختلفة: التقدير والفهم والتحويل والتحقق؛ ولا تمثل أي منها وحدها انتقالاً إلى الإنتاج. (إعلان Google Cloud في 6 أكتوبر)

التقدير يرث افتراضات مدخلاته

تعتمد قيمة TCO لاتخاذ القرار على دقة صورة البيئة المصدر وخيارات الوجهة. تتيح وثائق Google إدخال إجماليات الآلات الافتراضية والمعالجات والذاكرة والتخزين يدوياً أو تحميل ملف RVTools. ثم يختار المستخدم المنطقة المستهدفة وعائلة الآلات ونوع التخزين. يقارن التقرير البيئة المقدمة بتكوين Google Cloud نموذجي. وإذا غابت بيانات الأداء، يستطيع Migration Center اقتراح أحجام استناداً إلى استراتيجية يحددها المستخدم، مع تمييز الأصول المقدرة عن المقاسة. هذا مفيد للتخطيط، لكنه نموذج وليس استهلاكاً مقاساً ومفوترًا. (وثائق Quick TCO Estimator؛ وثائق تقارير TCO)

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

تصف وثائق Migration Center نفسها فحصاً للملاءمة التقنية لا شهادة قبول تجاري. وتعني «ملاءمة جيدة» أن الشروط لم تجد عوائق تقنية ضمن بيانات المصدر المجمعة؛ أما «ملاءمة مع جهد» فتعني أن عملاً إضافياً قد يلزم. كما توصي Google بجرد العناقيد وأعباء العمل، وفحص الاعتماديات وعمليات التشغيل، واختيار استراتيجية وأدوات، وتحديد جدول زمني والتحقق من الخطة. ليست هذه إجراءات شكلية، بل العمل الذي يحول التوصية إلى تغيير آمن قابل للتسعير. (تقييم الملاءمة في Migration Center؛ إرشادات الترحيل من EKS إلى GKE؛ إرشادات تخطيط الترحيل)

تسريع مرحلة لا يعني إكمال المسار

يوضح وكيل EKS-to-GKE الحد الفاصل. تقول Google إنه يستطيع ترجمة ملفات Kubernetes ومواءمة التخزين والشبكة، مع إبقاء الموافقة البشرية وحماية بيانات الاعتماد في الذاكرة. قد يقلل ذلك الأعمال المتكررة ويجعل مسار النقل أوضح. لكن حالة المعاينة العامة تعني أيضاً أنه قدرة قيد التطوير، لا بديل شامل عن اختبار كل عبء على حدة. تظل سياسة الشبكة ودلالات التخزين والرصد والهوية وأهداف الاعتمادية ونقل البيانات وإجراءات الإطلاق عوامل تحدد الجاهزية. ولا تنشر Google عدد عمليات الإنتاج التي أنجزها الوكيل أو معدل الخطأ والتراجع أو وفورات الوقت والتكلفة لكل عميل.

توفر أمثلة العملاء في الإعلان سياقاً، لا دليلاً على إطلاق المنتج. تقول Google إن NetEase Games خفضت سابقاً تكلفة الخوادم 40% وقلصت وقت التوسع عند الذروة من ساعات إلى خمس دقائق باستخدام خدمات على GKE. ولا تنسب المدونة هذه النتيجة إلى Google Cloud Modernize أو وكيل EKS الجديد. إنها نتيجة ذكرها العميل لتنفيذ GKE، وليست قياساً لأدوات أكتوبر.

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

يحتاج المشتري إلى سجل يستمر بعد الانتقال

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

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

قد تقلل Google Cloud Modernize كلفة اتخاذ القرار والاستعداد. لكن الإعلان لا يوضح كم مرة تتحول تلك السرعة إلى انتقال إنتاجي ناجح أو نتيجة اقتصادية أفضل. وحتى يصل العملاء بين خط أساس موثق وأعباء مقبولة وتكاليف محققة، تبقى الأدوات طريقاً أسرع إلى فرضية، لا برهاناً على أن الانتقال مجدٍ.

المصادر