وباء التعقيد

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

مشروع CRUD يضم 10000 مستخدم منتشرون على Kubernetes مع Istio، Prometheus، Grafana، ArgoCD، ناقل أحداث Kafka، 12 خدمة صغيرة، 3 قواعد بيانات مختلفة وشبكة خدمة. لماذا ؟ لأن هذا ما تفعله Netflix. لأن هذا هو ما هو "رائع" في عام 2025.

النتيجة: فريق من 5 مطورين يقضون وقتًا أطول في إدارة البنية التحتية بدلاً من تطوير الميزات.

تطور العمارة

التراجع. إن تاريخ بنيات البرمجيات هو قصة ذات تعقيد متزايد:

متراصة → تطبيق واحد، نشر واحد، قاعدة بيانات واحدة. بسيطة وفعالة ومناسبة تمامًا لغالبية المشاريع.

SOA (البنية الموجهة نحو الخدمة) → تتواصل الخدمات عبر ESB (ناقل خدمة المؤسسة). أكثر مرونة من متراصة، ولكن ESB يصبح نقطة واحدة من الفشل وعنق الزجاجة.

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

EDA (الهندسة المبنية على الأحداث) → تتواصل الخدمات عبر أحداث غير متزامنة. أقصى قدر من الفصل، ولكن تصحيح مجموعة من الأحداث عبر 15 خدمة يعد بمثابة كابوس.

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

مبدأ القبلة

KISS — أبقِ الأمر بسيطًا أيها الغبي — هو مبدأ ينبغي نشره على جدار كل مكتب لمهندس برمجيات.

المبدأ لا يقول "ابق الأمر بسيطًا لأنك سيئ". فهو يقول: للتعقيد تكلفة، وهذه التكلفة يجب تبريرها.

كل مكون يضاف إلى بنيتك هو:

عنصر آخر للمحافظة عليه
نقطة إضافية للفشل
مهارة إضافية مطلوبة في الفريق
تكلفة البنية التحتية الإضافية
تمديد وقت التصحيح

Kubernetes: المثال المثالي

Kubernetes هي أداة غير عادية. من الضروري تنسيق مئات الحاويات على نطاق Google أو Netflix أو Spotify.

لنشر تطبيق MariaDB / MySQL + PHP/Node.js مع 5000 مستخدم؟ إنه مدفع لقتل ذبابة.

خادم مخصص (أو VPS) مع Docker Compose ينجز المهمة مقابل جزء بسيط من التكلفة والتعقيد:

# docker-compose.yml — c'est tout ce dont vous avez besoin
services:
  app:
    image: myapp:latest
    ports:
      - "80:80"
    depends_on:
      - db
  db:
    image: mariadb:11.4
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MARIADB_ROOT_PASSWORD_FILE: /run/secrets/db_password
volumes:
  db_data:

لا توجد مجموعة Kubernetes. لا توجد مخططات هيلم. لا توجد خدمة شبكية. لا توجد مراقبة موزعة. حاويتان فقط تقومان بعملهما.

الشركات التي تتراجع

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

أعادت Basecamp/37signals أحمال عملها من السحابة إلى خوادم مخصصة، مما أدى إلى توفير ملايين الدولارات سنويًا
Amazon Prime Video قامت بترحيل خدمة الخدمات الصغيرة إلى وحدة متراصة، مما أدى إلى خفض التكاليف بنسبة 90%
DHH (منشئ Ruby on Rails) يقوم بحملات نشطة من أجل "الخروج من السحابة"

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

السؤال الجوهري

قبل اختيار التكنولوجيا، اسأل نفسك: ما هي المشكلة التي أقوم بحلها؟

ليس "ما هي التكنولوجيا الساخنة". وليس "ما الذي سيثير الإعجاب في سيرتي الذاتية". ليس "ماذا يستخدم GAFA". والسؤال هو: ما هي المشكلة الملموسة، وما هو الحل الأبسط الذي يحلها؟

إذا كان الجواب على "لماذا Kubernetes؟" "لأن هذا ما سنفعله في عام 2025"، فإن لديك مشكلة في القرار، وليست مشكلة فنية.

عندما يكون التعقيد له ما يبرره

لنكن واضحين: التعقيد ضروري في بعض الأحيان.

إذا كنت تدير 10 ملايين مستخدم بحمل يصل إلى 50x، فإن Kubernetes له ما يبرره. إذا كان لديك 200 مطور على نفس المنتج، فإن الخدمات الصغيرة تسمح باستقلالية الفريق. إذا كنت بحاجة إلى معالجة 100000 حدث في الثانية، فإن كافكا هو الإجابة الصحيحة.

لكن هذه الحالات هي الاستثناء وليست القاعدة. 90% من تطبيقات الويب ليس لديها هذه القيود. وبالنسبة لنسبة الـ 90% هذه، فإن الوحدة المتماسكة جيدة البناء بقاعدة MariaDB / MySQL، والتي يتم نشرها على خادم (أو خادمين للتكرار)، ليست كافية فحسب - بل إنها مثالية.

بياني من أجل البساطة

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

الخلاصة

أفضل معمارية هي الأبسط التي تحل المشكلة. ليست الأكثر إثارة للإعجاب، وليس الأكثر عصرية، وليس الأكثر اكتمالا. أبسط.

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

تم نشر هذه المقالة في الأصل على متوسط.

احتضان البساطة