الدرس 5 — الاعتماد على المزوّد
الاعتماد ليس شرّاً في ذاته: خدمات المزوّدين ممتازة، والاستفادة منها مشروعة. المشكلة أن تعتمد بلا أن تعرف كلفة الخروج.
أشكال الاحتجاز
احتجاز تقني. استخدام خدمات لا مقابل لها عند غيره: صيغة بيانات خاصّة، وواجهة فريدة، وأدوات منصّة لا تعمل في مكان آخر. الترحيل يعني إعادة كتابة لا نقلاً.
احتجاز البيانات. بياناتك عند المزوّد، وإخراجها مكلف. وهذا الشكل الأقوى في مشاريع الذكاء الاصطناعي، لأنّ حجم البيانات كبير بطبيعته.
احتجاز المهارات. فريقك يعرف منصّةً واحدة، والانتقال يعني تدريباً وتوقّفاً وأخطاءً.
احتجاز تعاقدي. التزامات طويلة بخصومات، والخروج المبكّر مكلف.
عدم تكافؤ نقل البيانات
نقطة اقتصادية تستحقّ الوضوح: الدخول مجّاني والخروج مدفوع.
وهذا ليس تفصيلاً تقنياً بل بنية تسعير تخلق احتجازاً حقيقياً: كلّما زادت بياناتك عند المزوّد، ارتفعت كلفة مغادرته. والمشاريع التي تراكم عليها سنوات من البيانات تجد نفسها أمام فاتورة خروج تجعل الترحيل غير مجدٍ اقتصادياً، بمعزل عن أيّ اعتبار تقني.
والوعي بهذا قبل التراكم أرخص بكثير من معالجته بعده.
الاعتماد على مزوّدي النماذج
شكل جديد ظهر مع النماذج اللغوية، وهو أشدّ من احتجاز البنية التحتية:
- تغيّر النسخ: المزوّد يحدّث النموذج، فيتغيّر سلوك تطبيقك بلا أيّ تعديل من عندك. وقد حدث هذا لفرق كثيرة.
- إيقاف نسخة: النموذج الذي بُني عليه تطبيقك يُتقاعَد، فيصبح التحديث إلزامياً بجدول المزوّد لا بجدولك.
- تغيّر الأسعار: اقتصاد مشروعك يعتمد على قرار طرف آخر.
- تغيّر السياسات: استخدام كان مسموحاً يصبح ممنوعاً.
- التوافر: انقطاع عند المزوّد يعني انقطاعاً عندك.
حتى لو استخدمت واجهة تجارية اليوم، فوجود بديل مفتوح قادر على أداء المهمّة بجودة مقبولة يغيّر موقعك التفاوضي كلّياً. أنت تستخدم الخدمة لأنّها أفضل، لا لأنّك مضطرّ. وهذا الفارق يظهر عند أوّل تغيّر في الأسعار أو الشروط.
ما يقلّل الاعتماد فعلياً
استخدم القياسي لا الخاصّ. صيغ ملفّات مفتوحة، وحاويات، ومكتبات قياسية. الكود الذي يعمل على عتاد خامّ ينتقل إلى أيّ مكان؛ والكود المبني على أدوات منصّة لا ينتقل.
افصل منطقك عن الواجهة. طبقة رقيقة بينك وبين واجهة المزوّد تجعل استبداله تعديلاً في مكان واحد لا في كلّ التطبيق. وهذه أرخص وقاية متاحة، وتُنفَّذ في ساعات.
احتفظ بنسخة من بياناتك. ولو أبطأ وأرخص، عندك أو عند مزوّد ثانٍ. هذا يحوّل الترحيل من مشروع ضخم إلى عملية محتملة.
جرّب الترحيل فعلياً. الترحيل الذي لم يُجرَّب لا يوجد. انقل مكوّناً واحداً صغيراً وقِس ما استغرقه وما كسره. هذا التمرين يكشف الاعتماد الحقيقي.
وثّق كلفة الخروج. رقم مقدَّر مكتوب: كم يكلّف إخراج بياناتك، وكم شهراً يستغرق إعادة البناء. اعرفه قبل أن تحتاجه.
السحابة المتعدّدة: نادراً ما تكون الجواب
الفكرة جاذبة: استخدم عدّة مزوّدين فلا تعتمد على أحد.
والواقع أنّها تعني بنية بأدنى قاسم مشترك بين المزوّدين، وتعقيداً تشغيلياً مضاعفاً، وكلفة نقل بين المزوّدين، وفريقاً يجب أن يعرف منصّتين. وهي تجعل النظام أهشّ غالباً لا أمتن.
وما يعمل عملياً مقاربة أوسط:
- مزوّد أساسي لمعظم الأعباء.
- قابلية نقل مصمَّمة بالممارسات أعلاه.
- مزوّد ثانٍ لعبء محدَّد حيث يكون أفضل بوضوح، مثل تأجير معالجات للتدريب.
- نسخ احتياطية خارج المزوّد الأساسي.
متى تكون السحابة الخيار الخاطئ
سؤال مشروع، وله أجوبة واضحة:
- حمل ثابت وعالٍ على مدار السنة: العتاد الخاصّ أرخص بفارق كبير.
- قيود قانونية تمنع خروج البيانات.
- حاجة إلى زمن استجابة أدنى ممّا تتيحه الشبكة: تصنيع، وأنظمة زمن حقيقي.
- بيانات ضخمة جدّاً حيث كلفة النقل تتجاوز كلفة المعالجة.
- حساسية شديدة للكلفة مع خبرة تشغيلية موجودة فعلاً.
وقد عادت شركات فعلياً من السحابة إلى بنية خاصّة بعد أن استقرّت أحمالها، ووفّرت مبالغ كبيرة. القرار ليس عقائدياً في أيّ اتّجاه، بل حسابياً بحسب استقرار الحمل.
في ثلاث جمل
الاعتماد ليس مشكلة في ذاته، والمشكلة أن تعتمد بلا معرفة كلفة الخروج، وعدم تكافؤ تسعير النقل — الدخول مجّاني والخروج مدفوع — يجعل الاحتجاز يتعمّق بصمت مع تراكم بياناتك. والاعتماد على مزوّدي النماذج أشدّ من احتجاز البنية لأنّ سلوك تطبيقك وأسعاره وجدول تحديثه تصبح بيد طرف آخر، ووجود بديل مفتوح قادر على المهمّة يغيّر موقعك التفاوضي حتى إن لم تستخدمه. والسحابة المتعدّدة تجعل النظام أهشّ غالباً، والبديل الصحيح مزوّد أساسي مع قابلية نقل مصمَّمة من اليوم الأول ونسخ احتياطية خارجه، مع الاعتراف بأنّ السحابة خيار خاطئ للأحمال الثابتة العالية.
التالي — الدرس 6: الملخّص والأسئلة الشائعة ←