למי זה מתאים
חברות עם מערכת שעובדת — שלהן או שנבנתה עבורן — ויותר ממקום אחד להריץ אותה בו: כמה סניפים, כמה לקוחות, או מוצר שהן רוצות למכור.
הבעיה
תוכנה שנכתבה לעסק אחד נשברת בצורה מאוד מסוימת כשמגיע השני. נתונים מתערבבים. הגדרות שהיו הנחות הופכות לאפשרויות. וכל לקוח חדש דורש מפתח. מה שעבד כמערכת מפסיק לעבוד כמוצר, והתיקון הוא ארכיטקטוני ולא פיצ'ר.
מה יוצא לכם מזה
פלטפורמה שבה לקוח חדש מוקצה בקריאת API אחת במקום במפתח ובפריסה.
מה אנחנו בונים
- בסיס נתונים לכל דייר — בסיסים נפרדים עם מנהל חיבורים ורישום, לא טבלה משותפת עם עמודת דייר
- הקצאה כפעולה מהמעלה הראשונה: דייר חדש, בסיס הנתונים שלו והבעלים — בקריאה אחת
- קונפיגורציה בזמן ריצה במקום פיצול קוד — פריסה, מיתוג והתנהגות נבחרים לכל דייר
- חיוב, תוכניות ומגבלות שימוש שהמוצר באמת אוכף
- חבילות חוזה משותפות כך שהשרת והלקוח לא יכולים להתפצל בשקט
- תלת-לשוני וימין-לשמאל כתכונה ארכיטקטונית ולא כשלב תרגום
ההוכחה
TorchCommerce, TorchLab ו-TorchAI נבנו כל אחד לעסק אחד והם היום מוצרים רב-דיירים. TorchLab מפעיל שני עסקי תיקונים עצמאיים על פריסה אחת, לכל אחד בסיס נתונים משלו, ושלישי הוקצה בלי לגעת באף אחד מהם. אותה עבודה, שלוש פעמים.
שאלות נפוצות
יש לנו כבר מערכת. אפשר להפוך אותה לרב-דיירת?
לרוב כן, אבל זו בנייה מחדש של אופן הפרדת הנתונים ולא הגדרה שמשנים. הצעד הראשון הכן הוא להסתכל איך הנתונים שלכם מאוחסנים היום. אם זה יעלה יותר מלהתחיל מחדש, נגיד את זה.
עמודת דייר זה לא פשוט יותר?
פשוט יותר לכתוב, ומשמעותו שבאג אחד בשאילתה חושף נתונים של לקוח אחד לאחר. אנחנו עובדים עם בסיס נתונים לכל דייר כדי שסוג הטעות הזה לא יוכל לקרות. זה עולה יותר בתפעול ואנחנו חושבים שזה שווה.
אתם בונים רעיון SaaS מאפס?
אנחנו מעדיפים לבנות לעסק שכבר יש לו את הבעיה, כי זה מה שגורם למוצר לשרוד את עשרת הלקוחות הראשונים. אם יש לכם לקוח משלם או עסק משלכם להריץ עליו — מעניין אותנו. אם זה רעיון בלי משתמש ראשון, אנחנו בדרך כלל הבחירה הלא נכונה ונגיד לכם.
בואו נדבר על המערכת שלכם
שתי שאלות ומספר טלפון. עונה אדם אמיתי, בדרך כלל באותו יום. אנחנו שני אנשים בירושלים, לא תור.
ספרו לנו על העסק