כל מייסד B2B SaaS שעבדנו איתו בסוף שואל את אותה שאלה: האם נלך מולטי-טננט או ייעודי? התשובה הכנה היא ״גם וגם, בשלבים, והשלבים חשובים״. הנה עץ ההחלטה שאנחנו עוברים.
שלוש אופציות אמיתיות, לא שתיים
הדיון בדרך כלל ממוסגר כבינארי: תשתית משותפת עם בידוד לוגי לעומת סטאק ייעודי לכל לקוח. יש אופציה שלישית באמצע שכמעט אף אחד לא מדבר עליה מראש — טננטים מבודדים פיזית על תשתית משותפת (DB נפרד, שרתי אפליקציה משותפים, cluster משותף). שם רוב מוצרי ה-SaaS המצליחים מסיימים.
אנחנו קוראים להם משותף, מבודד, וייעודי. לכל אחד יש עקומת עלות שונה, עמדת אבטחה שונה, וסיפור תפעולי שונה.
משותף: אופטימלי ל-100 הלקוחות הראשונים
DB אחד. עמודת tenant_id בכל שורה. Row-level security ב-Postgres אם אתם רוצים חגורה ושלייקס. כל שאילתה לוקחת את הקונטקסט של הטננט מה-session המאומת. זה המודל הזול ביותר להפעלה, המהיר ביותר לשליחת פיצ׳רים, והקל ביותר לדיבאג.
הוא נכשל כשנפח הנתונים של לקוח אחד מעוות את הסכמה המשותפת (שאילתות אנליטיקה נהיות איטיות לכולם), כשסקירת אבטחה דורשת בידוד נתונים כתנאי חוזי, או כשמתחילים לחתום לקוחות בתעשיות רגולטוריות.
מבודד: המיגרציה שרוב הצוותים מעריכים בחסר
DB לכל טננט, שרתי אפליקציה משותפים. קוד האפליקציה צומח middleware קטן שמחליף את החיבור לכל בקשה. מיגרציות עכשיו צריכות לרוץ מול N מסדי נתונים במקום אחד. גיבויים הם לכל-טננט. אנליטיקה לרוחב כל הטננטים דורשת pipeline נפרד של warehouse.
הזכייה אמיתית: לקוחות רעשניים לא משפיעים על האחרים, ביקורות אבטחה מפסיקות לחסום עסקאות, ואפשר להציע מקום אחסון נתונים לכל טננט על-ידי deploy של DBs מבודדים באזור המועדף של הלקוח. העלות היא תפעולית. ראינו צוותים מעריכים את המיגרציה הזו בחסר פעמיים.
ייעודי: מוצר שונה
סטאק ייעודי אומר שהלקוח מקבל שרתי אפליקציה משלו, DB משלו, מטמון משלו, לעיתים קרובות subdomain משלו או אפילו חשבון AWS משלו. זה המודל שאנחנו משתמשים בו ללקוחות אנטרפרייז של פונד-CRM. זה לא פיצ׳ר SaaS; זה מודל עסקי שונה. אתם מחייבים לכל סטאק, לא לכל מושב.
ייעודי פותח שווקי תאימות שהמודלים האחרים לא יכולים להגיע אליהם (כמה רגולטורים בריאות ופיננסים דורשים אותו). הוא גם דורש pipeline של deploy שיכול להקים סביבה שלמה תוך פחות משעה, תצפיות לכל-סטאק, ומודל חיוב שמשקף את העלות.
איך בוחרים
עץ ההחלטה שאנחנו משתמשים בו:
- אתם חותמים את עשרת הלקוחות הראשונים? משותף. תמיד.
- שווי החוזה הממוצע שלכם מעל $50k? תכננו את המיגרציה למבודד עכשיו, לא אחר כך.
- אתם מוכרים לבריאות, בנקאות, או ממשלה? ייעודי, עם מבודד כ-fallback ללקוחות קטנים יותר באותה ורטיקל.
- אתם מנסים לסגור לקוח גדול ספציפי שצריך ייעודי? תבנו את זה עבורו, אבל חייבו אותו על עלות ההנדסה — אל תסבסדו עסקה אחת עם מהירות פיתוח עתידית.
הדבר היחיד שאף אחד לא אומר לכם
מיגרציה ממשותף למבודד היא קשה אבל אפשרית. מיגרציה ממבודד לייעודי גם אפשרית. מיגרציה אחורה — מייעודי למבודד — היא פרויקט של רבעונים מרובים בלי upside נראה ללקוח. אל תלכו לייעודי עד שאתם חייבים.