إغلاق البائع في VDI: المخاطر والحلول

مقدمة

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

ما هو قفل البائع في VDI؟

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

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

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

ما هي أسباب الاحتجاز من قبل البائع في بيئات VDI؟

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

وسطاء الاتصال الملكية وأدوات الإدارة

تتحمل وسطاء الاتصال مسؤولية إدارة اتصالات المستخدمين مع أجهزة الكمبيوتر المكتبية الافتراضية بينما تُستخدم أدوات الإدارة لتوفير وتوزيع وصيانة أجهزة الكمبيوتر المكتبية والتطبيقات. تم بناء أدوات مثل تطبيقات وأجهزة الكمبيوتر المكتبية الافتراضية من Citrix، وOmnissa Horizon، وAzure Virtual Desktop باستخدام بنية إدارة وتقنيات تكوين مختلفة.

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

اعتماديات الهيبرفايزر والبنية التحتية

تتطلب منصات VDI بنية تحتية قادرة على استضافة وإدارة desktops الافتراضية. قد تشمل هذه تقنيات معينة مثل hypervisor، cloud، التخزين، أو تقنيات التزويد.

قد تتضمن عملية الترحيل عدة مهام:

• تحويل أو إعادة بناء صور الآلات الافتراضية
• إعادة تكوين الشبكات والتخزين وتخصيص الموارد
• استبدال أدوات توفير محددة للبائع
• V تحقق من توافق التطبيق والأداء
• إعادة إنشاء آليات التوفر واستعادة الكوارث

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

ترخيص والقيود التعاقدية

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

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

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

يوفر موقع Microsoft Learn رؤية في ترخيص Azure Virtual Desktop وكيف ينطبق ذلك على أنظمة التشغيل المختلفة وحالات الاستخدام.

لذلك، من الضروري تحليل مجموعة الترخيص بالكامل، بما في ذلك آثار أي التزامات تعاقدية، عند اتخاذ القرار، وليس فقط تكاليف الاشتراك.

اعتماديات التطبيق وملف تعريف المستخدم

يمكن أن تحتوي تطبيقات Windows على عدد من الاعتمادات على نظام التشغيل، السجل، برامج التشغيل، الموقع، أو خدمات أخرى.

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

في هذه الحالات، يصبح من الصعب للغاية فصل التطبيقات عن عناصرها الداعمة، مما يقدم ديونًا تقنية كبيرة ويجعل قابلية النقل صعبة للغاية.

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

ما هي مخاطر وجود قفل بائع VDI؟

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

تتعلق المخاطر الرئيسية بالتكاليف، والمرونة المعمارية، واستمرارية العمليات.

ارتفاع تكاليف البنية التحتية والترخيص

يمكن أن تجعل بيئة VDI المرتبطة بشكل وثيق من الصعب على المؤسسة تحسين مكونات بنيتها التحتية.

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

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

نشر التطبيقات ليس أرخص بأي حال من الأحوال من VDI: ستختلف اقتصاديات الطريقتين اعتمادًا على كثافة الأحمال، وأنظمة التشغيل المطلوبة، والبصمة التحتية، ومتطلبات الإدارة والإدارة.

مرونة معمارية مخفضة

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

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

زيادة تعقيد الهجرة

انتقالات بائعي VDI ليست فقط حول ترحيل الآلات الافتراضية.

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

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

تعرض أكبر لتغييرات البائع

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

كلما زادت الاعتماد على منصة نشر واحدة، زاد التأثير التشغيلي المحتمل لهذه التغييرات على الأعمال.

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

كيف يمكنك تقليل مخاطر وجود قفل من بائع VDI؟

يتطلب تقليل الاعتماد على بائعي VDI مجموعة من الاعتبارات الفنية والمتعلقة بالأعباء المعمارية.

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

1. تدقيق الاعتماديات الحالية لـ VDI

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

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

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

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

يمكن أن تساعد هذه التصنيف مديري تكنولوجيا المعلومات على فهم أي الاعتماديات يمكن استبدالها بسهولة، وأيها تتطلب إعادة تصميم كبيرة.

فصل تسليم التطبيقات عن بنية سطح المكتب

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

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

تقوم الطريقتان بتركيز التطبيقات، ولكن بطرق مختلفة.

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

الفرق هو هيكلي، وليس وظيفي.

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

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

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

3. اعتماد هياكل معيارية وقابلة للتشغيل المتبادل

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

يجب على فرق تكنولوجيا المعلومات إعطاء الأولوية لما يلي حيثما كان ذلك ممكنًا:

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

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

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

لذلك، الهدف هو تجنب الربط غير الضروري بين مكونات التطبيق والبنية التحتية، ومكونات الإدارة، والمكونات التشغيلية.

4. اعتبر تسليم التطبيقات الهجينة

لا يتعين على المؤسسات الاختيار بين الاحتفاظ بجميع بنية VDI التحتية الخاصة بها أو استبدالها بشيء آخر تمامًا.

يمكنهم اعتماد استراتيجية هجينة تستفيد من أحمال العمل المختلفة وفقًا لاحتياجاتهم.

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

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

تظل التطبيقات المحلية أفضل عندما لا تؤدي المركزية إلى تحسين الأداء العام بشكل كبير.

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

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

5. قارن التكلفة الإجمالية لنماذج التسليم

توفير التراخيص وحده لا يحدد فعالية تكلفة بنية تسليم التطبيقات البديلة.

يجب على فرق تكنولوجيا المعلومات تقييم التكلفة الإجمالية للملكية بما في ذلك البنية التحتية، تكاليف البرمجيات، الإدارة، الأمان، والهجرة.

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

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

على سبيل المثال، ستتطلب تكوينات استضافة جلسات خدمات سطح المكتب البعيد التقليدية من Microsoft (RDS) تراخيص وصول العميل المناسبة لـ RDS كما هو موضح في وثائق RDS CAL من Microsoft .

يجب التحقق من متطلبات الترخيص بناءً على البنية الفعلية، ومنتج التسليم، والشروط والأحكام ذات الصلة من Microsoft.

يجب أن يكون الهدف هو تقليل التكاليف الإجمالية مع الاستمرار في تقديم الأمان والأداء والموثوقية اللازمة لتلبية احتياجات الأعمال.

ماذا تحتاج إلى فعله للهجرة بعيدًا عن احتجاز البائعين في VDI؟

تقليل الاعتماد على البائعين هو أمر أكثر أمانًا للقيام به بشكل تدريجي بدلاً من إجراء استبدال كامل للمنصة.

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

الخطوة 1: تصنيف التطبيقات حسب متطلبات التسليم

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

• تطبيقات تتطلب أجهزة سطح مكتب كاملة - أحمال عمل تتطلب بيئة نظام تشغيل مخصصة، تكوين خاص، أو عزل على مستوى سطح المكتب
• تطبيقات مناسبة للنشر عن بُعد - تطبيقات ويندوز، متوافقة مع بيئات استضافة الجلسات المشتركة/المخصصة المدعومة
• التطبيقات المناسبة للوصول المحلي أو عبر المتصفح - البرمجيات التي لا تتطلب التشغيل ضمن بيئة VDI بعد الآن

يمكن أن تساعد مثل هذه التصنيفات المسؤول في تحديد المرشحين لنماذج تسليم بديلة، والتي لا تتطلب تعديلات كبيرة.

الخطوة 2: اختر عبء عمل تجريبي منخفض المخاطر

اختر تطبيقًا بمتطلبات موارد محددة بوضوح، وقليل من الاعتماديات، وقاعدة مستخدمين محدودة.

تجنب البدء بتطبيقات حيوية للأعمال تعتمد على تكاملات طرفية معقدة، أو برامج تشغيل فريدة، أو مكونات قديمة معرضة للخطر.

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

الخطوة 3: التحقق من التوافق والأداء والأمان

قبل التوسع، اختبر الوظائف والميزات التشغيلية في بيئات واقعية.

يجب أن يتضمن مشروع ترحيل تسليم التطبيقات المجالات التالية في سيناريو الاختبار:

• تثبيت التطبيق، التبعيات، والترخيص
• المصادقة، MFA، وأذونات المستخدم
• ملفات تعريف المستخدمين والإعدادات والوصول إلى الملفات
• الطباعة، الحافظة، وإعادة توجيه الأجهزة الطرفية
• تزامن الجلسات واستهلاك الموارد
• الكمون والاستجابة وإعادة الاتصال
• تسجيل الدخول والمراقبة وسياسات الأمان
• نسخ احتياطي، استعادة، وإجراءات التراجع

إطلاق التطبيقات بنجاح لا يضمن التوافق الكامل.

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

يجب على فرق تكنولوجيا المعلومات تصميم الاختبارات والمعايير اللازمة للأداء للجلسات والتطبيقات والأمان وميزات التراجع.

الخطوة 4: ترحيل التطبيقات في مراحل محكومة

بمجرد أن يلبي الطيار معايير القبول الخاصة به، قم بتوسيع النشر بناءً على أولوية العمل وتعقيد التقنية.

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

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

الخطوة 5: مراجعة الاعتمادات المتبقية

مسألة احتجاز البائع ليست مقتصرة على حالة واحدة فقط.

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

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

سيسمح ذلك للبيئة الجديدة بتجنب أن تصبح قيد احتجاز آخر من البائع.

في أي حالة تكون VDI هي الحل الجيد للاحتفاظ به؟

تقليل الاعتماد على بائعي VDI لا يتطلب استبدالًا كاملاً لـ VDI.

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

إنه أيضًا ذو قيمة لتقديم بيئات عمل موحدة، مدارة مركزيًا، مع سياسات إدارة سطح مكتب متسقة.

يجب أن يستند القرار لاعتماد بنية مختلفة على سلوك التطبيق واحتياجات الأمان ومتطلبات المستخدم والعوامل الاقتصادية.

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

الاحتفاظ بـ VDI للأحمال التي تتطلب ذلك مع استخدام نشر التطبيقات المستقل للأحمال الأخرى سيسمح بتقليل الاعتماد على VDI دون التخلي عن قدرات VDI.

كيف يمكن أن تظل توصيل التطبيقات مرنة على المدى الطويل؟

تتحقق المرونة على المدى الطويل للنظام من خلال القدرة على الاحتفاظ بالتحكم في علاقة التطبيق بالبنية التحتية والوصول إلى المستخدم.

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

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

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

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

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

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

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

هل تبحث عن طريقة أبسط لتقديم تطبيقات ويندوز؟

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

الختام

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

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