الهندسة المعمارية المتجانسة في مقابل الخدمات المصغرة: أيهما أفضل بالنسبة إليك؟

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

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

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

أيهما ستختار؟ أولاً، دعنا نلبي خياراتك.

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

عادةً ما تحتوي التطبيقات المتجانسة على المكونات التالية:

• واجهة المستخدم من جانب العميل (واجهة المستخدم (UI)): “يشير مصطلح "جانب العميل" إلى ما يُعرض على جهاز الحوسبة الخاص بالمستخدم. تتولى واجهة المستخدم (UI) إدارة ما يراه المستخدم، بما في ذلك الصور والنصوص وأي شيء آخر يمكن نقله عبر شاشة واجهة المستخدم (UI)، مثل المعلومات المتعلقة بإجراءات المتصفح.

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

• تطبيق جانب الخادم: يتعامل تطبيق جانب الخادم مع موارد الخادم مثل الذاكرة ووحدة المعالجة المركزية والتخزين.

يحقق استخدام الهندسة المعمارية المتجانسة العديد من الفوائد:

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

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

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

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

يثير استخدام العمارة المتجانسة أيضًا مشكلات محتملة:

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

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

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

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

مزايا الخدمات المصغرة عديدة. فهي تستوعب كلاً من نمو الأعمال المستمر والتغيرات التكنولوجية الجديدة:

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

• جاهز للأتمتة: تتيح الخدمات المصغرة المستخدمة للمؤسسات أتمتة عملية التكامل المستمر/التسليم الثابت (CI/CD). يسمح هذا بتطوير تحديثات الشيفرة البرمجية التي تحدث وفقًا لجدول زمني مستمر.

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

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

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

• التعرض الأمني المحتمل: يستخدم تبادل البيانات الذي يتم بين العمليات المختلفة داخل نظام الخدمات المصغرة بوابة واجهة برمجة التطبيقات (API). يمكن لـ API Gateway إنشاء ثغرات أمنية في المصادقة والأنشطة الحساسة الأخرى.

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

قبل أن نجري مقارنة مباشرة بين البنية المتجانسة وبنية الخدمات المصغرة، يجدر بنا استعراض بعض التفاصيل التاريخية لتوفير سياق أوسع.

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

لطالما كانت شركة International Business Machines (IBM®) لاعبًا رئيسيًا في هذا التطور المبكر. وفقًا للمساهم في DZone Pier-Jean Malandrino، "... أدت شركات مثل IBM دورًا أساسيًا في تحديد بنية البرمجيات المبكرة من خلال تطويرها لأجهزة الكمبيوتر المركزي في ستينيات وسبعينيات القرن العشرين".¹

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

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

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

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

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

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

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

كيف تقارن بين البنية المتجانسة وبنية الخدمات المصغرة عند النظر إليها من منظور المراحل التشغيلية الرئيسية؟

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

• الهيكل: تم تصميم وبناء بنية أحادية كوحدة واحدة. تدعم بنية الخدمات المصغرة فكرة النمطية من خلال استخدام مجموعة من التطبيقات الأصغر حجمًا والقابلة للنشر والتي تمكّن من تشغيل خدمات مستقلة بشكل منفصل.

• التعقيد: كلما كان النظام أكثر تعقيداً، كان أكثر ملاءمة لبنية الخدمات المصغرة. إن الخدمات المصغرة المعيارية ترحب بالميزات الجديدة والتقنيات الجديدة التي تميل إلى أن تصاحبها تعقيدات إضافية.

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

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

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

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

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

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

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

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

• التجارة الإلكترونية: تعتمد التجارة الإلكترونية على بنية الخدمات المصغرة لجعل سحر السوق الإلكترونية ينبض بالحياة من خلال تجربة مستخدم سلسة. مع قيام تجار التجزئة الطموحين مثل Amazon (AWS) بتحفيز المبيعات مع توفير قدر أكبر من الراحة وسرعة التسليم، من السهل معرفة سبب تجاوز سوق مبيعات التجارة الإلكترونية لعام 2023 مبلغ 5.8 تريليونات دولار أمريكي^.2

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

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

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

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

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

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

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

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

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