478 with Haim Yadid, Software in young startups

רברס עם פלטפורמה

[קישור לקובץ mp3]

פרק 478 של רברס עם פלטפורמה, שהוקלט ב-27 באוגוסט 2024. אוטוטו מתחיל החופש הגדול של ה-1 בספטמבר - ואורי ורן מארחים (לראשונה, באורח פלא) את חיים ידיד לשיחה על, ובכן - תוכנה.

Image by DALL-E

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

00:54 חיים, Next disclaimers והכנות למזגן בממ”ד

(רן) אז לפני שנצלול לנושא של היום - רמז: “תוכנה” - אז חיים, בוא קצת ספר על עצמך ועל המקום שבו אתה נמצא כעת.

• (חיים) אז אני בעולם התוכנה כבר הרבה מאוד שנים, יש האומרים יותר מדי - ועדיין לא למדתי להתקרב למיקרופון . . .
• יצא לי לעשות הרבה דברים, אבל בתפקיד האחרון שלי אני עובד בחברה שנקראת Next Insurance
• בעצם, הייתי המפתח הראשון בחברה, וראיתי איך החברה גדלה מחברה של אנשים שנכנסים בחדר אחד מאוד מאוד קטן לחברה עם אלף איש והמון המון מכירות והרבה מאוד כסף שמתגלגל.
• עם 1000 אנשים - 700 בחו”ל, 300 בערך בישראל - בהחלט אופרציה מרשימה.
• [גיקונומי #306 – אלון חורי מבטח עסקים]
• ויש הרבה מאוד דברים שלמדתי בדרך, ושאליהם בעצם הייתי רוצה להתייחס בפרק הזה.

(רן) כן, אז למעשה הפרק הזה זה איזשהו Follow-up לפרק קודם, שאני כרגע לא זוכר את מספרו [469!] אבל לא מזמן [~4 חודשים], שהקלטנו עם שי ילין [469 Software development in early stage startups with Shai Yallin] - ובפרק הזה אנחנו גם נפגש עם שי, בקרוב, עוד מעט, אז Stay Tuned.

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

אז רק נזכיר כמה מהנושאים, ותיכף גם נצלול אליהם - אחד זה Microservices vs. Monolith, כן או לא?; השני זה תלויות או שימוש ב-Framework-ים - לא יודע אם נגיע לזה או לא; טסטים - איזה טסטים? מתי ואם בכלל; טיפול ב-Infrastructure ואחרים.

אז חיים פה, למעשה אפשר לנחש לפי ה-Intro, מייצג את הפרספקטיבה של סטארטאפ שהתחיל קטן - וגדל, ועדיין גדול (טפו-טפו), וגם שם יש לקחים.

(רן) אז במה נתחיל?

• (חיים) אז קודם כל, אני רוצה לתת ה-Disclaimer, כי Next Insurance שטיפה רציתי לדבר עליה, זו בעצם חברה בעולם של InsurTech. עולם הבעיה הוא עולם של ביטוח.
• זה בגדול אומר Scale, מבחינת טרנזקציות (Transactions) בשנייה שהוא יחסית נמוך.
• זה אומר - אתה יודע, אם יש “Big Data”, אז הרבה שנים הייתי אומר שאנחנו “Small Data - Big Money” , אבל זה כבר לא נכון כל כך היום . . .
• יש לנו כבר כמויות מאוד מאוד גדולות של Data, שעוזר לנו בעצם לתמחר את הפוליסות יותר נכון, אז זה כבר לא ממש מדויק.

(רן) דרך אגב, בעולם הביטוחים - איפה אתם? יש סוגים שונים של ביטוחים . . .

• (חיים) אנחנו מתעסקים בעצם בביטוחים לעסקים קטנים - ביטוחים לעסקים קטנים בארצות הברית.
• לדוגמא, אם אתה צלם או שיש לך מסעדה - אתה צריך ביטוח, כי אחרת אם יתבעו אותך אתה תפשוט את הרגל.
• ו-Next Insurance בעצם פותרת את הבעיה הזאת - זה שוק מאוד מאוד גדול, אנחנו שולטים על חלק קטן ממנו ויש לנו הרבה לאן לגדול.
• דרך אגב, אם רוצים תיאור מלא על ה-Business של Next Insurance, יש פרק בפודקאסט גיקונומי עם ניסים טפירו, שהוא ה-CTO של החברה.
• מאוד מאוד מעניין, עם הרבה מאוד היבטים עסקיים וראיית-עולם מאוד מפוקחת על איך בונים סטארטאפ מאוד מאוד גדול
• ונראה לי שפה אני אעצור על נושא ה-Business, למרות שגם בזה יש הרבה דברים מעניינים.

(רן) אז יש כמה Take-aways מעניינים . . . אחד - זו חברה בתחום הביטוח, שאני מניח שיש משמעות לתשתיות כשהולכים לתחום כזה; ושתיים - אמרת מקודם ואני אזכיר שוב, היית שם ממש מההתחלה, והחברה היום גדולה.

• (חיים) ואני עשיתי את הטעויות . . . אם שי אמר שאותו שונאים ב-Wix, אז אותי שונאים ב-Next Insurance על הטעויות שאני עשיתי . . . .
• אני רוצה להגיד עוד Disclaimer - מה שאני אומר הוא מהניסיון שלי, ושקצת כולל את השקפת-העולם שלי.
• לא כל הדברים הם בהכרח נכונים.
• אני מאוד מעריך את שי מבחינה מקצועית, ואם אתם בוחרים אם להאזין למה שאני אומר או למה שהוא אומר - אז תבחרו את שלו.
• אני כן רוצה לתת את הפרספקטיבה שלנו.
• ופה בעצם הייתי רוצה להתחיל בשני דברים: הדבר הראשון שהקפיץ אותי, המשפט הראשון שהקפיץ אותי, זה “ההכנה למזגן”.
• אנחנו בשנת 2024! - התחממות גלובלית! אם יש משהו שכל אחד צריך זה מזגן. צריך להחליף את האנלוגיה למשהו אחר.
• “הכנה לחימום”? הכנה לכל דבר אחר . . . .
• אבל מזגן - תמיד צריך.

(רן) הכנה לממ”ד . . .

• (חיים) הכנה לממ”ד . . . גם ממ”ד צריך.

(אורי) ממ”ד עם מזגן.

06:10 מזגן מסוג Microservice ובעיית כמות המפתחים

(רן) אז בואו אולי נדבר, לפני שאנחנו ככה צוללים, נצא מעולם הסיסמאות ונכנס למקום יותר… למשהו קצת יותר “תוכנתי”. אז תן דוגמה של “הכנה למזגן” שאתה חושב שצריך?

• (חיים) Microservices - ותיכף נגיע לזה.
• אני רוצה להביא איזושהי פרספקטיבה - הרבה פעמים אומרים שכשמתחילים סטארטאפ, אתה לא יודע לאן אתה תגיע ואתה לא תדע לאן צריך, אבל יש משהו שצריך לקחת בחשבון: יש סיכוי שהחברה תצליח . . .
• ואם היא תצליח, הרבה מהדברים שאתה עשית בהתחלה, שהיה מאוד מאוד קל לעשות אותם, בעיקר באיזורים של תשתיות - יהיה מאוד מאוד קשה להזיז אותם אחרי זה, בהמשך.
• ואם אנחנו רגע ננסה להיכנס לנושא הזה של Microservices - יצא לי לראות בלא מעט מקומות Monolith-ים שהיה סיוט לפרק אותם.
• ויש פה שני דברים: אחד, במישור הארכיטקטוני; אבל הדבר השני הוא בכיוון של התשתיות.
• זאת אומרת, לעבוד כ-Monolith ולעבוד כ-Microservice זה לא רק לעשות חלוקה ארכיטקטונית לחלקים, אלא גם להצהיר שהולכת להיות חלוקה ארכיטקטונית לחלקים.
• זאת אומרת שלצורך העניין, יש הבדל בין חברה שמגדירה את עצמה כ-Monolith לחברה שמגדירה את עצמה עם “Microservice אחד”.

(רן) בוא נהיה רגע בפוזיציה, אני אשחק את ה-Devils’ Advocate - אתה אומר “תתכוננו למצב שבו החברה תצליח ותגדל”, ואני אומר “אם תלכו יותר מדי עם Microservices, היא לעולם לא תצליח”, כי אתם תשימו לעצמכם “מקל בגלגלים”, תסבכו יותר מדי את העניינים, תכינו יותר מדי “פתחים למזגן”, whatever הדימוי שתבחר לעצמך.

ולכן, גם הקיצוניות השנייה היא כנראה לא טובה.

• (חיים) לגמרי. זאת אומרת, אם הייתי יכול לתת עצה לחברה שמתחילה, אז תתחילו עם שני Microservices - ואל תעלו מעל לשני Microservices הרבה מאוד זמן.
• למה אני חושב שזה נכון? אני חושב שזה נכון כי זה מכריח אותך “לחשוב Microservices”, זה מכריח אותך שתהיה לך תשתית ל-Microservices.
• אבל להתחיל עכשיו לבנות מאות Microservices, עשרה Microservices - זו כנראה טעות.

(רן) בוא נגיד שאם מפתח אחראי לעשרה Service-ים שונים, בשלב הזה - כנראה שעשית משהו מוגזם.

• (חיים)כן.

(אורי) אז אני רוצה לתת, כאילו, משהו שמנחה אותי - גם Outbrain הייתה הפעם Monolith . . .

• (חיים) אני יודע . . .

(אורי) . . . אבל די מהר היא יצאה מזה - ואחד הדברים שהנחו אותי הרבה מאוד זמן, זה משפט שלמדתי מספר שקשור

ל-Scalability: תאמין שאתה הולך להיות גדול פי אלף; תתכנן כאילו אתה הולך להיות גדול פי מאה; תקודד כאילו אתה הולך להיות גדול פי עשר - ותעשה Deploy לפי-2 (x2).

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

(רן) אז בוא רגע נתרגם את זה [גרסת ההגדה ל-Microservices?] - ה”תאמין שאתה הולך להיות גדול” זה ההבנה ששני ה-Service-ים שחיים דיבר עליהם, יום אחד יכולים לפוך להיות אלף. זה כנראה לא בשנה הקרובה, לא בשנתיים - אבל יום אחד זה יכול לקרות, ויש הבדל בין להתחיל עם Monolith אחד לבין להתחיל עם, נקרא זה “שני Monolith-ים”, זה אפילו לא שני Microservices, אבל שני Monolith-ים. זה State of Mind שונה.

(אורי) “Two-o-Lith-ים” . . .

• (חיים) זה State of Mind שונה, שאומר אחד - אתה יכול לדפלט (Deploy) אותם בנפרד.
• יש לך איזושהי מחשבה שיש חלוקה-לוגית שאמורה לקרות.
• לדוגמא - אחת מהטעויות הכי גדולות שיכולים לעשות זה Database משותף, במקרה של Microservices.
• אני מניח שאתם ב-Outbrain מכירים את זה.
• היה לכם את ה-Outbrain DB - ולקח לכם שנים לפרק את זה, וזה היה פרויקט מאוד מאוד גדול.
• אני חושב שבכל מקום שבו עושים טעות באזור של התשתיות, במיוחד במקומות של ה-Data, זה קטסטרופה לתקן את זה אחר כך.
• אתה משלם פי-עשר, אם לא פי-מאה, בשביל לשכתב את המערכת.
• (רן) זאת אומרת, לייצר Data-Contracts ו-Database זה לא Data-Contracts, אוקיי? לצורך הבהרה . . .
• (חיים) נכון.
• ודרך אגב, Monolith זה לא רק Microservices - בעצם, כל דבר שהוא יחיד במערכת הוא Monolith.
• אני יכול לתת דוגמה שוב מ-Outbrain, כי כפי שאתם יודעים עבדתי ב-Outbrain, ואני רוצה לתת דוגמה ממש מקסימה.
• היא מתחילה ב-Commit של [אחד] רן תבורי, לפני המון זמן, שבה הוא מציג את הקונפיגורציה (Configuration) החדשה שהוא פיתח . . .
• (רן) סיקרנת . . .
• (חיים) . . . והוא אומר שעכשיו סוף סוף יש לנו קונפיגורציה מאוחדת, וכל ה-Service-ים יכולים לשים את הכל במקום אחד, וסוף סוף יפסיק להיות לנו בלאגן.
• (רן) אני זוכר שהיה לי איזושהי גירוד בראש כשכתבתי את זה . . .
• (חיים) 8 שנים - או 10 שנים או 12 שנה אחרי זה - חיים ידיד מגיע ל-Outbrain
• ובמשך שנה, כל מה שהוא עושה - אחד מהפרויקטים החשובים שהצוות שלו עושה - זה לפרק את אותה קונפיגורציה, שהפכה כבר להיות מפלצת . . . .
• כי ברגע שמשהו הוא Monolith, הוא הופך להיות סוג של “פח זבל” - כולם זורקים לשם דברים, אף אחד לא יודע מה קורה שם.
• היו שם כמה עשרות-אלפי רשומות, בתוך הדבר הזה, שאף אחד . . . כולם פחדו לגעת.
• (רן) “אומני ה-YAML” הגדולים ביותר מפחדים לגעת בקובץ . . .
• (חיים) . . . ולקח מלא זמן לפרק את זה.

(אורי) אבל אני חושב שה . . . . אם כולנו פה, או אם יש מישהו מהמאזינים שחושב, שהבעיה Scalability שנתקלים בה היא בעיה של כמות הטרנזקציות (Transactions) או כמות הפניות שה-Monolith שלך יקבל - לא, זאת לא הבעיה. הבעיה היא כמות המפתחים.

(רן) כן, תודה אורי, וגם חיים הקדים ואמר - אנחנו היינו חברה של Small Data, Big Money [ו-Gartner יוצרים קטיגוריה סביב ה-Acronym של SDBM בעוד 3,2,1…]. נכון, הבעיה היא בדרך כלל “הבעיה האנושית”, הבעיה הארגונית - ולא באמת בעיה של Data Keys. אוקיי, אפשר בהרבה מקרים, לפחות בשלבים הראשונים, אפשר “לזרוק CPU יותר גדול” או דיסק יותר גדול, אבל לייצר Concurrency בין מפתחים זה החלק הכי מורכב.

• (חיים) נכון.

(אורי) . . . או גם שהקוד שלך הוא Monolith - אבל אתה יכול לשכפל אותו, זה לא פותר את הבעיה. זאת אומרת, אתה יכול לדפלט (Deploy) כמה שאתה כמה שאתה רוצה, אבל זה לא תמיד פותר את הבעיה - כי הבעיה היא מה קורה כשיש בעיה? או כשצריך לפתח Feature חדש, וב-Monolith זה פשוט “להכניס את היד לקן נחשים” . . .

• (חיים) לגמרי . . . וב-Next Insurance, אנחנו דאגנו להתחיל ב-Microservices From Day 1, ובעצם . . .

(רן) בלי חרטות? כלומר, לא היו נקודות שבהן אמרת לעצמך “לא . . . .”

• (חיים) לא נתת לי להגיע ל”אבל” . . .
• אז לא - בלי שום חרטות על התשתית ששמנו בשביל Microservices.
• ולהגיד שאנחנו נמנענו מ-Monolith? זה Wrong . . .
• אנחנו נפלנו בכל מיני מקומות, שאחרי זה היה מאוד מאוד קשה לתקן אותם
• ואני אסביר - יש משהו מאוד נחמד שעשינו: בגלל שאנחנו עובדים עם Microservices ואנחנו חברה מאוד מאוד צעירה, החלטנו לעשות משהו, שבזמן שעשינו אותו היה נשמע מאוד הגיוני - והוא גרם לקטסטרופה כמה שנים אחר כך.
• דיפלטנו (Deployed) את ה-Service-ים ביחד [מוזמנים להאזין ל-Soundtrack של Jaws להנאתכם]
• לכאורה - פעולה פשוטה. מה זה משנה? דפלט אחד, תדפלט שניים, שלושה . . . - זה כל מה שהיה, מה זה משנה?

• (רן) מה זה משנה? קובץ קונפיגורציה (Configuration file) אחד, שניים, שלושה . . . .

• (חיים) . . . בפועל, זו הייתה טעות אחת - והייתה עוד טעות אחת, שנוגעת דווקא לנושא של טסטים.
• חודש אחרי שהתחלנו לעבוד כבר עלינו ל-Production - שזה די מרשים בשביל סטארטאפ.
• ואני התחלתי לכתוב Framework של End-to-End Tests
• וה-Framework של End-to-End Tests הזה פשוט בא “ותפר” כמה שרשראות כאלה של רכישה של פוליסה של ביטוח - כל השלבים לעבור דרכם ששמתי.
• וזה היה בעצם התחלה של תשתית - תשתית של End-to-End Tests, שבעצם הפכה להיות מאוד מאוד מצליחה, וגרמה לכמה דברים -
• אחד, אנשים כמעט לא כתבו Unit Test-ים - הם התמקדו בלהרחיב ולשפר את ה-End-to-End Tests.
• דבר שני - ה-End-to-End Suite הזה היה רץ בתוך ה-Deployment המשותף של כל ה-Services.
• ובלי לשים לב, הפכנו להיות “Distributed Monolith” . . . - כי לא היינו יכולים לדפלט (Deploy) Service אחד - היה לנו Build אחד שמשותף לכל הצוותים.
• וה-Build הזה הפך להיות לא יציב ולא הגיוני
• ובאיזשהו שלב התחלנו לשבור את זה - וזה כבר היה פרויקט כואב . . . .
• אני חושב שזה לקח בערך שנה לשבור את הדבר הזה לחתיכות, לגרום לזה ש...

(אורי) זה בעצם, בתכל’ס, כשהצוות מתרחב - קורים דברים שהם בכלל לא הארכיטקטורה של התוכנה שלך. הם

הארכיטקטורה של איך שאתה מפתח קוד - אם הקונפיגורציות (Configurations) שלך הן Monolith-יות, אם ה-Build-ים שלך, אם אתה על עץ אחד או כמה עצים . . .

16:30 מה עם “ה-Business”?

(רן) אבל שוב אני אשחק את “פרקליט השטן” - כשאתה בונה את הדברים בצורה “מהונדסת נכון”, לצורך העניין אתה אומר “אוקיי, צריך איזון נכון בין End to End Tests לבין Unit Tests, צריך שכל Service יהיה Deployed באופן עצמאי ולא יהיה Coupling שם, צריך שהחוזים יהיו כמו שצריך ולא דרך ה-Database”. כל הדברים האלה נכונים -

אבל האם זה לא מאט את ה-Business?

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

האם היו רגעים שבהם עצרת עצמך או שאנשים אחרים באו ואמרו “רגע-רגע-רגע! למה אנחנו צריכים את כל ה-t!h$ הזה?! אנחנו ‘רק שנייה’ ורק רוצים לבדוק פה איזשהו Concept, רוצים לעשות איזשהו MVP - ואחר כך נכתוב את זה ‘כמו שצריך’” . . . .?

• (חיים) אז בגדול זה נכון - אבל אני רוצה להדגיש שוב דבר אחד: הבדל בין Business “עסקי” לתשתיות.
• תשתיות מאוד מאוד קל לכתוב בהתחלה
• אתה כותב, אם נגיד אתה רוצה שתיהיה לך מערכת Monitoring, אז אתה בונה מערכת Monitoring עם שני Monitor-ים, ולוקח לך חמש דקות לעשות את זה
• ואתה בונה CI/CD, אז זה לדפלט Service אחד - ולוקח לך חמש דקות לעשות את זה.
• ברגע שהנחת את ה-Concept-ים, זה Streamlined עם תהליך הפיתוח וההתקדמות של החברה.
• ואם הזנחת אספקט קריטי בתוך תהליכי הפיתוח, יהיה לך מאוד מאוד קשה לתקן את זה.
• ודברים שאתה לא תרגיש, שהם קצת כמו “לצחצח שיניים” - הם פתאום יהיו הפכו להיות פרויקטים מאוד מאוד גדולים ומאוד מאוד כואבים.
• אני יכול לתת דוגמה - ב-Service-ים של ה-Java של ה-Backend, יש לנו Service-ים של-Java של Backend, שכאילו תומכים בכל המנועים שלנו.
• ויש לנו Service-ים שהם יותר Frontend-oriented, שהם קצת סוג של Router-ים של דברים ומכוונים את הדברים של מפתחי Frontend.
• ל-Service-ים של מפתחי ה-Frontend לא היה מיגרציות אוטומטיות (Migrations) של Database, והם כל פעם בנו כאילו את השאילתות בעצמם.
• הריצו אותi פה ב-Staging, הריצו אותi ב-Production וכו' וכו'.
• לכאורה, הם חסכו זמן של לבנות את התשתית הזאת, אבל זה התנקם בהם.
• בסופו של דבר, להכניס את זה זה היה תהליך כואב - כי כבר אין לך את כל ההיסטוריה של כל הטרנזקציות (Transactions) שעשית על הסכמה של ה-Database.
• והגעת לאיזשהו מצב שבאיזשהו מצב כבר נשבר ה . . . - אבל אתה החלטת לעשות את זה.
• אנחנו אף פעם לא סבלנו את זה ואף פעם לא הרגשנו את זה - כי בהתחלה זה היה פשוט לבחור את התשתית, לעשות שאילתת Database אחת, כל פעם להמשיך ככה.
• ואתה מתקדם ואתה לא מרגיש את זה.
• בגלל זה אני אומר שזה שאתה תעשה Pivot-ים - אתה לא תעשה Pivot-ים כנראה בתשתית, אלא אם כן עשית טעויות מהותיות בבחירת ה-Stack הטכנולוגי שלך.

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

(אורי) . . . או התפתחות של ה-Stack הטכנולוגי.

• (חיים) אבל אין ספק שה-Business כנראה מאוד ישתנה במשך הזמן.
• לדוגמה, כל הקוד שאני כתבתי - כבר נמחק.
• לא נשארה שורת-קוד שאני כתבתי בתחילת הדרך.
• וחגגנו כל פאזה (Phase) כזאת.
• התשתיות שאני הנחתי בתחילת הדרך עדיין קיימות היום.

20:15 אנשים שהקונספט זר להם

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

יש שם הרבה אנשי Machine Learning, זאת אומרת חוקרים - שמעולם בחיים שלהם לא כתבו Unit Testing, אוקיי? “הקונספט זר להם”. הם יודעים מה זה, אבל זה לא חלק מההרגל.

אז אמרתי, טוב - אני רוצה עכשיו לייצר איזשהו Template של פרויקט חדש, נגיד ב-Python, אוקיי? ובפרויקט הזה, אני אכתוב רק Unit Test אחד: “2+2=4”, זה הכל. סופר-סופר פשוט, בתור דוגמה לאיך כותבים Unit Test.

ביקשתי מכולם להשתמש באותו Template, ופתאום ה-Unit Test-ים פרחו כמו פטריות אחרי הגשם . . . . זאת אומרת, פתאום אתה רואה חוקרים הולכים וכותבים לעצמם Unit Test-ים יפים מאוד, כן? כמובן שהייתה להם את היכולת, אבל היה רק צריך את ה-Push הזה, או את הדוגמה הזאת או את התשתית הזאת, האוטומציה הדי-פשוטה של ה-Test הראשון - ומשם כבר כולם, ככה, עוקבים אחרי הדרך.

(אורי) אז אני אגיד משהו - היום, מהנדס חדש שמגיע ל-Outbrain, עושה את ה-Bootcamp - ותוך כמה ימים הוא יודע לייצר Service חדש בכמה לחיצות כפתור. אבל לייצר את הדבר . . . זאת אומרת, אם אני רוצה לייצר מחר משהו שמייצר Service חדש בכמה לחיצות כפתור, בסטארטאפ חדש, כשה-Service הזה יודע להתחבר לכל ה-Database-ים ויש לו Self-Test ויש לו זה ויש לו זה - הוא וואחד Undertaking . . . .

• (חיים) ברור, ולא הייתי נכנס לזה.
• אבל אני כן אומר, שאם אתה בונה את המערכת שלך ב-Mode של Microservices - אתה לא תעשה את זה.
• אתה תבנה את השני Microservices, יחסית Hardcoded . . .

(אורי) . . . “תאמין שיהיו לך אלף מפתחים" . . .

• (חיים) זה אפילו לא זה. אתה בונה את זה בצורה כזאת שאתה מדפלט (Deploy) שני Service-ים.
• איך תעשה את זה? כנראה הכי “רוק ודבק” - אבל הנחת איזשהו משהו, שאחרי זה אתה יכול להניח איזשהו Vision, שבסוף תגיע אליו.
• לדוגמה, אנחנו התחלנו ב-Elastic Beanstalk. אני קצת מצטער שלא התחלנו ב-Kubernetes, כי להתחיל ב-Kubernetes, כמה שזו מערכת מגושמת, כשאתה מתחיל כשזה קטן אז מה קרה?
• להכניס Kubernetes אחרי זה, זה היה פרויקט שלקח בערך שנה
• אבל Once שעשינו את זה, פתאום התחלנו לעשות משהו שלא יכולנו לעשות [קודם] - התחלנו להרים סביבות דינמיות בלחיצת כפתור.
• ל-Production ולא ל-Production, למה שאנחנו רוצים.
• זה לא משהו שכנראה הייתי משקיע בו בהתחלה - אבל אם הייתי מניח Kubernetes ביום הראשון, יכול להיות שהייתי לאט לאט לוקח את המערכת לשם, ולא הייתי שם לב שזה אפילו קורה.

23:19 שחק אותה ערן הראל

(רן) חיים, אני חייב “לשחק אותה ערן הראל” נקרא לזה, או כל דמות אחרת שמקשיבה לך ושומעת “Kubernetes“ וקופצים להם הפיוזים . . . .

• (חיים) דרך אגב - הקשבתי לערן הראל, ובגלל זה לא הכנסתי Kubernetes בתחילת הדרך. . .

(רן) . . . אז הוא יבוא ויגיד, וברור שהוא לא בדעת-יחיד בעניין הזה - למה אתה צריך את הסיבוך הזה על ההתחלה? Kubernetes From Day One?! אוקיי, אני מבין שאחר כך החיים יהיו יותר קלים - אבל אתה עושה היום את החיים יותר קשים, כשהמפתחים שלך עדיין גם ככה “נאבקים ב-Pivot-ים כל שני וחמישי”, ב-Hiring, בגידול של הצוות, במיליון צרות אחרות . . . בוא תחסוך לעצמך צרה אחת, ובסדר, נכון - תשלם את ה-Technical Debt הזה אחר כך, אבל זה ישתלם לך עשרות מונים.

אני לא מדבר על האם Kubernetes זה כלי טוב או לא טוב - אני רק שואל על תזמון של האם באמת אתה מאמין שנכון להכניס, נקרא לזה “Kubernetes מ-Day One”?

• (חיים) אני לא הייתי אומר “מ-Day One”, אבל אני אומר שככל שדוחים את ההחלטה הזאת לשלב יותר מאוחר, זה לא ליניארי.
• להזיז תשתית של חברה Mature זה משהו שהוא יחסית קשה, וההכנסה של תשתית בשלב מוקדם היא משהו מאוד מאוד קל.
• כי זה לא באמת חייב לעבוד עד הסוף . . .

(אורי) אז אני פה קצת Devil Advocate . . .

(רן) יש פה הרבה שטנים בפודקאסט הזה . . .

(אורי) כן . . . ההנחה, שלי לפחות, ברוב ימיי כ-CTO, היא שתמיד אנחנו נחליף תשתיות. למה? זה לא קשור בכלל

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

ואני אגיד לך עוד משהו - בשלב ש-Outbrain רצתה לפרק את ה”קובץ קונפיגורציית-רן-תבורי” - כל הקללות בהמשך - היא הייתה מוכנה לשלם את השנה שיקח לחיים ידיד לעשות את זה . . .

(רן) “וצוותו!” . . . .

(אורי) . . . . וכולם יקללו את רן תבורי . . . .

(רן) עכשיו אני מבין מה זה המבט המזוגג הזה בעיניים . . . .

• (חיים) זה לא היה אני באופן אישי . . . .תראה, זה ברור שאפשר להחליף תשתיות, אבל יש כמה דברים שאתה יודע שאתה תצטרך, בהנחה שאתה יודע - יש לך קצת ניסיון בעולם התוכנה.
• כנראה שאם אתה חברת SaaS, אתה תרצה שיהיה CI/CD, נכון? כי זה Proven Practice של התעשייה.
• כנראה שאתה תרצה Monitoring.
• כנראה שאתה תרצה Logging - ואולי גם איזה Log Shipping לאיזשהו שירות חיצוני . . .
• כנראה שאתה תרצה מיגרציות אוטומטיות (Automatic Migrations) של ה-Database
• כנראה שאתה תרצה Microservices.
• כנראה שאתה תרצה עוד כמה דברים . . . .

(רן) . . . . אתה תרצה Deployment אוטומטי . . .

• (חיים) . . . אתה תרצה CI/CD, אתה תרצה להיות מסוגל לעשות Spawning לסביבות נוספות . . .

(רן) . . . כן, אתה תרצה יכולת לבנות את ה-Database מאפס, לקחת חלקים קטנים שלו לצורך טסטים . . . .

(אורי) אבל כל הדברים האלה - כשאתה אומר “תרצה”, אצלי זה ב”תאמין” . . .

• (חיים) אבל ה”תאמין” הזה - אם אתה לא בוחר תשתית, שתיאורטית יכולה לבנות את זה או לתמוך בזה, אז אתה כאילו הכנסת איזשהו “עז” לתוך המערכת שלך, שאתה תצטער עליה אחר כך.

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

• (חיים) . . . זה לא “גדלה” - היא גדלה אקספונציאלית . . .

(רן) . . . גדלה אקספונציאלית - אבל אמרתי “דריבית”, דריבית זה ה-Exponent - ואתה צריך להחליט. אז עכשיו, כשהבנת את זה, תחליט האם אתה מוכן לשלם המון אחר כך, או אולי קצת פחות עכשיו - או קרוב לאפס אתמול. אוקיי? אז אני גם מזדהה עם זה.

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

28:04 חיים בהכחשה עם Latin1

• (חיים) אני יכול לתת דוגמאות לכל מיני טעויות.
• הטעות הכי מטופשת, שנראה לי שאני עשיתי באופן אישי - אנחנו עובדים עם MySQL . . .

(רן) הנה - אמרת . . .

• (חיים) . . . ה-Default היה Latin1 לטבלאות ול-Database.

(רן) “להטעין אחד”? . . .

• (חיים) Latin1 - זה ה-Encoding כאילו . . .

(רן) חיים, לא הייתי מאמין עליך . . . . Latin1.

• (חיים) ואני זוכר שהסתכלתי וזה היה לי מוזר, אבל אמרתי “אבל מה אכפת לי מזה עכשיו?”

(רן) . . . “מי צריך ל-UTF?” . . .

• (חיים) . . . “אז נעביר את זה בהמשך ל-UTF” . . .

(רן) כן, “notescript אחד קטן וסוגרים עניין” . . .

• (חיים) כעבור כמה שנים הבנו את חומרת המצב - אנחנו כבר, נראה לי יותר משנה וחצי, מנסים להעביר את כל הטבלאות שלנו ל-UTF, כי ה-Latin1 הזה הוא קטסטרופה בכל פרמטר וסכנה ל-Data Corruption בכל מיני צורות.
• וכולה הייתי צריך לעשות מיגרציה (Migration) פשוטה ל-Database, כשעוד הייתי יכול.

(רן) אז רגע, נעשה גנרליזציה (Generalization) ל-Database-ים, או Data בכלל - מאוד קשה לשנות כל דבר שקשור ב-Data, בין אם זה Database-ים, בין אם זה Pipeline-ים של Data, בין אם זה כל . . . תמיד תמיד יהיה יותר קשה. ופה כנראה שכדאי לשלם מוקדם, כי שם החוב הולך ותופח בצורה סופר-אקספונציאלית.

(אורי) אבל בוא נודה על האמת - גם ה-Data שלך מאוד קשור ל-Business שלך, ל-Business Model, למה שיהיה איתו, וזה...

• (חיים) נכון, נכון - אבל אתה לא רוצה טעויות של Latin1.
• בוא נגיד שאנחנו עשינו גם טעויות במידול, כי לא ידענו - לא ידענו את מורכבות הבעיה העסקית שלנו, והיינו צריכים לעשות פרויקטים ענקיים בשביל להחליף את המידול של ה-Data שלנו.
• בגדול, Level of indirection - שזה הגיוני.
• אבל לא להתחיל כ-UTF8 - זה סתם דבילי . . . .

(רן) כלומר, אם אתם עובדים ב-Latin1, אתם "חיים בהכחשה” - זה מה שאנחנו אומרים לכם היום.

• (חיים) כן . . .

30:25 מפתחות זרים

(רן) אוקיי, עוד כמה דוגמאות? דוגמא צבעונית, יפה . . .

• (חיים) אז שוב - נחזור רגע לנושא של המיגרציות (Migrations).
• אני מאוד הייתי גאה בזה ששמנו Flyway, ושכל המיגרציות שלנו אוטומטיות או קרוב בזה.
• והייתי מאוד גאה בעצמי - עד שדיברתי שוב עם שלומי נוח [388 Remote Work (Coronavirus special) With Shlomi Noach], ואז הבנתי שאנחנו עושים דברים לא כל כך טובים.
• שאנחנו לא כל כך מסוגלים להתמודד עם טבלאות גדולות.
• האמת, ידעתי את זה - אבל אם הייתי מדבר עם שלומי על איך צריך לעשות מיגרציות (Migrations), יכול להיות שהייתי בונה תהליך אחר, מוקדם בתהליך הזה, שהיה מאוד עוזר לעבור לסכמות, ששלומי יודע לעשות אותן - ושב-GitHub עשו אותן כמו שצריך.
• כמו לדוגמה - העובדה שיש לנו Foreign Keys דופקים את כל היכולת של כלים כמו Ghost וכל מיני כלי מיגרציה, שיודעים להעתיק גם טבלאות תוך כדי, ולא לעשות איזשהו משהו שלא מתאים לטבלאות גדולות - פיזיבילי (Feasible).
• ועכשיו, לך תעיף את כל ה-Foreign Keys שדאגת לשים בשמחה ובששון . . .

(רן) בוא רק נזכיר למי שלא “חי ונושם Database-ים” בעשור האחרון - Foreign Key עוזר לך לעשות ולידציה (Validation), שאם יש לך רשומה עם מפתח שהוא מתייחס לטבלה אחרת, אז זה יהיה קונסיסטנטי (Consistent).

זאת אומרת, אותו המפתח יהיה קיים גם בטבלה ההיא - וזה נחמד, זה עוזר, זה סוג של וולידציה, איזשהו Test ל-Database.

אבל מה הבעיה כשאתה רוצה לעשות רפליקציה (Replication)?

• (חיים) . . . שאתה לא באמת יכול להעביר את ה-Data - כי אין לך את ה-Foreign Keys . . .
• אתה לא יכול ליצור טבלה נוספת, כאילו, שאליה אתה אמור להעתיק את הסכמה החדשה - כי אין לך את ה-Foreign Keys.

(רן) כן, כי הרפליקציה (Replication) כנראה תרוץ באיזשהו Stream - ואז אתה לא יכול פשוט לקחת Snapshot של ה-Data בלי להעביר את זה, כי זה לא באמת רפליקציה. זו “רפליקציית ה-Offline” אולי, אבל זה לא מה שאתה רוצה, אתה רוצה להסטרים (To Stream) את ה-Data. אבל כשאתה מסטרים (Streamlining) את ה-Data, יכולות להיווצר - לשניות בודדות או לאיזושהי תקופה - איזשהן אינקונסיסטנטיות (Inconsistencies), ואתה כנראה מוכן לחיות עם זה, לטובת היכולת באמת לרפלק (Replicate) את ה-Data.

אוקיי, אז אתה אומר “Foreign Keys זה Big No-No”? - או שאולי זה קצת...

• (חיים) . . . .זה בגדול “Big No-No” . . .

(רן) אוקיי, אז הלכנו עד הסוף עם זה . . .

• (חיים) כן.

(אורי) כאילו, אם אתה מאמין, שאתה תגדל . . .

• (חיים) כן.

(אורי) ואגב - אגב, מי שמאמין לא מפחד.

(רן) מי שלא מפחד - משלם . . . [מי שמאמין, לא מתעד - חזי לפלאסיאן]

32:40 לשבור את ה-Mono-Repo?

• (חיים) להריץ את כל הטסטים - גם של צוותים אחרים - בכל Build, זה לא Scalable-י.
• ולכן, אם אין לך סוויטה של טסטים (Tests Suite), של הצוות שלך, שעוזרת לך לדפלט (Deploy) את ה-Microservice שלך, אתה נמצא באיזשהו סוג של מצב, שבסופו של דבר זה יתפוצץ.
• ושוב, אני חוזר לאותו Framework של End-to-End Tests שהיה מאוד מאוד מוצלח - יותר מדי מוצלח - וגרם לנו לזנוח Component ו-Unit Tests, ולקח לנו הרבה מאוד זמן לתקן את זה.

(אורי) זה Practice “שמגיע בחינם” אם מפצלים Repos בין הצוותים?

• (חיים) דרך אגב, אנחנו רצים ב-Mono-Repo, לפחות כל ה-Service-ים של ה-Backend רצים אצלנו ב-Mono-Repo.
• יש אנשים ששונאים את זה ומקללים אותי על זה . . . אבל יש לזה גם יתרונות.
• אנחנו עוד לא הגענו לנקודה ששוברים את ה-Mono-Repo - אבל יש כבר אנשים שמדברים על זה ורוצים את זה.

(רן) כן, ברמה טכנולוגית, כאילו, GitHub, GitLab - זה לא חוסם אתכם?

• (חיים) אנחנו עובדים ב-GitHub, וזה לא חוסם אותנו ב- Mono-Repo של כמה מיליוני שורות Kotlin.
• ה-IDE - כאילו, יש אנשים שטיפה מתלוננים על זה, אבל רוב הזמן זה בסדר
• או נסבל, או שהתרגלו . . .
• אני בטוח שזה יכול להיות יותר טוב.
• ויש לנו כלים שדואגים, לדוגמה, לעשות אנליזה לבאיזה מקומות נגעו בקוד, בשביל לעשות Triggering ל-Pipeline הנכון, של ה-Service הנכון שהשתנה
• וכלים שמתריעים על זה, אם מישהו נגע ביותר מ-Service אחד.
• כי זה בגדול, למעט מקרים קיצוניים - זה לא מצב תקין.

(רן) זה מאפשר לך, נגיד, לשנות קוד של ספרייה, ואחר כך לריץ את כל הטסטים שתלויים, Upstream, באותה ספרייה.

• (חיים) כן.

(אורי) אני זוכר את הוויכוח הזה, מ-Outbrain - כשבסופו של דבר, לא יודע, אני הבנתי שזה הופך לסוג של “ויכוח דתי”. אבל כשאתה מפרק אותו, בסוף - כל דרך שיש . . . לכל דרך יש יתרונות וחסרונות, ובסוף תצטרך לבנות כלים שיתגברו על החסרונות בדרך שבחרת. אמרנו לארכיטקטים: “תבחרו דרך, ותבנו את הכלים כדי לפצות על זה”, וזהו.

(רן) כן, אתה אומר “בין אם תבחרו Mono או Multi - בכל מקרה נצטרך לבנות כלים מסביב לזה”, אז יאללה, “נטיל מטבע”.

34:32 בעיות בזמן, במרחב ועם Conway's law

(רן) אוקיי, אנחנו ככה ממש כבר לקראת סיום. יש עוד איזה “סיפור צבעוני” אחד שהיית רוצה לחלוק?

• (חיים) אני חושב שהדבר אולי הכי מטופש שעשינו - והוא לא כזה דרמטי, אבל הוא עדיין מטופש - זה שבחרנו לשים את ה-Time-zone של ה-Database להיות PST.
• כי ה-Headquarters ב-Palo Alto, והלקוחות שלנו בארצות הברית.
• ואין לי מושג למה עשינו את זה - וזה מעצבן ומטריד כל פעם מחדש, כי זה לא הגיוני.
• זה לא הגיוני מבחינה סיסטמית (System)

(רן) כן, אני אגיד לך סוד - כשאני הייתי ב-Google, וזה לפני הרבה מאוד זמן, גם שם עשו את הטעות הזאת . . . . אבל שם אולי רוב העובדים גם חיו בקליפורניה. אבל עדיין, בתור אנשים בישראל זה כאילו, “מה?! WTF?” כאילו, יש לכם . . . “יש UTC, למה שלא תשתמשו בזה? מה נסגר?” אבל כן, מבחינתם, העולם נמצא בקליפורניה - “ושכולם יתיישרו לפינו”.

• (חיים) ויש עוד דבר, שלפי דעתי הוא אולי חומר לפרק שלם, אז אני אזכיר אותו רק במילה אחת . . .
• בעצם כאילו, מה שקורה זה שבגדול יש לנו מוצר אחד - בערך 40 Microservices, אבל שמשרתים מוצר אחד, אספקטים שונים שלו.
• ויש עוד Level של התייחסות של המוצר הזה, שבו יש סוגים של מוצרים.
• והרבה פעמים יש לנו Squd-ים Business-יים, שנועדים לקדם סוגים מסוימים של מוצרים - והם נוגעים שוב בכל ה-Service-ים האלה.
• וזה יוצר לנו איזו מטריצה מאוד מאוד מסובכת, בין Squad-ים ל-Team-ים
• כשה-Squad-ים מייצגים את הנושא ה-Business-י וה-Team-ים מייצגים את התוכן הטכני.
• וזה, לפי דעתי, בעיה מאוד מאוד קשה להתמודד איתה.

(אורי) גם ב-Outbrain . . .

• (חיים) . . . ואנחנו עושים הרבה מאוד מאמצים בשביל להצליח לשמר איזשהו Balance - אבל זה ממש ממש לא פשוט.
• הזנחה של כל אחד מהכיוונים - זה קטסטרופה.
• וזה כמו ללכת בין הטיפות - שאתה לא באמת יכול לנצח כאן.

(אורי) זו בעיה שהיא בין “ארגונית” ל”תרבותית” - כי השורש של . . . מה קורה עם ה-Service? ה-Service שייך לצוות, והצוות מרגיש המון המון Ownership על ה-Service הזה - ונוצר מצב שבעצם ה-Service-ים . . . הארכיטקטורה שומרת על חוק Conway, אוקיי? והיא נשמרת ככה עם המבנה הארגוני. ולשבור את זה - זה לשבור.

וה-Squad-ים הולכים לפי ה-Business - וזה לא מתיישר, וזו בעיה.

(רן) טוב, אז עשית לעצמך Build-up לפרק הבא - אז הישארו איתנו, עם ה-Cliff-hanger הזה, עד שנפתור את כל בעיות עולם התוכנה!

38:55 כתוביות

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

(אורי) What’s Next? . . .

• (חיים) אז כמובן שאנחנו מגייסים - אין תמיד המון משרות פתוחות, כי אנחנו מנסים לשמור על איזשהו Budget ולהגדיל את ה-Capacity ואת הריווחיות של החברה, על בסיס אותו Budget.
• אבל בתוך ה-Framework הזה, אנחנו עדיין קצת גדלים, וגם לפעמים יש אנשים שעוזבים ואז צריך לחפש אנשים במקומם.
• ואני מקווה שתנאי השוק יבשילו, ושנוכל להגיע למצב שרצינו ושאנחנו כל כך רוצים להגיע אליו - שזו הנפקה.

(רן) מבחינה טכנולוגית, הזכרת קצת. הזכרת MySQL ו-JVM - מה עוד יש לך לספר על זה? Kotlin הזכרת . . .

• (חיים) אנחנו בעצם מפתחים את ה-Service-ים של ה-Backend ב-Kotlin, מעל JVM.
• את הקוד ה-Frontend-י שלנו אנחנו כותבים ב-TypeScript - יש לנו Angular ויש לנו גם React.
• כשזה מתחלק בין סוגי האפליקציות.
• ויש לנו גם Stack מאוד מורכב של Data Engineering ושל BI
• אנחנו עושים הרבה מאוד אנליזות על ה-Data, ויש שם הרבה מאוד מרכיבים שאוספים ועושים אנליזות על כל הדברים.
• אני חושב שיש כרגע משרה פתוחה של ראש צוות ב-Data Engineering.

(רן) אוקיי, ואמרת איפה אתם יושבים?

• (חיים) אה - והרבה מאוד תוכניות לגבי Machine Learning, כי כל הנושא של LLM הוא מאוד מאוד רלוונטי לעולם של ביטוח.

(רן) איפה אתם בארץ? הזכרת?

• (חיים) אנחנו נמצאים בכפר סבא, ה-Headquarters ב-Palo Alto.
• יש לנו עוד מרכז ב-Waltham, שזה על יד Boston.

אוקיי, טוב - אז תודה חיים! תודה רבה.

האזנה נעימה ותודה רבה לעופר פורר על התמלול!