كيفاش تبني SaaS
باش يكبر :
21 عام من الدروس

غالبية المشاريع SaaS اللي كيفشلو بعد 12 شهر ما كيموتوش من نقص السوق. كيموتو من معمارية ما كتسحبش النمو، دين تقني (technical debt) كيعيق سرعة التطوير، ولا حادثة أمنية كتخسر ثقة العملاء فـ 48 ساعة.

هاد المقال كيغطي القرارات المعمارية اللي كيفرقو بين SaaS كيصمد فالـ enterprise scale وبين بروتوتيب كيوقف عند أول 1,000 مستعمل. ماشي كلام نظري — هادو patterns شفناهم فـ 40+ مشروع SaaS على مدى 21 عام.

الغلطة القاتلة #1 : المونوليث بلا استراتيجية للخروج

تبدا بمونوليث ماشي غلط. تبقى فيه بلا تخطيط من بعد الـ PMF، هاديك هي الغلطة.

المشكل ماشي فالمونوليث، المشكل أن غالبية الفرق كيتعاملو معاه بحال هو المعمارية الدائمة، ماشي بحال بداية. ملي توصل لـ 50+ مهندس و500+ عميل، المونوليث بلا حدود واضحة كيولي bottleneck فالنشر، كابوس فالاختبارات، وعقبة فالـ onboarding فنفس الوقت.

الـ Modular Monolith : المعمارية اللي حتى حد ما كيهضر عليها

ما خاصكش microservices فمرحلة seed. خاصك modular monolith — وحدة وحدة قابلة للنشر، بحدود داخلية نظيفة كيتطابقو مع domains ديال البيزنس. كل module عندو :

• namespace ديالو فالـ schema (ماشي DB منفصلة — نفس الـ DB، ولكن جداول معزولة بلا foreign keys بين modules)
• API contract عمومي (modules لخرين كيتواصلو فقط عبر interfaces محددة، ما كيدير حتى query مباشر للـ DB عبر modules)
• test suite مستقلة (يمكن تتختبر بوحدها بلا ما تخدم التطبيق كامل)

ملي تحتاج تخرج module لـ microservice — حيت عندو متطلبات scaling مستقلة أو cadence نشر مختلفة — الحدود راها معروفة. الخروج كيولي تغيير فالنشر، ماشي إعادة كتابة معمارية.

الغلطة القاتلة #2 : schema مصمم لليوم، ماشي لغدا

الدين التقني الأغلى فـ SaaS غالباً كيكون فالـ database schema. ماشي فالكود — فالـ schema. الكود يمكن يتفاكتر شوية بشوية. ولكن migrations فجدول production فيه 10M صف، تحت traffic حي، بزيرو downtime، هادي مشكلة من نوع آخر.

الخمس قرارات فالـ schema اللي كيخلقو دين ما يمكنش يتفك

• تستعمل integers auto-increment بحال IDs خارجية. ملي تزيد database ثانية (read replica، sharding، multi-tenant)، الـ integer IDs كيخلقو مشاكل ديال collision و ordering. استعمل UUIDs v7 (مرتبة بالوقت) من اليوم الأول.
• بلا soft delete. الـ hard deletes cascade فـ SaaS فيه متطلبات audit (مالية، صحة، حكومة) هي مخالفة للـ compliance. كل جدول entity خاصو deleted_at و deleted_by من البداية.
• تخزن data ديال tenants فـ schema مشترك بلا isolation row-level. تزيد tenant isolation فـ schema مشترك فالـ scale كيخصك تمس كل query. Row-Level Security (PostgreSQL RLS) كيكلف 2 سوايع فالبداية وكيوفرلك شهور من بعد.
• بلا versioning فجداول الـ configuration أو rules. ملي عميل كيسولك «شنو كانو قواعد التسعير ديالي فـ 15 مارس؟»، كتحتاج جدول event-sourced أو versioned. تزيدو فالعام 2 مشروع كبير.
• JSON blobs للبيانات structured. تستعمل JSONB للمرونة فالـ schema ماشي مشكل. تستعملها بحال بديل للـ normalization حيت «schema يمكن يتبدل» هادا دين كيتراكم. عرف schema ديالك. غادي يتبدل قل مما كتظن.

الغلطة القاتلة #3 : الأمن مزاد من بعد الإطلاق

الـ security by design ماشي معناه تزيد firewall. معناه أن السلوك الآمن يكون هو الدفولت فكل layer — authentication، authorization، access ديال data، logging، secrets — قبل ما تكتب أول سطر من business logic.

الحد الأدنى ديال الأمن اللي ما يمكنش يتفاوض عليه فـ SaaS production

• Authentication : عمرك ما تبنيه بيدك. استعمل identity provider managed (AWS Cognito، Auth0، Keycloak on-prem للنشر الحساس). إلا كنتي كتعالج data ديال مواطنين مغاربة، الـ auth خاصها تكون مستضافة فالبنية التحتية السيادية ديالك.
• Authorization : دير Attribute-Based Access Control (ABAC) من اليوم الأول، ماشي Role-Based. RBAC كيتكسر ملي تزيد permissions دقيقة (وغادي تزيدهم). ABAC كيعطيك المرونة بلا refactor.
• Secrets management : ما تخليش credentials فـ environment variables مباشرة. استعمل AWS Secrets Manager ولا HashiCorp Vault. دير rotation أوتوماتيكي. دير audit للوصول. هادا setup ديال 2 سوايع، شفناه كيوقف breaches اللي كلفو شركات ملايين الدراهم.
• Transport security : TLS فكل بلاصة، حتى الـ traffic الداخلي بين services. mTLS للتواصل بين microservices إلا كنتي كتعالج data حساسة. ما تظنش أن VPC ديالك حد ثقة.
• Input validation : كل input خارجي خاصو يتحقق ويتنقا قبل ما يوصل لـ database. Parameterized queries فكل بلاصة. هادا أساسي ماشي متقدم — ولكن حتى دابا فـ 2026 كنلقاو SQL injection فـ code reviews ديال SaaS.

نموذج البنية التحتية الهجينة للـ SaaS المغربي

سؤال المعمارية لغالبية الـ SaaS المغاربة ماشي «cloud ولا on-premise» — هو «أي workload فين كيمشي». النموذج الهجين غالباً هو الجواب الصحيح :

اللي خاصو يمشي لـ AWS Wavelength Zone Casablanca

• الـ APIs user-facing والـ web application (حساسة للـ latency، خاصها تكون قريبة من المستعملين المغاربة)
• Endpoints ديال AI inference (LLM سيادي، vision models)
• Features ديال real-time (WebSocket servers، presence، notifications)
• الـ database الرئيسية (مع Multi-AZ للـ failover)

اللي خاصو يمشي لـ AWS eu-west-1 (ولا us-east-1)

• Workloads ديال batch processing (تدريب ML بالليل، توليد reports)
• Cold storage و archival (S3 Glacier للـ audit logs)
• Infrastructure ديال CI/CD pipeline
• Integrations مع أطراف ثالثة ماشي حساسة

اللي يمكن يبقى on-premise

• أنواع data حساسة بزاف (سجلات طبية، أدوات مالية) فين عقد العميل كيطالب معالجة on-premise
• Edge processing real-time فين latency ديال الـ cloud غير مقبولة (vision صناعي، integration ديال embedded systems)

إطار قياس الدين التقني

الدين التقني ماشي غير كود مخربق. هو أي قرار معماري كينقص من الخيارات المستقبلية ديالك. باش تدبرو، خاصك تقيسو.

كنستعملو 4 metrics فالـ reviews المعمارية كل ربع :

• Deployment frequency : شحال من مرة فالأسبوع تقدر تدير deploy للـ production؟ إلا الجواب «مرة فالأسبوع حيت خطير»، عندك مشكل دين هيكلي، ماشي مشكل انضباط.
• Mean time to restore (MTTR) : ملي production كيتكسر، شحال كتاخذ باش ترجع؟ إلا MTTR > 2 سوايع، عندك نقص فالـ observability.
• Change failure rate : أش من نسبة من الـ deployments كتسبب incident فالـ production؟ فوق 5% كيدل على نقص فالـ tests ولا feature flags ناقصة.
• Cognitive load لكل module : شحال كيخذ مهندس جديد باش يدير تغيير فـ module بلا ما يكسر شي حاجة؟ إلا الجواب «أكثر من نهار»، الحدود ديال الـ module خايبة.

الدين التقني هو ضريبة. بحال جميع الضرائب، مبلغ صغير ومتوقع ومدبر مقبول. التراكم بلا تدبير كيولي مصادرة — كياخذ أكثر من 100% من capacity الهندسة ديالك غير باش تبقى فبلاصتك.

نقط القرار ديال الـ scalability : إمتى تعمل upgrade لكل layer

الـ optimization السابقة هي ضياع. ولكن الـ scaling بلا تحضير هو أزمة. القرار باش تعمل upgrade لكل layer خاصو يكون مبني على metrics، ماشي على milestones ولا ضغط ديال المنافسين.

• Read replicas ديال الـ database : ملي queries ديال القراءة كيفوتو 70% من الحمولة الكلية ديال الـ DB، ولا ملي p99 latency فالقراءة كيفوت 200ms. ماشي قبل.
• Caching layer (Redis/ElastiCache) : ملي تكتشف queries كيرجعو نفس النتائج لنفس inputs وكيخدمو أكثر من 100×/سايعة. خبيهم فالأول ; optimizي الباقي.
• Service extraction : ملي module عندو متطلب scaling مختلف على التطبيق الرئيسي، ولا ملي نشر features ما عندهومش علاقة كيوقف نشر ديك module.
• CDN للـ assets : اليوم الأول. ما كاينش سبب باش ما تحطش CloudFront قدام assets static ديالك من البداية. التكلفة قليلة ; ربح الـ latency للمستعملين فبلدان مختلفة فوري.
• Job queue (SQS/BullMQ) : ملي action ديال user كيطلق خدمة كتاخذ >200ms والمستعمل ما خاصوش النتيجة فنفس الوقت. ما تديرش خدمة synchronous فدورة الـ request اللي يمكن تأخر.