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

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

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

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

قائمة المحتويات:

1. ما هي بنية الخدمات المصغرة؟
2. ما هي العمارة المتجانسة؟
3. الهندسة المعمارية المتجانسة مقابل هندسة الخدمات الدقيقة: المزايا والعيوب
4. أيهما أفضل هندسة متجانسة مقابل هندسة الخدمات المصغرة؟
5. الهجرة من الهندسة المعمارية المتجانسة إلى نظام بيئي للخدمات الدقيقة
6. هل يجب على الشركات الناشئة استخدام الخدمات المصغرة؟
7. استنتاج
8. أسئلة وأجوبة حول Microservices مقابل Monolithic Architecture

ما هي بنية الخدمات المصغرة؟

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

مكونات بنية الخدمات المصغرة التي تجعلها واحدة من أفضل بنية المؤسسة :

• الخدمات مستقلة وصغيرة وغير مترابطة
• يتضمن سيناريو عمل أو عميل
• كل خدمة هي مصدر كود مختلف
• يمكن نشر الخدمات بشكل مستقل
• تتفاعل الخدمات مع بعضها البعض باستخدام واجهات برمجة التطبيقات

مع السؤال حول ما هي بنية الخدمات المصغرة التي تمت الإجابة عليها الآن ، دعنا ننتقل إلى النظر في ما هو العمارة المتجانسة أو ماذا يعني monolithic؟

ما هي العمارة المتجانسة؟

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

الآن بعد أن نظرنا في تعريف monolith أو ما الذي يعنيه monolithic وما هي بنية الخدمات المصغرة ، دعونا ننظر في العيوب والفوائد التي يقدمها نظام الواجهة الخلفية لفهم ما يفصل بينهما.

الهندسة المعمارية المتجانسة مقابل هندسة الخدمات الدقيقة : المزايا والعيوب

مزايا العمارة المتجانسة

تبعيات النشر الصفري

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

تتبع الأخطاء

واحدة من أكبر فوائد monolithic هي أن جميع المعاملات يتم تسجيلها في مكان واحد ، مما يجعل مهمة تتبع الأخطاء أمرًا سهلاً.

لا صوامع

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

الاهتمامات الشاملة :

إن قضاء الوقت في تحديد الخدمات التي لا تنفد في وقت بعضنا البعض هو الوقت الذي يمكنك أن تقضيه بالفعل في تطوير الأشياء التي تساعد العملاء.

كود مشترك:

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

حدود العمارة المتجانسة

عدم المرونة:

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

سرعة التطوير:

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

قابلية التوسع الصعبة:

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

الآن بعد أن فهمنا إيجابيات وسلبيات الهندسة المعمارية المتجانسة في الاختلاف بين الخدمات المتجانسة مقابل الخدمات المصغرة ، دعنا ننتقل إلى إيجابيات وسلبيات الخدمات المصغرة.

فوائد هندسة الخدمات المصغرة

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

عيوب هندسة الخدمات المصغرة

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

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

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

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

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

دعنا نساعدك.

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

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

هل تعمل في قطاع مألوف؟

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

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

ما مدى استعداد فريقك؟

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

ما هي البنية التحتية الخاصة بك مثل؟

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

هل قمت بتقييم مخاطر العمل؟

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

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

متى تختار معمارية متجانسة؟

• عندما يكون فريقك في مرحلة التأسيس
• عندما تقوم بتطوير إثبات المفهوم
• عندما لا يكون لديك خبرة في الخدمات المصغرة
• عندما تكون لديك خبرة في تطوير أطر عمل صلبة ، مثل Ruby on Rails و Laravel وما إلى ذلك.

متى تختار بنية الخدمات المصغرة؟

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

الهجرة من الهندسة المعمارية المتجانسة إلى نظام بيئي للخدمات الدقيقة

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

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

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

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

في القسم التالي ، دعنا نتعلم كيف تؤثر الخدمات المصغرة على الشركات الناشئة وهل يجب على الشركات الصغيرة التفكير في استخدام الخدمات المصغرة؟

هل يجب على الشركات الناشئة استخدام الخدمات المصغرة؟

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

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

بالنسبة للشركات الناشئة ، يمكنك الاستفادة من الخدمات المصغرة عندما:

• الخدمات طرف ثالث أو سحابية أصلية ، أو
• تعمل الخدمة المصغرة على بنية أساسية بدون خادم

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

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

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

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

استنتاج

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

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

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

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

أسئلة وأجوبة حول Microservices مقابل Monolithic Architecture

س: ما هو الغرض من الخدمات المصغرة؟

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

س. هل يساعد الانتقال من بنية متراصة إلى بنية الخدمات المصغرة في المرونة؟

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

س: ما هو الفرق بين نهج monolith مقابل microservices ؟

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

س: متى تختار Microservices فوق Monolithic Architecture

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

• عندما تحتاج إلى خدمة توصيل مستقلة
• عندما يتعين عليك تمديد الفريق
• عندما يتعين عليك إنشاء منصة فعالة
• عندما لا يكون لديك موعد نهائي ضيق