أنواع توزيع التطبيقات

مكتمل

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

الأجهزة الظاهرية أو الحاويات أو النظام الأساسي كخدمة؟

السؤال الرئيسي هو ما إذا كنت تريد أو تحتاج إلى نشر التطبيق الخاص بك على جهاز ظاهري (VM) أو داخل حاوية أو كحل النظام الأساسي كخدمة (PaaS).

• مع الأجهزة الظاهرية ، فأنت في عالم مشابه لبيئة محلية أو بيئة مركز بيانات كلاسيكية. يوفر Azure مجموعة من الأجهزة الظاهرية التي تم تكوينها مسبقا والتي تقوم بتشغيل أنظمة التشغيل الرئيسية (Windows وLinux)، وستحتاج إلى تكوين هذه الأجهزة وصيانتها.

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

  يعمل حل الجهاز الظاهري بشكل جيد إذا كان لديك فريق عمليات من ذوي الخبرة يقوم بتكوينها وصيانتها، وإذا كانت لديك حالات استخدام محددة. على سبيل المثال، قد تستخدم بعض المكتبات الأصلية أو بعض البرامج الخاصة، مثل Oracle WebLogic Server أو IBM WebSphere Application Server.

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

  نظرا لأن الحاويات توفر الكثير من الحرية، فإنها تعاني من بعض القضايا نفسها مثل الأجهزة الظاهرية. إذا قمت بتوفير JVM الخاص بك، فستحتاج إلى تحديثه وتصحيحه حسب الضرورة. ونتيجة لذلك، تتطلب صور Docker سلسلة أدوات جيدة للتكامل المستمر والتسليم المستمر (CI/CD) للحفاظ على الحاويات بشكل صحيح. نظرا لأن صور Docker يمكن تشغيلها محليا وهي أخف من الأجهزة الظاهرية، فإنها توفر أيضا تجربة مطور رائعة.

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

  يمكنك تحقيق المزيد باستخدام حل PaaS. يمكنك إعداد التكوين التلقائي وإدارة البيانات السرية وتحميلها (على سبيل المثال، باستخدام Azure Key Vault)، ومراقبة التطبيق الخاص بك، وتشغيل جلسة عمل جمع معلومات مباشرة، وتمكين نشر دون توقف.

خيارات النشر

سواء كنت تستخدم الأجهزة الظاهرية أو الحاويات أو حل PaaS، يمكنك عادة نشر تطبيقات Java الخاصة بك على السحابة بأي من طريقتين:

• توزيع التعليمات البرمجية المصدر: يمكنك تثبيت التعليمات البرمجية المصدر إلى مستودع Git ويدير موفر السحابة عملية تقوم بتجميع التطبيق وبناءه وحزمه.
• نشر ملف JAR أو WAR أو EAR: يمكنك حزم التطبيق الخاص بك، عادة كملف JAR قابل للتنفيذ (Java ARchive)، ولكن WAR (Web Application ARchive) و EAR (Enterprise Application ARchive) وتنسيقات الملفات الأخرى ممكنة أيضا. ثم يقوم موفر السحابة بتشغيل الملف القابل للتنفيذ.

خياري النشر هذين هما الطرق الكلاسيكية لتشغيل تطبيقات Java. لكلا الخيارين، عادة ما تكون عملية الإنشاء متشابهة، والفرق الرئيسي هو مكان تشغيل هذه العملية. السماح لموفر السحابة بإجراء البناء أبسط، ومع هذا النهج يطبق موفر السحابة عمليات التحقق من الأمان والتصحيحات الخاصة به. من خلال إنشاء التطبيق محليا أو باستخدام نظام أساسي CI/CD مثل GitHub Actions، يمكنك الحصول على مزيد من المرونة والتحكم.

دالات بلا خادم

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

تشترك الوظائف في الميزات مع حل PaaS الذي وصفناه سابقا. في Azure، يتشابه حل PaaS (Azure App Service) وحلنا بلا خادم (Azure Functions) تقنيا ويشاركان بعض التعليمات البرمجية والخدمات الشائعة.

بالنسبة لخيارات النشر، تعمل الوظائف عادة مع ملفات JAR. تتوفر خيارات أخرى مثل Docker، ولكنها أقل شيوعا وعادة لا تؤدي أيضا. وذلك لأن النظام الأساسي لا يمكنه تحسينها بنفس الطريقة التي يمكن بها لملفات JAR.

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

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