تطوير SaaS متعدد المستأجرين بـ Laravel

كل منتج متعدد المستأجرين يتخذ مبكرًا قرارًا واحدًا لا يسهل التراجع عنه: أين يقع الجدار بين العملاء. وكل ما عداه - كم يكلّف انقطاع، وكم يستغرق استرجاع، وهل تمرّ مراجعة أمنية مؤسسية بسلام - يتبع منه.

ويُتخذ القرار عادةً ضمنًا، على يد من يضيف أول عمود company_id، ويُكتشف بعد سنتين حين يبدأ في الإيلام.

النماذج الثلاثة، ولمن تصلح

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

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

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

والكلفة تشغيلية وحقيقية: الهجرات تعمل N مرة وقد تفشل في الرابعة والتسعين، والاتصالات تتضاعف، ويصير "كم مستأجرًا لدينا" سؤالًا عن البنية التحتية لا عدًّا.

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

ماذا نبني في الحالتين

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

عزل يفرضه النموذج لا الانضباط. النطاق العام يعني أن شرط where المنسي يعيد لا شيء بدل أن يعيد كل شيء. ومع مصنع واعٍ بالمستأجر واختبارات تؤكد أن سجل مستأجر آخر غير مرئي، ينجو الضمان من المطوّر الذي ينضم العام القادم.

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

تخزين مؤقت وتخزين ملفات بمفاتيح حسب المستأجر. مفاتيح التخزين المؤقت والملفات المرفوعة والمستندات المولَّدة كلها تحتاج الحد أيضًا. ومفتاح تخزين يغفل المستأجر أسرع تسريب بيانات ممكن وأصعبه ملاحظةً.

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

الفوترة، وهي حيث يتسرّب المخطط

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

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

أين يقع هذا

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

كيف يجري التعاقد

تبدأ بسؤال يُجاب عنه على الورق: أي نماذج تعدد المستأجرين الثلاثة يحتاجه هذا المنتج، وما الذي يُرجَّح أن يطلبه عقدٌ مع أكبر عميل مرتقب لديكم.

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

ثم البناء، في مراحل ينتهي كلٌّ منها منشورًا، مع كتابة اختبارات العزل إلى جانب المزايا.

ماذا تتسلّم

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

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