بنية SaaS متعددة المستأجرين: قرار العزل بين العملاء أولًا

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

الأنماط الثلاثة

الخطأ الذي يسبب الاختراقات

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

الإقامة تغيّر الحساب إقليميًا

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

افتراض عملي

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