التخطيط لمنصات التطبيقات الحديثة
تساعد منهجية الخطة في Cloud Adoption Framework على إنشاء خطة اعتماد سحابية شاملة لتوجيه البرامج والفرق المشاركة في التحول الرقمي المستند إلى السحابة. يوفر هذا التوجيه قوالب لإنشاء تراكمك وخطط لبناء المهارات الضرورية عبر فرقك، كل ذلك استنادا إلى ما تحاول القيام به في السحابة.
يركز تطبيق منهجية الخطة على خمسة Rs لترشيد ممتلكاتك الرقمية. يركز المسار الأكثر شيوعا إلى السحابة على سرعة وكفاءة وقابلية تكرار عمليات الترحيل والتحديث. من Rs الخمسة، عادة ما يعطي التخطيط الأولوية لخيارات إعادة الاستضافة مع دعم مواز محدود لخيارات إعادة التصميم وإعادة البناء.
العقارات الرقمية
عند التخطيط لممتلكاتك الرقمية، ستحتاج إلى جمع بيانات المخزونوترشيد ممتلكاتك. في خطة اعتماد الحاوية، من الضروري تجميع جميع الأصول، على سبيل المثال الأجهزة الظاهرية والبيانات والتطبيقات، حسب حمل العمل الذي تدعمه. بمجرد اكتمال التجميع والترشيد الأساسي، يمكنك تقييم أحمال العمل هذه لتحديد خيارات الحزمة وإعادة استضافة أو إعادة التصميم.
يمثل قالب خطة اعتماد السحابة القياسي أنواع العمل المطلوبة في جهد نموذجي لاستخدام السحابة. ولكن ستحتاج إلى إضافة مهام إلى خطتك لتغليف حمل العمل في حاويات وتنسيق توفير الحاوية.
تنبيه
تفترض هذه المقالة أن القارئ يتبع بالفعل أفضل الممارسات الموضحة في سلسلة المقالات حول إنشاء خطة اعتماد السحابة في Azure DevOps. إذا كنت تتعقب خطة استخدام السحابة في جدول البيانات أو أدوات تعقب المشاريع الأخرى، فلا تزال الأقسام التالية قابلة للتطبيق ولكن يجب تعديل الخطوات القابلة للتنفيذ لإضافة البيانات إلى خطتك.
تحذير
سيتطلب دمج استراتيجية النظام الأساسي للتطبيقات الحديثة في عمليات الترحيل القياسية (أو مصنع الترحيل) تنفيذا ناضجا للمهام المرتبطة بتصميم بنيات حمل العمل قبل الترحيل. سيؤدي الاستمرار في هذه الاستراتيجية دون هذه المهام إلى تأخير جهود الترحيل وقد يؤدي إلى قرارات هيكلية رديئة لمضيفي الحاويات المنشورين وأحمال العمل الداعمة.
تحديد أحمال العمل المرشحة
في سيناريو النظام الأساسي للتطبيق الحديث، يتم إعطاء الأولوية للعائدات طويلة الأجل، والتي تتطلب استثمارا مقدما أكبر، على عمليات الترحيل الأكثر كفاءة. ويتم تمثيل الاستثمارات الطويلة الأجل في أجزاء محددة من الخطة باعتبارها زيادة التركيز على تمكين الابتكار وتبسيط العمليات لمجموعات محددة من أحمال العمل.
لبدء محاذاة الاستراتيجية والخطة، حدد أي أحمال عمل من المحتمل أن تتأثر بإضافة الأنظمة الأساسية للتطبيقات الحديثة في استراتيجية اعتماد السحابة الخاصة بك. وسيتم التحقق من صحة هذه الافتراضات قبل تنفيذ أي تغييرات تقنية. للمساعدة في تحديد المرشحين المحتملين، ابحث عن المعايير التالية ضمن قائمة أحمال العمل الخاصة بك:
- التطوير النشط أو استثمارات DevOps: ستكون نسبة مئوية من أحمال عمل الإنتاج قيد التطوير النشط. قد تتم إدارة بعضها حتى من خلال ممارسات DevOps المستمرة.
- إمكانية نقل حمل العمل: تتأثر بعض أحمال العمل بالتوافق أو حماية البيانات أو القيود التشغيلية التي قد تتطلب إمكانية النقل عبر السحابة الخاصة أو الحافة أو حتى العديد من موفري السحابة العامة.
- دمج حمل العمل: قد تكون العديد من أحمال العمل (خاصة أحمال العمل منخفضة الاستخدام) مرشحة للدمج على مضيفي الحاوية مما يؤدي إلى عدد قليل من الخوادم/الأجهزة الظاهرية وتقليل تكاليف التشغيل.
- أحمال العمل القديمة: يمكن لأحمال العمل القديمة حظر التحديثات لأنظمة التشغيل وحتى منع الترحيل إلى السحابة. قد تكون أحمال العمل القديمة غير المتوافقة مع ميزات Azure مرشحة للترحيل على مضيف حاوية.
توثيق أحمال عمل المرشح
ملاحظة
يجب توثيق قائمة الاعتبارات التالية فقط لمرشحي الترحيل الذين تحددهم المعايير المذكورة أعلاه.
عند إنشاء خطة اعتماد السحابة، يتم توثيق كل حمل عمل باتباع الإرشادات الواردة في تعريف أحمال العمل وتحديد أولوياتها. سيتطلب أي حمل عمل مرشح لسيناريو النظام الأساسي للتطبيق الحديث معلومات إضافية لتوجيه تنفيذ الخطة. تسلط هذه المقالة الضوء على أهمية توثيق المدخلات التجارية والتقنية لتحديد حمل العمل. بالنسبة لمرشحي النظام الأساسي للتطبيقات الحديثة، يجب إضافة نقاط البيانات التالية إلى تعريف حمل العمل.
مدخلات الأعمال
فيما يلي نقاط البيانات المتعلقة بالأعمال التي قد تؤثر على قرار تضمين حمل عمل في استراتيجية النظام الأساسي للتطبيق الحديث.
- برامج تشغيل التوافق: ما معايير التوافق المحددة التي تدفع الاعتبارات لاستضافة حمل العمل هذا في سحابة خاصة؟
- برامج تشغيل حماية البيانات: ما هي تدابير حماية البيانات التي تدفع الاعتبارات لاستضافة حمل العمل هذا في سحابة خاصة؟
- القيود التشغيلية: ما هي القيود التشغيلية التي تدفع الاعتبارات لاستضافة حمل العمل هذا في سحابة خاصة؟
- نتائج النظام الأساسي للتطبيق الحديث: أي مما يلي هو المحرك وراء تقييم حمل العمل هذا كمرشح حاوية؟ DevOps أو قابلية النقل أو الدمج أو القديمة أو العديد من برامج التشغيل هذه.
- نموذج التشغيل: هل ستتم إدارة حمل العمل هذا مركزيا (بواسطة تكنولوجيا المعلومات المركزية/CCoE)، أو إلغاء المركزية (بواسطة فريق حمل العمل)، أو مع عمليات المؤسسة (الدعم المركزي والعمليات الخاصة بحمل العمل)؟
المدخلات التقنية
فيما يلي نقاط بيانات من فرق التكنولوجيا التي قد تؤثر على قرار تضمين حمل عمل في استراتيجية النظام الأساسي للتطبيقات الحديثة.
اعتبارات الموقع:
الاعتبارات المتعلقة بمكان استضافة حمل العمل.
- متطلبات استضافة السحابة العامة: هل هناك قيد تقني محدد مرتبط بمتطلبات السحابة العامة؟
- متطلبات استضافة السحابة الخاصة: هل هناك قيد تقني محدد مرتبط بمتطلبات السحابة الخاصة؟
- متطلبات استضافة Edge: هل هناك قيد تقني محدد مرتبط بمتطلبات الحافة؟
- متطلبات قابلية النقل: هل هناك قيد تقني محدد مرتبط بمتطلبات قابلية نقل السحابة؟
اعتبارات العمليات:
الاعتبارات المتعلقة بعمليات النظام الأساسي والمضيفين وأحمال العمل.
- النظام الأساسي السحابي الأساسي: يجب على المؤسسات تحديد نظام أساسي سحابي لتوفير أدوات إدارة العمليات. قد يكون لدى بعض المؤسسات أكثر من نظام أساسي سحابي أساسي لإدارة أنواع مختلفة من العمليات. ما هو النظام الأساسي السحابي الأساسي لتشغيل حمل العمل هذا؟
- الأنظمة الأساسية للعمليات الإضافية: هل ستتم إدارة حمل العمل هذا أيضا من خلال أي منصات عمليات إضافية؟
- متطلبات استضافة السحابة: هل يتطلب حمل العمل هذا استراتيجية استضافة سحابية محددة؟ السحابة العامة أو السحابة الخاصة أو قابلية نقل السحابة
- النظام الأساسي الموحد للتنسيق: إذا كان لدى الشركة حل قياسي لتنسيق الحاوية، فضمن اسم النظام الأساسي الموحد الذي سيتم النظر فيه. أمثلة: خدمة Azure Kubernetes (AKS) أو محرك AKS أو Kubernetes.
- اعتبارات التزامن المخصصة: هل هناك شرط لمنصة تنسيق حاوية غير قياسية؟ إذا كان الأمر كذلك، فاشرح هذا المطلب.
- عمليات المضيف الموحدة: يفترض أن أحمال العمل غير معادية ويمكن استضافتها على حاويات مشتركة تدعمها عمليات المضيف الموحدة. هل حمل العمل هذا متوافق مع هذا النهج؟
- اعتبارات عمليات المضيف المخصصة: إذا لم يكن حمل العمل متوافقا مع العمليات الموحدة، فما هي المتطلبات المحددة التي يجب مراعاتها عند إنشاء ممارسات عمليات المضيف لحمل العمل هذا؟
اعتبارات التطبيق:
اعتبارات خاصة بكيفية تطوير التطبيق وسيتم تطويره للمضي قدما.
- وقت تشغيل النظام الأساسي كخدمة (PaaS): ينتج موفرو السحابة العامة أوقات تشغيل تطبيقات متسقة، غالبا ما يشار إليها باسم عروض النظام الأساسي كخدمة (PaaS). في Azure، أوقات تشغيل PaaS التي توفرها Azure App Service. هل يمكن أن يعمل هذا التطبيق في وقت تشغيل PaaS؟ ما وقت التشغيل الأكثر توافقا؟
- وقت التشغيل الموحد: إذا كان التطبيق غير متوافق مع وقت تشغيل PaaS، هل هناك وقت تشغيل موحد توفره المؤسسة؟ ما وقت التشغيل الذي سيتم بناء حمل العمل هذا عليه؟
- اعتبارات وقت التشغيل المخصصة: ما الاعتبارات المحددة التي تتطلب وقت تشغيل مخصصا لحمل العمل هذا؟
- قيود وقت التشغيل: هل هناك أي قيود مفروضة على التطبيق بواسطة وقت التشغيل المختار؟
- تبعيات التطبيق: هل يعتمد حمل العمل هذا على أي أنظمة موجودة في موقع معين (مثل عام أو خاص)؟ تتضمن الأمثلة نظام ERP مثل SAP يعمل في حل معين.
- خطورة البيانات: هل يعتمد حمل العمل هذا على مصدر بيانات موجود في موقع معين (مثل عام أو خاص)؟ يمكن أن تتضمن الأمثلة تبعية على البيانات في SAP أو مصادر البيانات المركزية الأخرى.
- اعتبارات القائمة المعتمدة: هل تمت الموافقة على اعتبارات العمليات المخصصة للاستخدام داخل النظام الأساسي السحابي الخاص بك؟ ما هي الخدمات المعتمدة التي يجب تضمينها في التوزيع؟
اعتبارات الحاويات الأولية
حزم أحمال العمل الخاصة بك في حاويات هو أول نص من العمل الذي يجب جدولته والعمل عليه. والثاني هو التخطيط لاستضافة تلك الحاويات.
حلول النظام الأساسي كخدمة لأوقت التشغيل الموحد والتنسيق والعمليات
بعض أحمال العمل قائمة بذاتها للغاية، ولا تستفيد بالضرورة من عناصر التحكم المتقدمة ومتطلبات البنية الأساسية التي تأتي مع نظام أساسي كبير مثل Kubernetes. لمجرد أن حمل العمل الخاص بك في حاويات لا يعني أنه يجب نشره في Kubernetes. يوفر Azure مجموعة متنوعة من الحلول لتشغيل أحمال العمل داخل محفظتك التي لا تتطلب مستوى الإدارة والبنية الأساسية التي تتطلبها AKS. ستتبع كل الحلول التالية هذا النهج للتخطيط:
ضع في اعتبارك استخدام حل أكثر خفة لحاوياتك مع أحمال العمل التي لا تتوقع أن تنمو في التعقيد والتي تتوافق مع أغراض وحدود هذه الحلول.
التزامن الموحد مع أوقات التشغيل والعمليات المخصصة في السحابة العامة
بالنسبة لأحمال العمل التي لا يمكن تشغيلها في نظام أساسي PaaS مدار بالكامل ويجب ترحيلها على عناصر التحكم على مستوى البنية الأساسية، أو الرغبة في استخدام ميزات التوزيع المتقدمة مثل تلك التي يقدمها منسقو الحاويات، أو تتوقع أن تنمو في تعقيد نمطي، انتقل إلى Azure Kubernetes Service (AKS). تحل AKS لكل من استضافة الحاوية، ولكنها توفر أيضا خيارات معمارية واسعة النطاق، وSRE، والأمان، والنشر، والمراقبة، والبنية الأساسية.
تأتي مجموعة ميزات النظام الأساسي مع متطلبات لتعلم النظام الأساسي على مستوى مشغل نظام المجموعة وعلى مستوى حمل العمل. ضع في الاعتبار تعليم فرق العمليات وفرق البنية وفرق هندسة حمل العمل في المخططات الزمنية للترحيل. أيضا، نظرا لأن AKS عبارة عن نظام أساسي، تأكد من أن فرق أحمال العمل تفهم فصل المسؤوليات داخل هذا النظام الأساسي مقابل ترتيب الاستضافة الحالي الخاص بها. قد يكون مشابها في بعض الطرق، ولكن من المحتمل أن يكون جديدا في نواح أخرى.
التنسيق المخصص وأوقات التشغيل والعمليات في السحابة العامة
بالنسبة لأحمال العمل المتخصصة جدا أو المتطلبات التنظيمية المحددة، يقدم Azure نظامين أساسيين رئيسيين آخرين في مساحة تنسيق الحاوية.
- Azure Red Hat OpenShift
- Azure Service Fabric
إذا كان هناك سبب لاستكشاف البدائل، فتأكد من تخصيص الوقت لفهم فوائد ومفاضلات جميع خيارات النظام الأساسي. الحل الافتراضي ل Azure هو AKS، وتفترض هذه الوثائق أن AKS هي التقنية المختارة.
توحيد العمليات عبر الأنظمة الأساسية السحابية
غالبا ما ينشر العملاء منسقي حاويات مختلفين في بيئات السحابة الخاصة والحافة والسحابة العامة. لتوحيد العمليات عبر هذه الأنظمة الأساسية السحابية المتباينة، يمكن للعملاء دمج نهج عمليات موحد من خلال توسيع أدوات عمليات السحابة الخاصة بهم إلى منصات سحابية متعددة.
في Azure، يمكن للمؤسسات توحيد العمليات عبر منسقين مختلفين عن طريق إلحاق مضيفي الحاوية المتباينين في Azure Arc ل Kubernetes. تضمن هذه الأداة مراقبة وعمليات وحوكمة متسقة عبر كل مضيف حاوية.
أوقات تشغيل التطبيق في بيئات السحابة والحافة الخاصة
عندما يجب تشغيل أحمال العمل في سحابة خاصة أو بيئة حافة، ولكن يتم دعم حمل العمل بشكل أفضل بواسطة وقت تشغيل PaaS، هناك بعض الأدوات التي يمكن أن تمكن المطورين من البناء على أعلى أوقات تشغيل PaaS المتسقة باستخدام Azure App Service:
- Azure Stack HCI: يسمح باستضافة Azure App Service أصلا على Azure Stack، الذي يديره عامل تشغيل Azure Stack.
- Azure Stack HCI ل AKS: يسمح باستضافة أوقات التشغيل المخصصة التي تعمل على AKS داخل Azure Stack، والتي يديرها مشغلو Azure Stack وAKS للسماح بقابلية النقل إلى حلول Kubernetes الأخرى.
- Azure App Service على Kubernetes مع Azure Arc: يسمح لأي مضيف Kubernetes بتوفير خدمات التطبيق في Azure. تصبح جميع المضيفين مثيلا صغيرا من Azure App Service. نظرا لأن كل مضيف يتم إلحاقه أيضا في Azure Arc، يمكن أيضا إدارة هؤلاء المضيفين من خلال عمليات مضيف متسقة مستندة إلى السحابة.
خطة جاهزية النظام الأساسي للتطبيقات الحديثة
بالإضافة إلى خطة مهارات اعتماد السحابة، قد تحتاج فرق اعتماد السحابة إلى تطوير المهارات المتعلقة بالحاوية وKubernetes قبل تنفيذ خطتك:
تأكد من تخصيص الوقت لفرق حمل العمل لتوثيق خطط الترحيل وتشغيلها الجاف. قد يلزم تعديل التطبيق الحالي أو النظام الخارجي (كل من التبعيات والأنظمة التي تعتمد على حمل العمل هذا) بمرونة إضافية لدعم جهود الترحيل. ينطبق هذا على كل من بيئات ما قبل الإنتاج والإنتاج.
الخطوة التالية: مراجعة بيئتك أو منطقة Azure المنتقل إليها
ستنقلك قائمة المقالات التالية إلى الإرشادات في نقاط محددة في رحلة اعتماد السحابة لمساعدتك على النجاح في سيناريو اعتماد السحابة.