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