אחרי שנים של שימוש במוצר מדף, בנינו מערכת ליבה משלנו. הנה מה שלמדנו בדרך

מערכת ליבה קריטית שנרכשה כמוצר מדף הפסיקה לעמוד בסקייל שלנו. כך בדקנו אם Build בכלל אפשרי ומה ה-AI שינה בחישוב - כולל 4 תובנות פרקטיות

כשהמערכת לא עומדת בסקייל, השאלה משתנה (צילום: Dreamstime)

מאת טל יערי ולירון יוסף

תלות-יתר בספק, או Vendor lock-in, היא לא תמיד שאלה של חוזה או מחיר. לפעמים אתם עלולים להגיע לשם בלי לשים לב, בעקבות אלפי החלטות טכניות שהצטברו במשך שנים וייקרו את ההחלפה.

זה בדיוק מה שקרה לנו ב-Viber. עד לא מזמן עבדנו עם מערכת ליבה תפעולית קריטית, שנרכשה כמוצר מדף. הרציונל ברור: רכישת מוצר מחברה בעלת מומחיות בתחום, שגם תתחזק את המערכת עבורינו, מפנה את הצוות הפנימי שלנו לעבודת הליבה שלו.

עם השנים החברה התפתחה והצרכים שלנו השתנו, מה שדרש התאמות רבות של המערכת. כל התאמה כזאת הוסיפה שכבה של מורכבות, ודרשה הכפפה של הדרישה העסקית למה שהמערכת יודעת לעשות. ההתאמות הגדילו את הפער בין הגרסאות, מכיוון שכל שדרוג טמן בחובו סיכון לשבירת שכבת הקסטומיזציה שבנינו ופגיעה בזמינות תהליכים עסקיים קריטיים בפרודקשן. שינויים קטנים דרשו Regression רחב, וה-Release cycle של הספק לא תמיד התאים לדרישות שלנו.

לא מזמן בחנו שדרוג לגרסה החדשה, וגילינו שהיא לא עומדת בעומס הבקשות שלנו בפרודקשן. בזמן שהסקייל שלנו גדל עם השנים, המוצר התפתח בכיוון שמתאים לרוב הלקוחות שלו, אבל לא לפרופיל העומס הייחודי שלנו. הבנו שהצרכים שלנו גדלו מעבר למה שמוצר מדף נועד לתת.

ברגע הזה הפסקנו לדון ב-Build or Buy, והתחלנו לשאול שאלה אחרת: איך בודקים אם Build בכלל אפשרי ומשתלם? הנה 4 תובנות פרקטיות שעזרו לנו בתהליך, ואולי יקצרו גם לכם את הדרך.

1. לפני שבונים – בודקים (אבל באמת)

אחרי שהחלטנו לבנות את המערכת בעצמנו, הסכמנו שכל החלטה בדרך חייבת להיות מבוססת על ניסוי, ולא על הנחות. האתגר הראשון היה בחירת טכנולוגיה. התלבטנו בין שתי אפשרויות: הראשונה הייתה Java – שפה שנמצאת בשימוש מאסיבי בחברה, מוכרת לצוות ובעלת תשתית קיימת. השנייה הייתה Node.js, שמציעה יתרונות ביצועיים רלוונטיים לפרופיל העומס שלנו, אבל אין לה תשתית רחבה בארגון.

במקום לנהל דיון תיאורטי בלבד, בנינו שלושה Microservices שמדמים את ליבת המערכת בשתי הטכנולוגיות במקביל. האפיון הטכני-עסקי ארך כשבועיים, וזאת הייתה עבודה שהיינו צריכים לבצע בכל מקרה. יצירת הקוד באמצעות AI לקחה לנו ימים בודדים.

הרצנו בדיקות זהות על שתי הגרסאות:

• Throughput ו-Latency תחת עומס מייצג
• Memory footprint ו-CPU utilization
• Operational ו-Development complexity
• עלות הרצה בפרופיל ה-Workload שלנו

במבחן התוצאה, Node.js הראתה יתרון ברור בתפוקה תחת עומס גבוה, עם זמני תגובה נמוכים יותר ועלות הרצה נמוכה יותר. המדדים החליטו בשבילנו.

2. ה-AI שינה את השיקולים הכלכליים, לא את עקרונות ההנדסה

הבינה המלאכותית לא כתבה לנו את המערכת, אלא הורידה את עלות הכניסה לפרויקטים שבעבר לא כדאי היה להתחיל. פעולות שבעבר הפכו Rewrite לפרויקט בלתי כדאי – כתיבת טסטים, Boilerplate ,Migration tooling ותיעוד – אורכות כעת ימים בודדים במקום שבועות.

אבל שיקול הדעת ההנדסי לא השתנה. ניתוח ה-Trade-offs, ה-Debugging של Distributed behavior, ההחלטה מה בכלל לבנות – כל אלה דרשו היכרות עמוקה עם המערכת, בדיוק כמו קודם. לכן, המדד הנכון הוא לא כמה קוד ה-AI כותב, אלא כמה מהר הצוות מגיע לקוד שמוכן לפרודקשן.

3. אם כבר אז כבר: בנו לולאת פיתוח AI Native

בעבודה עם Coding Agents, הפקטור הקריטי הוא איכות הקונטקסט. השאלה הרלוונטית היא לא "האם האייג'נט יודע לכתוב JavaScript?", אלא "האם הוא מבין את הפרויקט?".

באמצעות Claude Code ו-Kiro בנינו פרויקט אפיון מקיף: הגדרות שירותים, דיאגרמות, ניתוח מקרי קצה וסיכומי פערים. לא מסמך Word אחד, אלא מבנה שניתן לנהל ב-Git ולבנות עליו.

הניהול ב-Git אפשר לנו גרסאות מבוקרות. בנינו אייג'נט שמסנכרן אוטומטית כל שינוי ב-Git לדף ב-Confluence. הצוותים העסקיים ראו בזמן אמת כל שינוי בתכנון, בלי צורך לפענח קוד. זה יצר שקיפות שלא הייתה קיימת בפרויקטים קודמים.

עם המעבר למימוש, פיתחנו סקיל שיודע לקרוא ולנתח את הדרישות מפרויקט האפיון ולהזין אותן לתהליך הפיתוח. במקום שכל מפתח יסביר מחדש את הפרויקט לאייג'נט בכל סשן, הפכנו את הידע הזה לחלק מסביבת הפיתוח עצמה.

בנינו סקיל נוסף שמייצר טסטים ישירות מתוך מסמכי האפיון – כך הם בודקים גם את הדרישה, ולא רק את המימוש.

4. תקשיבו למשתמשים

ה-Rewrite לא רק פתר חוב טכני, אלא גם פתח מחדש את הדיאלוג עם האנשים שמשתמשים במערכת מדי יום. ברגע שהיה ברור שאנחנו לא מעתיקים את המערכת הישנה, אלא חושבים מחדש – התחילו להגיע שאלות שלא נשאלו שנים: למה התהליך הזה עובד כך? למה הפעולה הזאת עדיין ידנית? ומה היינו בונים אחרת אם היינו מתחילים היום?

לבנות או לקנות? 7 שאלות שיחסכו לכם הרבה טעויות

לפני שרוכשים, מחדשים חוזה או מחליטים על Rewrite, שווה לשאול:

• האם המוצר עדיין מתאים לדומיין שלנו, או שאנחנו מתאימים את הדומיין למוצר?
• כמה מהמערכת כבר מותאמת לנו אישית? היכן עובר הגבול בין Standard לבין Company-specific?
• כמה מה-Roadmap שלנו תלוי בזה של הספק?
• מה מחיר השינוי במערכת (ולא רק מחיר הרישיון)?
• מה רמת ה-Version Drift? כמה קשה לבצע שדרוג?
• האם הספק יכול לעמוד בסקייל ובדרישות עתידיות?
• אם היינו מתחילים היום, עם AI-native development workflow, האם עדיין היינו קונים?

שאלת ה-Build or Buy לא נעלמה, אבל החישוב השתנה

פרויקט כזה של בנייה מחדש דרש בעבר 6-8 מפתחים ובודקים לתקופה של שנה וחצי. אנחנו עובדים עם צוות קטן משמעותית ומעריכים שנסיים אותו תוך כ-6 חודשים. ה-AI לא החליף מפתחים, אלא שינה את מה שצוות קטן מסוגל לבצע.

ה-AI גם מאפשר אימוץ טכנולוגיה חדשה ללא תשתית קיימת, או עם תשתית מוגבלת בלבד. כשאייג'נטים מסוגלים לייצר קוד בסטנדרט גבוה ובשפה שהצוות לא עבד בה קודם, חסם הכניסה לטכנולוגיה חדשה נמוך בצורה משמעותית.

שאלת ה-Build or Buy לא נעלמה, אבל החישוב השתנה. אם לפני 3-4 שנים התשובה הייתה חד-משמעית "לקנות", הרי שהיום היא שווה בחינה מחודשת. לפעמים התשובה לא תשתנה, אבל אולי תגלו שמה שנחשב לא כדאי עד ממש לא מזמן, עשוי להתאים מצוין היום.

הכותבים הם R&D Director, Business Solutions ו-R&D Director, Business Platform Domain ב-Viber