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

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


פרק 474 של רברס עם פלטפורמה, שהוקלט ב-9 ביולי 2024. אורי ורן מארחים במזגן את שי דוידסון מחברת Lemonade כדי לדבר על פרויקט מעניין שהוא עבד עליו שנקרא UniClient - איך הוא נולד, מה עושים איתו ולמי זה עלול להתאים. השיחה היום היא סביב עולם ה-Frontend ועולם התשתיות של ה-Frontend.
00:51 קצת על שי ועל Lemonade
(רן) שי, אני אתכבד להגיד שפעם הצגת אצלנו בכנס והייתה לך הרצאה קסומה ומעניינת שזכתה להמון פופולריות, אז תודה על זה. מי שלא ראה - מוזמנים לחפש אותה ב-YouTube שלנו, רק תזכיר לי את השם  . . . 

• (שי) יש שתיים . . .  יש את In a galaxy far, far away [A procedural generation tale] ואת ה-Board Games Frontend Joyride, על פיתוח משחקי קופסה באמצעות טכנולוגית Web.

(אורי) זוכר באיזה שנים של הכנס? . . . 

• (שי) 2019 ו-2021.

(אורי) רק אומר כמה שנים אנחנו עושים את הכנסים האלה . . . . [גם על זה יש הרצאה . . . The Reversim Story / Ran Tavory & Ori Lahav].(רן) אז לגמרי, לגמרי . . .  הרצאות שאני ממש זוכר שהייתי [בהן], לפחות בזאת עם הגלקסיות, והיה ממש כיף - אז מומלץ, לכו צפו.אבל עכשיו, שנייה לפני זה… קרא עוד

[קישור לקובץ mp3]
פרק 473 של רברס עם פלטפורמה, שהוקלט ב-27 ביוני 2024 - אורי ורן מארחים את הילה פוקס מ-Forter, כדי לדבר על “איך חושבים מוצרית” לאנשי טכנולוגיה או - איך אנשי טכנולוגיה חושבים (יכולים לחשוב? עלולים לחשוב?) מוצרית.00:40 הילה והצוות המועצם(רן) אז קצת לפני שנצלול בפנים, הילה - בואי נכיר אותך קצת . . . אז קצת עלייך?

• (הילה) אז אני הילה - אני מובילה טכנולוגית, עם מעל עשר שנות ניסיון.
• עבדתי ב-Intel וב-Fiverr, וגם בחברה בשם Augury, לפעמים קצת פחות מוכרת . . . 
• ועכשיו אני Staff Engineer ב-Forter - כש-”Staff Engineer” זה “Tech Lead”, אפשר לומר.

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

• (הילה) נכון, יפה . . . . כן, זו חברה חיפאית, מי בכלל זוכר, מי יודע?

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

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

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

• (הילה) אני חושבת ש . . .  קודם כל, גם ב-Fiverr עובדים כזה מאוד Oriented ללקוחות, כן?
• ועבדתי בצוות Web-י - והיה לנו איש מוצר שהיה ביחד עם הצוות, ואפשר להגיד ששם התהליך קצת התחיל.
• באמת להבין - מה משפיע על הלקוח? מתי זה משפיע על הלקוח?
• אבל אני חושבת שה-Ramp-up האמיתי שלי מסביב לזה היה ב-Augury.
• כש-Augury האמת היא קצת כזה . . . חברה שבשביל אנשי-מוצר היא קצת כזה “חלום רטוב”, כן?
• הם עובדים שם כזה בצורה נורא הוליסטית, יחסית לפרקטיקות של עבודה של אנשי-מוצר.
• אם אתם מכירים את המונח הזה, “Empowered PM” - שמגיע מתוך הדיונים והשיחות של Marty Cagan והמתודולוגיות שהוא מוביל [Product management theater | Marty Cagan (Silicon Valley Product Group)].
• אז בעצם בגלל שהם נורא מאמינים גם ב-”Empowered PMs” ובלתת הרבה כוח לאנשי מוצר להוביל את הצוותים שלהם, זה גם נורא התחבר לזה שהאנשים הטכנולוגיים צריכים להיות חלק מזה בסופו של דבר.
• (אורי) גם הם Empowered . . .
• (הילה) נכון . . . בסופו של דבר, מ-Empowered PM אתה עובר גם ל-Empowered Team - ואיך אתה עושה את זה?
• קודם כל על ידי זה שכולם ביחד יכולים לשרת את אותה מטרה, ויש להם את כל ה-Skill-set שהם יכולים.
• כמו שיש לנו Squad-ים - צוותים אוטונומיים, נכון? אז יש לנו גם בעצם יכולת להיות Empowered מבחינת ה-Business, נכון?

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

• (הילה) אז זה . . .  היתה תקופה ב-Augury . . .

(אורי) איך זה נראה ביום-יום, מה קרה?

• (הילה) אני אספר איפה אני התחלתי - איפה זה התחיל לפגוש אותי יותר ויותר.
• היתה תקופה שבה Augury בעצם עברה להיות מחברת “מוצר אחד” לחברת Portfolio - והמוצר החדש שרצו להקים הגיע אליי לצוות.
• והיתה לנו המון עבודה משותפת לי ולאיש-מוצר, ו...

(אורי) כשאת כבר היית Squad-Lead?

• (הילה) הייתי Squad-Lead כבר בצוות, כן.
• ובעצם, אחד מהדברים שהיו הכי קריטיים לנו לעשות, כשמביאים מוצר חדש, זה לעשות MVP ו-to-Scope-it 
• וכמה שיותר להוריד תוכן שלא רלוונטי, בשביל להתחיל ולרוץ וללמוד מהר.
• ושם התחיל מאוד מאוד חזק הפינג-פונג בין האתגרים הטכנולוגיים וכמה אנחנו באמת רוצים להשקיע עכשיו או לא עכשיו - איזה Requirements אנחנו באמת רוצים למלא או לא למלא, כן?
• ואני חושבת שפה זו נקודת החיבור הכי חזקה, בין Product ל-Engineering
• וגם איפה שעולה החשיבה המוצרית ביחד.

(אורי) מה שאת אומרת זה בעצם שלצורך בניית ה-MVP הזה, היינו צריכים, אני - את, כן . . . - וה-Product  Manager- כל אחד היה צריך להבין קצת ב-Domain של השני, כדי שתהיו מוכנים ותוכלו בעצם “לקלף את הבצל הזה” ולהגיע לליבה שלו, ולהבין בעצם מה אתם מקלפים . . . זאת אומרת, הוא היה צריך להבין מה קשה טכנולוגיתומה לוקח יותר זמן, ואת היית צריכה להבין מה חשוב מוצרית.

• (הילה) נכון, נכון - מה בעצם אנחנו מנסים לבדוק בהתחלה? מה חשוב לנו לבדוק בהתחלה? איפה אנחנו יכולים להתפשר? כן . . . 
• והיו הרבה פשרות שעשינו ברמה המוצרית - ברמה טכנולוגית, סליחה.
• היו הרבה מאוד פשרות בעולם הזה, היו הרבה דברים שעשינו כזה Hot Fixes, Quick & Dirty - רק בשביל שנוכל להתחיל לראות את זה במערכת.
• (אורי)למשל, לא חושבים על Scale בהתחלה . . . 
• (הילה) לא, לא חושבים על Scale . . .  זה לא היה בכיוון שלנו.
• אחר כך, אחרי שה-MVP הצליח, ובעצם היה לנו כזה “Pilot” - לקוח ראשון, לקוח שני, לקוח שלישי, והתחילו לדבר על איך זה משתלב באמת כ-Portfolio, שני מוצרים שנותנים ללקוחות - פתאום התחלנו לחשוב על איך אנחנו בונים לזה Vision ולאן אנחנו לוקחים את זה קדימה.
• ואיך זה מתחבר ב-UI, וב-Backend, מוצרית וטכנולוגית . . . 

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

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

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

• (הילה) כן, כי זו בעצם הנקודת-חיתוך שלי ושל כל הצוות - לא עשיתי את זה מתוך היותי Squad Lead - כל הצוות נמצא בדיונים, ובעצם מזה שמאתגרים אותנו כל הזמן לעשות את ה-Brainstorm ביחד עם האנשי-מוצר, זה מכניס אותנו נורא עמוק ל-Context.
• ובגלל שאנחנו מקבלים אתגרים נורא גדולים, אנחנו חייבים לעשות את ה-Back and Forth עם האנשי-מוצר, בשביל לדייק אותם למשהו שאפשר לדלבר (To Deliver) בזמן סביר, ושעדיין יביא את הערך.
• ובשביל הנקודות האלה - של היצירתיות, של איפה שאני רוצה גם להתעקש, כ-Engineering, “פה לא ופה כן” - אני צריכה להבין איפה כדאי לי דווקא לשחרר ואיפה לא.
• מתוך הבנה של איך המערכת בנויה - גם טכנולוגית וגם איך המוצר ומה חשוב ואיך זה מרגיש ללקוחות.
• ואז זה יוצר שפה משותפת וממש אינטראקציה, “חיכוך חיובי”.

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

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

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

• (הילה) זה Skill-נרכש . . . 

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

• [Never Split the Difference: Negotiating As If Your Life Depended On It]

• (הילה) מסכימה.

(אורי) והא’-ב' של משא ומתן זה “תבין מה חשוב לצד השני” - וזו בעצם החשיבה המוצרית.

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

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

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

(אורי) דרך אגב, צריך להכין את זה - “כי למה דווקא זה? למה ה-Roadmap נראה ככה?” - כשזה בא מ-Engineering, בואו נודה על האמת, זו שאלה מעצבנת . . . 

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

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

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

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

• (הילה) נכון.

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

• (הילה) אז זה קצת משתנה כנראה בתפקיד . . . לאנשי פיתוח, הייתי אומרת, אולי זה אפילו לא כזה קריטי - באמת לתפוס אותם בזמן שהם פנויים לזה, ולהתחיל להתעניין ולשאול שאלות.
• זה יכול להיות לפני Sprint Planning, אם זה על איזה משימות נכנסות ולמה.
• או אחרי שה-Roadmap מגיע - בואו נשב על זה ונבין יותר לעומק.
• בדרך כלל מציגים את זה, נגיד, לכל הקבוצה או לכל המחלקה - ואז זה כזה מאוד ב-High-level, אז זה מקום טוב.
• למובילים טכנולוגיים הייתי בכלל מציעה להבין איך הם, אפשר לומר “מסתננים” - עוד לפני שהדברים האלה אפויים.
• אם לבקש להיות חלק מה-Planning - לשבת בחדר, אפילו לא בשביל לקבל החלטות 
• [למה לא?]
• באמת שאין לי כוח-וטו בחדר של ה-Planning, כי מי שאחראי על זה, זה לצורך העניין ה-Team-Lead והאשת-מוצר - אבל אני יכולה לבוא לתת את ה-Impact שלי ואת ה-Input  שלי, ולעשות ככה השפעה על מה שקורה, מתוך הידע שלי.

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

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

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

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

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

• (הילה) בטח. כאילו, זה קורה כל הזמן . . .
• פחות עולה לי דוגמא  לראש, נגיד, מסביב למוצר, למשהו שהתעכב, אבל תמיד כזה, בתהליך של עשיית Design-ים, תמיד זה כזה “למה זה כל כך הרבה זמן?! למה זה כל כך הרבה שבועות?!”
• והפרקטיקה שאני מאוד אוהבת, זה פשוט להיות מאוד Details-Oriented, ולצאת ממש מ-Design עם פירוק משימות מאוד מאוד ברור, עם ריאליזציה (Realization) מאוד ברורה מסביב לכל דבר.
• לבוא ולהגיד “זה חודש” - זה לא מספיק טוב.
• לבוא ולהגיד “הנה כל המשימות שפרטתי - פה יש לי כן Refactor קטן, אבל הוא רק שלושה ימים, וכל שאר הדברים הם ממש . . .”
• “זה עונה ל-Requirement הזה, וזה עונה ל-Requirement הזה”, כאילו...

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

• (הילה) אני מסכימה. אני חושבת שיש גם הרבה דברים ברמה הטכנית, שאנחנו קצת יכולים לפשט ולהסביר יותר את ההשפעה שלהם על המערכת, ופחות באמת את הדבר הטכני.
• נגיד, לא מזמן הגעתי לאיזושהי שיחה, ומישהו התחיל להסביר - זה לא היו אנשי מוצר, אלו היו אנליסטים בחברה - אבל כזה, “כן, הבעיה פה” . . . . 
• אתם יכולים להגיד להם ש”הבעיה היא ב-WebSocket!” - וכאילו, מפה ועד לזה שמישהו מבין מה ההשפעה, זה כמה קפיצות, נכון?
• אם אפשר לבוא ולפשט את זה . . . 
• (אורי) מה ההשפעה על הלקוח או על המוצר?
• (הילה) כן, על המוצר - אבל אם פתאום, נגיד, נשנה את ההסבר, ונבוא ונגיד “תראו, למערכת יש כמה חלקים נעים - בעצם זו פעולה שקורית א-סינכרונית” . . . 
• וניסינו להסביר להם למה ה-Event לא חוזר ל-UI, כן?
• אז המערכת שלנו מורכבת מכמה חלקים נעים - ומה שקורה זה שחלק אחד שולח הודעה לחלק השני, אבל משום מה החלק השני לא מחזיר הודעה בחזרה לחלק הראשון,
• עכשיו, זה הרבה יותר פשוט, כן?
• עכשיו, מן הסתם שבשיחה גם הסברתי מה זה כל חלק ומה זה כל קומפוננטה (Component) כזאת, בשפה שהן גם מכירות, כן?
• אז זה הרבה יותר מקרב והרבה יותר מחבר - במקום לדבר בשפה שלא מבינים, ואז הם במקום כזה  של תסכול, אף אחד לא מבין את אף אחד.

19:37 איש המוצר התאום(רן) יש לך איש מוצר, נגיד, שהוא “התאום שלך”? איש או אשת-מוצר, או שזה ככה מול כולם? זאת אומרת, מה ה-Working Set שלך?

• (הילה) אז אני יודעת שיש הרבה Setups בהרבה חברות שונות, אבל בשלוש החברות האחרונות שאני עבדתי בהן היה איש-מוצר או אשת-מוצר בתוך הצוות.
• זאת אומרת שזה כזה ממש ה-Go-To - ואנחנו Go-To‘s, זה אחד של השני, שזה Setup שאני אישית מאוד מאוד מאמינה בו ורואה בו את ההצלחה.
• אבל אולי גם אני מדברת מתוך זה שלא חוויתי גם את המשהו האחר - אולי זה טוב, אבל אני...

(רן) כן, זאת אומרת, אז בדרך כלל יש איזשהו Counterpart אחד - יש איזשהו איש-מוצר ספציפי שיש... יש לך איזשהו שגרת עבודה איתן? זאת אומרת, One-on-Ones, או לא יודע - ארוחת צהריים מדי פעם? או דברים כאלה, זה הכל כזה “מה שיוצא, יוצא?”

• (הילה) לא, זה לא “מה שיוצא, יוצא”  . . . אנחנו - לצורך העניין, יש לנו Cadence כזה: 
• ה-Leads של הצוות, שזה אני כמובילה טכנולוגית, ה-Team Lead וה-Product - מעבר לזה שאת ה-Sprint Planning אנחנו גם עושים ביחד, בתכנון הרבעוני יש לי גם חלק מאוד משמעותי שם.
• מן הסתם, כשיש כזה “בירות על הגג”, או כשעושים משהו ל-Fun - כולנו נמצאים שם, כן? אנחנו צוות אחד.

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

• (הילה) על מה הם צריכים לעשות בשביל להגיע ל-Level הבא?

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

• (הילה) אז אני לא יודעת מה ה-Responsibilities שלהם, בתוך ה-Job Description בדיוק.
• אני כן יודעת שאנשי מוצר לרוב נוטים להיות מאוד מפוקסים על ה-Business Metrics שמגיעים אליהם, שנגזרים מתוך ה-KPIs של החברה.
• אז יש את המטריקות שיש לנו ברמת החברה - ובדרך כלל כל חלק בארגון גוזר את זה אליו, עד שגוזרים את זה לאט לאט לתוך כל הצוותים.
• או KPIs או OKRs, שזה Objectives and Key Results או Key Performance Indicators
• אז זה כאילו, זה הדבר שעליו בסופו של דבר הם נמדדים.
• הם צריכים לאפיין על מה הם רוצים להשפיע ואיך זה מתחבר ל-Business - ובסופו של דבר זה נמדד על זה שבאמת הצלחנו לעשות את זה.

(רן) הבנתי, אז את ה-KPIs או את ה-OKRs של מנהלת המוצר שמולה את עובדת - אותם את מכירה.

• (הילה) אני מכירה - ומעבר “למכירה”. אנחנו צריכים - אשת המוצר אחראית על זה יותר ממני, כן? היא אחראית על זה האמת לבד, אבל אני צריכה להכיר, בעצם, איך כל משימה מתקשרת ל-KPIs האלה, כן?
• עכשיו אני גם אבוא ואחמיר ואומר - זה קצת לא מה ששאלת, אבל I'll go rogue - שכשאנשי המוצר עושים את זה, יש נקודה שאנחנו -כאנשים טכנולוגיים - מתי שאנחנו רוצים להשפיע ולשנות ולהביא, לא יודעת מה, אולי Refactor-ים גדולים או דברים שאמורים להשפיע על המערכת - אנחנו צריכים גם לדעת איך לקשר אותם ל-KPIs, כן?
• כאנשים טכנולוגיים, אם נגיד אני רוצה להכניס Refactor שעכשיו ייקח חודש או חודש וחצי, כי אני יודעת ש”וואו, איך זה חשוב, איך זה יעבוד” . . . 
• אם אני לא אצליח להסביר בשפה של אנשי ה-Product למה זה מספיק חשוב, יהיה לי מאוד קשה לדחוף את זה קדימה.

(רן) כן, למעשה הקדמת את השאלה . . .  

• (הילה) אה, יפה, אוקיי...

23:27 דילמה, Buy-In, חשיבה מוצרית ופול-גז בניוטרל(רן) כן, אבל בעצם הרבה פעמים כמפתחים, יש לנו את הדילמה של “אנחנו יודעים שצריך לעשות פה איזשהו תיקון - איזשהו תיקון ארכיטקטוני, איזשהו Refactor - אבל אנחנו לא יודעים איך למכור את זה לאנשי המוצר”, במובן שיתעדפו את זה, שיהיה לנו מספיק זמן לעבוד על זה “בשקט” - ואולי גם לעזור לנו להבין מה חשוב מתוך זה ומה לא,כי גם בכל דבר כזה יש אולי 80% חשוב שלוקח 20% מהזמן, ו-20% שלא - ולוקח את ה-80% האחרים.אז איך באמת . . .  קצת התחלת לענות, אבל באמת - איך מקבלים את ה-Buy-In הזה - מצוות המוצר, מאנשי המוצר - כדי לעשות את “ה-Refactor הזה”, שמבחינתם זה כאילו, זה “פול-גז בניוטרל”, הרבה פעמים? . . . או שלפחות ככה הם רואים את זה, כמובן.

• (הילה) נכון. בגלל זה אני התחלתי בלהגיד שאנחנו צריכים . . .שוב, אם זו עבודה משמעותית
• אני לא מדברת על איזה עבודה של יומיים - שאז אפשר תמיד, כנראה, לבוא ולהכניס בדרך כזו או אחרת.
• אבל אם זאת עבודה משמעותית - באמת לחבר את זה ל-KPIs או ל-Blocker-ים משמעותיים.
• לא יודעת, אולי תגידו “זה Pre-requisite למשימה מאוד משמעותית שרוצים לעשות ה-Product” - שמתקשר לדבר הזה.
• אולי מה שאנחנו רוצים זה ה-Enable ל-Build for Scale, שאנחנו צריכים שהמוצר שלנו יגיע לשם.
• אנחנו רוצים להבין איך הדברים האלה מתקשרים לצרכים Business-יים.

(רן) ודרך אגב - ואם זה לא, אז אולי לא צריך את זה . . .

• (הילה) לגמרי - אבל אני רוצה לתת פה סייג, שככל שאני מדברת על הנושא יותר, אני חושבת ש...
• כאילו, אוקיי - שני סייגים . . . 
• אחד - נושא ה-Velocity, שמאוד מאוד קשה למדוד ונורא מורכב.
• וכמו שאמרתי לכם - “Repository Face” על האשת-מוצר אצלנו.
• כמובן שכולם רוצים שהאנשים - שהמפתחים - יזוזו מהר, אבל קשה להביא Impact מאוד משמעותי בזה הרבה מהזמן.
• זה דבר אחד שאני רוצה לשים בצד - אז מאוד קשה להסביר את זה טוב.
• ויש שם את ה-DORA Metrics ויש הרבה דרכים לבוא ולנסות לפרמל (To Formalize) את זה ולהביא את זה מתוך ה-Engineering כמשהו שאנחנו רוצים לקחת קדימה.
• והדבר השני שרציתי להגיד שהוא Outlier - לפי דעתי להכל - זה “Developer Happiness".
• [בשביל זה יש את okify, לא? Your feelings are more important than production]
• כן? כאילו, אנחנו צריכים לבוא ולהסביר, שלפעמים יש דברים שאין מה לעשות - אנחנו לא יכולים שמפתחים ישבו מתוסכלים ויעבדו בדרכים שפשוט גורמות להם תסכול כל היום . . .
• זה מוריד מוטיבציה - וגם זה קשור ל-Business, כן? 
• אף אחד לא רוצה Attrition שלילי, חיובי, איך זה נקרא? - שאנשים יעזבו את החברה.
• אז פה דווקא אני מוצאת את עצמי באה ואומרת “לא - אבל זה נורא חשוב, מזה ל-Developers אכפת”
• “פה כן לבוא ולתעדף דברים כאלה” - גם אם זה לא על KPI.

(אורי) וזה עובר את “Repository Face”?

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

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

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

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

• (הילה) מסכימה מאוד.

(אורי) . . . והדבר השני הוא להגיד “קו בחול” - “20% מהזמן של המפתחים הולך לדברים שהם לא מקדמים את ה-Business”. הם מקדמים את הטכנולוגיה.

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

(אורי) מה יותר חשוב? . . .

• (הילה) לא, אולי לא ספציפית לאנשי-מוצר, אבל כאילו - מגיעים בסופו של דבר לנקודה הזאת, מתוך מקום שרוצים קצת להוריד את ה-Friction של “האם כן זה או לא זה” ו-”כן קשור ל-Business או לא”.
• ולתת ל-Engineering איזשהו Bucket כזה.
• זה לא כזה “תלכו תהנו, תתפרעו”, נכון? צריך גם שם לעשות ריאליזציה מאוד חזקה.
• ופה כבר נכנס זה שאנחנו - בתור אנשים טכנולוגיים - צריכים בכלל Skill-set של אנשי מוצר, בשביל לנהל את ה-Backlog הזה.
• פתאום אנחנו עושים Prioritization, פתאום אנחנו מנסים להבין מה באמת עושה Impact . . .

(אורי) אני אגיד לך - זה כמו הילדים שלי וממתקים: זה אף פעם לא מספיק להם . . . 

• (הילה) נכון - גם ל-Product לא מספיק . . .  לאף אחד לא מספיק.

(אורי) נכון - אז כאילו, בסוף צריך לנהל עדיפויות בכל דבר.

• (הילה) נכון, אבל זה חלק מזה - לפתח את החשיבה המוצרית זה לא רק להבין את המוצר.
• זה להבין קצת את המתודולוגיות - וזה ישרת אותנו מאוד מאוד חזק, במקומות האלה של הניהול Technical Backlog, שאליו אנחנו רוצים.
• כי גם מתוך ה-Technical Backlog, אנחנו רוצים להביא את ה”הכי הרבה Impact”, מתוך איך שאנחנו מודדים את זה.
• ובין אם זה Refactor גדול או בין אם זה באמת להזיז גם מחט business-ית - הכל Fair.

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

• (הילה) אני בטוחה שהיא תשמח לשמוע שהשתמשתי ב-“Repository Face” כמה פעמים . . . 

(אורי)  . . . והיא לא שמעה על זה בכלל, זה רק מאחורי הגריל . . . 

• (הילה) לא, היא יודעת שקוראים לה “Repository Face” - היא צוחקת על זה בעצמה.
• (רן) “מוקדש באהבה” . . . 

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

• (הילה) אז אני יכולה להגיד שנגיד ב-Augury זה היה מאוד מאוד סטנדרטי.
• ברמת שמפתחים טסים עם אנשי-מוצר - לעשות סיור במפעלים, לפגוש לקוחות . . . 
• במפעלים - כי זה בעצם הלקוחות שיש ב-Augury.
• שיחות עם לקוחות - להבין, לראות, לא יודעת . . . . 
• לפעמים זה גם לא אפילו לעלות לשיחה עם האנשי-מוצר - יש המון כזה הקלטות - ב-Gong או איזה כלי שלא משתמשים - אז גם אפשר משם לדלות הרבה מאוד מידע ולקבל הרגשה.
• וגם ב-Forter - יש לנו המון אינטרקציות עם לקוחות, אז אנחנו גם עולים עם הלקוחות לשיחות, וגם בשיחות Discovery, מתי שאפשר.
• אנחנו באמת מנסים כזה לבוא ולהצטרף.
• כן, זה תלוי ב-Ballance - אבל אישית אני מוצאת בזה הרבה מאוד ערך, כי לפעמים לקבל את הכל, כזה, בלי פילטרים - שהם אולי Biased כבר על ידי אנשים קיימים.
• פתאום לשאוב את זה לבד - “פעם ב-”, לא כל שיחה.
• לא יודעת, “פעם ברבעון” - שכל מפתח יעלה לשיחה עם לקוח, נשמע לי כמו משהו מדהים.

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

• (הילה) . . . כן, CS ו . . .  [Customer Success]

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

• (הילה) הם Stakeholder-ים, חד-משמעית.
• זה כאילו - אפשר לבוא ולדבר גם קצת על ההבדל בין B2C ל-B2B . . . 
• אבל ב-B2B הם בעצם באמת מייצגים לנו את הלקוח בצורה פנימית.
• וגם ב-Forter - חברת B2B - ו-CS הם Stakeholder-ים מאוד משמעותיים בשביל להבין

(רן) "CS” זה “Customer Success” . . .

• (הילה) “CS” זה “Customer Success” ו-”B2B” זה “Business to Business”, ו-”B2C” זה “Business to Customer” . . . כן.

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

• (הילה) מדי? . . .

(אורי) לא . . . . וכשזה קורה, כש”הקסם” הזה קורה - “ה-KPI-ים עפים קדימה”.איך זה קורה? זה פשוט - זה כאילו, זה גם בן אדם מיוחד, אוקיי . . . . שמסוגל לקחת דברים מקצה לקצה, גם מבחינת יכולות טכניות וגם מבחינה מחשבתית. הוא עבד על איזושהי מערכת, פיתח אותה, פיתח את ה... מבין טוב מה ה-KPI-ים שלו - ועכשיו המערכת יצאה לשוק, והוא שואל את עצמו “אוקיי - למה לא מצטרפים עוד לקוחות?”.עכשיו, הוא לא הולך ל-PM . . . ובכלל, רוב המפתחים פיתחו - והם אפילו לא ישאלו את ה-PM, הם אפילו לא יסתכלו על המטריקות (Metrics), להסתכל אם הצטרפו עוד לקוחות או לא . . . מי שיש לו קצת חשיבה-מוצרית יסתכל, ישאל את השאלה “למה לא מצטרפים עוד לקוחות?”.אז הוא לא - במקרה שלו, הוא לא הלך ל-PM לשאול. הוא הלך ל-Customer Success, ל-Account Management. לקח את הכיסא, ישב לידם - חצי יום - אמר “למה אתם לא משתמשים? למה לקוחות האלה ואלה ואלה שלכם . . .” - שהם מה שנקרא “ה-Ideal Customer” למוצר שלו - “למה הם לא משתמשים?”.אז יש כל מיני תשובות . . . חלק מהתשובות לגיטימיות, חלק לא. כשהוא מגיע ושואל את השאלה "למה לא משתמשים?” אז זה מגרד למישהו בראש, והוא אומר “רגע, באמת למה לא?”. ואז הוא אומר לו “אוקיי, אז הנה, ככה תשתמש”. ואז מנסים, ומזה הוא מקבל פידבקים - והוא רץ חזרה למערכת ומתקן, וחוזר עם משהו יותר טוב . . .

• (הילה) אם לבן-אדם טכנולוגי - כאילו, בכללי -  זה יהיה “PM נורא טכנולוגי” או “טכנולוגי נורא מוצרי”, זה לא משנה מה . . . המולטי-דיסציפלינריות הזאת מאפשרת לנו להוריד הרבה Feedback Loops, לרוץ מאוד מהר . . .

(אורי) בדיוק . . . 

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

(אורי) מפתח להצלחה, או להעלות KPI, זה פשוט היכולת לטעות מספיק מהר . . .

• (הילה) מסכימה . . . 

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

• (הילה) היום יש לך ChatGPT . . .
• איש מוצר מוציא קוד ב . . אתה יודע.
• [כן יודע - 472 Bumpers 83 - Nostalgia]

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

• (הילה) כן,

35:37 תצאו מהקופסא(רן) אז אוקיי - אז זאת היתה שיחה מעניינת, ואני חושב שאולי ה-Take-Away שלי - ואני מקווה שגם של אחרים מפה - זה “תצאו רגע מהקופסא שלכם”: אתם באמת רוצים לעשות Impact, תשאלו את האיש-מוצר שעומד לידכם, תשאלו את ה-Customer Success Manager  שנמצא לידכם . . . (אורי) תעניינו - במוצר ובלקוח.(רן) . . . מה הם עושים? מה האתגרים שלהם? מה הלקוח רוצה? . . . ואתם תגלו מהר מאוד, שלכם כנראה יש יכולת מאוד מאוד גדולה להשפיע לחיוב גם על המטריקות (Metrics) שלו - אבל בסופו של דבר גם על שלכם, ולהיות Happy-Happy, כמו שמפתחים אוהבים להיות.תודה רבה! איזה כיף.

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

[קישור לקובץ mp3] פרק מספר 472 של רברס עם פלטפורמה - באמפרס מספר 83, אחרי כמעט שנה של בצורת. רן, דותן ואלון עם סדרה של קצרצרים שתפסו את תשומת הלב בתקופה האחרונה - בלוגים מעניינים, כלים ב-Open Source, כל מיני Utilities למפתחים, Database-ים, שירותים, או סתם דברים שיכולים לעניין אותנו.


01:10 מבוא(רן) הפעם, בגלל שהרבה הרבה זמן לא הקלטנו , חשבנו לעשות פרק קצת שונה - פרק של נוסלטגיה. פרק שבו אנחנו ככה קצת מסתכלים אחורה, ובאים ומרימים לדברים שנראה שתפסו - ואולי גם קצת מורידים לדברים שנראה לנו שלא תפסו. אז ככה, לגמרי באופן אקראי, הלכנו והסתכלנו על הפרקים הישנים יותר, וכל אחד מאיתנו דג משם דברים שנראו לו מעניינים בקטגוריות השונות.אה - ו-Kudos על האפקטים ל-Riverside . . . .
02:30 רן(רן) אז ככה, הלכתי ואספתי ממש באופן די אקראי, דברים שראיתי - שאני או דותן או אלון, אני כבר לא זוכר מי המליץ  עליהם, ונראה לי שתפסו - לפחות אצלי. דברים שאני נשארתי איתם.

• הראשון שבחרתי זה iTerm והשימוש ב-Z shell - דבר ראשון כשאני מקבל Mac חדש זה מתקין עליו iTerm, ככה גיליתי . . . 
• ניסיתי גם אחרים, זאת אומרת חוץ מהטרמינל ה-Default-י של Mac, שקיים שם תמיד.
• יש עוד אחד, על מה דיברנו? . . . דיברנו על עוד איזשהו אחד שיצא לו מזמן, שאני דווקא פחות אהבתי, זוכרים איך קוראים לו? Warp!, נזכרתי.
• (אלון) שכתוב ב-Rust ,יש לציין . . .
• (רן) . . . והוא גם הומלץ פה בפודקאסט - זאת אומרת, מה זה “הומלץ”? הבחנו בו, ואני ניסיתי אותו במשך לפחות איזה חודש, ובסוף פחות התחברתי
• אבל האמת היא שהגרסה האחרונה של iTerm מאמצת ממנו פיצ'רים, ככה ראיתי - התקנתי לא מזמן את iTerm, והדמיון מתחיל ככה לעלות, אז כנראה שהיו שם כמה פיצ'רים נחמדים.
• אז Anyway, זה iTerm ו-Z shell, ו-Oh My Zsh - זה אחד הדברים הוותיקים שאני מתקין כמעט בתור דבר ראשון ב-Mac.
• אבל דותן, הבחנתי שאתה דווקא מעדיף את Fish  . . . 
• (דותן) כן . . .  אני חייב להגיד קודם כל בנושא הטרמינלים, שאני די בטוח שזו פונקציה הפוכה לגיל . . . . ככל שאתה יותר צעיר, ככה אתה אוהב טרמינלים יותר “מודרניים”, כמו Warp, וככל שאתה יותר זקן, אין לך כוח לשטויות האלה . . . 
• (רן) כן, כן . . . . אז למשל, אחד הפיצ'רים החדשים ב-iTerm החדש שהתקנתי זה שכשאתה עושה דאבל-קליק,  אז במקום לעשות Select - כאילו, במקום לעשות Copy אוטומטית - הוא מציע לך איזשהו “משהו אינטליגנטי” . . .
• וזה עיצבן אותי, אז מיד כיביתי את זה  . . . 
• אז כן, בקיצור, אני חוזר לפיצ'רים הבסיסיים, מה שאני כבר רגיל . . .  אולי זה עניין של הרגל, אולי זה סתם עניין של פשטות, אבל כן, לגמרי . . .
• (דותן) זה גם יכול להיות מכיל - אני למשל עכשיו עשיתי Setup ל-Mac חדש, ובפעם הראשונה לא ישבתי ועשיתי את” הטקס” של להתקין את כל התוכנות שאני רוצה, ולקחת את ה-dotfiles וכל הדברים האלה, קנפוגים על קנפוגים (Configurations) . . . פשוט לא עשיתי שום דבר מזה.
• לקחתי איזה שתי תוכנות בסיסיות שאני רגיל - וזהו.
• אמרתי ככל שזה יגיע, אני אבוא ואני אקנפג את הדברים, כאילו בשיטה “לא מתוחכמת”.
• כי פשוט נמאס לי . . .
• והאמת שזה עושה איזשהו משהו טוב, כי אז יש . . . אחד הדברים השנואים עליי דווקא במהלך עם השנים, זה Z shell - לבוא ולקנפג אותה עם Oh My Zsh וכל ה-Plug-in-ים, שזה יכול להיות טקס מייגע, למרות שיש לך כבר את כל הקונפיגורציות.
• ומה ששמתי לב הוא שאחרי הקונפיגורציות, ה-Terminal שלך הוא איטי . . . - בגלל שזה Z shell וכל מיני  כאלה.
• אז אמרתי, טוב, זה הזדמנות לתת ל-Fish ניסיון, ובגלל שלא באתי עם כל המטענים שיש לי ב-dotfiles שלי והתחלתי מחדש, זה הלך חלק. 
• עכשיו, החיסרון ב-Fish זה שאתה לא יכול לזרוק עליו Shell-סקריפטים רגילים - אם יש לך אוסף של כל מיני “קשקושים שצברת עם השנים”, כל מיני קונפיגורציות, אז אתה לא יכול.
• כי השפה שלו היא קצת שונה, ואפילו ה-Command-ים הם טיפה שונים.
• אבל בסוף, לא יודע, אני עובד עם Fish shell, אני חושב בלי כלום - וזה 80% מכל ה-Setup שלי ב-Oh My Zsh.
• ואת ה-20% הנותרים אני פשוט לא עושה . . . 
• (רן) ועם iTerm, עדיין?
• (דותן) כן, iTerm. ניסיתי עכשיו Alacritty, שזה טרמינל יותר Light-weight, גם מבוסס Rust, ולהגיד את האמת, אני לא רואה הבדל . . . . 
• הרי הביצועים, זה מה שכאילו כולם אומרים - לא רואה הבדל בביצועים.
• (רן) אוקיי . . . . יאללה, נקסט.
• (רן) הדבר הבא, שלפחות אצלי תפס - וגם פה אולי זה קצת שנוי במחלוקת - זה שימוש ב-Copilot או כלים אחרים להשלמת לקוד.
• אני משתמש בהם המון, ואני גם רואה הרבה מאוד ביקורת על זה - אבל אני מאוד נהנה מזה.
• אני לא מרגיש שזה עושה אותי טיפש יותר בתור מפתח . . . . אני כן יכול לראות איך זה עלול לעשות אותי, אבל  בינתיים לפחות לא נראה לי.
• דווקא להפך - אני מגלה שאני לומד מזה. זאת אומרת, לעשות דברים בצורה קצת אחרת, השלמות שאולי לא חשבתי עליהן . . . 
• נכון, מדי פעם אני מקבל דברים ואני מסתכל ואני אומר “איזה שטות!”, כאילו - “למה שמישהו יעשה דבר כזה?!” 
• [מזה שזו ההשלמה שקיבלת, סביר שמישהו עשה את השטות הזו וגם כתב את זה במקום מספיק פומבי כדי ש-GPT התאמן עליו…]
• אבל דווקא ברוב המקרים אני מוצא שזה לא רק שזה עושה אותי פרודוקטיבי - דרך אגב, בעיקר בתיעוד ודברים כאלה, זאת אומרת כתיבה של טקסט - לא רק שזה עושה אותי פרודוקטיבי, אלא שזה גם מלמד אותי לפעמים דברים חדשים, שיטות שלא הכרתי.
• אז אני אוהב את קו Copilot. משתמשים?
• (אלון) אני מאוד אוהב את Copilot . . . 
• (דותן) אני לא . . . . אבל אני עושה דבר שונה - אני לא “מתנגד AI”, אני כאילו כותב קוד, וברגע שאני מרגיש שהקוד הוא קצת “מגעיל”, או ש”הלך לי קשה” לממש משהו - אז קודם כל אני מסיים את מה שרציתי לעשות, ואז אני לוקח את כל הדבר הזה וזורק את זה ל-ChatGPT-4, ואומר לו “איך היית משפר את זה?” ו”מה היית עושה?”.
• והרבה פעמים יוצא לו דווקא לתת לי כל מיני זוויות מעניינות . . . . אני לוקח את זה - וחוזר חזרה.
• במקום של ה”לייצר קוד” נכוויתי כמה פעמים . . . היו לי ניסיונות כאלה, לייצר נגיד פונקציה או משהו כזה, וזה היה נראה ממש טוב, אמרתי “וואלה, איזה יופי! תאמין לי - הדבר הזה מדהים!” - וחודש אחרי זה אני קולט כל מיני באגים מוזרים . . . .
• והאפקט הפסיכולוגי הוא שדווקא החלק שיוצר על ידי AI - זה החלק שלא בדקתי ב-Codebase . . . . כי אמרתי “אה, זה יוצר, זה ‘ברזל’, זה נראה טוב זה כאילו . . . “, ובסופו של דבר היה שם איזשהו באג מאוד עדין ואיזוטרי כזה, שה-AI ייצר, בביטחון מעולה כמובן - וזה מה שהכשיל אותי.
• אז אחרי פעמיים-שלוש כאלה, אמרתי שאני עובר ל-Mode שבו אני כותב, נותן ל-AI לראות מה הוא חושב - ואז או לוקח הוא לא לוקח את השיפורים שלו.
• (רן) אלון רצה להגיד משהו . . . 
• (אלון) כן . . . . אני קודם כל, ה-Copilot - אחד השימושים הכי טובים שלו זה טסטים.
• כאילו, “תכתוב לי טסטים על הקוד” - ואתה מקבל “ערימה של טסטים”, בדרך כלל סבבה.
• או כותב שני טסטים ואומר לו “תכתוב לי עוד כמה כאלה!” - כאילו, עוד טסטים, תבדוק עוד דברים - אז זה גם עובד מעולה.
• ודבר נהדר - זה לא ה-Copilot, זה דווקא ה-ChatGPT - זה ה-Boilerplate.
• כלומר זה לא ה-Boilerplate המעצבן של פרויקט, אלא כשאתה רוצה עכשיו לעשות איזה אלגוריתם או משהו, אז אתה אומר לו “תכתוב לי”.
• ואתה מתחיל ממשהו בסיסי - ואחרי זה משפר אותו
• יצא לי מקרים שהיה לנו איזה אלגוריתם שרצינו לכתוב ואמרנו “מורכב מדי” - אז כאילו לא התעסקנו עם זה  בכלל, כי אמרנו “עכשיו איפה נבנה Complier-ים ועצים וכל מיני דברים “, אז אמרנו “בוא נסרוק את זה עם ChatGPT”.
• ואז איזה שעתיים שיחה איתו - והיה לנו כבר קוד עובד.
• זה לא עוד לא היה Production, עוד אחרי זה היה צריך כמה ימי עבודה כדי באמת לגרום . . . to” Productionize it” - אבל זה חסך, בוא נגיד, השיחה איתו חסכה Research של שבועות, שאם הייתי נותן למישהו “בוא, תתחיל לכתוב Complier, ואיך אתה מפרק עצים ומקרים וטה טה טה . . . .” - וזה עשה את זה מעולה, עם טסטים, ובאמת . . . .
• אז יש מקרים מדהימים.
• (דותן) כן כן - זה, אחד לאחד, גם אצלי.
• כאילו, “ה-Brainstorming יחד איתו” עובד ממש טוב.
• גם אם יש לך או גם אם היה לך את הפתרון בראש, ופשוט היית צריך “מישהו” במרכאות לדבר איתו - ואז להוציא את זה מהמוח שלך - זה עובד טוב.
• (רן) אני מוצא, דרך אגב, גם הרבה פעמים שנגיד אני מקבל איזושהי השלמת קוד - אז מה שאני פחות אוהב ב-Workflow שהזכרת, דותן, עם נגיד ChatGPT, זה שאתה צריך לעשות Copy ולהעביר - זאת אומרת, זה קצת שובר את ה-Workflow, שובר את השטף.
• מצד שני, אני מסכים שהאיכות היא טובה, בדרך כלל.
• אבל מה שאני מוצא את עצמי עושה הרבה פעמים זה עושה סוג של איטרציות - זאת אומרת, מקבל איזושהי השלמה, לא אוהב אותה, כותב נגיד איזושהי שורת-תיעוד או משנה קצת את החתימה של הפונקציה, מקבל השלמה אחרת, אולי קצת יותר טובה . . . .
• סוג של עושה Prompt Engineering ל-Copilot, כדי שהוא ייתן לי את הדבר הנכון.
• לפעמים נגיד כותב את ההתחלה של הפונקציה ואת סוף הפונקציה - ואז מנסה לקבל השלמה קצת יותר טובה . . .
• וזהו, ממש גיליתי שאני כאילו סוג-של מפתח לפי זה - זאת אומרת, כותב את ה-Template מסביב, ואז מחכה להשלמות ורואה מה יוצא.
• מחליט אם אני לוקח או לא לוקח - ועושה איזה קצת Fine-Tuning.
• אבל אני לגמרי מסכים ששגיאות והזיות וכאלה - זה דברים שיכולים לקרות וכואבים.
• במיוחד בשפות שהן Untyped - אז שם צריך להיזהר עוד יותר.
• אז כן - לא ללכת “על עיוור”.
• טוב יאללה - נמשיך.
• (רן) אז הכלי הבא שגיליתי שאני משתמש בו מלא, ואני גם חושב שהוזכר ממש פה בהתחלה, זה JQ
• זה כלי CLI ש”מפרסר” (Parsing) מ-JSON, ויכול לבחור חלקים מתוך ה-JSON.
• סופר-פשוט, סופר-שימושי - בקיצור, נחמד.
• אני משתמש בו מלא ב-CLI, לפרק קבצים וככה לעבוד איתו.
• אני זוכר שיש גם איזושהי גרסה חדשה שלו, שנכתבה ב-Rust - זה “JQ-משהו” . . .  לא זוכר את ההמשך, שהזכרנו גם בפודקאסט [MiSawa/xq].
• אבל לא משנה - מבחינתי ה-Performance שלו מספיק טוב, גם אם הוא לא הכי מהיר, אבל הוא מספיק  סבבה למה שאני משתמש.
• אז כן - גם אחד הכלים הראשונים שאני מתקין.
• ובעולם אחר - נדבר רגע על ספר! אז לא הרבה ספרים נשארו איתי, אבל ספר אחד שאני מגלה שמדי פעם אני ככה חוזר אליו בשיחות ומזכיר ולוקח מנו רפרנסים זה ה-Google SRE Book.
• ספר שהוציאו . . . זה למעשה כמה כרכים, זה לא בדיוק ספר, ולמעשה גם יש שתי גרסאות שלו, אבל זה נקרא ככה, “The Google SRE Book”, שבא ומסביר איך עושים - או לפחות איך עשו - Site Reliability Engineering בGoogle בתקופה שבו הוא נכתב.
• ואחד - זה מעניין גם לדעת איך עשו, וזה גם מן הסתם דומה וזה קורה גם בחברות אחרות.
• אבל יותר מעניין מזה זה עולם המושגים - מושגים כמו “Budget של שגיאות”, איך מגדירים “Uptime” וכאלה.
• זה מושגים שהם שימושיים, שבין אם תסכים או לא תסכים עם ההגדרות שלהם - זה עדיין שימושי לבוא ולהגדיר ולכמת את הדברים האלה, ולהשתמש במושגים האלה ביום-יום.
• (אלון) זה אחלה ספר - שמנו פה גם לינק בעבר, לגרסה הדיגיטלית שלו, בחינם - מי שרוצה, אפשר למצוא, לשים שוב [ושוב] . . . 
• כן, ספר מעולה - עשיתי סביבו הרצאה אפילו פעם . . . אני חושב שיש שם פשוט “עקרונות נצחיים” כאלה . . . זה מסוג הספרים שאתה יודע, “לא יתיישנו” - הם יישארו מודרניים עוד תקופה ארוכה, עד שה-AI יחליף אותנו, ואולי נצטרך ספרים . . . .
• אבל עד אז, נראה לי שיש פה . . . שיש שם הרבה דברים חשובים.
• (רן) כן, אז כל מי שנמצא בעולם של SRE מן הסתם - אבל גם מסביב, זאת אומרת, גם ראשי צוותים ובקיצור -  אנשים שיש להם “שירותים באוויר” - מומלץ לקרוא ולפחות ככה להכיר את עולם המושגים שם.
• (רן) הכלי הבא, שלדעתי גם הוזכר פה, האמת שקשה לזכור, אבל דיברנו לא מעט על כלים לניהול של Infrastructure as Code, והזכרנו אני בטוח הרבה פעמים את Terraform ודומיו. אני מגלה שאני דווקא יותר אוהב כלי אחר, שנקרא Pulumi, שהוא קצת יותר חדש, קצת יותר “צעיר” מ-Terraform.
• הוא מנהל Infrastructure, זאת אומרת - אם יש לכם Deployment ב-AWS או ב-GCP או בפלטפורמות אחרות, אז במקום להשתמש ב-Console או במקום להשתמש ב-API, אתם יכולים להשתמש ב-Pulumi - או ב-Terraform או בכלים אחרים - כדי בעצם להגדיר את ה-Infrastructure שלכם.
• איך נראה ה-VPC? איזה Instance-ים יש לכם? איך נראה Bucket ב-S3? - וכו'.
• וזה מאוד נחמד, במיוחד כי אני עכשיו בתקופה שבה אני עובד עם כמה חשבונות AWS שונים - ואני רוצה שיהיו דברים דומים שם.
• אז אני פשוט כל פעם עובר חשבון ועושה “Apply” - וזה עובד שם.
• הסיבה שאני מעדיף דווקא את Pulumi על Terraform - שלטעמי זה היתרון, אבל זה לגמרי יכול להיות גם חיסרון - זה ש-Pulumi כתוב בשפת תכנות . . . 
• זאת אומרת, ב-Pulumi אתה יכול לכתוב ב-Python, אתה יכול לכתוב ב-JavaScript, אתה גם יכול לכתוב ב-Go - אבל אתה כותב “בשפה אמיתית”.
• לעומת Terraform, שהוא דקלרטיבי (Declarative) - אתה כותב במשהו שנראה ככה קצת כמו JSON או YAML
• והשפה שלהם, שהיא מצד אחד מאוד מתוחזקת ומשוכללת מצד שני היא שפה שונה, וצריך להכיר אותה.
• ואם אתה רוצה לעשות Whatever, נגיד Reuse - לכתוב פונקציות, לעשות אבסטרקציות וכל זה - אתה צריך ללמוד את השפה של Terraform כדי לעשות את זה “נכון".
• לעומת זאת, ב-Pulumi אתה לא צריך ללמוד את השפה - זאת אומרת, אם אתה יודע Python אז אתה יכול פשוט לכתוב את זה ב-Python, ולעשות אבסטרקציות כמו שאתה אוהב.
• אז לפחות לי זה עובד - זה נחמד.
• (אלון) אני רוצה להגיד על Terraform משהו - אני יודע שאני בדעת-מיעוט, אבל אני שונא Terraform. אני חושב שזה השטן.
• והרשימת-טקסט הזאת שאי אפשר לדבג (Debug) אותה, אי אפשר לעשות לה טסטים - ורק אחרי שאתה עושה Deploy ב-Production אתה מגלה אם שברת משהו - זה פשוט אחד הדברים הגרועים שקרו לעולם התוכנה.
• אני חושב ש-Pulumi כן פותר את הבעיה הזאת - אני, כאילו באמת, אני שונא את ה-Terraform הזאת, כי אי אפשר לבדוק שם דברים, ואיך אתה בודק? אתה מסתכל על ה-Plan ואז “בעיניים” ואתה בודק?
• כאילו, אתה שם שם את זה ב-ChatGPT ומקווה שהוא יעלה לך על מה שפספסת?
• אין לך איך לעשות לזה שום טסט, עד שאתה לא באמת מעלה את זה.
• ואז - סיפור אמיתי, למשל - בשבוע שעבר מישהו העלה קוד, בטעות העיף הרשאות מאיזה Service ב-Production, והכל נעלם . . . .
• עכשיו, לא הייתה שום דרך לבדוק את זה, וב-Plan לא שמו לב שהשורת-קוד נעלמה, כי היו שם כל מיני דברים - קורה, אי אפשר לתפוס הכל ב”להסתכל על קוד” - והופ! הכל הלך לפח . . . .
• לא הכל הלך לפח - ה-Service הפסיק לעבוד, תקנו, הכל בסדר בסוף - אבל אני ממש לא חסיד גדול של Terraform.
• (רן) אני חושב ששגיאות לוגיות כאלה גם ב-Pulumi קל לעשות . . .  זאת אומרת, אולי קצת יותר קל לבדוק אותן, אבל די קל לעשות גם אותן.
• זאת אומרת, אני חושב שהוא רגיש באותה מידה.
• אבל שגיאות - בוא נגיד “יותר פשוטות”, זאת אומרת, שגיאות “Python-יות”, לא שגיאות לוגיות - ב-Pulumi קל יחסית לתפוס.
• (אלון) לא, יש הבדל מהותי בין Pulumi ל-Terraform, שזה משהו שנתקלתי בו הרבה - נגיד, ב-Terraform אתה יוצר Database, ואז אחרי זה אתה צריך לזכור להעביר אותו ל-Service-ים שלך.
• ב-Pulumi זה לא יתקמפל (Compile) לך - כי יצרת Database, ולא השתמשת בו.
• אם אתה ב-Go נגיד, ב-Flavor של Go כותב - הוא פשוט לא יתקמפל לך, יש לך משתנה שהוא “Not used”.
• וב-Terraform זה לא יקרה - הוא [Pulumi] מגן עליך הרבה הרבה יותר.
• אז אני - קשה לי עם Terraform . . . 
• (דותן) אבל האמת שזה הסיפור של הנושא הזה - כי אני לא יודע אם לפני Terraform, אבל לפני זה היה את Ansible.
• והייתה “שגעת מטורפת” על Ansible, שאני בכלל לא הבנתי אותה - שאתה בא ולוקח “ערימות של YAML-ים”, ויש לך איזשהו Server  . . . 
• ולפני זה גם היה Chef כמובן.
• אז תמיד זה הסיפור של “אני בא עם “ערימה של דקלרציות” (Declarations) - שזה כאילו דבר חיובי - ואני עושה Apply, ואז נבנה לי Cloud בדמות “הקבצים המתים, היבשים” של הקונפיגורציה שהכנתי . . . .
• ואין פה שום לוגיקה . . . 
• זאת אומרת, דווקא זה שזו לא שפת תכנות וזה דקלרטיבי (Declarative) - אז זה נתפס כמשהו חיובי. 
• “אין לך לוגיקה - אז אין לך באגים!” . . . 
• אז תמיד היה את הסיפור של הנושא הזה - ואת האמת שאני לא יודע . . . לא יודע למה זה תפס וזה לא.
• כאילו, Pulumi - חשבתי שהוא מת . . . . ועכשיו הפתעת אותי, רן.
• (רן) יכול להיות שהוא מת, יכול להיות שרק אני משתמש . . . 
• (דותן) לא, אבל עכשיו כשאני כאילו “מעבד פנימה” את המחשבות, וחושב על HashiCorp ומה שקורה עם זה  ו-Terraform ומה שקורה עם זה - הפוליטיקה שם וכל הריצה החוצה והזניחה של הפרויקט, שגם על זה נדבר בהמשך [וגם דיברנו בהרחבה כאן - 470 Carburetor 37 Open Source שלום לתמימות].
• (רן) כן, אבל בוא רגע נפריד את הפוליטיקה מהטכנולוגיה. זאת אומרת, כן - יש שם הרבה עניין עסקי, פוליטי, Whatever איך שנקרא לזה, אבל נפריד את זה רק שנייה מהטכנולוגיה.
• למרות שאוקיי - יש  . . . 
• (דותן) אז הטכנולוגיה - “ה-Pitch היבש” [איך עוד אין דמות כזאת בלינדקאין/טוויטר/טיקטוק? קלאסי לאיזה Fake-Investor . . . ] אומר “אתה יודע מה? אם אתה הולך על שפת תכנות, אז יש לך באגים; ואם יש לך באגים - אז אכלת אותה!”.
• כי שפת תכנות == באגים . . .
• ואם אתה הולך על שפה דקלרטיבית, כמו XML כמו YAML - כמו Terraform, שאין שם שום לוגיקה - אז אין לך באגים.
• אז אתה שמת תג לא נכון, או שאתה שמת חתיכה של קונפיגורציה לא נכונה - אז כאילו המעבר בין טעות לכשל ב-Production הוא פשוט . . . 
• עכשיו כתבתי איזה For-Loop של Off by 1 Zero - ואכלתי אותה כזה . . . 
• (רן) אז זה לא שאין לך באגים; יש לך באגים - מסוג אחר. 
• והאמת שכמו שאלון אמר - הם הרבה יותר גרועים . . .  
• זאת אומרת, באגים מסוג Infrastructure.
• עכשיו, אף אחת מהמערכות האלה לא חסינה לזה יותר, אבל לטעמי לפחות, אם אתה כותב בשפת תכנות שאתה מכיר יותר טוב, אז יש לך יותר מיטיגציות (Mitigations) לדברים האלה.
• אתה עדיין צריך לעשות את המיטיגציות ולנקוט בצעדים - אבל אתה מרגיש קצת יותר “בבית” , ואז אתה עושה את זה קצת יותר טוב.
• (דותן) כן, אז אני אקח את הצד הנגדי - ואז אני אגיד ”אתה מכיר יותר טוב” . . . אם יש לך צוות, ו”חוליה חלשה“ שלא מכירה טוב - ושפת תכנות זה דבר גדול - אז יש לך יותר הזדמנות לא להכיר טוב. זה רק סטטיסטיקה . . . 
• אז אם אתה לוקח שפה דיקלרטיבית, אז הגבלת את כל הצוות ל-10% יכולת, ואז ככה יצרת “מכנה משותף של כשל” גם.
• (רן) כן, מסכים. העולם מלא Tradeoff-ים, אין מה לעשות.
• (אלון) לא יודע, זה כמו שאלה קבועה של קונפיגורציה (Configuration), שאתה שם בקוד - וזה YAML או JSON או לא משנה מה - או שתכתוב קוד . . . 
• (דותן) השאלה היא מה אפשר “לדפוק יותר ביצירתיות” - Codebase שהוא מבוסס נטו-קונפיגורציה, או Codebase שהוא Codebase של שפת-תכנות - מה אתה יכול לדפוק יותר, בצורה יותר תכופה וגם בצורה יותר חריפה . . .
• (אלון) אני חושב אבל שהרציונל הגיע מזה שכביכול SRE היו מתעסקים ב-Terraform פעם, או שפעם הייתה איזו אסכולה כזאת - אז הם “לא יודעים לתכנת”, כביכול.
• (דותן) בדיוק, אני באתי מכיוון חיובי, רגע לתת לזה פרשנות של “אתה יודע מה? אם נגביל את כולם, אז יכול להיות שזה דבר טוב, להגביל את כולם” . . . בסדר.
• (רן) טוב, בסדר - יאללה, בואו נמשיך, הרשימה עוד ארוכה.
• (רן) עוד אייטם קטן שתפס אותי - שלדעתי אלון הביא פעם [420 Bumpers 76], לפני הרבה הרבה מאוד זמן - זה איזשהו פיצ'ר קטן שבנו מעל GitHub, מעל האתר של GitHub שנקרא GitHub 1S בזמנו.
• פעם זה היה איזשהו פרויקט חיצוני, והיום זה למעשה Feature שהוא Built-in בתוך GitHub
• זאת אומרת שאם אתם נמצאים בתוך איזשהו Repo - תלחצו על נקודה (“.”) במקלדת, פשוט נקודה - וזה “פותח לכם IDE”.
• זה פותח לכם למעשה את VSCode בתוך הדפדפן - ואתם יכולים ככה “לטייל בקוד”, ואפילו להתקין  Plug-In-ים.
• ונכון שאם אין לכם הרשאות עריכה אז אתם לא תוכלו לערוך, זאת אומרת - אם אין לכם הרשאות ל-Repo אתם לא תוכלו לערוך, אתם תוכלו רק לקרוא.
• אבל זה עדיין מאוד נוח לקרוא ככה קוד - אפשר לדלג להגדרה, אפשר לעשות קצת . . . בקיצור, לשנות . . .
• זה סופר-סופר נוח, אפשר להשתמש אם אתם ב-Node או ב-Python, להתקין את ה-Plug-In וזה יצבע לכם את הדברים בצורה יפה ויהיה “אינטליגנטי”.
• אז אם אתם רוצים לעשות איזושהי קריאה מאסיבית של קוד - אז תלחצו על נקודה ויש לכם “IDE בתוך הדפדפן” וככה הרבה יותר קל לקרוא אותו.
• (אלון) קודם כל, ל-Code Discovery זה הרבה יותר נוח לעבוד עם IDE, לא רק לכתוב קוד.  Code Discovery - להתחיל לחפש, לרוץ בין פונקציות, משתנה . . .  עם הכל זה הרבה יותר נוח.
• בזמנו, אמרתי שזה ה-Feature הכי טוב שראיתי באינטרנט . . . 
• (דותן)  רגע, זה בקטגוריה של “תפס” עכשיו, זה מה שאנחנו אומרים? . . . 
• (אלון) זה בקטגוריה של “תפס” - ואני בזמנו אמרתי שהזה הדבר הכי טוב שראיתי, ו-Drop the Mic, וזהו . . . 
• (דותן) רגע שניכם משתמשים בזה?
• (רן) אני משתמש בזה, כן . . .
• (אלון) כן, בטח . . . הקיצר, זה אחלה, זה כיף, זה נחמד.
• (רן) אני לא משתמש בזה כל הזמן . . . כשאני מגיע ל-Repo - שהוא לא שלי, שלא עשיתי לו Clone - ואני קורא כמה שורות, אז אני לא משתמש בזה.
• אבל אם אני רוצה לקרוא קצת יותר “לעומק” - אני רוצה לדלג בין פונקציות ואני רוצה לחפש דברים - אז כן, זה נוח.
• (דותן) רגע, אז בוא נסביר לקוראינו [מאזינינו?] איך מתקינים את זה . . . 
• (רן) אתה רק נכנס ל-Repo ב-GitHub ולוחץ על נקודה [“.”] במקלדת . . . 
• (דותן) אבל איך מתקינים?!
• (אלון) אתה מתקין את ה-Chrome שלך או Safari - בעצם בטח לא עובד ב-Safari, אז אל תתקינו Safari . . . 
• אתה נכנס ל-Shell, תרשום . . . .
• (דותן) זה Extension? . . . לחפש ב-GitHub?
• (אלון) תרשום: “rm, רווח, מינוס rf enter” . . . 
• (דותן) רגע . . . 
• (אלון) . . . ו-Sudo! . . . 
• (דותן) לחצתי - וזה נראה כאילו זה לא עובד . . .  אני לא רואה כלום.
• (רן) רגע, רגע, תכף תכף זה יורד, תן לזה זמן . . .
• (דותן) לחכות, או? . . . אתה יודע מה? - אני אריץ את זה עוד פעם!
• (אלון) תריץ, תריץ עוד פעם.
• (רן) רגע, לא עשית סלאש / בסוף, תעשה סלאש!
• (דותן) כן, אני אריץ את זה פעמיים -  בשני טרמינלים, ליתר ביטחון.
• טוב - דברים שלא תפסו! בואו . . . . בחרתי אקראית, יש מלא מלא דברים שלא תפסו, כן . . . .  אבל סתם ככה בחרתי אקראית - ונתקלתי ב-NFT . . .
• זוכרים שלפני כמה - איזה חמש שנים או משהו? - כולם דיברו “NFT, NFT”. . . 
• עכשיו, כולם ידעו שזה לא יתפס, עדיין כולם דיברו
• והנה, אכן - זה לא תפס . . .
• אז כן, זה לא תכנות Proper - אבל יצאנו לדבר על זה גם גם בפודקאסט . . .  אז הנה, מצאתי אחד לקטגוריה, לעשות לו סיפתח: דברים שפחות תפסו - NFT.
• אלון, שלך?

25:47 אלון

• (אלון) שלי? טוב - Flutter. דיברנו פה עליו, ה-Framework Mobile של Google.
• שאז היה ראש-בראש עם React Native  . . . 
• (רן) אנחנו עכשיו בדברים שתפסו, כן? רק נתמקד . . . 
• (דותן) יכול להיות שהוא אומר שתפסו . . . 
• (אלון) רגע, רגע, רגע, חכה לפינה . . . [דמיינו אפקטים אקראיים של Riverside, סטייל שירים ושערים . . . ] - בקיצור, אני לא יודע, האפקטים - צריך לעבוד עליהם טיפה . . .
• (רן) יש להם Delay - ברגע שאני לוחץ, אז זה לוקח קצת זמן . . . 
• (אלון) בקיצור, היה את Flutter, שהיה מחליף של React Native והכל - והאמת שאני לא יודע מה המצב היום לגמרי, אני חייב להודות . . . .
• מצד אחד, אני לא חושב שהוא השתלט על השוק; מצד שני, הוא לא נעלם.
• (דותן) תשמע, בואו נעשה לכם רגע אתגר, רוצים אתגר?
• (אלון) אתגר קרת או אתגר אחר?
• [שבוע הספר, והבנאדם הוציא ספר וקרא לו “אוטוקורקט” - לגמרי אייטם לגיטימי לבאמפרס]
• (דותן) תנו לי Framework של Google - שתפס . . .
• (רן, אלון) Angular, Kubernetes . . . .
• (דותן) ו-Framework אפליקטיבי?
• (רן, אלון) או, נו - אתה מתחיל לצמצם . . .
• (אלון) “Framework  אפליקטיבי ב-PHP!” . . . .
• (דותן) לא - משהו לאפליקציות, של Google - ו-Android לא נחשב . . . 
• (רן) זה לא של Google, זה של Android . . .
• (אלון) אתה מתחיל לצמצם, כן . . . .טוב, כנראה שהתשובה היא בטח שאין משהו מיוחד . . . 
• (דותן) אני מבקש מקוראינו לשלוח - אם אתם יודעים, אם שמעתם, אם אתם משתמשים . . . .
• (רן) אפליקטיבי? לא יודע - נגיד, אוסף ספריות ב-Java זה נחשב?
• (דותן) איזה?
• (רן) היה Guice, לדעתי - אבל זה ישן, כן . . .
• (אלון) אבל זה Java . . .
• (דותן) היה גם את Google Widget Toolkit - זה תפס בזמנו, זה עבד.
• אבל מאז . . . .
• (רן) Google Widget Toolkit היה זוועה, עבדתי עם זה קצת . . .
• (דותן) אבל זה תפס - ויחסית לזמן זה גם עבד, זה עבד טוב.
• (רן) תפס - אבל זה היה קשוח . . . 
• (אלון) היה להם פעם גם את ה-Design שלהם, ה-UX Design Framework הזה, איך קראו לו? עם הכפתור . . . . 
• (רן) Flex?
• (דותן) לא, Flex זה Adobe.
• (אלון) לא, אחד אחר.
• (רן) לא Flex . . . . הכפתורים השטוחים האלה . . .
• (אלון) עם הגדולים - הכפתור הגדול, בצד ימין למטה שתמיד היה . . . היה כזה Pattern שלהם, עם Framework, אבל לא זוכר . . . טוב, לא משנה.
• (דותן) אוקיי . . .  Material?
• (אלון)Material!
• (דותן) נו, וזה תפס?
• (אלון) לתקופה . . . 
• (דותן) הפונט אולי נשאר איתנו - Roboto - אבל לא חושב שזה תפס  . . . 
• (אלון) בקיצור, לפי שאלתך, אני מבין מה המצבו של Flutter כיום . . . 
• (דותן) כן, לדעתי כן - זה הסאבטקסט פה . . . .
• (אלון) אז אם אני שואל אותך מה המוביל ב-Cross-Mobile Development?
• (דותן) אני רואה את React Native, עדיין.
• האמת שהרבה זמן לא נגעתי, אבל אני עדיין כאילו בכל הפורומים וכל הזה.
• ואני נהנה לקרוא מהצד, וזה נראה שזה כלי שהפך להיות כלי עבודה.
• זה כבר בלי ה-Hype, אבל זה כלי עבודה - זאת אומרת, אנשים ניגשים לזה בלי יותר מדי עכשיו . . . 
• זה כבר לא כזה “נוצץ” כמו שזה היה לפני, אבל משתמשים - וזה עובד.
• (אלון) זה כבר לא דת, לפחות . . .  בוא נגיד, זה עבר מרמת הדת לרמת הפרקטיקה.
• (דותן) נכון, זה לא דת, זה כאילו ה-Hype cycle לגמרי במקום שזה צריך להיות
• ותשמע, זה עובד. אנשים ששואלים, אני עדיין ממליץ - למה להסתבך?
• (רן)) אוקיי, Next. אלון?

29:40 אלון

• (אלון) טוב - .NET Core!
• יצא בהכרזה לפני זה, אני לא זוכר כבר כמה זמן - שנתיים? אני לא זוכר מה - זה היה החזרה של .NET Framework לבמה.
• לדעתי הוא הולך - כאילו, במגמת עלייה.
• זה לא שהוא עכשיו הדבר הכי פופולרי בעולם - אבל הוא כן מתחזק, הוא בטרנד הולך ועולה.
• וגם קצת במעקב - הוא די מרשים.
• מבחינת Performance, חתימות זיכרון וכל מיני כאלה.
• עדיין לא ברמה של Go ו-Rust ברוב המקרים, אבל הוא מרשים מאוד - ו-#C זו אחלה שפה.
• אז אני חושב שבסך הכל הוא בעלייה.
• (רן) תזכיר לנו - .NET Core זה בעצם ה-Framework שהוא Cross-Platform, שגם ב-Linux ואחרים ו . . .?
• (אלון) כן, ה-.NET זה ה-.NET Framework החדש - ה-.NET Framework היה רץ רק על Windows, ואז היה איזה משהו שהיה נקרא בזמנו Mono, שהיה רץ על Linux - או מנסה לרוץ על Linux, מי שעבד איתו אז זה יותר “פחות עובד” מאשר “עובד”.
• ואז יצא .NET Core, שזה ההבטחה שלהם של “ה-Java האמיתי”, ה-Cross Framework, ה-Cross-Platform Framework של .Net.
• ובגדול - נשמע שהוא אחלה ועובד להם.
• (רן) אתם משתמשים אצלכם בחברה?
• (אלון) אצלנו לא - אבל געגועי ל-#C הם קיימים, אני חייב להודות.
• (רן) אוקיי, אוקיי - מה הבא?
• (אלון) הבא - היה פעם “ריב תקשורתי גדול” בין AWS ל-Elastic, על “האם זה הסוף של Elastic או ש-AWS נוטשים
• והיה בלגן עם התביעה, ש-AWS השתמשו בשם “Elastic” בשביל ה-Elasticsearch שלהם - שלא באמת היה Elasticsearch אלא “דמוי-Elasticsearch”, או משהו כזה . . .  אני כבר לא זוכר את כל הפרטים בדיוק.
• [פרק 365 הקוסמי! 365 Carburetor 26 - open source politics]
• (רן) היום קוראים לזה OpenSearch,  דרך אגב - והמוצר חי וקיים.
• (אלון) כן, אבל אז אמרו שזה הסוף של Elastic . . . היו דיבורים ש”הרגו אותם, אכלו אותם, אין להם עתיד”.
• אני חושב מאז Elastic רק עלו וגדלו משמעותית . . . 
• אז בסוף נראה שיש מקום לכמה ביחד.
• אז AWS - לא יודע מה היה בסוף, ניצחו או לא ניצחו - אבל נראה ששניהם בסדר.
• (רן) לא, אז בסופו של דבר, אני לא עקבתי אחרי כל הסיפור, אבל נכון היום יש את OpenSearch, שזה מוצר של Elastic, שהוא סוג של Fork של Elastic - Elastic התקדמו מאוד מאז, יש להם הרבה יותר פיצ'רים.
• זאת אומרת, זה מוצר הרבה יותר עשיר.
• ומבחינת הצלחה מסחרית - Elastic לדעתי במקום טוב . . . לא קראתי את הדוחות שלהם, אבל אני חושב שהם במקום בסך כל די טוב.
• (דותן) כן, ו-Elastic היום זה לא רק Elasticsearch - זו כבר חברה-חברה . . . 
• (אלון) הם נחשבים Cyber Company, Security Company . . . 
• זהו, טוב, נראה - אולי עוד כמה שנים נבדוק מה קורה עם Redis - עכשיו שהם יצאו מה-Open Source וסגרו את הרישיון, אז יהיה מעניין לראות מה קורה איתם בעוד כמה שנים.
• למרות שדותן, אתה אמרת לי “למי אכפת? כבר אין מה לפתח ב-Redis, הוא עובד” . . .  כאילו, “תעזבו אותנו בשקט”.
• (אלון) תמיד זה עבד, כן - אבל בואו נשים פה גם כוכבית: Redis זה מצוין ו-Redis זה מעולה, שלא נחטוף איזו תביעה . . . 
• זאת אומרת - שרן לא יחטוף תביעה . . . 
• (אלון) אם אתם תובעים אותי - תתקשרו לרן . . . 
• (אלון) לא, להפך - Redis עובד!
• (דותן) כן, הוא מעולה, הוא מצוין, הוא יפה . . . גם הצבעים של הלוגו מדהימים . . . .
• (אלון) הפרק בחסות Redis!, נותני שירות Cache מהיר, Database-ים ועוד . . . 
• (רן) כן, אני חייב להגיד פה שאני לא לוקח אחריות על שום דבר שאלון אומר . . . .
• (אלון) גם אני לא לוקח אחריות על מה שאני אומר . . . 
• (רן) אבל את זה כולם יודעים . . . אני הייתי צריך להגיד את זה.

33:52 דותן

• (רן) דותן - מה באמתחתך?
• (דותן) טוב, אז קודם כל בחרתי לתת מקום של כבוד ל-Postgres.
• אני חושב שלאורך כל הפרקים - מכמה זמן זה? עשר שנים אחורה? - Postgres הוזכר בכל מיני סיטואציות . . .
• זאת אומרת, תמיד היה כזה “או, הנה Database חדש שעושה Geo, רק Geo וכו’
• ואז Postgres בא עם איזשהו Extension - ואכל אותו.
• וניקח נגיד לאחרונה את כל ה-Vector Databases
• אז רק נגיד - בחודשים האחרונים אני רואה שה-pgvector אוכל גם את ה-Database-ים האלה.
• וזה פשוט מוצר-תוכנה נפלא, שאני לא יודע . . . 
• כאילו, נגיד אם צוללים ל-Design שלו ולהכל - אם הוא כזה טוב חיצונית, אז הוא גם חייב להיות בנוי טוב פנימית.
• אז זה חייב . . . באמת, חבל שאין חסות, לפרסם את Postgres . . . 
• (רן) האמת שאני חוזר ל-Postgres הרבה פעמים
• רק השבוע עשיתי פרויקט קטן - הייתי צריך לעשות איזשהו חיפוש טקסטואלי ב-Corpus כזה גדול, אמרתי "יאללה, הכי פשוט Postgres”
• התקנתי Postgres, ארזתי - וזה באמת סופר-קל, זה ממש כאילו, בתור כלי.
• ניסיתי בהתחלה SQLite - לא סחב; עברתי ל-Postgres - וסחב כמו מלך.
• (דותן) כן, אני חושב שבמקצוע שלנו קשה למצוא את העוגן לחזור אליו, ואתה רוצה את זה.
• כאילו, אתה רוצה לחזור למשהו שתמיד עבד לך.
• אז נגיד אצלי זה Vim - Vim זה בית   . . . זה הדבר שאני חוזר אליו, והוא תמיד עובד.
• וגם Postgres זה בית . . . .
• (אלון) אתה עושה פרסומות, דותן? בחסות . . . .
• (דותן) אלון, אני רואה לחלוחית של דמעה בעיניים שלך . . . 
• (אלון) ממש, ריגשת פה, עם הבית שלך . . . .
• (דותן) בואו תגידו - מה “בית” אצלכם? לאן אתם חוזרים שאתם מדוכאים מתוכנה?
• (אלון) אני מרים אליך טלפון ושואל . . . .
• (דותן) לא . . .  לאן בתוכנה אתה חוזר כשאתה בדיכאון מתוכנה?
• (אלון) לא, Postgres הוא מדהים . . .  האמת, לא מזמן היה לי איזה ריב-טוויטר קטן [קשה מצוא בין העדכונים על זחלי-משי…]
• שאיזשהו חברה - שמישהו רשם שהם יורדים מ-Postgres.
• זה סטארטאפ עם שני לקוחות - “יורדים מ-Postgres! עוברים ל-Elastic!”.
• ואני לא יודע, בסדר, כל כלי לשימוש שלו - אבל נראה לי שאפשר לסחוט מ-Postgres הרבה יותר שאתה עם שני לקוחות.
• אני אישית, הגענו למצב ש-Postgres עשה חצי מיליון Records per Second הכנסנו איתו - זה עניין של אופטימיזציות ו”לסחוט את לימון”.
• אבל זה כלי . . . כאילו, ה-Go-To הבסיסי כמובן זה Postgres.
• יש לו את התחליפי-ענן המקבילים שלו, שאמורים להיות “אותו דבר” - שזה  Aurora DB, שהוא גם Postgres בגדול אבל קצת שונה, והמקביל שלו ב-Google, שאני לא זוכר את שמו אז הוא לא יקבל חסות . . 
• (דותן) אז רגע - המסקנה של חברות מהפודקאסט הזה זה שהם חייבים לבחור שמות שזוכרים - שמות קליטים.
• לא מוצרים שעובדים - שמות שהם קליטים, לנו.
• (אלון) לא פשוט ב-Google זה כנראה . . . כן, נכון - הם צריכים לתת לנו שמות משעשעים . . . 
• (דותן) נגיד FlotzDB - זה קליט! 
• (אלון) FlotzDB זה זה שם טוב ל-Database . . . מה הוא עושה, אבל? ה-FlotzDB?
• (דותן) זה לא משנה . . .  הוא Database רגיל, תואם Postgres והכל - אבל השם הוא זה “FlotzDB”. זה סופר -קליט . . . 
• (אלון) תכלס כן . . . בקיצור, אז Postgres זה אחלה. אני איתך, אני עובד איתו עדיין הרבה עם ה...
• (דותן) Postgres זה בית!
• (אלון) Postgres זה בית . כן, אין ספק - Postgres זה בית .
• (רן) זו הסיסמה שלנו. אוקיי.
• (רן) אז... בתים שהתפרקו - בואו נדבר על בתים שהתפרקו.
• (דותן) אז ככה - דברים שלא תפסו, ואני חייב לומר שבאיזשהו מקום ראו עליהם שלא יתפסו, זה רק מהזיכרון, כן? 
• אז זה Atom, העורך-טקסט שהזכרנו אותו הרבה - הוא תפס ולא תפס . . . .
• כי בלי Atom לא היה לנו את VSCode, אז חייבים פה להגיד מילה “לעורך הפורש” . . . .
• (רן) לגמרי. כן.
• (אלון) היה גם את ה... על Atom, היה פעם את הזה של Facebook, ב-React. . . 
• (רן) Flow?
• (דותן) היה להם את Flow, שזה ה...
• (אלון) לא, לא Flow - זה Nucleus! 
• (דותן) אוקיי, נכון.
• (אלון) היה ממש IDE, מבוסס Atom . . . 
• (דותן) כן, זה לרגע תפס . . . 
• (אלון) לרגע הוא היה הדבר הכי נוצץ בשוק . . . 
• (דותן) נכון, נכון . . .  איזה תמימים היינו. אגב - כל הדברים שלא תפסו, ואנחנו המלצנו, אז... זה אלון!
• (רן) כל הדברים שלא תפסו ואנחנו המלצנו - זה אלון.
• (אלון) טוב, אני רוצה להגיד - Atom היה חבר טוב. באמת, אני חייב להגיד...
• (דותן) האמת שזה היה צריך להיות פרק עם עורך-דין פה בתוך הזה, כדי ש...
• (אלון) לא לוקחים אחריות. רק רן נושא באחריות . . . לא, Atom באמת היה חבר ואח - עד ש-VSCode בעט אותו החוצה . . . 
• (דותן) כן, שזה גם סוג של הפתעה . . . אתם חייבים לומר, חייבים להודות שבאמת, VSCode - אז Microsoft עושה Code Editor בפעם ה-X, נכון? הרי הם עשו את זה כמה פעמים . . . .
• מצד אחד אתה אומר, Microsoft יודעת לעשות IDEs - כי זה היה מסוף שנות ה-90.
• מצד שני, אתה אומר, אוקיי, אבל זה Microsoft, אז... איך זה יקרה עוד פעם, כאילו?
• וואו, חייבים להגיד שאפו על VSCode . . . 
• (דותן) זהו, אז שני דברים שלא תפסו, אבל אני חושב שמראש מי שחשב שיתפוס היה סופר-אופטימי, זה Storm, למי שזוכר.
• זה היה Event-Based Real-Time Processing, בלה בלה בלה . . . ש-Twitter קנו, והשתמשו בזה חזק ל-Analytics בתקופה שלא היה שום פתרון טכנולוגי שייתן לזה מענה.
• ואחרי זה, כמובן, התפתח כל העניין של ה-Real-Time, Event-Based, Lambda, Gamma, כל הארכיטקטורות האלה . . . 
• אבל Storm, איפשהו, נעלם - הוא היה מבוסס גם Scala ו-Clojure
• אני מדבר מהזיכרון, אז לא לתפוס אותי במילה . . . .
• ו-Scala - וואו, זה אני, כאילו, אני בא, ואין שמחה-לאיד יותר מזה . . . 
• כי אני אימצתי Scala בערך לשבוע - ואז אמרתי “אני לא נוגע בדבר הזה יותר בחיים”.
• ואז היה קהל שלם של פאנטי-Scala [אולטראס-Scala?], שאמרו ש-”Scala זה מדהים!” ו-”Scala זה ה-Java הבא!” ו-Scala, Scala, Scala . . . .
• והתעקשתי לא לגוע בזה - וזה מזל, מזל גדול.
• (אלון) אני שנאתי Scala מהיום הראשון, אני תמיד הייתי בצד ההייטרי של Scala, בדעת מיעוט . . . 
• וכמו שאתה אומר - שמחה לאיד, איזה כיף. שנאתי אותם, שנאתי את השפה הזאת.
• (דותן) כן, אני חושב שזה שפה שגם הרסה לעצמה, עם כל ה-Scala 2, Scala 2.13, 2.14, וכל הקפיצת-מינורי בגרסאות, שזה כל כך ביג דיל ושובר . . . 
• ואז Scala 3, ובקיצור - שיגעון.
• (אלון) תן לי להרחיב לך פה בשניים - קשור ל-Scala:  אחד זה שהיה את ה-Swift, שהיה לרגע Swift Server, ושחשבנו והיתה איזו הרגשה לרגע שזו תיהיה “שפת ה-Backend הבאה” - שלא הצליחה.
• אבל לחילופין, מה שהאמנו בו מהרגע הראשון, זה היה Kotlin - בניגוד ל-Scala - והוא כן דווקא צמח יפה.
• (דותן) נכון.
• (רן) כן. דרך אגב, אני גם מהאנשים שאהבו Scala בהתחלה ואחר כך ממש ממש לא . . .
• (אלון) בוז! אה, למה האפקטים אצלך? תעשה לך בוז!
• (רן) אין פה, יש פה רק דברים חיוביים.
• אבל מה שכן, יצא לי לעבוד לא מעט עם Spark בזמן האחרון - ו-Spark כידוע כתוב ב-Scala - אז עם כל זה שהשפה כאילו הולכת החוצה, יש עוד המון המון Code Base ב-Scala
• ויש לא מעט מפתחים שכותבים,  לפחות ל-Spark - וכותבים את זה ב-Scala.
• ויש גם חברות שמה לעשות? עדיין עם השפה הזו . . . 
• (דותן) שאין להן ברירה. כן.
• (רן) אז היא אולי, מבחינתנו, בדרך החוצה - אבל עדיין יש לא מעט מפתחים שעובדים ב-Scala ביום יום, אני בטוח שגם חלק מהמאזינים שלנו.
• אז אני לא בטוח שזו המילה האחרונה של השפה, למען האמת, אבל אני מסכים שכן - המגמה היא לגמרי החוצה.
• (דותן) כן. טוב - אז עשיתי פה קטגוריה של “Over-Promised”, וזה בעיקר לעצבן אתכם. אז אחד זה ה-Microservices . . . .
• ואני חייב להגיד - בשביל להבין את מה שאני מנסה להגיד פה, צריך רגע ללעצום עיניים ולדמיין את התקופה, של Micro Services . . . 
• ודמיינו כנסים - כשבכל כנס, 8 מתוך 10 הרצאות היו על “איך אני בניתי ארכיטקטורת Microservices!” ו”ולמה לפרק מוצר ל-100 פונקציות, שלכל פונקציה היא בכלל Microservices . . . ”
• (אלון) כנס רברסים 2016 . . . 
• (דותן) אמרתי כנסים, אני לא...
• וככה, לפני שאתם זורקים עליי את העגבניות, אני כבר אשחיל Kubernetes - שגם זה, לדעתי, סוג של Over-Promised גדול.
• ואני בעיקר מתכוון לזה שבהרבה מקרים, אתה פשוט יכול לקחת כמה Service-ים ולסגור עניין, וזהו.
• כדוגמת ECS, Fargate, Whatever . . . 
• לא רוצה לפרסם, אבל . . .  Keep it simple, כאילו. זה...
• (אלון) כבר נגמרו לנו החסויות פשוט . . . 
• (דותן) בדיוק, לא רוצה לפרסם יתר על המידה, כי כבר כולם דופקים פה על הדלת לחסות . . . 
• זהו, זה ה-2 cents שלי . . . 
• (אלון) אני חושב שה-Microservices - זה בגרות של התעשייה.
• כאילו, היה קטע, הרי היו מונוליטים (Monolith) ענקיים - ואז, כרגיל, התעשייה הלכה לקיצון השני, שאפילו לא הייתי אומר Microservices אלא ממש Nano-Services, שכל אחד היה אומר לך על כל פונקציה קטנה “תרים איזה Service!”
• (דותן) לא, זה היה מוגזם, כי זה היה דת, זה כבר היה דת . . . 
• (אלון) נכון.
• (דותן) אני רק זוכר את כל הספרים - כאילו, מה אתה עושה עם כל הספרים האלה עכשיו? מה אתה עושה איתם? אתה יודע איזה כמויות של ספרים יצאו על Microservices?
• (אלון) מה זאת אומרת “מה אתה עושה?” למה המסכים מגיעים תמיד בלי הגבהה? - כי יודעים שיש ספרי תוכנה שאין מה לעשות איתם, וזה שימוש שלהם . . .
• (דותן) אה, אוקיי.
• (אלון) אבל, תראה - Microservices היום נהיה הרבה יותר . . . עדיין יש Micro, כי קוראים לזה עדיין ככה, אבל זה נהיה הרבה יותר Services שהם הוליסטיים יותר, ולא Micro אלא “Normal-Size Services” . . . .
• (רן) כמו שהיה לפני זה . . . 
• (דותן) מה שעשית כל החיים, כן . . . 
• (אלון) לא, היו מונוליטים עצומים פעם, אם אתה חוזר קצת אחורה - היו מונוליטים עצומים, שהיה נורא קשה לתחזק אותם. ואחרי זה . . . .
• עכשיו יש איזושהי בגרות - לפרק דברים, לא ל... מצד אחד לא למיליונים, ומצד אחד לא Service אחד ענק.
• (רן) זוכרים את המושג של J2EE? התקופה הזאת של Java Beans וכל זה - זאת הייתה ההגזמה לכיוון ה-Monolith.
• אחר כך הייתה ההגזמה לכיוון הMicroservice.
• ועכשיו אנחנו איפשהו באמצע.
• (אלון) אבל Kubernetes - שמע, הוא תפס בטירוף, בניגוד...
• (דותן) כן, לא יודע . . . החשיבה שלי זה קצת פילוסופיה - אבל בוא נסתכל עשר שנים אחורה: קח $100 בכיס, ותגיד לי איזו חומרה אתה קונה ב-$100 לפני עשר שנים, ואיזו חומרה אתה קונה היום.
• מן הסתם, מה שאתה קונה היום זה פי כמה וכמה, מבחינת משאבים ויכולת וכו’
• וגם שפות התכנות השתפרו היום בביצועים שלהן.
• זאת אומרת - אותם $100 קונים הרבה יותר משאבים מאשר לפני עשר שנים.
• ואז אני בא ואומר שמוצרים - נורמליים, לא... כאילו, לא שנפלת עכשיו על איזושהי הצלחה מסחרת וכו’ - מוצרים נורמליים, SaaS, Whatever, לא משנה, eCommerce - כנראה שקצב ההתפתחות שלהם היה לינארי.
• זאת אומרת, אם לפני עשר שנים היו לך באופן טיפוסי 1000 User-ים, אז היום יש לך 10000 User-ים, לא משנה כאילו, בסדר גודל נורמלי.
• ואם לפני עשר שנים חשבת ש-100 Request-ים לשנייה זה מטורף - אז כנראה שהיום 1000 Request-ים לשנייה זה . . . 
• אבל החומרה, לדעתי, גדלה בקצב יותר מהיר - אז כאילו, למה לי? למה לי לסבך דברים?
• אם לא לקחת איזה שני Server-ים ולסגור את העניין? . . . 
• כי מבחינת ביצועים ו-Resource-ים, זה מספיק לי.
• (אלון) זה דותן פה מדבר, או DHH? . . . מי פה בפודקאסט איתנו?
• (דותן) אבל זה נכון . . . אבל זה נכון. כאילו, קחו את זה כחומר למחשבה.
• אם היתה לך מכונה, או בוא נעשה אחרת - אם היתה לך מכונה, שהיו מבטיחים לך שיש לה ביצועים אינסופיים, אוקיי? אז אתה לוקח שתי מכונות כאלה, בשביל Redundancy. 
• האם היית הולך ל-Over-Engineering של Microservices, על Kubernetes וכו' - או לוקח שתי מכונות, עם הביצועים אינסופיים האלה?
• אני טוען שהספרים האלה לא היו נכתבים בכלל, אם זה היה המצב . . . 
• (רן) האם הדובר כותב Framework דמוי-Rails בשפה כלשהי?
• (דותן) כן . . .
• (רן) גילוי נאות . . . כן, אז אני מסכים - אני חושב שאחד מהעניינים זה Performance 
• והעניין השני זה העניין של המבנה הארגוני - של אחריות ושל איך עושים Deployment וחלוקה של הצוותים וכל זה.
• וגם זה אולי היה...
• (דותן) כן, המבנה הארגוני זה אנשים, אין פה . . . אני טוען שבני אדם לא עכשיו השתנו מקצה לקצה - זה תמיד היה ככה, בכל חברה.
• זה טרנדים, זה משתנה עם הזמן - וזה גם עוד ישתנה, המבנה הארגוני וההדרך שבה אנחנו עושים באופן טיפוסי מבנים ארגוניים בתוכנה.
• (רן) כן, נכון, אני אומר רק שאחת מההבטחות - אולי לא ממומשות, אבל אחת מההבטחות - של Microservices או Services באופן כללי - זה התאמה יותר טובה למבנה הארגוני,  ככה שלהגדיר ממשקים בין רכיבים ולהגדיר אחריות של מי אחראי על כל רכיב, ושהם אחראים לכל ה-life-cycle של אותו רכיב.
• אם זה נגיד Service של אות’נטיקציה (Authentication) או Service של Storage - אז הם יהיו אחראים עליו, כולל ה-Deployment ו-Redundancy וכל זה.
• (רן) עכשיו, יכול להיות שישנן דרכים אחרות לפתור את זה, מסכים - אבל בכל אופן זה בא, מן הסתם לפתור לא רק את הבעיה של הסקליביליות (Scalability) ו-Redundancy, אלא גם את הבעיה של איך אתה מנהל צוותי פיתוח, ואיך אתה נותן להם חופש.
• (דותן) כן אז אז יש פה קטיגוריה נוספת של . . . יש לנו ככה, “Stick, didn't Stick” וכו’, יש פה Didn't Hold Data . . . 
• (אלון) רגע, רגע, רגע, רגע . . . רציתי שנייה לפני שאתה ממשיך הלאה, בקשר לזה, המבנה הארגוני זה - Conway Law, שאני חסיד מאוד גדול שלו.
• ודבר שני, על Kubernetes - אני כן חייב להגיד שאנחנו דיברנו על Istio ושיבחנו אותו די הרבה [אפילו עם פרק ייעודי - 353 Istio] - ואני חושב שאפשר לאכול את המפרש . . .
• (רן) Istio, רק נזכיר למאזינים, זה Service Mesh, איך זה נקרא? . . . 
• (אלון) כן, זה Service Mesh, מקביל ל-LinkerD, לא ידוע לשמצה . . .  אבל Istio הוא ה-Service Mesh מבית Google - עוד הצלחה מסחרת שלהם, דותן, אם חיפשת מקודם . . . . - שנחשב די סיוט . . . 
• (דותן) אבל Google זו אחלה חברה . . . כאילו, אנחנו אוהבים את Google!
• (אלון) Google זה חברה טובה - הם מגייסים כרגע . . .
• (דותן) והלוגו שלהם בצבעים! שזה דבר טוב ונעים לעין . . . אנחנו אוהבים את החברה.
• (אלון) אנחנו אוהבים את Google, אנחנו רצים בGoogle - ואני גם מחפש בGoogle!
• מדי פעם, כש-ChatGPT לא עונה לי . . .  אפילו זה.
• אבל Istio, ה-Service Mesh - הוא היה הבטחה מאוד גדולה, שGoogle הוציאו - והיה אמור להיות ה-Service Mesh, ל-Kubernetes או כל פתרון אחר.
• הוא נולד ל-Kubernetes - ובסוף די שונאים אותו, הוא די סיוט . . . 
• (דותן) מגניב . . . .מגניב.
• (דותן) טוב, אז שוב - קטגוריה של Didn't Hold Data: עכשיו, אני קצת מוטרד מהחשיפה המשפטית שיש לפרק הזה [באמת מזמן לא היה פרק 1 באפריל . . . ] - אז אני לא אגיד מה לא מחזיק Data, אני פשוט אגיד שיש ארץ, או חבל - מונגוליה! . . . . 
• (אלון) יש גם פרי דומה . . . מנגו? אתה אוהב מנגו? אגב, סתם - זו העונה עכשיו . . . 
• (דותן) כן, אני מאוד אוהב מנגו . . . אני חושב שה-Database, שקצת מזכיר את ה... זה פרי או ירק, מנגו?
• (רן) מנגו זה פרי . . . 
• (דותן) אז זה מזכיר את הפרי “מנגו” . . . 
• (אלון) האמת שיש בו גלעין . . . 
• (רן) יש Delay באפקטים [ויש יתרונות לגרסת הטקסט…] - אני לוחץ, וחמש שניות אחרי זה זה מגיע . . . 
• (אלון) אז תגיד לנו, דותן! תשלח צ'אט, משהו . . . תקרוץ.
• (רן) הכי נחמד כשאתה מפתיע . . . 
• (דותן) אז זהו, אז מי שהבין - לחפש Postgres . . . מי שהבין ובתחילת דרכו לשמירת Data, מה שנקרא - לחפש Postgres.
• (רן) טוב, אז דברים שעבדו, דברים שנשארו איתנו ? . . . 
• (דותן) אז דברים שעבדו, קצת אמרנו - הרבה אמרנו - VSCode עבד, עובד, מעולה.
• באמת, אני חושב, המוצר הכי טוב של Microsoft.
• חייב להגיד כל הכבוד, באמת, אחלה. 
• (דותן) React עבד . .  ופה יש לי וידוי - אני זוכר את עצמי, בפרק על React - אתם לא זוכרים, כי אם הייתם זוכרים אז הייתם יורדים עליי, אז עכשיו אני אפתח פה - אני לא הייתי בעד React!
• אני . .  זאת אומרת, לא הייתי נגד, לא הייתי בעד - אמרתי שזה נראה לי מוזר, השפה הזאת.
• אני זוכר שמה שראינו, באותו פרק, זה רק את ה-Syntax, ואמרתי “מה, זה XML חדש?” כאילו, יש פה איזשהו XSLT, לקחו אותנו לימים האלה  . . .
• ומה שלא ראיתי זה שזה לא ה-Syntax אלא שזה כל ה-Framework - ו-React תפס ובגדול, וזה עובד טוב.
• הדבר הבא זה Rust - וגם פה הייתי סקפטי לגבי Rust . . . 
• ואלון לא היה סקפטי, ואני הייתי ממש בעד Go - ובגלל שהייתי פאנאט על Go, אז ראיתי דברים בצבעים, בצבעים של Go, בצבעים של Gopher . . . 
• וטעיתי . . . וואו, כמה טעיתי.
• (אלון) דותן, מזמן לא הזכרת Rust . . . 
• (דותן) כן, אתה רואה? . . . 
• (אלון) כן . . . אגב, רגע, לפני ה-Rust והבדיחת-Rust שלך - בקשר ל-React: תגיד, איפה Vue.js עומד היום?
• כי Vue היה...
• (דותן) לא יודע, מבחינתי - התחלתי רק React, כי אני לא מבין למה ללכת לכל דבר אחר.
• חוץ מצורך כלשהו לבלות - לבלות במקומות בשביל הכיף, ללכת לטיול בכל מיני Framework-ים אחרים . . . 
• אם אתה בא לעבוד - אני חושב שאתה צריך לקחת React, ורק React.
• אלא אם כן אתה רוצה הרפתקה - אז אתה הולך, מטייל בכל מיני כאלה . . . 
• (אלון) אני אגיד לך, עוד משהו בעולם של ה-LLM-ים וה-ChatGPT - ככל ש-Framework הוא יותר גדול ובשל, יותר קל לך לעבוד איתו עם ה-ChatGPT.
• (דותן) כן.
• (אלון) כלומר, אם תלך למשהו נישתי, תקבל תשובות נישתיות, או בקושי תשובות . . .
• ולכן, האפקט-רשת הולך ומתחזק היום.
• (דותן) בדיוק - אתה רוצה להיות בסירה גדולה, אתה לא עכשיו...
• (רן) כן, פעם היינו בודקים כמה Tag-ים או כמה שאלות יש ב-Stack Overflow, כמה שאלות ותשובות, נגיד לטכנולוגיה מסוימת - והיום זה באמת, צריך את המדד הזה על GPT.
• (דותן) כן.
• (דותן) ואני חייב להגיד גם - הדבר הבא זה NVIDIA - NVIDIA תפס . . . 
• מי שזוכר, ויש לו זיכרון חזק וטוב, אז אני זוכר את כל ההכרזות - ש-”NVIDIA יוצאת משוק המשחקים” . . . . מדבר על תקופה של תחילת ה-Deep Learning.
• וכש-Cuda שנולד - והסיפור של NVIDIA לא היה כזה בזנ”ט . . . 
• והנה - הגענו למקום שזו החברה הכי גדולה בעולם.
• (רן) השנייה הכי גדולה, לא? שני טריליון דולר, משהו כזה? . . .
• (אלון) לא, לא - הכי גדולה, 3.3 טריליון . . . “הפרק בחסות מניות NVIDIA! קנו מניות NVIDIA וצפו לתשואה!”
• “אין זו המלצה או . . . .”
• (דותן) כן, הייתי להגיד שגם על זה את יכול לחטוף תביעה . . .
• (דותן) בקיצור, רן - אתה צריך עכשיו לבחור אם זה צחוק או כפיים . . . כי יש פה איזה מכפיל 60 או משהו כזה, ל-NVIDIA.
• כפיים . . . בחרת כפיים . . . 
• (רן) זו אכן בחירת הקהל.
• (דותן) סבבה. יש לי עוד קטגוריה של...
• (רן) אז NVIDIA תפס, אתה אומר . . . כדאי לקנות, יופי.
• (דותן) וזו לא המלצה, ולא זה . . .  אני מחפה עליך, רן - אתה חייב להגיד שזו לא המלצה.
• (רן) לגמרי, זה לא.
• (אלון) אני אומר “קנו NVIDIA בסופר הקרוב לביתכם! - חלב NVIDIA, קוטג' NVIDIA, כל מוצר של NVIDIA תופס!” . . . 
• (רן) כן - S4 של NVIDIA!
• (רן) טוב - דברים ש”למה הם לא משתפרים?”
• (דותן) כן, למה? מה קורה פה? אז Linux Desktop - אני חייב להגיד שלמרות שאני מניח שיש מלא אנשים שיגידו “וואו, זה... מה אתה מדבר שטויות?” - אני חושב שהנושא של Linux Desktop Distribution פשוט עומד ולא זז.
• עשר שנים אחורה, עשר שנים קדימה - אנחנו פחות או יותר באותה סיטואציה.
• שזה מאוד מאוד חבל - אבל זה נתון לויכוח, כאילו, לא יודע, זה...
• וניסיתי לחזור ל-Linux, לפני שבועיים - וזה בעסה
• (רן) על מה? איך אתה מתקין את זה?
• (דותן) איך אני מתקין Linux?
• (רן) לא, כאילו, על מה? על ה-Mac שלך? על...
• (דותן) דיסקטים . . . 
• (רן) על מה התקנת? על מה ניסית?
• (דותן) ניסיתי . . . אני ב-Mac M3, אז יש לך כמה אפשרות מאוד מאוד מוגבלות, כי ווירטואליזציה (Virtualization) וכו’ - VMware Fusion Player.
• הוא חינם, והוא עובד.
• (רן) הבנתי. אז סתם בשביל המשחק ניסית?
• (דותן) כן, אני לא עכשיו אמחק את הכל, ו... כאילו, עכשיו אתה תגיד “זה בגלל שלא התחייבת לגמרי!”, אז...
• (אלון) דותן, איך אתה יודע שמישהו משתמש ב-Linux?
• (דותן) נו?
• (אלון) הוא כבר יגיד לך.
• (דותן) אה, נכון. איפה הצחוקים? זה בא ב-Delay . . . 
• (רן) עשיתי טבעי בינתיים, נטורל . . .
• (דותן) והפינה הנראה-לי-הכי-לוהטת זה The Rise and Fall . . . . אז יש לי פה ככה: יש לי Terraform, ו-HashiCorp בכלל.
• שזו הפתעה מוחלטת, באמת.
• האמת הייתי גם צריך לשים פה Docker . . . החברה Docker.
• (אלון) נכון, תכל’ס . . . 
• (דותן) Elastic - במובן של חיפוש, אבל אני חושב שזה אין מה לעשות, פשוט הטכנולוגיות השתפרו כל כך, שאתה יכול לקחת היום מוצר חיפוש כמו Elastic - והוא יהיה טוב כמו Elastic.
• ו-Go - שאני במחנה הנגד, אבל לא יודע האם אני נגד בשביל סתם לעצבן, אני נגד כי אני לא רואה שום Value ב-Go יותר . . . 
• ואני עדיין בכל הפורומים של-Go, וכל ה-Reddit-ים  וכאלה - ואני רואה “ערימות של אכזבה” מתוך הקהילה”.
• כל מיני דברים שקורים ב-Go, שלא נכנסתי אליהם לעומק - אבל התלונות על הניהוג של השפה.
• אז זהו, זה מה שנקרא . . . 
• (אלון) תראה, התלונות על Go הן בעיקר שהשפה הולכת ונהיית מסובכת ומאבדת את הפשטות שלה.
• זה בעיקר התלונות על הגרסה של ה-1.23, שאמורה לצאת בקרוב - שהוסיפו Syntax,  והשפה נהיית יותר מתוחכמת, וזה כבר לא כמו “אוקיי, אני עושה For-Loop - וזו הדרך היחידה”.
• מה שאהבו, בניגוד ל-Scala נגיד, ש-Go היה דרך אחת לעשות דברים, בכל דבר.
• “ככה עושים דברים ב-Go, זהו, אין לך דרך אחרת”.
• בדרך אחרת זה ממש יהיה קשה לך לעשות את זה - והיא מכתיבה לך דרך אחת, בניגוד ל-Scala, שהיית עושה . . . פותח אחד באמצע פונקציה, עושה לולאה בשבע דרכים שונות.
• אז זה היה מה שיפה.
• ועכשיו פתאום נהיו יותר אופציות, והשפה קצת נפתחת . . . 
• (דותן) אז היד החזקה מתרופפת - וה-value העיקרי שזה זה, הולך וקטן . . . 
• (אלון) מצד שני, זה עדיין שפה שנורא . . . העקומת למידה היא מאוד, מאוד קלה, נורא קל להיכנס אליה.
• ומבחינת Performance והכל היא . . .  מה אלטרנטיבה שלך? רק Rust, כי אתה יודע . . . מה, Kotlin?
• (דותן) אני אגיד לך מה - השאלה האם זה שפה שאתה נהנה לכתוב בה?
• ולא נהנה כי “וואו, זה מגניב!”, אלא תזכר, בגלל שאני מכיר אותך - תזכר בימים של של #C, שהיה לך משהו “שעוטף אותך”, ואתה אומר “אתה יודע מה? אני יכול ללכת עם זה כל החיים, זה עושה הכל, אני לא צריך ללמוד שום דבר אחר”.
• באותה תקופה, כן? כי באותה תקופה גם ה-Use Case-ים והדברים שאתה צריך לעשות היו גם מוגבלים.
• (אלון) תראה, #C זה #C, אתה יודע . . . אהבתי אליה -  ואי-שם ל-Ruby עוד, אתה יודע, “ישארו לנצח”.
• אבל יש גם איזושהי הבנה, שאתה יודע - שאי אפשר לעשות הכל עם שפה אחת, כי לצערי אני מוצא את עצמי חוזר ל-Python מדי פעם
• בלית-ברירה, ממש - זה ממש “בכאב לב”, לעשות דברים ב-Python, כי יש דברים שאפשר לעשות בצורה הגיונית רק ב-Python.
• וזה מה שמבאס אותי, תכל’ס - שבסוף . . .
• (דותן)  אני יכול להגיד לך שב-Rust, מצאתי את הדבר הזה שלך ב-#C - ו-Rust עושה הכל.
• [מה קורה עם Werner באמת בסיפור הזה?]
• וגם במקומות של Python, אז קורה משהו מגניב - שהרבה מהתשתיות של Python מוחלפות ב-Rust, ובגלל זה, אז נגיד אם יש לך עכשיו DataFrames, ואתה חייב להשתמש ב-Python וכו’, אז אתה הולך ל-Polars.
• ושם אני, במקום להשתמש ב-Python, משתמש בספרייה-נטו, בלי כל העטיפה ב-Python, נטו.
• זו ספרייה של Rust, אז אני משתמש בה ישירות.
• אז זה Heck מגניב שקרה בצורה, לא יודע - הקהילה גרמה לו לקרות.
• (אלון) טוב, אולי נעבור ל-Rust . . . 
• (רן) כן, למרות שהעולם, אם אתה מסתכל, נגיד, באיזור של ה-Deep Learning, אז עדיין זה נשלט ב-Python,
• ומתחת זה הכל ++C, אבל... 
• [שוב Werner . . . ]
• (דותן) לא, אז גם שם המניות . . . תתפלא, המניות ב-Rust.
• כי סתם, בוא ניקח את . . . אני מסתכל הרבה על Hugging Face ומה שהם עושים - אני מאוד אוהב את הדרך שבה הם עושים כלים.
• ולמי שיבחין, מי שיחטט להם ב-Repositories ויחטט במה האנשים שלהם עושים - אתם תשימו לב שהם עושים Porting לכל התשתיות שלהם ב-Rust, מ-Python.
• (רן) כן, זהו, Hugging Face זו חברה שהתחילה ב-Rust, אם אני זוכר נכון? והם אימצו דווקא . . . אני דווקא ראיתי הפוך, אני ראיתי שהם אימצו הרבה מאוד Python מאז.
• אבל אולי, כמו שאתה אומר, הם אימצו כדי אחר כך לעשות לזה Port ל-Rust . . .
• (דותן) יכול להיות.

01:01:40 סיכומים

• (רן)  בכל מקרה, הגענו לסימן השעה - וזה הזמן לסיכומים. אנחנו מבטיחים לחזור בעתיד עם פרקים עם חומר מעודכן וחדש.
• אז זה היה פרק הזה של נוסטלגיה - עשינו, ככה, Review קצר על דברים שעבדו או לא, אבל בעתיד נביא דברים חדשים.
• (דותן) אחוז-הפגיעה שלנו בפרקים הוא, עכשיו שאנחנו מסתכלים אחורה, זה 50% . . . 
• (אלון) בקיצור, אז אתה אומר להקשיב לחצי-פרק?
• (דותן) לא - זה או שאנחנו צודקים, או שאנחנו לא צודקים . . .  או שההמלצה טובה, או שלא.
• (אלון) זה כמו הבדיחה ששניים משחקים שש בש - ואחד שואל את השני “מה הסיכוי שיצא לי שש-שש?”
• השני חושב חושב וחושב - ואומר לו “50%! - או שיצא, או שלא יצא” . . . 
• (דותן) איך זה היה בזמן טוב? [אפקטים של מחיאות הכפיים - דמיינו סאונד של PowerPoint מ-97 . . .]

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

[קישור לקובץ mp3]
פרק מספר 471 של רברס עם פלטפורמה, שהוקלט ב-30 באפריל 2024 - אורי ורן מארחים את גל ברק כדי לדבר על מלא (ממש מלא) נוטיפיקציות. גל עובד בחברת Plus500 - וגם דיבר לא מזמן בכנס רברסים האחרון {הנה ההקלטה - Real-time Market Event Notifications: Plus500's Scalable Fanout Architecture / Gal Barak).

(אורי) איך הייתה החוויה של לדבר בכנס?

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

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

• (גל) אחלה. אז אני גל, עובד היום ב-Plus500, נשוי ואבא לשתיים במשרה מלאה.
• לפני שהתחלתי ב-Plus500, עבדתי גם קצת בתעשייה הביטחונית, אחרי שהשתחררתי מקבע.
• ועוד איזושהי גיחה לעולם המחקר, בעולמות של Computer Vision - קצת רחפנים אוטונומיים, שעלו לכותרות לא מעט בתקופה האחרונה, ובנסיבות פחות משמחות.
• ובעצם, בשלוש שנים האחרונות אני עובד ב-Plus500 ומוביל שם את תחום ה-Communication - נוטיפיקציות, כמו שאמרת.

(רן) נוטיפיקציות (Notifications) . . . תיכף נברר מה זה. ו-Plus500? למי שלא מכיר - כמה מילים.

• (גל) אז Plus היא בעצם קבוצת FinTech גלובאלית . . .

(רן) רגע . . . “Plus” זה בקיצור, או שזה כבר השם האמיתי?

• (גל) לא, זה בקיצור  - Plus500 זו קבוצת FinTech גלובלית, שבעצם מפתחת פלטפורמות שונות למסחר מקוון בשוק ההון.
• אנחנו חברת B2C, כלומר - המוצר משווק ללקוחות פרטיים.
• אנחנו היום עם למעלה מ-25 מיליון לקוחות, סדר גודל של חצי מיליון אקטיביים (Active Users) בכל רגע נתון.
• החברה עצמה הוקמה ב-2008, והיום היא בעצם חברה גלובלית - נסחרת בבורסה הראשית בלונדון, ואנחנו עם רישיון פעילות בלמעלה מ-50 מדינות, כולל אגב גם בישראל.
• הרגולטור, המפקח שלנו כאן בישראל, הוא הרשות לניירות ערך - ואני מניח שעוד ניגע בנושא הרגולציה בהמשך, כי זה מן הסתם משפיע גם על עולם הנוטיפיקציות (Notifications).

(רן) כלומר, מי שרוצה להשקיע בשווקי-ההון - זה המקום? או שיש פה איזשהו משהו יותר ספציפי?

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

03:39 “נוטיפיקציות בסקייל” - איפה זה פוגש אותך?(רן) אוקיי, אז בכנס דיברת - בוא נעשה אולי קצת Recap על מה דיברת בכנס: דיברת על “נוטיפיקציות בסקייל” (Notifications at scale). איפה זה פגש אותך, בפעם הראשונה?

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

(רן) כלומר, זה כלי עבודה - זה לא סתם “FYI - הגיע מייל חדש!”, אלא . . . 

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

(רן) כלומר, א' - שלא תתפספס נוטיפיקציה, וב' -שתגיע מהר . . .

• (גל) שתגיע “נכון” - אם, כלומר, רוצים להגיע עם כל מיני “Placeholder-ים” למשתנים כאלה ואחרים . . . 

(אורי) כלומר, קרה . . . .

• (גל) קרה, בהחלט קרה . . . 

(אורי) מקרים שקרו . . . 

• (גל) לא אצלנו, כמובן . . . 

(אורי) על גבי איזה Medium הנוטיפיקציות האלה עוברות?

• (גל) אוקיי, אז מבחינת ה-Medium, או מה שנקרא בשפה יותר רשמית, נקרא לזה Cross-Channel Orchestration - בעצם כל המבנה שנדרש כדי לתמוך בהודעות האלו.
• אז אנחנו מדברים על הודעות שנשלחות במספר ערוצים - Channels, בעצם
• זה יכול להיות ערוצים בתוך הפלטפורמה - אם זה הודעות ה-In-App, בתוך ה-Inbox שלנו; הודעות Pop-up, שאנחנו מקפיצים
• אבל זה יכול להיות גם מחוץ לפלטפורמה - אם זה הודעות Push, עבור תוכן שצריך לעבור בצורה מיידית  ומהירה, או למשל ערוץ ה-Email או SMS או WhatsApp
• בעצם כל סוג של תוכן שאנחנו מעבירים - יש לו את הערוץ המותאם והרלוונטי ביותר עבורו.
• אגב - גם הרגולציה לפעמים מכתיבה לנו איזה תוכן צריך לעבור באיזה ערוץ או בכמה ערוצים שונים.
• זה מבחינת אופן ההפצה.
• מבחינת התמיכה בפועל - אז הפלטפורמה שלנו נתמכת במספר רחב של Client-ים.
• זה יכול להיות מכשירי Mobile ו-Tablet-ים ו-Smart Watches וגם כמובן Desktop או Web.
• אז גם מערכת הנוטיפיקציות בעצם צריכה לדעת לשלוח לכל אותם מכשירי-קצה את ההודעות.

(אורי) ויש גם איזשהו API או SDK, שעליהם אפשר לצרוך את ההודעות?

• (גל) אז בעצם, הנוטיפיקציות שלנו “רוכבות” על מספר ספקים שונים, שבסוף הם אלה ששולחים בפועל את ה-Mail או את ה-SMS וכו’.
• בסוף, אנחנו בנינו את המערכת שלנו על בסיס אותם APIs.
• אבל מבחינת SDK - לא הבנתי . . . 

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

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

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

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

(אורי) אני יכול להיות לקוח של הפלטפורמה - באמצעות אפליקציה, שלי?

• (גל) אפליקציה של Plus500 . . . 

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

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

(רן) . . .  למה הפתרונות האחרים לא מספקים פתרון מספיק טוב?

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

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

• (גל) נכון, אז בעצם, כל עולם ה-Communication מכיל כמה מערכות שונות.
• בראש ובראשונה, אנחנו תומכים בהודעות מערכת - שזה בעצם כל מיני רכיבים שונים אצלנו בפלטפורמה - 
• אם זה מערכת המסחר או מערכת ההפקדות או הכספים ודברים כאלה.
• שבעצם פונות אל מערכת הנוטיפיקציות - יש לנו איזשהו Client שה-Service-ים השונים במערכת הטמיעו אצלם, והם פונים ואומרים “תשלח עכשיו נוטיפיקציה ללקוח”.
• אלה הודעות, מה שנקרא “הודעות מערכת” - הודעות מיידיות, שצריכות לעבור ללקוחות.
• אבל המסה העיקרית היא בעצם הודעות - בין אם אלה קמפיינים שיווקיים, כשאגב, גם מערכת הקמפיינים היא מערכת שפיתחנו אצלנו
• ובין אם זה קמפייני Retention או Conversion וכל העולמות האלה - כשבעצם, מחלקת השיווק בוחרים לפנות ללקוחות מסוימים.
• ואז יש בבת אחת מסה של הודעות שצריכה לעבור לאותם לקוחות.
• אבל בעצם העניין היותר מעניין ומאתגר, שעליו גם דיברתי באריכות בכנס,  הוא הנושא של “אירועי שוק”
• אנחנו מתמודדים בשוק ההון, והשוק הוא מאוד מאוד תנודתי.
• אנחנו מן הסתם לא יודעים לצפות מה יקרה למניות - כי אם כן, אז כנראה שהיינו עושים דברים אחרים לחלוטין . . .
• ובעצם, ברגע נתון יכול להיות לנו עכשיו איזשהו אירוע, לדוגמא מה שקרה עם Facebook או עם nVIDIA בחודשים האחרונים - כשיש איזשהו אירוע “שמטריף את כל השוק”.
• ואנחנו בעצם רוצים, כמערכת מסחר, לאתר, בזמן אמת, את אותם אירועים
• לאתר את הלקוחות, שזה אתגר בפני עצמו - איזה לקוחות יש, שהאירוע הזה עשוי לעניין אותם?
• ואז - בבת אחת, ברגע אחד - להעביר אליהם את ההודעות האלה, אל הלקוחות.
• אנחנו מדברים פה על מיליוני הודעות, שעוברות בפרקי זמן של שניות בודדות.
• ברור לך, כמו שאמרנו קודם - הקהל יעד הוא Day Traders. זאת אומרת, אנשים שרוצים לקבל את ההודעה כמה שיותר מהר ולבצע פעולה כמה שיותר מהר.

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

• (גל) ולכן זה גם לא יהיה Email - זה יהיה Push, הודעת In-App, בתוך הפלטפורמה.

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

• (גל) אז כמו שאמרתי, אנחנו מדברים על מיליוני לקוחות.
• מה שנקרא “הרף העליון” - הבעיה שהגדרנו לעצמנו לעמוד בה מבחינת הספים (Thresholds) - אנחנו מדברים על כ-10 מיליון נוטיפיקציות שנשלחות.
• כשה”נוטיפיקציות" זה לא בהכרח 10 מיליון הודעות שונות - אלא 10 מיליון הודעות שנשלחות בערוצים שונים.
• לדוגמה, אותה הודעת Market Event שדיברנו עליה קודם, תשלח בשני ערוצים לפחות.
• ואם אתה בכלל לקוח שיש לו גם Mobile וגם Web, אז אתה גם תקבל לכל אחד מה-Client-ים שלך את ההודעה הזאת.
• אז אנחנו מדברים פה על סדר גודל של 10 מיליון הודעות, שעוברות ברגע נתון.

(רן) ברגע נתון?

• (גל) ברגע שמתקבלת ההחלטה לשלוח 10 מיליון הודעות ללקוחות - אז מבחינת הזמנים שעובדים בהם . . .

(רן) . . . ה-Burst, אוקיי . . .

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

(אורי)  . . . קצת יותר מתרומות לקבר רחל . . . 

• (גל) “קצת” . . . גם מבחינת ה-Scale שנדרש . . .

(רן) זאת אומרת, Throughput של כמיליון הודעות בשנייה, בסדר - זה כשיש לך איזה Peak, אבל לא כל היום הוא כזה . . .

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

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

• (גל) אז אני לא יודע - כי אם הייתי יודע, אז היה מצוין . . . . אבל לצערי אני לא יודע.

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

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

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

• (גל) אז קודם כל - הרגשה מטורפת. זה אני חייב להגיד.
• בעצם, סיימתי את ההרצאה - ולא כל כך ידעתי איך אנשים “יאכלו את זה”.
• בסוף, הצגתי פה את מערכת הנוטיפיקציות שלנו - שאוקיי, זה איזשהו תהליך אבולוציוני שאנחנו עברנו, אבל זה משהו שאנחנו עברנו.
• וכדי בעצם להמחיש אותו, אז הצגתי את אותו סיפור, על אותם “אירועי שוק”.
• ולא כל כך ידעתי איך אנשים “יאכלו“ את זה והאם יהיה לדבר הזה בעצם ביקוש והאם יתעניינו.
• ומאוד מאוד הופתעתי מכמות הפניות - גם ברגע שאחרי ההרצאה, עם חבר'ה שניגשו אליי או בהודעות שקיבלתי לאחר מכן - שבעצם הבנתי שהנושא של נוטיפיקציות, כמערכת בכלל, הוא משהו שמעסיק לא מעט חברות.
• אגב, גם היה מאוד נחמד לקבל גם אנשים שאמרו לי “שמעתי כמה דברים בהרצאה שלך ואנחנו נשקול לקחת את זה גם אלינו”.
• אבל מה שבאמת “פתח לי את הראש”, זו העובדה שהצגתי איזשהו Use Case נורא ספציפי שלנו - Market Event, שנורא ספציפי לשוק ההון ולתנודתיות שלו.
• ופתאום בשיחה ככה, בשיחת מסדרון אחרי ההרצאה, ניגש אליי מהנדס, שגם עובד בין היתר עם משרד הביטחון על המערכת של פיקוד העורף, של ההתראות.
• הוא אמר לי, כמו שאתה לא יודע להגיד מתי יהיה לכם אירוע שוק, שעכשיו יכניס את כל המערכת ל-Stress, גם אנחנו לא יודעים מתי יהיה מטח טילים, שיכניס את כל גוש-דן עכשיו למקלטים, וצריך להעביר להם הודעות Push.
• גם בשיחה עם חבר, שככה ראה את ההרצאה אחר כך ב-YouTube, והוא אמר לי “אה, זה אולי גם קיים בעצם בחברות ששולחות Push-ים על אירועי כדורגל, נגיד”.
• נגיד, עכשיו קבוצה הבקיעה גול - ועכשיו צריך לשלוח הודעות Push למלא לקוחות.
• פתאום, הבעיה שהצגתי - היא הרבה יותר רחבה ממה שנחשבתי שהיא...

(רן) אז פה תרשה לי רגע לשים את “כובע ה-Moderator” [אוי, זה רעיון מעולה!]. הרבה פעמים באמת אנשים, כשדיברנו קודם על הכנס ועל להגיש הרצאות, הרבה פעמים אנשים מסתכלים על החוויה שלהם - על מה שהם למדו, על המוצר שהם פיתחו, על הטכנולוגיה שהם פיתחו - והם אומרים “אוקיי, אבל זה נורא ספציפי. זה אני עשיתי, כי  הייתי צריך ב-Facebook משהו, זה אני עשיתי, כי הייתי צריך ב-Plus500 משהו” . . . וברוב המקרים אנשים באמת חושבים שזה לא מעניין אף אחד.אולי יש מקרים כאלה - אבל מצד שני, יש הרבה מאוד מקרים שבהם קשה לך באמת לדמיין את מי זה הולך לעניין, ותהיה מופתע לגלות שזה באמת הרבה הרבה יותר גנרי. וזו באמת, ככה, “חוויה פותחת עיניים” - לבוא ופתאום לפגוש את האנשים עם Use Case-ים דומים, שאולי קוראים לזה אחרת. אולי זה גול, אולי זו רקטה . . . זה לא בהכרח אירוע שוק, אבל כן, העקרונות הם אותן עקרונות, וזה באמת מאוד נחמד לבוא ולהיפגש עם אותם Use Case-ים.(אורי) האמת שגם המוח שלנו רגיל הרי לחשוב בתבניות, והוא רגיל לחשוב בתבניות של דברים שאנחנו מכירים . . . (רן) . . . אבל זה בגלל שיש לך תבנית על המוח שלנו, אורי . . .(אורי) כן . . . וגם, כשאתה מדבר על נוטיפיקציות של אירועי שוק, מישהו אחר שומע את הבעיה של פיקוד העורף. כאילו, אל תניחו - אנשים באים עם התבניות שלהם, והם ייקחו את מה שאתם אומרים לתוך התבנית שלהם, וזה פתאום יהיה רלוונטי.(רן) כן, כן. אבל מעבר לזה, גם אם אי אפשר לקחת את הפתרון שלך, לצורך העניין, ופשוט להשתמש בו כ”פתרון מדף”, עדיין - הרעיונות, העקרונות, יכולים להיות אותם עקרונות: ה-Design של המערכת.אז מה קרה אחר כך? זאת אומרת, באת ואמרת, “אוקיי, אני הולך לכתוב פרויקט ב-Open Source!, אני הולך לעשות כסף מחברה ששולחת נוטיפיקציות!” . . . כאילו, מה קורה אחר כך?

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

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

• (גל) עם האוכל, בא התיאבון . . .

(רן) כן.
20:51 טעויות, תיקונים ו-Vicious Cycles(רן) עכשיו, שוב, אנחנו לא ניכנס לכל ה-Design וכל הדברים שהיו בהרצאה - ושוב, מוזמנים ללכת ולראות את הווידאו, אבל אולי נדבר על דברים שלא הספקת להגיע אליהם בהרצאה. למשל, איזה כיוונים ניסיתם ללכת אליהם, ובסוף התחרטתם, או איזה דברים . . . נגיד, “ה-Playbook” או “פתרון הספר”, שלכאורה נתן פתרון, אבל גיליתם שלא.

• (גל) אוקיי, אז בוא נדבר על הטעויות - כי היו גם כאלה, צריך להגיד בכנות.
• באמת, אני מתחבר לכל מה שאמרת בסוף, עם ה-Playbook - אולי בעצם הטעות הראשונה שעשינו, זה ה-Playbook solution . . . 
• בעצם, אני קצת מדבר על זה גם בהרצאה, על הפתרון הראשון שבעצם עשינו. לא ניכנס פה עכשיו לפרטים  הטכניים, אבל בעצם יצרנו מעטפת אחת, Notifications Service
• שמכיל בתוכו את כל הלוגיקות שהיינו צריכים בשביל לתמוך בדרישות המוצר - עם כל מה שדיברנו קודם: רגולציה, בנייה של תוכן, וכן הלאה.
• ובנינו אותו בעצם על בסיס שני עקרונות מרכזיים:
• קודם כל, כמובן, תמיכה ב-Multi-instance - תצורה של Active-Active
• ואז בעצם, כדי לתמוך בזה,כל Instance כזה הוא בעצם Stateless.
• וכמובן, זה מאפשר לנו בעצם את ה-High Availability - אם עכשיו אחד ה-Instance-ים יקרוס, מכל סיבה שהיא, יהיה תמיד את ה-Service-ים האחרים.
• וככה אנחנו בעצם יכולים כל הזמן לוודא שהמערכת תהיה “למעלה”, שום מידע לא יאבד והכל יהיה בסדר.
• בפועל, כשהעלינו ל-Production והעומס התחיל לעלות ולגדול עם הזמן - בין אם זה הלקוחות, כי כמות הלקוחות גדלה, או בין אם זה כי ה-Use Case-ים השתנו
• אז פתאום ראינו שיש סוג-של יחס ליניארי כזה, בין כמות המידע שאנחנו צריכים לתת לו מענה ברגע אחד, כמות הבקשות - לבין כמות המשאבים, שאנחנו נדרשים להקצות, כדי לעמוד באותם עומסים.
• ואז בעצם הגענו למצב שבו מערכת הנוטיפיציות שלנו רצה על כמות משאבים כמו של מנוע המסחר
• וזה כבר ממש לא Infinite-Scale וזה כבר ממש לא Cost-Effective, וזה כבר ממש לא משהו שאנחנו יכולים להרשות לעצמנו, בעצם, להמשיך לתחזק ולעבוד איתו.

(רן) כלומר, זה “עומד ב-Spec”, במובן של אוקיי, זה Highly Available - אבל זה עולה המון כדי לתחזק את זה.

• (גל) בדיוק. עכשיו, יבואו הרי ויגידו “אוקיי, אבל בסדר - בוא נחזיק את רוב המערכת עם רוב המשאבים כל הזמן”
• אבל אז - בדיוק כמו שדיברנו קודם - אם האירועי-שוק האלה יהיו עכשיו במשך 10% או 20% מהזמן, אז, 80% מהזמן שילמתי המון כסף, ללא צורך.
• אז בעצם הבנו ש”ה-Playbook Solution” - אותו Service אחד, שעושה את העבודה כמו שחשבנו או שקיווינו שהוא יעשה - פשוט לא עשה כמו שצריך.
• ונדרשת פה חשיבה מחודשת על הארכיטקטורה.
• ואז עשינו פירוקים ודברים - וזה כבר מופיע בהרצאה.
• הטעות השנייה שהייתה לנו, קשורה לנושא השרידות, ה-Resiliency של המערכת. 
• כמו שאמרתי קודם, אנחנו התבססנו בעיקר על High Availability - זאת אומרת, תמיד אמרנו לעצמנו “לא משנה, מה יקרה, המערכת תמיד תהיה למעלה”.
• תמיד יהיה לפחות Instance אחד שיגבה.
• והדבר הזה באמת היה נכון - רק שכשהגיע אותו עומס, המערכת לא קרסה וגם אף אחד מה-Instance-ים לא קרס  . .. 
• מה שקרה בפועל, זה ש-Flow-ים מסוימים, בעיקר ה-Flow-ים הסינכרונים - 
• אלה שצריך כדי שעכשיו ה-Service יתן עכשיו תגובה מהירה, נגיד ל-Client, ללקוח, שפותח את האפליקציה, והוא רוצה עכשיו לקרוא תוכן בתוך האפליקציה - אז ה-Service לא היה זמין, כי הוא היה עסוק בהמון בקשות אחרות . . .
• וה-Flow הזה בעצם נתקע. 
• אז במקרה הזה אין לנו פה בעיה של High Availability - פשוט יש לנו Flow, איזושהי קומפננטה (Component) שלמה, שפשוט לא מגיבה מספיק מהר.
• והמשמעות כאן היא פגיעה אפשרית בחוויית הלקוח.

(רן) כלומר, זו בעיה של Throughput? נוצר איזשהו צוואר-בקבוק במערכת הזאת?

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

(רן) דרך אגב, רואים את זה הרבה פעמים במערכות מבוזרות - אני בטוח שראיתם [אורי] את זה גם ב-Outbrain - ברגע שנוצר איזשהו Failure, אז נוצר “כדור שלג” הרבה פעמים, “Vicious Cycle”, כמו שאמרת - כי אז יש יותר עומס על נגיד Instance-ים אחרים, ולפעמים צריכים כזה, ואז אולי Instance אחד בדיוק עלה כי רצית לעשות Scale-up - ונוצר יותר עומס על ה-Database . . .  בקיצור, זה איזשהו Vicious Cycle, שלפעמים עושה יותר נזק מאשר תועלת.אז כן, לצאת ממצבים כאלה זה לגמרי לא טריוויאלי.

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

(רן) דרך אגב, אם למישהו יצא לקרוא את ספר ה-SRE של Google - הם מדברים שם נגיד על Availability. ושם, אחד הדברים המעניינים שהם אומרים - אולי זה לא, שוב, לא גילוי גדול למי שמכיר - זה ש-Availability זה לא בינארי - זה לא שזה למעלה או למטה, זה באחוזים. זה יכול להיות למעלה ל-99.9% מה-USer-ים, או 99.9% מהזמן - ותמיד, להשיג עוד אחוזון קטן, זה הרבה הרבה הרבה יותר עבודה מאשר להשיג את האחוזון הקודם, ותתכננו את ה-Availability שלכם לפי זה. כלומר, אין טעם לדבר על 100% Availability, כי זה אינסוף כסף, אינסוף משאבים - אבל כן להציג איזושהי מטרה ריאלית, כי זה משהו שהוא לגמרי אפשרי, בין זה מבחינה גיאוגרפית, מבחינת מספר ה-User-ים, מבחינת אחוזי-זמן.(אורי) אם תסתכלו על ההרצאה של יונתן זוסמן מאותו הכנס [Throttling your service: the good, the bad and the ugly / Yonatan Zusman], אז הוא מדבר על מערכת של Throttling - שאתה בעצם, כדי להשיג High Availability, אתה “מוריד מהאיכות”, או לצורך העניין מההכנסות. אבל אתה יודע שאתה עושה את זה לזמן מסוים, כשאתה ב-Peak, ומוכן לוותר טיפה על הכנסה. זה עוד מנגנון לא-בינארי ל-High Availability.(רן) כן, כן, אז נגיד אני חשבתי על זה כשהזכרת ואמרת שאוקיי, יש נוטיפיקציות שצריכות “עכשיו-עכשיו” לצאת, ויש קמפיין, שזה בסדר, זה לא נורא גם אם יוצא בעוד חמש דקות. נגיד היום - המערכת שלכם יודעת לתעדף את העומסים האלה?

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

28:03 עננים וסוגיות של גידור(רן) אוקיי. דרך אגב - מבחינת Deployments: אתם, ככה, משתמשים בחומרה שלכם - ענן, Multi-region? . . . איך זה?

• (גל) אז זה משתנה - תלוי על איזה Component אנחנו מדברים במערכת. ספציפית על הנוטיפיקציות?
• אז כן - אנחנו מדברים בעצם על VM-ים שיושבים ב-GCP.
• אגב - אחד השיקולים, גם בגלל ה-Volume המאוד-מאוד גדול שיש על המערכות האלה, גם הפרדנו אותן, מן הסתם מה-Cluster-ים של מנוע-המסחר.
• כדי שלא משנה מה יקרה - מן הסתם, אנחנו לא נקריס עכשיו את מנוע המסחר.
• לכן הוא יושב ב-GCP - יש לו VM-ים משלו, וכל Instance כזה גם יושב על VM-ים, כל סוג של קומפוננטה (Component) שונה במערכת.
• אם זה ה-Write, אם זה ה-Fanout, ה-Read - אני מרחיב על זה בעיקר בהרצאה, אבל כל אחד הם יושב בתוך VM משלו.
• וגם ה-Cluster של ה-RabbitMQ - בעצם אותו Message Broker שאנחנו עובדים איתו - גם הוא נפרד מכלל המערכת.

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

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

(רן) . . . תקבלו נוטיפיקציה, מה הבעיה? . . .

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

29:59(רן) אוקיי - אז תודה רבה! היה מעניין.שוב נזכיר, זאת אומרת - ה-Design הטכני של המערכת זה משהו שאנחנו לא מדברים עליו פה בפודקאסט, אבל אני כן ממליץ ללכת ולראות את הוידאו - ואת כל שאר ה-Video-ים של הכנס [יש Playlist לכל שנה] מיד אחריו.אז תודה רבה גל! אולי ככה, לסיום - אז אמרנו: Plus500, בחיפה? . . .

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

(רן) אתה עוד שם . . . 
טוב - תודה רבה! אז Plus500  גם בחיפה וגם בתל אביב. תודה רבה גל, להתראות.

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

[קישור לקובץ mp3]
פרק מספר 470 של רברס עם פלטפורמה - קרבורטור מספר 37, שהוקלט ב-16 באפריל 2024 - 3 ימים אחרי המטח האיראני (הראשון?) ו-193 ימים למניין החטופים שעדיין בשבי. אורי ורן מארחים את נתי שלום לעוד סבב של אסקפיזם, רכילות ושלום לתמימות בעולם התשתיות.

01:29 אסקפיזם, קוד פתוח, חברות גדולות והמודל של Red Hat

• (נתי) אז אם באסקיפיזם עסקינן, אז למה לא Open Source? הטריגר לשיחה היום הייתה תביעה של Terraform מול משהו שנקרא OpenTofu. 
• “תקציר הפרקים הקודמים” -  . . . 

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

• (נתי) לא. עוד לא . . .  בעצם,  הסיפור שהיום נדבר עליו זה באמת “קורות מעשינו בעולם ה-Open Source” . . .
• מן הסתם, Open Source זה משהו שמאוד קרוב לליבי כבר הרבה מאוד שנים.
• מי שחושב על Open source - תמיד עולה המחשבה הרומנטית, שיש קהילה שמפתחת קוד ביחד, ובסוף יוצא מזה מוצר, בדרך כלל בחינם . . . 
• אני זוכר שאתה - אורי - היית חסיד מאוד של החינם, בצד הזה של ה-Open Source, בגדול.
• והתחילו לקרות הרבה מאוד דברים, שבעצם רוקנו  את כל “הרומנטיות הזאת”, נקרא לזה, מתוכן.
• ואני אנסה ככה, מפעת גילי, לסדר את הסדר הכרונולוגי.
• אז בעצם, אני חושב שהייתי . .  ההתחלה התחילה מ-Linux, בעצם, מבחינת המגמה.
• שהתחיל בכלל מכתיבה של Drivers ל-Printer-ים - ווככה בעצם הגענו למערכת הפעלה Open source.
• ואז בעצם Red Hat בנתה מודל עסקי שלם מאחורי זה.
• ומאחורי הדבר הזה, בעצם, נוצר הגל הזה של Open Source - לא רק כקוד פתוח לקהילה, אלא גם כמודל עסקי.
• מה שנקרא Fast Forward - בעצם, חברות סטארטאפ, שהן יותר VC Backed, בעצם זיהו את הפוטנציאל לעשות Disruption לשוק.
• זאת אומרת, גם אנחנו נניח ב-Cloudify בנינו את זה בדיוק מאותה התפיסה - שבעצם אני חברה קטנה ואני צריך להתחרות בחברה גדולה, איך אני עושה Disrupt לשוק?
• אז אני בעצם, במקומות שבהם יש מוצר שהוא Closed Source, שהוא Commercial, אני אבוא עם פתרון Open Source
• אכנס “מתחת לרדאר” אקבל Adoption - ועל גלי ה-Adoption אני בעצם אוכל לעשות מוניטיזציה (Monetization).

(רן) זו אסטרטגית חדירה לשוק . . . .(אורי) כן, שהיא Bottom-up ולא . . .

• (נתי) היא Bottom-up, וזה גם “חוק המספרים הגדולים” . . . אתה בעצם בא ואומר, בחוק המספרים הגדולים, אתה אומר “אני קודם בונה Adoption”.
• ואז,  עם 5%, 2% . . . נניח שיש לי מיליון Download-ים בזה, אז אני צריך מספר של בין 3% -5% כדי להצליח לייצר כבר מודל עסקי עובד.
• (אורי) . . . שעוברים לפרימיום? . . . 
• (נתי) שעוברים להיות לקוח משלם ואחרי זה לפרימיום.
• ויש גם מודל שבו אני יודע אחרי זה להגדיל את העסקה מול אותו לקוח, על ידי גידול השימוש.
• זה כמובן גם בעיקרון בא לידי ביטוי בזה ש . . . בצד, היית אומר “הפחות רומנטי”, אבל זה בא לידי ביטוי בזה שעלויות השיווק והמכירה אמורות להיות יותר זולות
• כי אתה בונה על איזשהו מנוע ויראלי כתוצאה מזה.
• אבל בעצם, כשכבר נכנסים VCs לתמונה, אז הרצון מן הסתם של VCs זה למקסם, כמו כל חברה מסחרית, ויש איזושהי תקרת-זכוכית למודל העסקי שתיארתי.
• אז א' - אמירה אחת, שאני חושב שהיא תובנה מאוד ברורה - המודל של Red Hat עובד רק ל-Red Hat . . .
• זאת אומרת, כל מי שניסה לחקות את זה, ראה שבעצם זה לא עובד . . .
• למה הוא עובד רק ל-Red Hat? כי בעצם, Red Hat שולטת בשוק מערכות ההפעלה ב-Enterprise, שולטת בכל ה-Ecosystem הזה, ומאוד מאוד מאוד קשה לחדור ל-Enterprise-ים “על הגב” של Red Hat, לצורך העניין.
• כי מה ש-Red Hat עושה בדרך כלל - וזו הביקורת, שלי לפחות, לגביה - זה שברגע שהיא רואה כל פרויקט Open Source שמקבל Adoption מספיק גבוה והוא מתחיל לגדול, אז היא בעצם משתלטת עליו . . . 
• איך היא משתלטת? היא שמה מפתחים, משנים Contributor . . . . זו שיטה מאוד קלאסית שבה אתה משתלט על פרויקט Open Source . . . [זו שיטה קלאסית לעוד כל מיני דברים . . . Backdoor Discovered in XZ: The Most Advanced Supply Chain Attack Known to Date].
• כי מאוד מאוד מאוד קשה לתחזק Open Source לאורך זמן [דותן פותח קבוצת תמיכה, ובמקביל קמה קבוצת גמילה . . . ]
• וככה בעצם היא מגיעה בשלב שבו יש בעיקר את השלב של “חליבת הכסף” ופחות השקעה בפיתוח של  Innovation ויצירת Innovation 
• אז זה יותר לבנות על הוספת יכולות - Enterprise-grade ו-Security, הקשחות . . . כל מיני דברים מהסוג הזה.
• ראינו את זה ב-Ansible, עכשיו אנחנו רואים את זה ב-Kubernetes ועוד כל מיני  . . . 
• (רן) הם גם “מספקים להם חמצן” . . . .
• (נתי) כן - ולכן זה עובד רק ל-Red Hat, כי בעצם הם יכולים להרשות לעצמם דברים, שאם אתה בונה על המודל העסקי הזה ואין לך את ה-Umbrella הזאת - אין לך את המעטפת הזאת - אז המודל הזה לא מחזיק את עצמו, כי בעצם אתה . . . .
• (רן) לפחות לחלק מהפרויקטים האלה שהם נכנסו אליהם זה דווקא עשה טוב . . . . אולי בחלק זה פוגע, אבל בחלק זה עשה טוב.
• (נתי) כן . . . אז בוא אני אציין כמה שמות:
• ל-OpenStack זה עשה מאוד רע, כי זה בעצם הרג את כל ה-Ecosystem.
• ל-Ansible, אפשר להגיד שזה השאיר אותו באיזשהו גובה פחות או יותר כמו שהוא נקנה, עם קצת Innovation - אבל הוריד מאוד את ה-Innovation מאחורי Ansible.
• הוא עדיין חי, נושם, מתפתח - אבל בקצב אחר לגמרי, “קצב Enterprise” הייתי אומר . . .
• אם אני מסתכל על Kubernetes, אז הם הלכו יותר לכיוונים של OpenShift
• אז יש כאלה שאוהבים את התרומה שלהם ויש כאלה שמאוד לא אוהבים את התרומה שלהם.
• מן הסתם הם תקעו את Docker - בצדק, אגב, במידה מסויימת במקרה של Docker ספציפית . . . 
• מי שלא מכיר את הסיפור של Docker, אז הם באמת היו אלה שהביאו את מודל ה-Container-ים לעולם
• אבל עלו Up the stack מהר מדי, והפכו להיות איום להרבה מאוד חברות גדולות - ואז בעצם Red Hat פיתחו את OCI - פיתחו משהו שבעצם סוגר להם הייתי אומר את ה-Ecosystem, ובעצם מוריד את  התקרה למקום הרבה יותר נמוך, שיותר קל להתחרות בהם
• ו-Docker נהיו פתאום איזה שחקן-נישה, שבקושי עכשיו אני חושב מצליח להצדיק את המוניטיזציה שלו.
• והתופעה האחרונה, שאני חושב שמובילה להרבה מאוד מהדברים שאנחנו רואים עכשיו, זה שהשחקני-Cloud נכנסו לתמונה
• והאסטרטגיה שלהם הייתה בעצם להיכנס בלב-ליבו של מה שהפך להיות המודל העסקי היותר מוצלח של ה-Open Source - זה ה-SaaS.

(רן) אז אם רק נסכם את “פרק א’” - המודל של Red Hat עובד ל-Red Hat . . . .

• (נתי) רק ל-Red Hat . . . לא עובד לאחרים.

(רן)  . . . המודל שבו יש Open Source “במרכז”, ומורכבים מעליו שירותי פרימיום. עבד פעם אחת - מצוין, חברה  גדולה ורווחית, עם כל הביקורת עליהם - אבל זהו, זה לא עבד יותר.

• (נתי) נכון.
• “מודל ה-VCs”, לצורך העניין - כל או רוב החברות Open Source, הייתי אומר “דור 2015” וצפונה, 2014-2015 וצפונה, נבנה לכניסה ל-SaaS.
• “קח Open Source בחינם - אבל את הניהול שלו אני אנהל לך ב-SaaS ואני אקח לך בעצם כסף על השירות שאני נותן לך”.
• וזה מסביר את Redis Labs [כאן מסבירים יותר - 457 Tech Debt with Gidon from Redis] וזה מסביר כמובן את Elasticsearch [גם כאן 362 Elastic, distributed corporate with Uri Cohen וכאן גיקונומי פרק #518 – שי בנון ואלסטיק], למרות שה-SaaS אצלהם הגיע במופע מאוחר.
• ו-Terraform היום עם ה-Cloud שלהם - Terraform Cloud נהיה בעצם “המנוע מוניטיזציה” (Monetization).
• זו הסיבה ש-VCs אוהבים את זה - כי יש לזה מודל-Scale יחסית מהיר
• אז אתה יכול בעצם לגדול ולגדול ב-Subscription שלך יחסית מהר.

(אורי)  אבל גם פה יש Pitfall . . . .

• ה-Pitfall בא, אני חושב,  כשה-Cloud נכנסו לתמונה . . . .
• כשה-Cloud נכנסו לתמונה, הם בעצם שברו את המודל הזה - כי בעצם מה הם באו ועשו? הם בעצם באו והציעו

“שירות מנוהל” בעצמם, בשירות ה-Cloud שלהם . . . . (רן)  . . . זה מה שהיה עם Elasticsearch [וזה מה שהיה לשי בנון להגיד על זה]

• (נתי) בדיוק - וזה ממש זיעזע, הייתי אומר, את כל ה-VC-backed Open Source.
• אף VC לא אוהב לממן את Amazon, בטח לא את Microsoft . . . 
• ובעצם, בפועל, זה מה שקרה - זאת אומרת, אומרים ש-Amazon או Microsoft עושים הרבה יותר כסף מ-Elastic מאשר Elastic עם OpenSearch . . . 
• ויש פה גם הרבה, לכאורה, “חוסר Fair-יות”, אם כי אני אומר בצינעה - רוב ה-Open Source-ים לקחו בעצמם גם Open Source ובנו על זה שירות מנוהל . . .
• גם Redis זאת דוגמה מאוד טובה, Elastic לקחו את Lucene . . . 
• זאת אומרת - זה לא עד כדי כך “הרשע” ו-”הטוב”, או “הטוב” ו”הרשע”, איך שלא נסתכל על זה.
• היה פה איזשהו גל שניצל Open Source מסוים כדי לבנות עליו מודל עסקי אחר, והיו Giant-ים יותר גדולים, כמו ה-Cloud-ים, שעשו את זה בצורה אפילו עוד יותר גרידית (Greedy).
• (רן) הדגים הגדולים אוכלים את הדגים הקטנים . . . 
• (נתי) כן, אז נכון - אני חושב ב-Retrospect, אני לא חושב שבהכרח . . . 
• אני בהתחלה ראיתי את ה-Cloud-ים כרשעים הגמורים, וכמובן ששחקנים כמו Elastic כצדיקים הגמורים . . .
• היום, אני חושב שהתמונה היא פחות הייתי אומר שחור ולבן - בהקשר הזה.
• [ובתזמון מעניין - הנה עוד סיפור דומה: אחרי Redis, גם Linkerd מ̶פ̶ס̶י̶ק̶י̶ם̶  מפחיתים תמיכה במוצר הקוד הפתוח שלהם]

10:53 הגבלה לא בגישה לקוד, אלא ההגבלה בשימוש בקוד(רן) אז הסיפור של Elastic היה לפני כמה - חמש שנים פלוס-מינוס?

• (נתי) נכון - ובאותו גל הגיעו Redis ו-MongoDB
• למעשה,  MongoDB היו ראשונים - ואני חושב ש-Redis היו שניים ו-Elastic אחרונים.
• כש-Elastic לקחו את זה למקום שבו הקוד נגיש - אני שכחתי כבר איך קוראים למושג הזה, אבל זה בעצם . . .
• זה לא OpenCore  . . .  אתה יכול לגשת לקוד, אבל בעצם הרישוי-שימוש הוא משתנה - זאת אומרת, אתה לא יכול לתת שירות SaaS עליו, שזה בעצם עיקר השינוי שעשו.
• ובעצם, הם חילקו את הקוד לחלקים שהם בעצם Apache License או License פתוח יותר, או Permissive יותר, וחלק שהוא לא.
• אז ההגבלה לא הייתה בגישה לקוד, אלא ההגבלה הייתה בשימוש בקוד - שזו נקודה שכשכל אחד שמשתמש ב-Open Source והיום צריך ללכת לעורכי-דין כדי להבין . . . 
• ויש את התעשייה השלמה, אגב, שהתפתחה רק סביב נושא של ניהול רישיונות של Open Source ובקרה עליהם . . . 
• ובעצם זה הנושא הגדול - לאו דווקא הגישה לקוד, כי הרבה מהפרויקטים כן מאפשרים גישה לקוד, אלא מה מותר לך לעשות אותו.
• (רן) היכולת לעשות מוניטיזציה (Monetization) היא בעיקר בסביבת קוד.
• (נתי) נכון. אז כמובן שאם אתה סיני, אז יכול להיות ש...

(אורי) למה רק Cloud? כאילו, כל SaaS . . .

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

12:38 עלילות Facebook עם הרישיון של React ומה שקורה היום(רן) כן, וזה גם קיים בעולם התשתיות -  נגיד React, מי שמכיר, גם היה סיפור עם רשיון, שחברות שמשתמשות ב-React, לפחות פעם, לפני שנתיים-שלוש, אסור היה להן לייצר רווחים מאותו מוצר, שזה מגוחך, כי כל מה ש... זאת אומרת, זה מגוחך, בתור מי שמשתמש, כי למה אתה בונה את ה-UI אם לא כדי בסוף לייצר רווחים?אז זה קיים לא רק בעולם “התשתיות ה-Hardcore”, אלא גם בתשתיות ה-Frontend-יות  . . . 

• (נתי) רגע, תספר לי שנייה על React, כי יכול להיות שאני צריך לדעת משהו שאני לא יודע . . . 
• (רן) אוקיי, אז אני לא יודע מה המציאות כיום . . . לפני כמה שנים היו מגבלות די משמעותיות בשביל השימוש ב-React, בתוך מוצרים... [Relicensing React, Jest, Flow, and Immutable.js].
• (נתי) אופס . . . 
• (אורי) נתי, כמו שאומרים - זה רק בינינו פה . . . 
• (נתי) כן . . . 

(רן) יכול להיות - הדובר אינו עורך דין ויכול להיות שלא הבנתי כהלכה - אבל אני כן זוכר שהיה שם איזשהו אישום, וחברות מאוד נזהרו במה שאפשר לעשות. [ובאופן כללי לא קיבלו את זה בהבנה - Facebook to Re-license React after Backlash from Open Source Community]
13:36 תקציר הימים האחרונים - (עוד) חדשות מטרידות וטקטיקות נלוזות

• (נתי) אז זהו . . . ועכשיו אנחנו מקצרים לקראת ימינו האחרונים ותקציר הדברים בימינו האחרונים.
• בעצם בסוף, אני חושב, שני סיפורים שאני חושב שהם הכי בעיניי בולטים ומייצגים מגמה מטרידה מאוד - שזה בעצם Open Source שמנצל את ה-Community ואת ה-Adoption, כדי באמת להגיע לגל הראשון של ההצלחה שלו - או לגל השני או השלישי, איך שלא, זה לא כל כך משנה.
• וברגע שטוב לו, והוא מרגיש מאוד חזק - בעצם משנה את ה-License והופך להיות Closed
• בצורה שהיא אפילו מאוד מאוד בוטה וברוטאלית, ואני לא יודע אפילו איך לתאר את זה בצורה . . .  אבל מאוד מאוד גסה.
• אז אני חושב ש-Terraform לקחו את זה למקום שבו, למרות שהם ידעו שיש Ecosystem שלם מאחורי זה, החליטו ביום בהיר אחד להגיד שלא רק שהם הופכים את זה לסוג של Closed, אלא שהם אלה שקובעים ורק הם יכולים לקבוע.
• זאת אומרת שלכל אחד שהם יכולים להחליט שהוא מתחרה שלהם, בעצם אסור לעשות שימוש.
• מי קובע מי מתחרה ומי לא? הם . . .
• אז אתה לא יודע אם אתה “תיפול” על התחרות למעשה . . . 

(אורי) אבל האם זה לא צד מגננתי, מה-Cloud-ים?

• (נתי) כן אבל - אם אתה חייב את ההצלחה שלך לזה שהיית ב-Community, ו-User-ים לקחו את המוצר שלך וכתוצאה מזה אתה בכלל קיים ואתה מוצלח, אז אתה לא יכול פתאום לשנות את כללי המשחק אחרי שהצלחת.
• אז כשלקחת את הצעד הזה ובנית על Adoption - וידעת על ה-Adoption הזה ועל הסיכון הזה, שישתמשו במוצר שלך, לצורך העניין . . .
• כל Open Source בנוי על הסטטיסטיקה הזאת - שיהיה “Abuse” באחוזים כאלה ואחרים
• ולכן אתה אתה יודע שכדי להגיע ל-Adoption, אתה מניח שיש אחוז Abuse
• קטן או גדול - זה כבר עניין של עד כמה אתה רוצה לעשות מזה כסף
• וזה התנאי שלך להצליח - ולכן אתה לוקח את הסיכון הזה.
• אתה לא יכול - אחרי שאתה מצליח - להגיד “אה פוס! עכשיו אני כבר גדול! תודה רבה Community שעזרתם לי להגיע לגודל שאני הגעתי, עכשיו אני משנה את כללי המשחק” . . . .
• שביום בהיר אחד אני מודיע לכם שמעכשיו, כל מי שמשתמש במוצר שלי מהנקודה הזאת והלאה הוא בעצם עובר עבירה.
• ועכשיו חברות שלמות שבנו מוצרים . . . 

(אורי) הם לא אמרו שהוא עובר עבירה, אלא הם אמרו “אנחנו נחליט מי עובר עבירה” . . .

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

(אורי) נתי, אני קצת ה-Devil Advocate פה - ממה נפשך? ממה הם רצו להתגונן?

• (נתי) הם רצו להתגונן מ-Amazon  . . . והם רצו להתגונן לא רק מ-Amazon, כי מ-Amazon זה דווקא היה חלק קל לדעתי עבורם להתגונן.
• הם רצו להתגונן כי - 
• א' - הם מנפיקים לבורסה, וכשאתה מנפיק לבורסה עוד יותר ניהיה Greedy, כי אתה רוצה בסופו של דבר למקסם רווח
• ואז אתה מתחיל להגיע לתקרות-זכוכית, ואתה רוצה כל הזמן לראות שאתה שובר את התקרות-זכוכית.
• הם אגב - בגלל קצב הגידול - הם בסוג של עדיין הפסדים למרות שהם גדלים ב-Revenue.
• אז המהלך שלהם היה . . .
• (אורי) אגב - זה כי הם ב-Cloud . . . 
• (נתי) גם יכול להיות . . .  זה כבר דיון אחר, לא נפתח אותו עכשיו . . . 
• אז אני אומר שכשקראתי את המהלך הזה ואמרתי “אוקיי משהו פה מאוד Fishy, זה לא נראה . . .”
• נראה שהם הלכו יותר מדי רחוק בצעד הזה - יותר רחוק מכל אחד אפילו שראיתי עד עכשיו.
• זאת אומרת - כמעט בלי התחשבות בכלל בקהילה.
• אז א’ - רואים שהיזם . . . לא Hashimoto, ברח לי השם שלו . . . 
• (רן) Hashimoto הוא היזם שיצר את החברה.
• (נתי) נכון - והוא כבר פחות פעיל.
• (רן) הוא כבר יצא מהחברה.
• (נתי) נכון, בדיוק - ואז בעצם אתה רואה שהייתה פה איזושהי השתלטות על החברה מהצד העסקי . . .
• (רן) מתי זה היה, השינוי הזה שהם עשו?
• (נתי) אני חושב ששנתיים פחות או יותר, די בצמידות למהלך הזה
• ואתה רואה שהרוח הזאת היא ש . . . כי Terraform, אני חושב, למשל אחד הדברים שבאמת אפיינו אותה זה באמת הליכה הזאת על Open Source בצורה מאוד, הייתי אומר כמעט כ-Role Model לאיך שבונים Open Source
• עם זה שהם באמת בנו תפיסה של One Product לכל פונקציה ולא לעשות איזשהו סוויטה (Suite) אלא ללכת על Product-ים שכל אחד הוא טוב בתחומו.
• ולבנות הרבה מאוד סוג כזה של מוצרים.
• בנו משהו לתפארת, באמת -  אני התחרתי בו בתקופות מסוימות.
• (רן) למי שלא מכיר את Terraform, זה כלי לתחזוקה ולניהול של Infrastructure. אותה חברה גם מייצרת את Vagrant.
• (נתי) יצרה את Vagrant - למעשה, Terraform צמחה מהניסיון ב-Vagrant.
• (רן) כן, שזה כלי לניהול של Virtual boxes, של Virtual Machines על מכונות קטנות, לטעמי. איזה עוד מוצרים יש להם אגב?
• (נתי) יש להם את Vault, שהרבה מכירים, שזה לעולמות ה-Security, ויש להם עוד כמה מוצרים אחרים, אבל בגדול, ה . . . 
• (רן) סדרה של מוצרים שהם Standalone, אבל כל אחד מהם מאוד טוב.
• (נתי) נכון. והם בנו מודל ממש מעניין לאיך הם בעצם בונים Stack מאחורי הדבר הזה, ואיך כל אחד מהם בעצם בסופו של דבר תורם אחד לשני.
• יש שם מודל עסקי לכשלעצמו.
• כמו המודל Open Source, גם המודל עסקי שלהם היה מאוד מאוד יפה ומוצלח - אבל הם הגיעו לנקודה שבה זה גם לא הספיק . . . 
• הם רצו להנפיק, כנראה במחיר מאוד גבוה - ופתאום גם . . .  וזה פחות או יותר הסביר את המהלך הראשון הזה, של להביא מנכ”ל שהוא יותר איש כספים ועסקי, ופחות מן הסתם רואה בקהילה . . .
• אני מכיר את השיח הזה מ-VCs שמגיעים לנקודה הזאת, אז אני יכול לראות את הלך-הדברים - ואני מעריך שלאותו יזם באמת היה פחות נוח כבר בסביבה הזאת, והוא הרגיש פחות . . .
• הוא היה מנכ”ל בתקופות האלה, ואני מרגיש שהלחץ הזה בעצם לעשות מוניטיזציה (Monetization) על חשבון Community כנראה “לא עבר לו טוב בנשמה”.
• וכנראה שזה עמד גם מאחורי המהלכים שהוא עשה - לקחת backseat אחרי הדבר הזה, אחרי הנפקה.
• וזו הייתה התגובה של ה-Community - בעצם, התגובה של ה-Community, ואני תכף אתן עוד כל מיני דוגמאות, כי יש כמה דוגמאות נוספות שמתחילות ללכת בקו הזה, זה להגיד “אוקיי, הבנו - אנחנו לא משחקים את המשחק הזה” - והם יצרו Fork.
• כש-Fork זה בעצם לקחת את הקוד לפני השינוי-רישיון, ובעצם לייצר פרויקט נפרד.
• ראינו את זה ב-MySQL, והיו עוד אי-אילו דוגמאות כאלה - לא כולן הצליחו, אבל זו תגובה מאוד לגיטימית של Community, שאומרת “זה שייך ל-Community. אתם הרווחתם את הזכות שלכם בכלל להיות במקום שאתם בזכות ה-Community, ואנחנו כ-Community נגיב וניקח את זה למקומות האלה”.
• הטענה, כמובן, של Terraform מהבחינה הזאת זה שמי שמממן את ה-Fork הזה אלו חברות For-Profits, . . . 
• זאת אומרת - זה לא כזה נקי, זה לא באמת Community.
• זה חברות שבעצם “רוכבות” על הגל הזה . . . 
• (רן) “מימון זר”, כמו שאומרים היום . . . 
• (אורי) לא, חברות שאומרות “יש לנו ביזנס מספיק גדול מעל ה-Primary, מעל ה-Truck, ואנחנו רוצים לשמר לעצמנו את ה...” . . . 
• (נתי) נכון, אז בשיח, אם אתה תראה, אז הם קוראים להם לא “Community” אלא קוראים להם “For-Profit”
• בכוונה מראש, כדי להגיד שזה לא באמת נקי.
• ובעצם משתמשים ברמה כזו או אחרת - ותכף ניגע ב-Linux Foundation ובתפקיד שלו בתוך הדבר הזה . . .
• אבל כמו שקרה ב-Elastic, אז בעצם חברות ה-Cloud הבינו שאם הם ייקחו Ownership על ה-Fork הזה, אז זה יצבע את זה בצורה מאוד נגטיבית
• אז לכן, מה שהם עושים זה בעצם מייצרים סוג של “Open Source נייטרלי” - והם בעצם עוזרים במימון שלו ובדחיפה שלו וב-Contribution אליו.
• וככה בעצם הם משאירים אותו עדיין Open Source - והם יכולים לעשות את המוניטיזציה (Monetization), והם מורידים מאחוריהם את האש טיפה . . .
• (אורי) בסוף זה שיווק . . . 
• (נתי) בסוף זה שיווק - והם טיפה מורידים . . . לא טיפה - הם מצליחים בדרך הזאת להפוך את עצמם מ”הרשעים” של העניין להיות, הייתי אומר, “המלאכים שמצילים את ה-Community”
• מזה שהחברה עושה עכשיו זה תרגיל של מוניטיזציה על חשבון ה-Community וכל מיני דברים מהסוג הזה.
• (רן) וקודם כל - זה מוצר של Microsoft או של Amazon, מייצרים איזשהו Foundation (לא כזה, כזה), תורמים אליו כסף - והנה אתם אלה שהצלתם את הOpen Source, “ועל הדרך” גם הם מרוויחים את זה.
• (נתי) בדיוק - והם יכולים לשמר את זה, ומן הסתם יש עוד חברות אחרות שממשיכות לתחזק את זה, ולא רק הם.
• וככה, פחות או יותר, זה נובע מזה.
• אז הייתי אומר שזו נקודה אחת.

22:42 הטופו שהגדיש את הסאה / שלום לתמימות

• (נתי) מה שככה הגדיש את הסאה בשבועות האחרונים זה היה תביעה של Terraform נגד OpenTofu, בחשש מ...

(רן) רגע, אז OpenTofu...

• (נתי) OpenTofu זה ה-Fork, שנוצר על ידי ה-Community, זה באמת חברות . . . 
• אני לא יודע כמה שחקני ה-Cloud מעורבים בזה - אני בטוח שכן, אני פחות בקיא בדיוק מי התורם וכמה.
• [ובכן - Linux Foundation Launches OpenTofu]

(רן) אז תביעה של Terraform נגד...

• (נתי) נגד OpenTofu - ש-env0 למשל, הם אחד מהתורמים היותר משמעותיים שם, אני חושב.
• ובעצם, התביעה היא ל-Infringement - זאת אומרת, להעתקה.
• בעצם, הם לקחו איזשהו Feature של Security, או מה שזה לא יהיה, והשווה קוד והראו שיש הרבה מאוד דמיון.
• ועכשיו התביעה היא בעצם להראות שהדמיון הוא לא באמת דמיון, ואין פה באמת העתקה.
• ראיתי תגובה של אחד מעורכי הדין שאומר שהעתקה יכולה להיות גם העתקה של רעיון, העתקה לאו דווקא של קוד, ועוד כל מיני דברים כאלה.

(רן) זה מזכיר לי נספח מתחילת שנות ה-2000, נגד Java?  . . . 

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

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

• (נתי) נכון, שהוא הפך להיות “פרימיום”, שהוא בעצם חלק מהמוניטיזציה שלהם.
• עכשיו כשחפרתי לראות, אמרתי “אוקיי, זה מהלך שהוא עדיין, גם אם הוא נכון, הוא נראה לי אגרסיבי מדי, אפילו ל-Terraform, אפילו כקרב הגנה”.
• ואז אמרתי אוקיי, משהו פה מאוד Fishy . . .  צריך לנסות לראות מה קורה שם ב-Terraform, מה המצב שלהם שם, למה פתאום זה עד כדי כך מטריד אותם . . . .
• (רן) או, הנה זה מתחיל להיות Juicy . . . .
• (נתי) כן . . . ואז מצאתי שבאמת הם התחילו לעשות שופינג לרכישה.
• כי א' - הם בסוג של הפסדים, וב' - הם כנראה ב-Peak של ה-Evaluation שיש להם כרגע - זה 5-6 ביליון דולר, כמה שזה לא יהיה.
• ומישהו שם עשה את החשבון, ואמר “מה-Peak הזה אני כנראה רק יכול לרדת”.
• ומן הסתם אם יש Open Source Fork, שבעצם מציג Terraform בדבר הזה, זה עושה Dilution - זה מדלל לי את הווליואציה (Evaluation), ולכן זה משהו שיכול לעלות לי הרבה מאוד.
• כי מן הסתם, אם אני לא סופר את זה בכמה זה פוגע לי בהכנסות הרבעוניות, אלא כמה זה פוגע לי בווליואציה (Evaluation), בדרך כלל המספרים בווליואציה הם מכפילים הרבה הרבה יותר גדולים, ואתם  כולים להגיע בקלות לביליון דולר רק באחוזים של פגיעה.
• ואז המוטיבציה כן לעשות “תקיעת טריז” הופכת להיות הרבה יותר משמעותית והגיונית, אפילו מבחינת הצד שלהם,
• כי בצד העסקי זה נראה ככה.
• אז אני חושב שזה מספר איזשהו סיפור מסוים, כשאני אומר עוד פעם - השורה התחתונה: כל קהילת הOpen Source שמסתכלת על זה, אני חושב שה-Output מהדבר הזה זה שזה כבר לא Open Source . . .
• הבנו כבר שזה לא רומנטי, ושיש פה מודלים עסקיים.
• ושזה לא כמו שאתה חשבת, שזה רק בחינם - אז אנשים לא עובדים בחינם, הם עובדים בשביל כסף.
• אבל כנראה שגם אם אתה Open Source, ברגע שנכנס כסף - אז גם טוהר מידות לצורך העניין, או “טוהר הנשק”, הולך קצת לאיבוד בדרך.
• בטח אם אתה VC-Backed.
• וזה מעקר...
• (אורי)  . . . . התמימות . . . 
• (נתי). . .  התמימות הולכת. 
• אבל אני אומר - זה מעקר . . . זה כאילו לכרות את הענף שאתה יושב עליו, לדעתי, וכן יש פה משהו מאוד טיפשי בסופו של דבר.

(רן) מצאתי שם לפרק - “שלום לתמימות”.

• (נתי) האמת יפה, אהבתי. יש שיר כזה.

26:57 עולמות ה-AI הפתוחים(רן) חשבתי אולי לעבור אלו עולמות ה-AI . . .

• (נתי) זה בדיוק הפרק הבא . . . 

(רן) . . . “השפה הכי פתוחה בעולם” . . . 

• (נתי) בדיוק. אז הפרק הבא זה מה שכבר נהיה מאוד Juicy, זה OpenAI.
• הביטוי “Open AI” - ואני חושב שכולם מבינים שבין “Open” ל-”AI” ולמעלה בחברה . . .

(אורי) בין “Open” ל-OpenAI . . .

• (נתי) כן, אז היה עכשיו, לאחרונה, למה זה הפך להיות Juicy? כי הייתה תביעה של Elon Musk נגד החברה של OpenAI.
• כשהייתי אומר, הקוריוז שהוא עשה שם זה שהוא אמר “אני מוכן להוריד את התביעה, אם עכשיו לא תקראו לזה “Open AI” אלא תקראו לזה “Closed AI” . . . “.
• ואם תשנו את השם, אני אמחק את התביעה.

(רן) נזכיר ש-Musk השקיע בעבר, אחד המשקיעים הראשונים של החברה . . .

• (נתי) נכון, ב-2018.

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

• (נתי) החברה הייתה באמת . . . וגם ה-Entity הזה שנקרא OpenAI הוא עדיין חברה שהיא Not for Profit
• היא חברה שהיא סוג של מלכ”ר, ללא מטרות רווח.
• אבל בעצם העבירו - ופה יש הרבה מאוד סימני שאלה, וגם ה-Federal הולך להיכנס חזק מאוד לדבר הזה, של איך נעשתה בדיוק העברה, בין החברה שהיא Not for Profit לחברה של OpenAI היום, כי . . . 

(רן)  . . . העברת IP . . . 

• (נתי) העברת IP, בדיוק - כי בעצם יש פה העברת נכס, ואז יש פה אירוע מס, למעשה.
• יש דרכים, אגב, לעשות את זה - אבל זה אירוע שיכול להיות מאוד מורכב.
• וממה ששמעתי בלא מעט פודקאסטים שמדברים על זה, כנראה שזה לא היה תפור והדוק בכל הרבדים.
• ויש פה חשיפה כנראה מאוד מאוד גבוהה ל-OpenAI סביב התביעה הזאת.
• מה שכן, אפרופו זה שאף אחד לא תמים בסרט - Elon Musk בעצמו, הוא מדבר כאילו בשם ה-Open Source, ושהוא כועס על זה שהם חרגו מה-License שלהם.
• אבל הם בעצם חשפו, כתגובה, את התכתובות שהיו בינם לבין Elon Musk סביב הנושא הזה.
• זאת אומרת, מה שהיה הרקע זה שהם הבינו שיש פה משהו מאוד מאוד גדול - ושהוא ידרוש הרבה הרבה הרבה כסף כדי להגיע למצב שאתה בונה מודל, שבעצם “מכיל את כל האינטרנט”.
• וכדי להגיע לדבר כזה, הבינו שצריך לעשות פה כסף מאוד גדול.
• ו-Elon Musk - יאמר לזכותו היה בין הראשונים שהבין את זה גם.
• זאת אומרת, בא ואמר להם “אוקיי, אתם, כדי ליישם את המודל העסקי שלכם, יש פה פוטנציאל מאוד גדול, אתם תצטרכו הרבה הרבה הכסף”.
• זה כבר לא סטארטאפ, במובן של “סטארטאפ” - זה אפילו לא 100 מיליון דולר, זה ביליוני דולרים.

(רן)  פה אנחנו מדברים ב-Timeline של מה? לפני כמה - ב-5 שנים?

• (נתי) זה תחילת ה-GPTs . . . אני חושב GPT1 . . . 

(רן) כשעולם עוד לא כל כך ידע . . . 

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

(רן) נתת לי עוד שם לפרק - “הראשון לזהות” . . . .

• (נתי) אז באמת מה שקרה שם, זה שהוא הציע להם - לטענתם, ורואים את זה בתכתובות באימיילים, אמר “אוקיי, בואו תיכנסו תחת Tesla, ו-Tesla תהיה המימון שלכם”.
• אבל בעצם זה הופך להיות סוג-של-בבעלות שלו . . . 
• ואני חושב שכנראה שזו אחת מהסיבות שהם לא רצו ללכת על עסקה כזאת.
• במקביל, Microsoft נכנסו - השקיעו בהתחלה המאה מיליון דולר שלהם, ולאט לאט בעצם לקחו אחוזים מאוד גדולים מהחברה.
• ולא ברור כל כך, כבר מבחינת המבנה - גם מבנה ההון וגם מבנה השליטה . . .
• (אורי) ה-Cap Table . . .
• (נתי)  . . . איך בדיוק היחסים האלה עובדים.
• וזה נראה שיש פה איזה גם תרגיל לא תפור ב-100 אחוז
• למרות ש-Microsoft ניסו כנראה - יותר ממה ש-OpenAI עשו - עשו הרבה יותר גידורים למהלך הזה.
• אבל עדיין יש פה איזושהי חשיפה.

(רן) השקיעו בסוף יותר מ-100 מיליון . . . 

• (נתי) השקיעו מיליארד דולר בסופו של דבר, כדי לקבל בעלות שהיא מעל 50 אחוז - ובאמת יש פה הרבה מאוד שאלות, למי שמסתכל על זה - לאן זה הולך ומי בעל השליטה ומה זה אומר . . . .
• והנזק, אני חושב שוב פעם, לדבר הזה - זה נזק / תועלת לצורך העניין, אתם לא יודעים איך מסתכלים על זה - זה שאם OpenAI היו באיזשהו מומנטום של “אנחנו כבשנו את עולם ה-AI ואנחנו עשרה צעדים לפני כולם”.
• אני חושב שהרבה אנשים לוקחים עכשיו טיפה צעד אחורה, להגידו “אוקיי, יש פה משהו מאוד מאוד גדול, מאוד Disruptive, אפילו Existential - משהו שיכול באמת להוות “להיות לחדול” מבחינתנו - אבל אנחנו לא יכולים להמר על משהו כזה”.
• ואז בעצם זה גרם להרבה לקחת גישה של “חזרה ל-Open Source” . . . 
• ובעצם Facebook יצאו עם Llama 2, והם מפתחים אותו מאוד והוא ממש מגיע למקומות טובים.
• ובעצם אנחנו רואים סוג של חזרה של Open Source בעולם ה-AI
• כדרך להוריד את ה-Risk של מודלים סגורים ושל ה-Giant-ים האלה, שכל העולם פתאום הופך להיות תלוי בהם, והמידע של כל העולם יושב אצל שחקן אחד, והוא בעצם עושה Scanning לכל העולם.

32:15 ההבדל המרכזי(אורי) כן, אבל אני חושב, אני רוצה, שנייה, להגיד בסוף את ההבדל המרכזי - להבדיל מה-Open Source-ים שדיברנו עליהם, מה שנקרא “בחלק הקודם של הפרק הזה”, פה יש Barrier to Entry שהוא מאוד מאוד Significant-י, שזה כבר לא משנה אם הקוד הוא פתוח או לא. יוכל לתת את השירות הזה רק מי יש לו את הכוח הפיננסי להרים תשתית ענקית.

• (נתי) אז כן ולא . . . כן ולא.

(רן) לא, שנייה - זה מה שעשו Facebook עם Llama, לצורך העניין - הם הורידו את ה- Barrier to Entry בצורה מאוד מאוד משמעותית, וכמעט כל אחד יכול להריץ . . . . נכון, זה עולה קצת, אבל זה לא ברמה של מיליארדים.

• (נתי) אני אחדד את זה - אני חושב שאם אתה מסתכל על מודל GPT, כמו שהוא באינטרנט, שהוא בעצם General AI, והוא בעצם נועד לתת לך תשובה לכל דבר ועניין, אז באמת אתה עדיין מדבר על אופרציה מאוד מאוד יקרה.
• אבל יש גם מגמה של מודלים מאוד יעודיים - זאת אומרת, לבעיות מאוד ספציפית, ל-Data מאוד ספציפי.
• כשאתה בעצם רוצה מנוע שבמקום לעשות שאילתות או Search ב-Data, אתה רוצה משהו שיש בו קצת “לוגיקה אנושית”, שנותנת לך מעטפת.
• יש המון Use Case-ים כאלה - המון המון Use Case-ים, שאתה יכול לעשות אותם ב-Footprint הרבה יותר נמוך
• אתה יכול לעשות אותם ב-Scale הרבה יותר נמוך, בעלות מאוד נמוכה - ו-Open Source הוא קלאסי לדבר הזה.
• אז אנחנו ממש רואים Adoption מאוד מאוד גדול של Open Source לאזור הזה.
• וכמובן, זה . . .

(אורי) כן, אבל זה מוצר שונה, בסוף זה מוצר שונה, זו חוויה שונה . . . 

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

(אורי) כנראה ששכחת כי הם ניסו ולא הצליחו . . . .

• (נתי) לא לא . . . היו חברות שניסו לבוא ולהגיד “אנחנו נהיה ה-Open Source של GPT”, ממש Head to Head . . . 
• יש איזה Poster-Child מאוד גדול, שברח לי השם שלה עכשיו . . . 

(רן) ויש את Mistral . . .

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

(רן) המתמודדים הגדולים זה Mistral . . . 

• (נתי) עכשיו גם Microsoft קנו את  . . ..  לא Anthropic, ברח כלל גם השם שלהם - הם קנו עכשיו חברה שבעצם, הם עשו מהלך שהוא סוג של Acqhire, במחיר מאוד גדול,כמעט ביליון דולר גם . . .
• בסכום מאוד מאוד גדול, שכאילו לא מסתדר עם Acqhire - וגם פה התיאוריה היא שבעצם זה מהלך שנוצר כדי לעקוף את הרגולציה . . .
• כי מן הסתם, אם הם היו קונים אותם, כ-IP, אז זה היה שם אותם, היות ויש היום כבר הרבה מאוד עיניים . . . 
• ששמים עין על Microsoft בהקשר של הגבלה עסקית והאם הם הופכים להיות סוג של מונופול.
• אז כדי לא להגיע למקום הזה, אז הם עשו סוג של Acqhire מאוד מוזר, מן תרגיל פיננסי כזה, שאני קונה את האנשים - אבל לא את החברה . . .
• החברה נשארת “חברת שלד” וממשיכה לתפקד - אבל אני משלם פרימיום לאנשים, וככה אני מרצה גם את בעלי המניות, ועובר מתחת לרדאר של האירוע-מס לצורך העניין, או אירוע-רגולציה, שיכול לקרות מאחורי הדבר הזה.
• [מניח שהכוונה לקרקס הזה עם Inflection]

36:16 תקצירים, משמעויות - והנשורת של כל התופעה הזאת

• (נתי) אני חושב שאם אני מחבר את זה לתקציר הפרקים הקודמים, הייתי אומר שני דברים.
• אחד - אנחנו רואים שמה שהיה נכון לOpen Source בעולם ה-Infrastructure נכון אפילו עוד יותר לעולם ולמגמות של Open Source בעולם ה-AI.
• רק שהמשמעויות של זה הן הרבה יותר מרחיקות לכת - כי AI היום הוא משהו שהוא נוגע בכל ה-Stuck.
• הוא משנה את כל התעשייה - מן הסתם את כל ה-workforce ואת כל ה . . . 
• בין אם זה עורכי-דין, בין אם זה רפואה, בין אם זה IT, בין אם זה אומנות, בין אם זה שירה . . . .כל דבר כמעט שאתה נוגע בדבר הזה.
• לכן השאלות האלה הופכות להיות עוד יותר משמעותיות.
• וכשאני מסתכל על זה, ממרום גילי, על ההיסטוריה הזאת - שרוב האנשים לא מכירים אותה - אז אני יוצא מאוד מוטרד . . .
• כשגם הבשורה של ה-Open Source - אני לא בטוח שהיא באמת בשורה אמיתית, שתחזיק מים.
• כשמעורב פה מן הסתם הרבה מאוד כסף - ואנחנו רואים מה הכסף עושה לOpen Source.
• ולכן אני חושב שזה קצת נאיבי לחשוב שOpen Source ייתן פתרון “דמוקרטי", נקרא לזה ככה, לעולם הזה.
• זה החיבור שאני עושה בין שתי המגמות האלה ובין הסיפורים האלה.

(רן) טוב, אולי דמוקרטיה is overrated . . .  

• (נתי) זה מאוד רלוונטי לימינו אנו . . .

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

• (נתי) לגמרי.
• אני חושב שמה שהייתי לוקח מזה, בתור שומע, זה א' - את “הכוכבית אזהרה” הזאת: שקודם צריך להיות מודעים לזה, ולדעת שיש פה את הסיכון, ושלפעמים אתה לא יכול לגדר את הסיכון. לפעמים העלות של הגידור של הסיכון היא יותר גדולה מאשר לקחת את הסיכון.
• אבל הסיכון הזה הוא בהחלט נוכח וקיים, ואסור להיות נאיביים ולהגיד “אה, לקחתי מודל Open Source, ולכן אני גידרתי את הסיכון דרך זה שלקחתי משהו Open Source” - זה יכול להתהפך די בקלות.
• וגם אני חושב שיש הרבה מאוד חוסר מודעות ל-License-ים סביב הOpen Source - זה License-ים פי-מיליון יותר מורכבים, שיפרנסו פה תעשייה שלמה של עורכי דין, ומוצרים שלמים שרק יעשו Scanning כנראה ל-License-ים, כדי לראות כמה חברות כבר עשו Breach לLicense-ים האלה . . . 
• יש חברות שאומרu, ש”מותר לך להשתמש בקוד - אבל לא בפרמטרים . . . ולא בפרמטרים מהסוג הזה, ואם ה-Data נמצא שם אז זה Liability שלך ולא שלי” . . . .
• זה עולם שהוא עץ סופר-מורכב - ואני חושב שרמת החוסר-מודעות או הנאיביות או החזרה על טעויות שאני רואה בתעשייה, שהולכת לקרות סביב הדבר הזה, באמת הולכת לפרנס סטארטאפים שלמים ותעשייה שלמה רק  בלהתמודד עם הנשורת של כל התופעה הזאת . . . .
• אז אם אני יכול לתרום במשהו למישהו - אז הנה הכוכבית אזהרה: שמנו את זה על השולחן, ובאמת תדעו את זה ותיכנסו לזה בעיניי פקוחות.
• זה אחלה Open Source - אבל הוא לא חף מסיכונים.

(רן) טוב, ובנימה אופטימית זו - שלום לתמימות.תודה רבה, נתי. האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]
פרק מספר 469 של רברס עם פלטפורמה - הוקלט ב-9 באפריל 2024. אורי ורן חוזרים לאט לקצב ומארחים את שי ילין לשיחה על איך מהנדסים תוכנה בחברות צעירות: Do & Don’ts של חברות שאולי רק עכשיו התחילו. שי מלווה לא מעט חברות כאלו - והוא גם מודרטור (בכנס האחרון) ומרצה ותיק בכנסי רברסים [How Scala promotes TDD ב-2013, Putting the 'D' in TDD ב-2015 ו-You (probably) Don't Need Global State Management ב-2022] וגם מארגן של כנסים אחרים.
01:40 רקע על שי ותנועת הזמישות(רן) אז שי - כמה מילים עליך? ספר לנו עליך . . .

• אז אני שי. בשלוש וחצי השנים האחרונות עמצאי, כשאני מחלק את הזמן שלי בין שלושה תחומים עקריים בחיים  שלי:
• יש לי שני ילדים - תום ואדם.
• אני עושה מוזיקה, בכל מיני קונסטלציות - חלק מהן יותר וחלק מהן פחות מצליחות מבחינה מסחרית ועסקית.
• ורוב הפרנסה שלי מגיעה מייעוץ לסטארטאפים וחברות שהן כבר לא סטארטאפים, או שהיו סטארטאפים או בדרך להפוך מסטארטאפים למשהו יותר מסודר . . .
• ובעצם, אני נותן שירותים לחברות שהן סטארטאפים או חברות שהן מיושבות יותר, של איך בונים מערכות וארגונים שקל לעשות להם שינויים.
• בעצם, אנחנו רוצים שגם . . .  ככל שהחברה יותר צעירה, שגם נוכל לעשות שינויים לקוד, ל-Codebase, לתשתיות - וגם לארגון עצמו, בצורה יותר קלה.
• אנחנו רוצים גמישות, אנחנו רוצים פחות נוקשות - כי אנחנו עדין לא יודעים איך המערכת צריכה לראות, מהן הבעיות שנתמודד איתן, ואיך הארגון צריך להיראות ומה הבעיות שנתמודד איתן.
• וחלק ממה שמייחד את מה שאני עושה זה שאני עובד גם עם מנהלי פיתוח וגם עם מהנדסים.
• עם מנהלי פיתוח אני עושה יותר Mentoring וארכיטקטורה ותכנון של בניין הכוח.
• ועם עם המהנדסים אני עושה יותר דברים כמו Pair Programing ו ו-Code Reviews ו-Design-ים.
• ואז בעצם אנחנו נותנים מענה הוליסטי לאיך שאנחנו יוצרים ארגונים ומערכות שהם גמישים ושהם ניתנים

לשינוי בקלות. 
(רן) כן, כמובן בתוך הנחה שסטארטאפ בדרך כלל “Doesn't know $h!t”, הוא לא יודע . . . כל מה שהוא יודע זה אולי שהוא גייס כסף ושהוא רוצה לייצר מוצר. אבל חוץ מזה לא הרבה, והדבר הכי חשוב זה גמישות - היכולת לבוא ולשנות כיוון . . . (אורי) אני רוצה לאתגר את זה . . . כי באמת, סטארטאפ “Doesn't know $h!t”, בעיקר לגבי העתיד שלו - המוצר יצליח, לא יצליח? נצליח לגייס את האנשים הנכונים? אולי לא, אולי כן . . . נצליח לגייס כסף? אולי כן, אולי לא . . . אבלאנשים באים לתוך הסטארטאפ עם איזשהו ניסיון חיים, בין אם הם Founder-ים פעם שנייה או . . . גם בחברות שהםעבדו בהם, הם מגיעים עם “משהו” . . . 

• (שי) זה מאוד נכון.
• אני חושב שמשהו שאני ראיתי זה ש-Founder-ים שהם 2nd Timers - הם כבר יודעים שהם לא יודעים  . . . 
• הם יודעים את הבעיות שלהם והם יודעים לחפש את הגמישות הזאת.
• לעומת פאונדרים שהם 1st Timers - שהרבה פעמים הם רצים מהר והם מנסים לתכנן קדימה, והם מקבעים דברים מוקדם מדי.
• בין אם זה לתת Title-ים מוקדם מדי, בין אם זה לפתור בעיות Scale שלא קיימות . . . 
• כל מיני אופטימיזציות שאנשים עושים ושלדעתי הם לא הדברים הנכונים.
• עכשיו, גם אם אני מהנדס - הייתי מהנדס בחברה גדולה, ועכשיו אני מגיע לסטארטאפ - לא בהכרח הכלים שהשתמשתי בהם בחברה הגדולה יתאימו לסטארטאפ.
• ואם אני מהנדס מנוסה, אבל עדיין לא “אכלתי קרבות קשים כאלה”, אז אני עלול להיות מסוגל לעשות אופטימיזציה מוקדמת מדי - Over-Engineering - כדי לפתור בעיות, כי אני “מפחד מהלא-נודע”, כי אני לא יודע מה יקרה.

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

• [עוד רקע כאן  - פרק 443 Hiring for strength, not skill with Sahaf from Hippo]

• (שי) ללא ספק, אני חושב  . . . מה זה סתגלתנות? זה אדפטיביות, נכון? זה בעצם Agile, נכון? מה ש-Agile בא להגיד לנו . . .
• (אורי) . . . אנחנו מתרגמים את זה לעברית, כאילו . . .
• (שי) “זמיש”, נכון? הם קוראים לזה “זמיש” . . .  אז “תנועת הזמישות”, שהופיעה לפני 20 ומשהו שנה - אני חושב שאחד הדברים שהם דיברו עליהם, זה שהמונח Agile היה פשרה
• הם בכלל רצו לקרוא לזה “אדפטיביות” או או “אדפטיביליות” או משהו כזה.
• כי בעצם, אנחנו רוצים לאמן את עצמנו להתמודד בצורה יותר טובה עם דברים שאנחנו לא יודעים מה הם יהיו
• (אורי) . . . לחזות אותם . . .
• (שי) נכון - אנחנו לא יכולים לחזות את העתיד, אין לנו יכולת לחזות את העתיד.
• והרבה פעמים, באופן אבסורדי, בניסיון לחזות את העתיד, בניסיון לפתור בעיות שתגענה - אנחנו עושים “הכנות למזגן”, אנחנו עושים מה שנקרא “YAGNI - “You  Ain't Gonna Need It. בעברית זה “הכנה למזגן”, זה בדיוק מאוד יפה.
• ומה שקורה עם הכנות למזגן זה שבדרך כלל כשאתה צריך מזגן - אז ההכנה לא מתאימה לו . . . 
• ואז יש לך שתי בעיות . . .
• (רן) . . . כבר יש התחממות גלובלית, צריך מזגן הרבה יותר גדול . . . כל מה שהכנת כבר לא רלוונטי . . . 
• (שי)  . . . התשתית לא רלוונטית, השקע-חשמל לא רלוונטי, עשית חור בקיר אבל אתה מתקין מזגן מפוצל . . .

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

• (שי) אני . . .  קודם כל - אין לי ניסיון הרבה יותר נרחב או מיוחד מאשר הרבה אנשים אחרים.
• אני הצטרפתי ל-Wix ב-2010 - התמזל מזלי להכיר את Wix יחסית מוקדם.
• וגדלתי עם Wix, מכ-20 מהנדסים למשהו כמו 1,000, ועשיתי תפקידים של פיתוח ושל ראש צוות ושל ראש קבוצה ובניין הכוח בחברה . . .
• ועשיתי מלא טעויות - מלא, מלא, מלא טעויות.
• יש אנשים ב-Wix שמקללים את השם שלי - וזו פריבילגיה שאין להרבה אנשים . . .
• וזה דבר אחד שקרה לי, שהוא מיוחד.
• אבל מעבר לזה, אני חושב שיש לי נטייה להיות יחסית ביקורתי, ולהסתכל על תהליכים וטקסים - ולפקפק בהם, תמיד.
• לפעמים יותר מדי . . . 
• אבל זה עוזר לי לפעמים לראות דברים שאנשים עושים ולשאול - למה?

08:02 בואו נתחיל ב-Monolith-ים ואחר כך נדבר - מחפשים צרות עם Monolith-ים ו-microService-ים(רן) סבבה, אז בוא נהיה יותר ספציפיים עכשיו. אז אתה אומר - יש טעויות שאנשים . . . אתה יודע, בין אם זהכי יש להם אפס ניסיון או בין אם זה כי יש להם מלא ניסיון, שעושים כשהם מגיעים לסטארטאפ היחסית-צעיר שאיתו אתה עובד.בוא נמנה כמה מהם - נדבר על מונוליטים [Monolith], נדבר על microservice-ים? . . .

• (שי) כן, יאללה -  אני גם עשיתי על זה Blogpost לא מזמן [ - Of Rigid Microservices and Flexible Monoliths], והוא היה די שנוי במחלוקת . . .

(רן) . . . To be or not to be - Monolith or microservice” - let's go”

• (שי) אז התשובה היא כמעט קטגורית “להתחיל מ-Monolith” . . . 
• נתקלתי בכמה מקרים: עבדתי בסטארטאפ - בעצם, המשרת-שכיר האחרונה שלי הייתה בסטארטאפ, שבו היה CTO שהחליט שהוא בונה Design מאוד מאוד מאוד Strict לחלקים של המערכת, כדי לאפשר לרוץ מהר ולפתח כל חלק בנפרד.
• אז הוא בעצם יצר אוסף של Inerface-ים והגדיר היטב את הממשקים ביניהם ואיך כל אחד מתנהג …
• ומה שקרה זה שזה יצר קשיחות מאוד מאוד מאוד גדולה - ואי אפשר היה . . . היה מאוד קשה לעשות שינויים ב-Interface-ים האלה
• בגלל שהתחלנו מ . . . אפילו לא התחלנו מ-microservices - הוא רצה להתחיל מ-microservices
• ואז אמרנו “רגע - לא צריך Process-ים נפרדים, בוא נעשה Modular-Monolith
• נשים את כל אותם מימושים בתוך אותו Process, הם ידברו אחד עם השני דרך הזיכרון - כאילו, In-process ולא דרך הרשת.
• אבל הייתה התעקשות להשאיר את ההגדרה של ה-Interface-ים ב-Protobuf, בקבצי IDL של Protobuf
• שזו בעצם שפה שהיא Language-Agnostic - היא לא קשורה לשפת פיתוח ספציפית, שמגדירה ממשקים של מערכות Web, מערכות אינטרנט.
• אז יש לנו Interface-ים, ממשקים, ויש לנו Instruct-ים  . . . 
• (רן) כשהטכנולוגיה לכשלעצמה היא מצוינת - רק לעוד חמש שנים או עשר שנים . . . 
• (שי) הטכנולוגיה מעולה - אם צריך microservices . . . .
• אבל ברגע שאתה מכניס את העובדה שצריך לעשות כל שינוי ב-Protobuf ואז לג’נרט (Generate) קוד לשפת הפיתוח שאתה משתמש בה, זה הופך כל שינוי להרבה יותר קשה ומורכב.
• וזה בעצם כאילו זה אומר לאנשים “רגע - יש פה גבול, אי אפשר לשנות אותו” - ואז האנשים לא מפקפקים  בגבול הזה.
• (רן) . . . או שהם עוקפים אותו בצורה מוזרה . . . 
• (שי) . . . או שהם עוקפים אותו בצורה מוזרה . . . היה לי לקוח שהתחיל מ-microservices, כי היו לו מהנדסים שהגיעו מחברות שבהן עשו microservices.
• ואז הם התחילו את המערכת עם מספר לא קטן של microservices ב-Node - ואז אי אפשר לעקוף את זה בצורה הזאת, זה ממש כאילו “לצאת לרשת” . . . 
• ואז אתה משלם את “המס” של בעיות Scale - לפני שיש לך בעיות Scale . . . 

(אורי) אני חושב שאם אנחנו מדברים על microservices, תמיד יש את הוויכוח “Monolith או microservices” וכו' . . . ל-microservices יש תכונה, שהיא טובה מאוד ב-Scale - אבל פחות ב-Scale של מערכת או של ב-Scale הטכנולוגי או ה-Performance או זה, אלא דווקא ב-Scale של ארגון הפיתוח . . .(רן) HR-י . . . . נכון, לכל צוות יהיה את ה-Service שלו - או או שניים-חמישה שלו . . . (אורי) . . . זה יוצר Decoupleing כזה “טוב” - ואז אתה אומר לעצמך “רגע, מתי אני אגיע לבעיה הזאת?” יכול להיות שהקיר הוא עוד הרבה יותר רחוק ואתה מפספס הרבה מאוד אג’יליות (Agility) שיש ב . . . (רן) כן - אבל כל אחד שמסיים עכשיו לימודים והולך קצת ללמוד על איך נראה עולם הפיתוח “האמיתי”, אז הוא לומד  שאוקיי, יש Bug Management systems ויש Git - “וצריך זה” ו”צריך microservices”, נכון? זה מה שלומדים - לצערנו. הרבה שמסיימים את הלימודים שלהם באים ואומרים “אוקיי microservice-ים! זה הדבר, את זה אני צריך להכיר וזה מה שאנחנו הולכים לעשות בחברה שלי!”. או, מצד שני - אם הייתי בחברה גדולה אחרת, ושם כולנו עשינו microservices, אז ברור שגם בסטארטאפ שלי, אני מראש אבנה אותו Robust-י עם microservices - ושי אומר שזו טעות. אתה מקדים בהרבה מאוד את מאוחר, ואתה הולך לשלם על זה מחיר מאוד כבד בזמן שאתה בכלל לא צריך. (אורי) הרבה פעמים משחררת קצת התפיסה הזאת של “הקוד הזה הולך להימחק” . . . .

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

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

• (שי) אני חושב שאנשים מסתכלים על תוכנה בצורה לא נכונה - אני חושב שאנשים מסתכלים על תוכנה כ”משהו שאנחנו בונים”.
• אבל תוכנה זה לא משהו שאנחנו בונים - זה משהו שאנחנו “מגדלים”, כמו גינה, כמו עץ.
• וכשהעץ צעיר, אז הוא שתיל קטן, עם גבעול רזה - והוא יכול להתכופף.
• וככל שהוא גדל ומזדקן, אז הגזע מתעבה ונהיה יותר עצי וקשה.
• ומערכות תוכנה הן אותו הדבר - הן מתחילות כמשהו מאוד קטן, ואתה רוצה לגדל אותן באופן הדרגתי.
• אין לך מושג מה יהיו בעיות ה-Scale שיהיו לך.
• אין לך מושג מה יהיו “גבולות הגזרה” - מה שנקרא ה-”Bounding Context”, ההבדלים ב-Domain-ים השונים שאתה הולך להתעסק איתם.
• עוד חצי שנה, עוד שנה, עוד שנתיים . . . מתי שזה לא יהיה שתזדקק - אם בכלל תזדקק ל-microservices.
• וכמו שאורי אמר - microservices זה פתרון לבעיה. 
• זו לא אסטרטגיית פיתוח או אסטרטגיית ארכיטקטורה של קוד - זה פתרון לבעיה שהיא בעייה ארגונית: איך אני מאפשר לצוותים שונים לעבוד בו זמנית, לעשות Deployment בו זמנית, בלי לדרוך אחד לשני על הרגליים, בלי לעשות Coupling בין פיצ'רים (Features) שלא קשורים אחד לשני.
• לפעמים, microservices הם גם פתרון לבעיה ארכיטקטונית - אם יש לי שתי מערכות שונות, אחת צריכה להיות ב-High-Throughput אבל לקריאה בלבד ואחת היא ב-Throughput יותר נמוך והיא לקריאה וכתיבה, אז זה הגיוני לחלק ל-microservices, ולעשות איזשהו תהליך של להעתיק את המידע ביניהן.
• אבל אלו מקרים מאוד מאוד מאוד ספציפיים, ורוב החברות לא צריכות microservices.
• בטוח לא עכשיו - בשלב הראשון, כשאנחנו רק מגששים ומנסים להבין מה ה-Product-Market Fit שלנו.

14:55 סיכום ביניים - תבנה “Monolith טוב”(רן) אז לקח מספר אחד עד כה, נעשה סיכום ביניים - אם אתם מתחילים איזשהו מוצר תוכנה צעיר, איזשהו “שתיל” כזה, שהוא עדיין גמיש - יכול Monolith-ים, זה בסדר, יש Framewrok-ים טובים . . .(אורי) . . . מה שמביא לכם את ה-Product הכי מהר . . . .(רן) . . . . כן, יש Framewrok-ים טובים גם בעולם ה-Monolith-ים, והם כנראה יאפשרו לכם את הגמישות שאתם  צריכים בשלב הזה, וזה בסדר. אחר כך יהיה זמן לעשות Refactor . . . אתם גם ככה הולכים, כמו שאורי אמר, למחוק את הקוד, אתם הולכים לעשות Refactor באיזשהו שלב, וכנראה שתייצרו איזשהם microservice-ים, אם תצטרכו. אבל תעשו זה כשאתם צריכים, כי המחיר הוא גבוה - המחיר של לשלם על microservices בשלבים המוקדמים האלה הוא מאוד מאוד גבוה.

• (שי) אני רוצה להוסיף ש-Monolith - יצא לו שם רע . . . .
• כאילו, זו נהיתה מילה גסה כזאת - “מה? Monolith?! מה זה, “קוד ספגטי”? זה Big Ball of Mud . . . .
• לא - זה לא חייב להיות ככה. 
• תבנה Monolith טוב, תעשה Refactor-ים תכופים בזמן שאתה בונה את ה-Monolith.
• אתה תקבל Monolith מודולרי.
• וכשתרצה - אם תרצה - לקחת איזשהו נדבך ממנו ולהוציא אותו החוצה ל-Process נפרד, זה פשוט יהיה להרים אותו ולהעביר אותו הצידה לשתול אותו ב-Process אחר.
• כמו שאנחנו עושים השתלה של עץ או של שתיל מגינה לגינה.

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

• (שי)  . . .  

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

• (שי) אז אני אגיד שקודם כל - המטרה של טסטים זה לא למצוא באגים. 
• זאת אומרת, כשאני מוצא באג, אז אני משחזר אותו בטסט שנכשל, ואז אני יודע שהבאג הזה לא יחזור.
• אבל המטרה של טסטים זה להוכיח לי שהמערכת עובדת.
• זאת אומרת, אם עכשיו כתבתי קוד, והקוד הזה עושה משהו והוא עובד - זה מקרי שהוא עובד . . . אין לי שום הוכחה שהוא עובד.
• אני רוצה את היכולת לדעת, בכל רגע נתון, שהמערכת שלי עושה את מה שהיא אמורה לעשות, שהפיצ'רים עובדים.
• עכשיו, זה לא משנה אם אני עכשיו כותב Prototype, ואני מנסה להתכנס על Product-Market Fit,  או שאני כבר בשלב של Expansion או של Hyper-Growth, של גדילה מהירה.
• אני עדיין צריך לדעת שהפיצ'רים עובדים - וזה מגוחך בעיניי שאנשים לא כותבים טסטים לפיצ'רים שלהם. 
• עכשיו, זה לא אומר שאתם צריכים לכתוב עכשיו מלא מלא מלא Unit Test-ים . . .
• צריך למצוא את “נתיב הזהב” שבין לכתוב יותר מידי טסטים שבודקים פרטי מימוש, ואז אנחנו בעצם מבזבזים את הזמן שלנו על שטויות, על לכתוב טסטים שאף אחד לא צריך ושרק יפריעו לנו לעשות שינויים, לבין לא  לכתוב טסטים בכלל.
• אז אני רוצה להציע איזושהי גישה, שהיא כמעט ממשיכה את הדרך של הגישה שהצעתי כשאמרתי “בוא נתחיל

מ-Monolith ולא נתחיל מ-microservice.(רן) אוקיי . . . אז מהי “גישת הטסטים” בעולם הזה? 

• (שי) אז בגדול, אני בודק פיצ'רים.
• אני רוצה להתחיל - אני מתחיל מערכת, יש לי איזושהי הנחת יסוד, השערה לגבי מוצר שיכול לעבוד - אז אני כותב טסט לדבר הזה.
• אם אני כותב מערכת Web-ית אז אני כותב טסט במשהו כמו Playwright, או איזשהו Framework UI כזה.
• ואני אכתוב טסט שהוא מאוד מאוד “גס” באופי שלו.
• לצורך העניין, אם אני בונה חנות, אז הטסט יכול להיות “לקוח יכול לקנות מוצר” . . . 
• (רן) כלומר, לא Unit Test, נדגיש.
• (שי) ההיפך . . . ההיפך הגמור - זה End-To-End Test: הוא רץ לאט, הוא רץ על דפדפן . . . 
• וכל עוד אני מנסה להתכוונן על Product-Market Fit, אני אכתוב מעט End-To-End Tests כאלה
• שהם ישתנו רק כשהדרישות תשתננה - ולא כשהמימוש ישתנה.
• והם יהיו “רשת ביטחון" - שאני יודע שאני “עובד”, שאני תמיד עובד.

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

• (שי) אז כמו שאמרנו קודם ש”המערכת שלנו היא עץ", אז כשהעץ מתחיל “להתעבות” - כשהמוצר מתחיל להתקבע ולהתקשח. זאת אומרת, כשאנחנו כבר יודעים מה אנחנו עושים - אז אנחנו רוצים להעמיק את הטסטים, לבדוק יותר מקרי קצה.
• אנחנו רוצים אולי לקחת חלק מה-End-To-End טסטים האלה, ולהפוך אותם לטסטים שהם רצים יותר מהר.
• אז אם אנחנו יכולים, אנחנו נריץ - לבדוק פיצ'רים בתוך Process בזיכרון.
• באמצעות משהו שנקרא Hexagonal Architecture, אנחנו נרים מערכת - עם Fake-ים במקום כל מה שיוצא החוצה מהמערכת, ואז אני לא יוצא מתוך גבולות ה-Process.
• ואז אני מקבל Performance של Unit Test - ורמת Scope של End-to-End Test, שבודק פיצ'רים ולא יחידות תוכנה, שהן כמעט מקריות, שהן Implementation details, שהן פרטי מימוש של המערכת שלי.

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

• (שי) אנחנו קוראים לזה Executable Specifications - אלו דרישות שניתן להריץ אותן.
• אני קורא לזה “ראיות” - אלו הראיות שהמערכת עושה את מה שהיא אמורה לעשות.
• וככל שהמערכת יותר ראשונית ופחות מוגדרת היטב - ככה הטסט צריך להיות יותר גס ופחות מדויק.
• וככל שאני יודע יותר מה היא רוצה לעשות, אני רוצה יותר טסטים שבודקים יותר מקרי-קצה - ואז, בשלב הזה, גם יותר הגיוני להפוך אותם ליותר מהירים.
• כי אם אני יש לי עכשיו אלף End-to-End Tests, ייקח להם המון זמן לרוץ - וזה יהיה מאוד יקר, וזה לא הגיוני להרים כל פעם מערכת שלמה בשביל לדאוג לניואנס של איזשהו מסך.

22:26 זה הולך להיות ב-Rust בוודאות(רן) אני מחר בבוקר מקים סטארטאפ [רגע - מה?], ואני לא יודע מה הולך להיות המוצר ואני לא יודע את מי אני הולך לגייס . . .(אורי) אפשר להשקיע? . . . (רן) . . . אבל אני יודע דבר אחד - זה הולך להיות ב-Rust בוודאות [דותן מרגיש הפרעה בכוח…], , כי זו שפה יפייפיה, היא Type-safe, והיא ממש מגניבה. מה דעתך?

• (שי) דעתי היא שאתה לוקח סיכון . . . .
• למה אתה לוקח סיכון? כי אתה בחור מאוד חכם ומאוד ותיק ומאוד מנוסה - ואתה יודע שהשפה הזאת טובה לך.
• אבל אתה לא תצליח, כנראה, לגייס צוות שמורכב מהאנשים כמוך.
• אתה תגייס צוות של אנשים שהם הרבה פחות מנוסים . . .
• עכשיו, אתה יכול ללמוד אותם Rust - אבל את הזמן שאותו אתה משקיע בללמד אותם Rust, או שהם משקיעים בללמד את עצמם Rust, הם היו יכולים להשקיע ולכתוב לך פיצ'רים ב-Go [עכשיו אלון מרגיש הפרעה בכוח…] או ב-TypeScript או בכל שפה שהיא יותר נפוצה.
• אז כשאני הולך לפתח מערכת ב-Rust - ואני עשיתי את הטעות הזאת . . . 
• לא יודע אם אני קורא לזה טעות, אבל אני העברתי את Wix לפתח ב-Scala . . . 
• ו-Scala שפה נהדרת, מדהימה - ומתקמפלת מאוד לאט, ומאוד קל לעשות בה “פשעים נגד האנושות” . . . .
• ועשור אחרי שהעברתי את Wix ל-Scala, או 12 שנים אחרי שהעברתי את Wix ל-Scala, אני שומע קולות מ-Wix, של אנשים שאומרים “למה אנחנו עובדים ב-Scala?!”
• אז בזמנו, כשהיינו חברה של 30-40 מהנדסים, זה היה איזשהו “Differentiator” - איזשהו משהו מבדל.
• יכולתי להגיד “אנחנו כותבים ב-Scala, ומי שרוצה לכתוב ב-Scala יבוא ויעבוד ב-Wix!”
• וזה היה מגניב לנו - כשאתה סטארטאפ חדש, אתה רוצה כמה שפחות לבדל את עצמך ברמה הטכנולוגית, כדי שתוכל . . . . כדי שלא לצמצם את ה-Funnel של הגיוס שלך, שתוכל לגייס אנשים בלי שהם יצטרכו לחשוב  עכשיו “האם אני רוצה להיכנס ל-Rust? מה אני צריך את הדבר הזה בחיים שלי?” . . . .

(רן) כן, אז אתה מסתכל מהפן של הגיוס. מה לגבי “הצרות הרגילות” - Community Libraries, תשובות של - כולם עוד אומרים “Stack Overflow!”’ אבל “תשובות של GPT” - וכו’? האם גם זה Concern בעיניך?

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

25:21 אובססיה לטכנולוגיה - על Framework-ים  וחיות אחרות (רן) עכשיו - נניח שאני הולך לפתח משהו בעולם הLLMs, סתם ככה כי בא לי, כי זה מה שכולם עושים היום [לא סתם - Surviving the Hype - How to Not Let the Success of Your Domain Ruin You / Rachel Wities], ובא לי, ואני רואה שיש Framework ממש מגניב שנקרא LangChain, ווואלה דווקא נראה לי דווקא סבבה, אז אולי אני אאמץ אותו אליי, ונבנה את הכל ב-LangChain . . . . איזו טעות אני עושה פה?

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

• אבל האם אני צריך את כל היכולות של ה-Framework הזה? כנראה שלא . . .

(רן) כן, כלומר אוקיי - אז זאת אומרת שיכול מאוד להיות שמי שכתב את ה-Framework עשה עבודה מצוינת, אבל ה-Use Case שלו היה הרבה הרבה יותר מורכב מה-Use Case שלי, או לחילופין - אולי לא הרבה יותר מורכב אבל פשוט שונה, ואני אשלם “מס גדול” על להתאים את עצמי לדרך המחשבה של ה-Framework.אבל האם אין מקרים שבהם Framework דווקא יכול להיות שימושי? אני אתן אולי את הדוגמה הכי טריוויאלית: אם אני הולך לכתוב משהו ב-Web, אני לא אכתוב את הכל מאפס ב-HTML ו-JavaScript, אני כנראה אשתמשב-React או חברים . . . לגיטימי?(אורי) יש את המקום ש-Framework מקצר לך דרך. איך אני יודע להבדיל בין  Light” Framework”  לבין Framework שיש בו הרבה “שיער”, נקרא לזה, ואני אעסוק כל הזמן בלגלח את היאק?

• (שי) אני חושב ש-React היא דוגמה מצוינת, כי-React היא לא Framework - היא ספרייה.
• היא מאוד מאוד קטנה ופשוטה, וזה נכון ש-React עם Hooks זה כבר קצת Framework, ו-Next זה ממש Framework . . . .
• ואני אגיד לך לא להשתמש ב-Next - בשום פנים ואופן אל תשתמש ב-Next.
• אין לך שום סיבה להשתמש ב-Next - היא נועדה לפתור בעיות שאין לך.
• אבל React היא ספרייה, היא קטנה - היא לא “אולר שוויצרי”, היא “סכין קומנדו”.
• היא יודעת לעשות דבר אחד - וזה לרנדר (To Render) UI
• וזו בדיוק הדוגמה למשהו שהוא סטנדרט דה-פקטו היום בתעשייה.
• גם הרבה מאוד Framework-ים אחרים לקחו מ-React רעיונות או משתמשים ב-JSX כמו ש-React עושה.
• יהיה לך קל להביא אנשים שמכירים את זה, יש Best Practices, יש סטנדרטים . . . 
• ועדיין - אני ממליץ לא לעשות Coupling של הקוד שלכם לספרייה או ל-Framework.
• אני גם לא אומר לעשות Abstraction Layers או Interaction Layers - שכבות הפשטה מעל הספרייה הזאת.
• אבל אני כן אומר שצריך להיזהר ממצב שבו אני מתעסק, כמו שאורי אמר, ב-Yak-Shaving, בלהתאים את עצמי לתוך ספרייה או Framework.
• כי אז בעצם אני מכניס את עצמי לשבלונה - ואני מגביל את עצמי ביכולת שלי לגדול ולהתפתח.

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

• (שי) אתם לא צריכים Kubernetes, אתם לא צריכים Next, אתם לא צריכים Next.js, אתם לא צריכים Kubernetes, אתם לא צריכים את Elixir, אתם לא צריכים את LangChain  . . .
• אתם צריכים לכתוב את הקוד הכי פשוט שפותר את הבעיה שאתם חושבים שאתם רוצים לפתור.
• ולהביא זה למשתמשים ולשוק ולראות איך מקבלים את הקוד שלכם, איך מקבלים את המערכת שלכם, איזה פיצ'רים צריך . . . 
• ותפתרו את הבעיות כשהם יקרו, ולא לפני.

29:40 סיכום ביניים(רן) אז סיכום ביניים לסעיף האחרון שעליו דיברנו - נקרא לו “אובססיה לטכנולוגיה” - שיכולה להיות אובססיה לשפה מסוימת, דהיינו Rust במקרה הזה - שפה מצוינת, אבל אולי אתם לא צריכים את זה, וגם אם אתם באמת רוצים את זה,יהיה לכם קשה לגייס. אז לזה קראנו “אובססיה לטכנולוגיה”.לפני זה דיברנו על Testing - האם, מתי ואיך?; וממש לפני זה דיברנו על “בואו נתחיל ב-Monolith-ים ואחר כך נדבר”
30:11 איך מנהלים חוב טכנולוגי?(רן) אני רוצה להעלות עוד נושא אחד, וזה איך מנהלים חוב טכנולוגי? וזה הכי קל, כאילו בסטארטאפ, לבוא ולהגיד “אוקיי, אוקיי, את זה אני אעשה אחר כך”, “פה אני אשאיר לי עצמי To-Do”, “פה אני לא באמת אסגור את ה-Security hole הזה”, “פה אני לא באמת אטפל ב-Performance” - ולפעמים זה לגיטימי. אבל איך אחר כך מתמודדים עם זה?

• (שי) קודם כל בוודאי שזה לגיטימי.
• למעשה, כמו שאמרתי - אני, במוצרים חדשים . . .  
• אגב, לא בהכרח בסטארטאפ חדש - גם אם אני עכשיו בתוך  חברה גדולה ואני בונה מוצר חדש, ואנחנו עדיין לא יודעים אם למוצר הזה יש שוק
• אני אנסה להיות “כאילו שאני בסטארטאפ” - אני אנסה להיות הכי Lean שאני יכול, בתוך המגבלות של החברה שאני נמצא בה.
• אז אני לא רוצה לפתור בעיות Performance ואני לא רוצה לפתור בעיות Security עכשיו - אני כן רוצה לייצר מערכת שבה אני אוכל לעשות את זה אחרי זה בקלות.
• זאת אומרת, אני רוצה שהקוד שלי יהיה גמיש לשינויים.
• זאת אומרת שאני רוצה טסטים מספקים כדי להגן עליי.
• ואני רוצה רגע לדבר על המונח “חוב טכני” - המונח “חוב טכני” הוא מונח שהוא גם בעייתי . . . 
• כי לא כל החוב הטכני הוא בעייתי באותה רמה.
• כי אנשים אומרים “יש לי פה Class שכתבתי - והוא מכוער! זה חוב טכני!”
• ואני אגיד שזה חוב טכני אם ה-Class הזה משתנה הרבה - אבל אם ה-Class הזה לא משתנה אף פעם, אם כתבתי איזה Adapter לאיזה ממשק SOAP של חברת ביטוח, שהשתנה בפעם האחרונה ב-2004 . . . 
• וזה קוד מגעיל - אבל אף אחד לא נוגע בו אף פעם, או שפעם בשנה מישהו נכנס לשם ועושה איזה תיקון
• האם זה בסדר שהקוד הזה יהיה מגעיל? אני טוען שכן.
• כי אנחנו רוצים שקוד יהיה נקי כדי שנוכל לקרוא אותו - קוד שמשתנה הרבה זה קוד שקוראים הרבה.
• אז איפה שיש הרבה שינויים - אנחנו רוצים להשקיע ולפרוע Technical Debt, לפרוע חוב טכני.
• איפה שאין הרבה שינויים - זה לא חוב טכני, זה פשוט קוד מכוער.

(אורי) אני רוצה לתת עוד אספקט של “חוב טכני" ו”חוב מוצרי” - יש גם דבר שנקרא “חוב מוצרי”: המוצר “לא מדויק”. זה משהו שלמדתי מהרצאה בכנס רבסים האחרון [מניח שזה - It’s time to pay off your management debt / Daniel Korn]: בטח בסטארטאפים, כשאתה בונה משהו ולא בטוח שהוא יעבוד ושהוא יעבוד טוב - ויש מצב טוב שתצטרך לזרוק את הקוד הזה - תאפשר לעצמך “תספורת” . . . זאת אומרת, לפני שאתה משלם את החוב הטכני, תראה אם באמת המוצר הזה, יש לו אורך חיים רלוונטי. כי אם לא, זרוק את הקוד. החוב מחול - פשוט זרוק את הקוד.(רן) כן . . .  “תספורת”, רק לתרגם מעולם הפיננסים, זה "להשליך לפח”, לשכוח מהחוב.

• (שי) כי בעצם, מה אנחנו אומרים? יש פה מדד מאוד פשוט: איפה אני רוצה לפרוע חוב טכני?
• אז אמרנו אחד - זה מקומות שבהם הקוד משתנה הרבה.
• אנחנו קוראים לזה “Hotspot”.
• יש מערכות שעוברות על Git ומנסות למצוא “Hotspot”. 
• איך מוצאים Hotspot? זה קל -  זה הרבה מאוד Commit-ים [טובים!] לאותה שורת קוד, או הרבה מאוד Committers לאותה שורת קוד, או לאותן שורות קוד, או לאותם קבצים.
• אז יש לנו איזשהו משהו שיחסית קל לכמת אותו.
•  יש גם מערכות, כמו למשל CodeScene, שיודעות לתת לנו את האינפורמציה הזאת.
• ומקום שני זה באמת מוצרים שלא משתמשים בהם, או פיצ'רים שלא משתמשים - וגם פה אפשר למדוד את זה.
• באמצעות מערכות Monitoring, באמצעות BI, אנליטיקות (Analytics) - אני עכשיו מכניס איזה Mixpanel ואני רואה במה משתמשים.
• ווואלה - אם לא משתמשים בזה, או אם משתמשים בזה מעט, ואני רואה שהפיצ'ר הזה עכשיו “נרקב” לאט לאט, או קמל לאט לאט, אז וואלה, כן, תן לו למות.

(אורי) בשלב מסוים התחלנו להגדיר שלבים בפיתוח מוצר. קראנו לזה Crawl-Walk-Run - [עוד על זה ב-437 Refactoring (and Observability) with Omer van Kloeten]. ב-Crawl, אם אני עכשיו כותב קוד שהוא Crawl - לא מעניין אותי החוב הטכני. כי אם הוא לא יצליח, המטרה שלו זה ניסיון, פשוט לנסות, לראות אם המוצר עובד, תופס מים, מעניין את מישהו. אז אם אני ב-Crawl, והמוצר לא יצליח, אז ברור שלא שווה לי לעבוד יותר מדי על החוב הטכני אלא פשוט לזרוק את הקוד. אם הוא כן יצליח אז אוקיי - צריך להתחיל לתכנן אותו ל-Scale, צריך להתחיל לתכנן אותו להרבה משתמשים . . . הוא גם יכול להתפתח כ-Hotspot פתאום, אז בטח ששווה לי להתחיל לטפל בחובות הטכניים שלו.

• (שי) נכון - אני חושב שזה גם המשך ישיר של הקו שדיברנו עליו קודם, נכון?
• אנחנו רוצים להיות גמישים, אנחנו רוצים להיות אדפטיביים, אז כאשר אני אני מתחיל, כאשר אני ב-Crawl, אני בעצם אותו שתיל דק וקטן.
• ואז אני רוצה שיהיה לי Coverage קטן של טסטים, אני רוצה להיות Monolith שקל לעשות בו שינויים - ואני רוצה להשתמש בטכנולוגיות פשוטות ומוכחות.
• ואני לא רוצה להשקיע הרבה . . . 
• וככל שהזמן חולף והמוצר מתמצק ונהיה יותר מדויק, אני אתחיל לעשות Refacr-ים אופורטוניסטיים (Opportunistic).
• בגלל שיש לי טסטים אז אני בטוח - אני יכול לעשות את ה-Refactor-ים האלה, ואני יודע שאני לא אשבור שום דבר, אין לי פחד משינוי.
• ולאורך זמן, החוב הטכני פשוט “ייפרע לבד”.
• ואם אני מוצא את עצמי לא נוגע במוצר הזה יותר, אז אני גם לא צריך לעשות לו Refactor-ים ואני לא צריך לפרוע את החוב הטכני.
• זה כאילו מין כזה משהו שהוא מאוד הוליסטי, לשיטתי ולאיך שאני מסתכל על זה.

(רן) בסדר גמור.
36:21 חוק Conway הדו-כיווני(אורי) לפני שאנחנו סוגרים כאילו, יש פה משהו שמתחילת הפרק הוא . . . ברמה אחרת, ברמת “הכה את מומחה” . . . (רן) תן לזה דרור, שחרר . . . (אורי) אמרת “מערכות וארגונים”, בסדר? אמרת גם בהתחלה, כשהייתה לנו פה תקלה טכנית, שארגונים זה גם מערכות - וזה עשה לי טריגר למשהו שנקרא Conway's Law - שהארכיטקטורה הטכנית תמיד תהיה שיקוף של המבנה הארגוני, וההפך.זה סבבה - אבל זה משהו שמייצר המון המון קשיחות, בסדר? כי - בטח כשיצרת כבר ארכיטקטורה מבוססת וכו’ - יש לך שיקוף במבנה הארגוני. אתה אומר פתאום “וואלה, הרבה יותר קל לי לשנות מבנה ארגוני מלשנות את הארכיטקטורה הטכנולוגית שלי” - ופתאום מתחיל להיות לך קשה, או עוצר אותך, או עוצר את השינויים שלך ברמת המבנה הארגוני - המבנה של הקוד, המבנה של הארכיטקטורה.כמה אתה נתקל בזה?

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

(אורי) . . . הם פשוט תמונת-מראה ברוב המקרים.

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

(אורי) יש שלבים בבניית המערכת שהמערכת היא כבר כל כך רובסטית, שאז קשה לך לעשות שינויים במערכת, יותר קל לך לעשות בארגון.זה נכון שאם אתה שובר דברים ל-microservices, אז פתאום אתה יכול ברמת הגרנולריות (Granularity), שהופכת לגרנולריות של ה-microservice - אבל זה נהיה יותר קשיח.אני יכול להגיד שאני מצאתי את עצמי מייצר “Super-structure” - מבנה ארגוני שהוא מעל המבנה הארגוני שמכריח חוק Conway, רק כדי להיות מסוגל להיות הרבה יותר אדפטיבי.כאילו, “Interface על Interface” - “שכבת אבסטרקציה” . . . (רן) אתה בא לדבר עם מנהל שלך והוא אומר לך “אל תדבר איתי - דבר איתו” . . .(אורי) כן . . . 

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

• (רן) אורי - אנייה! אתה יודע מה זו “אנייה”?

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

(אורי) דיברנו על האנשים האדפטיביים? בשבילנו שינוי ארגוני זה Piece of Cake, אנחנו לא . . . אין לנו הרבה עכבות.

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

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

• (שי) כן, זאת אומרת - יש את ה-Level שלך, איפה אתה ברמת הוותק המקצועי
• ואז אתה יכול להיות מנהל פיתוח ב-Level מסוים או Individual Contributor ב-Level מסוים.
• (אורי) . . . באותו Level.
• (שי) אני חושב אבל שבעצם, הבעיה של ה”לעשות שינוי ארגוני” היא קצת בראש שלנו - והיא קצת אמיתית.
• מצד אחד, קשה לקחת לאנשים Title-ים - אבל אולי, מראש, היינו צריכים להימנע ולתת Title-ים מוקדם מדי, ואז היה לנו יותר קל לעשות שינויים.
• וגם פה, לפעמים זה משהו שלוקח זמן - כמו שלוקח זמן לעשות Refactor למערכת גדולה ולפרק אותה ל-microservices, אז אתה לא עושה את זה בין לילה.
• גם לשנות המבנה של הארגון - אתה לא עושה את זה בין לילה, אתה חותר לשם לאט לאט.
• אתה מציב לך איזשהו “כוכב צפון”, ואתה לאורך כמה חודשים מגיע לשם.

(אורי) ולא דיברנו בכלל על אבולוציה של תרבות . . . (רן) בוא, אורי - יש הרבה דברים, יש לנו Backlog . . . (אורי) כן . . . ((רן) לא דיברנו הרבה על זה, זה נכון.  גם לא דיברנו על ברנארד, שחשבנו שאולי נגיע לזה אבל אין לנו זמן לזה.
42:26 סיכום וסיום וגמישות(רן) אנחנו ממש מגיעים ככה לקראת סיום, אז רק נעשה סיכום קצרצר על מה שכן דיברנו - נסתכל על חצי הכוס המלאה.אז הסעיף האחרון בעצם היה על איך לנהל חוב טכנולוגי, ומתי הוא מעניין, החוב הטכנולוגי - ומתי הוא גם לא, מתי אפשר פשוט, כמו שאורי אמר, “לספר”, לשכוח מהחוב הזה. גם זה לפעמים...(אורי) למחול.(רן) דיברנו על “אובססיה לטכנולוגיה” - שפה מסויימת, Framework מסוים, הצמדות כזו - שבמקרים נדירים היא מועילה, ובהרבה מקרים היא מביאה יותר נזק מתועלת.לפני זה דיברנו על טסטים - איך לבדוק בשלבים המוקדמים ומתי נכון לבדוק את הקוד.ודיברנו על “בואו נתחיל ב-Monolith-ים” . . ובמטא, דיברנו על מערכות תוכנה - וגם על מערכות של אנשים, נכון? איך אפשר לעשות Refactor לא רק לתוכנה,אלא גם לצוותים ולאנשים, ככה שבסופו של דבר נהיה כמה שיותר אג'ילים (Agile). איך אמרנו בעברית? “זמישים” . . . 

• (שי) זמישים . . . גנבתי את זה מפודקאסט אחר - “מפתחים חסרי תרבות”, זה מונח שלהם [אולי, לא בטוח…].
• אבל להיות . . . אני קורא לזה להיות באמת גמיש. כאילו, זה... אני מאפטם (Optimize) לגמישות - של הכל
• של המערכת תוכנה, של ארגון הפיתוח, של הארגון בכלל, של האינטראקציות בין האנשים . . . 
• אני מנסה לקבע כמה שפחות דברים בשלב מוקדם - כדי שאני אוכל להיות כמה שיותר גמיש וכמה שיותר אדפטיבי לכל שינוי שיבוא.

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

[קישור לקובץ mp3] 
פודקאסט מספר 468 של רברס עם פלטפורמה - הוקלט ב-19 במרץ 2024, רגע לפני פורים. הפעם הקודמת הייתה לפני סוכות, והרבה דברים קרו מאז. רובם רעים מאוד, אבל היה גם כנס מאוד מוצלח. מנסים לחזור לשגרה - ומקווים לחזרתם של כולם לשגרה מבורכת במהרה.אורי ורן מארחים את אריק מחברת Fireblocks - אחרי המון פגישות לאורך המון שנים בכנסים ועוד, שחקן מאוד משמעותי בקהילה שלנו - כדי לדבר קצת על קריפטו, נושא שאיכשהו לא זכור שממש נגענו בו לעומק לאורך כמעט 470 פרקים [היה קצת בפרק עם בנצי מ-eToro - פרק 436 How to reach retirement as a software developer with Bentzy Lupu], ולהיכנס לחלק מהאיזורים המאוד מעניינים של Crypto Currencies: אלגוריתמים ועוד נושאים טכנולוגיים שאריק מביא - מילים כמו MPC ו-CMP ועוד.
02:04 על אריק ו-Fireblocks
(רן) ולפני הכל - אריק: כמה מילים עליך ועל מה אתה עושה היום?

• (אריק) כן, אז היום, כמו שאמרת, אני בעצם סמנכ”ל טכנולוגיה ב-Fireblocks, מוביל את המחקר הטכנולוגי.
• אני ממר”מניק - בוגר אופק של חיל האוויר בעברי.
•  ומאז מספר מקומות - מספר שנים בעולמות ה-AI ב-HiredScore,   באזורים של AI for Recruiting.
• ובשנתיים וחצי האחרונות בערך צללתי לעולם הזה של Blockchain ו-Crypto Currencies - היום אפשר לדבר על ההבדלה.
• אם פעם הם כזה “הגיעו לעולם שלנו ביחד”, אז היום אפשר גם להבדיל בין ה-Asset Class - בעצם הסוג החדש של נכסים דיגיטליים, לבין ממש הטכנולוגיות-Blockchain שיושבות מתחתיהם.

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

• (אריק) כן, אז Fireblocks זו חברת טכנולוגיה, קודם כל.
• אנחנו בונים תשתית טכנולוגית, שמעליה חברות וארגונים - הרבה מהם ארגונים פיננסיים, אבל לא רק - הם בונים ברגע שהם רוצים להשתמש בעולמות ה-Blockchain.
• אפשר להסתכל על זה קצת בצורה דומה ל-AWS - כשאתה בונה אפליקציית Web, אז הם נותנים לך את כל הכלים שאתה צריך כדי לבנות אפליקציה.
• לא רק Web, מן הסתם, המון המון use-cases שונים - אבל יש כזה את המרכז: ה-Compute שהם נותנים לך, שרתים . . .  
• מזה הכל התחיל, אבל זה התרחב לכל השירותים.
• ו-Fireblocks זה סיפור די דומה בעולם שלנו.
• התחלנו מלפתור איזושהי בעיה מרכזית שיש ללקוחות ברגע שהם משתמשים בכל עולמות ה-Blockchain, מה שקשור לאיך הם מתנהלים עם הארנק שלהם.
• והמשכנו ללתת להם מענה לכל הצרכים השונים שעולים ברגע שאתה בונה “מערכת אמיתית”.
• אנחנו משרתים ארגונים, כלומר - זה לא מוצר-ארנק לאנשים, זה לא משהו שאתה מחזיק את הביטקוין שלך בתוכו, אלא ארגונים מכל הסוגים.
• זה החל מסטארטאפים וממשיך לכל מיני חברות טכנולוגיות שבונות בעולמות האלה, Brand-ים שעושים כל מיני דברים עם NFTs וכל מיני דברים אחרים ששמעתם עליהם.
• וממשיך כל הדרך גם לבנקים - או בנקים מרכזיים אפילו - שעושים כל מיני דברים בעולמות ה-Blockchain.
• כלומר ממש שחקנים פיננסיים כבדים גם בחלק מהזמן.

(רן) כן, אז אתם רוצים להיות - או אולי כבר - “ה-AWS של עולם ה-Crypto Currency”…

• (אריק) כמו בכל תחום, יש איזה מישהו שמתכנן להיות “ה-AWS של התחום” הזה, אז אנחנו לגמרי שחקן באזור הזה.

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

• (אריק) כן, אז זה כמובן לא אני פרסונלית - אנחנו מדברים על כל Fireblocks - אבל אנחנו חוזרים כמה שנים אחורה.
• והיה אז הרבה, כמו עכשיו, כשפתאום כשמחיר הביטקוין עולה והעיתונים כותבים הרבה - אז גם אז הייתה תקופה שבעיתונים כתבו הרבה על כל האזורים האלה של ביטקוין ו-Crypto Currencies אחרים.
• והרבה פעמים הכתבה התחילה ב”מישהו שנגנב לו מפתח”, נכון? זה משהו ששמענו עליו.
• בין אם הוא איבד מפתח ומחפש אותו באיזה מזבלה . . . 
• וגם הרבה פעמים זה לא היה בן אדם שאיבד מפתח - כלומר, יש לך איזו בורסה, שמחזיקה כסף של אלפי אנשים, מאות אלפי אנשים, ופתאום המפתח נגנב, כולם איבדו את הכסף ויש בלאגן גדול והסכומים גבוהים . . .
• זאת הייתה בעיה מהותית בעצם - איך אני רגע מאבטח את ה-Private Key?

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

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

(רן) כן, במילים אחרות - המפתח הוא Single Point of Failure באיזושהי צורה.

• (אריק) לגמרי, Single Point of Failure, כן - שאנחנו לא אוהבים, 
• בטח כשה-Single Point of Failure הזה יכול, תוך שניות, להיות מנוצל כדי לקחת הכל - שזה יכול להיות גם מיליארדים.
• עכשיו, הפתרונות באותו זמן היו באמת ברעיון הזה - הרעיון האוטומטי של אנשים, זה “בוא נשים אותו בכספת”, נכון?
• הייתה אפילו חברה שהשכירה בונקרים בשוויץ - שמו בתוכם כספות, סגרו את הבונקרים, ופעם בחודש הבן אדם היה מגיע לכספת ועושה את הפעולה שאתה רוצה מול הארנק שנמצא בתוך הכספת, שנמצא בתוך הבונקר . . .
• שזה נחמד - אם לקחת ביטקוין ואתה רוצה להחזיק אותו עכשיו ל-20 שנה, אולי זה שימושי.
• אבל ברגע שאתה חברה פיננסית, אתה עושה פעולות פיננסיות כל הזמן - לפעמים עשר פעמים ביום, לפעמים מאה פעמים ביום, ולפעמים עשרת אלפים פעמים בשנייה, נכון?
• כאילו Visa - שישים אלף טרנזקציות, TPS, טרנזקציות בשנייה.
• אז בעצם זה לא עובד ל-Use Case הזה.
• ו-Fireblocks הייתה חברה שבאה ואמרה “אנחנו רוצים פתרון שהוא מאובטח ברמה של ‘הכספת הזאת, שנמצאת באמצע בונקר’ - אבל אנחנו רוצים שהוא יהיה שמיש כל הזמן, בתוך ארגון”.
• כלומר, באמת ה-Single Point of Failure זו בעיה, במיוחד כש-Single Point of Failure מקושר גם הרבה פעמים לאיזה בן אדם, שיכול לקחת את הכסף.
• וכמובן שה-Temptation עולה ברגע שהסכומים עולים.
• וזה בעצם הבעיה שבאנו לפתור.

08:20 חישוב בשיתוף פעולה
(רן) בסדר גמור. עכשיו, אני מניח שלא כולם מכירים את ביטקוין לעומק, אבל אחד הדברים שכולם יודעים על ביטקוין - או על כל המטבעות הקריפטוגרפיים, סליחה, בואו נכליל, נעשה אבסטרקציה לבעיה - זה שהם מורכבים מחישוב מבוזר, חישוב שנוצר על ידי שיתוף פעולה. זאת אומרת, צד אחד עושה חישוב, צד נוסף עושה חישוב נוסף - ובסופו של דבר, התוצאה של החישובים האלה - אפשר באמצעותה לייצר טרנזקציות של Crypto Currency.אבל בסיפור הזה יש גם כמה בעיות. אוקיי? אז לזה אנחנו קראנו, או הולכים לקרוא לו, Multi-Party Computation או MPC, נכון? ואתם הייתם צריכים להתמודד עם זה . . .

• (אריק) כן, אז בדיוק - Multi-Party Computation זה דווקא כאילו הסוג-של-הפתרון שלנו לבעיה.
• אז הבעיה בעצם היא שיש לי את המפתח, יש את ה... כמו שאמרתי, יש רשת - רשת כלשהי, Blockchain כלשהו.
• בסוף, הרשת הזאת, היא לא עושה פעולות בעצמה, כן?
• מה שקורה על הרשת, זה בעצם שטרנזקציות מגיעות אליה - והטרנזקציות צריכות להיות חתומות, חתומות קריפטוגרפית.
• ואת החתימה הזאת - יש באמת Private Public Key Signature שם, כן? כאילו יש איזשהו מפתח פרטי, אני חותם איתו, זה תקף לרוב על ה-Public Address  שלי, שזה המפתח הפומבי שמקושר אליו
• ואז כל בן אדם ברשת ה-Blockchain יכול לוודא שהטרנזקציה הזאת, שיוצאת מה-Public Key הזה, נחתמה על ידי ה-Private Key התואם - ונחתמה בפרוטוקול הרלוונטי לאותו Blockchain, כן?
• לBlockchain-ים שונים יש פרוטוקולים שונים, אבל יש כמה שהם העיקריים.
• עכשיו, אני רוצה לייצר את החתימה הזאת - ושכל אחד יוודא חתימה וידע שהיא תקינה - אבל אני לא רוצה להחזיק מפתח אחד, אני רוצה לפתור את ה-Single Point Of Failure, וכאן נכנס MPC.
• כשהרעיון ב-MPC בעצם, הוא במקום שיהיה מפתח פרטי אחד - יהיו מספר חלקים למפתח.
• אנחנו סוג-של-נפצל רגע את המפתח לכמה חלקים . . .
• (רן) Sharding!
• (אריק) בדיוק. . . . אנחנו נעשה איזה Sharding כזה
• או אם היינו ממש מפצלים מפתח בודד אז זה Secret Sharing - כשאנחנו בעצם מפצלים סוד כלשהו לכמה חלקים.
• ואז אנחנו נרצה לעשות את הפעולה בצורה מבוזרת - שיהיו כמה שחקנים שצריכים לעשות פעולה כלשהי.
• אבל אנחנו רוצים לעשות את זה בצורה מאוד מאוד מדויקת - כי אם הייתי עושה את זה כמו שאמרתי עכשיו,
• אז היה לי מפתח במקום אחד, שכמובן מישהו היה יכול לגנוב כבר אז, ואז פיצלתי אותו - אז זה לא מנגנון טוב עבורנו.
• אנחנו רוצים משהו יותר Secure, אז אנחנו אומרים “בוא מראש נייצר את המפתח בצורה מבוזרת, כשהוא מעולם לא היה מפתח בודד”.
• יש פה איזה קצת “קסם קריפטוגרפי” כזה . . .
• (אורי) הוא כן מפתח בודד - אבל הוא מורכב מכמה חלקים.
• (אריק) יש מפתח תיאורטי בודד, שמעולם לא היה שלם - אבל יש X שחקנים שמכילים חלקי-מפתח, שאם הם היו מחברים אותו, אז הוא היה מייצר את המפתח הזה.
• אבל אף אחד מעולם לא ראה את החיבור הזה.
• (רן) זה מזכיר לי, אתה יודע . . . אני מדמיין את נאום ה- I have a Dream - אין מישהו אחד שהחזיק בכל החלום ביחד, אבל כולם ביחד מגשימים את החלום.
• (אריק) יפה מאוד . . . הרעיון שנכנס לי זה “There is no Spoon” - אתה רואה כף, אבל אין כף. אין מפתח באמת.

11:38 היה מפתח?
(רן) אבל רגע, בוא נעצור אותך שנייה לפני שאתה דוהר קדימה. אוקיי, אז הייתה לך בעיה של Single Point Of Failure, ועכשיו יש לך בעיה של Distributed Single Point Of Failure  . . . זאת אומרת, מספיק שכל אחד מהשחקנים האלה פתאום נכשל, מאיזושהי סיבה - איבד את המפתח או whatever - אז איבדת שבריר מהמפתח, דהיינו - אין לך יותר מפתח . . .

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

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

• (אריק) נכון. אז בעצם מה שאפשר לעשות - MPC זה כזה איזה שם כולל, ויש כמה - הוא מדבר על כל סוג של חישוב שאתה רוצה לעשות בצורה מבוזרת.
• בתוך העולם הזה יש את העולם של TSS, שזה בעצם Threshold Signatures - שהוא מדבר על זה שאתה יכול לייצר חתימה עם X מפתחות, “T out of N” בדרך כלל מתארים את זה.
• כלומר, אני יכול לבחור X חלקים של מפתח - ואני יכול גם לייצר סכמות.
• אני יכול לומר סכמה של 2 מ-2, 3 מ-3, 2 מ-3, 5 מ-10 - אפשר לייצר כל מיני סכמות.
• אז אם אני רוצה להימנע ממצב שמפתח בודד - שחלק מפתח אחד יאבד, אז זה יימנע חתימה - אני יכול לעשות את זה.
• לא בהכרח אני רוצה - כלומר, יש איזה Design Principles שעכשיו אני צריך להכיל על הדבר הזה.
• אבל מעבר לזה יש שאלה, אולי אפילו יותר קשה - מה יקרה אם אחד השחקנים הוא Compromised, הוא ינסה לרמות את האחרים?
• ו-MPC, בבסיס שלו - כלומר, אם אנחנו מדברים על הכי-הכי Simple-MPC - הוא מה שנקרא “Honest But Curious”, אנחנו מניחים שכולם מוגנים.
• ברגע שאנחנו הופכים את זה ל-Secure-MPC, אנחנו בעצם יוצרים פרוטוקול מורכב יותר וקשה יותר.
• אבל ב-Secure-MPC, כל אחד מהשחקנים לא סומך על השחקנים האחרים.
• כלומר, מספיק שיש בן אדם אחד שהוא מקיים פרוטוקול תקין - ואז אנחנו בעצם בסדר.
• בניגוד ל”מספיק בן אדם אחד שעושה פעולה רעה”, כן?

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

• (אריק) כן, אז הרבה פעמים - אני לא יודע בדיוק מה מיממשתם שם, אבל הרבה פעמים, כשעושים דברים כאלה, אז עושים יותר, כאילו, Secret Sharing - ה-Shamir Secret Sharing, למשל - כי פחות מעניין אותך העניין של “האם היה מפתח או לא היה מפתח”, אתה פשוט רוצה לפצל אותו כדי שזה יהיה בחלקים שונים.
• אז יכול להיות שזה היה כזה, אבל יכול להיות שזה באמת היה MPC.
• ה-MPC הומצא, אני חושב, בשנות ה-80 בערך - אבל בתכלס לא היה בו שימוש מהותי עד עולמות ה-Blockchain.
• כלומר, ה-Killer Use Case של MPC הגיע בעצם בהגנה על ארנקים - זה היה המקום הראשון שבו זה התפוצץ.
• היום כל האנשים שהיו מעורבים בהולדת ה-MPC והפיתוח שלו עובדים בחברות שקשורות לעולמות ה-Blockchain, כי שם ממש קורה ה-Innovation.
• הרבה אנשים לא מבינים את זה, אבל כל העולם של קריפטוגרפיה מתקדמת - ו-MPC נכנס לקטגוריה הזאת, ויש עוד תחומים בעולם הזה - הם היו שקטים למדי במשך הרבה מאוד שנים, זה היה תחום לא מאוד סקסי.
• ומאז שה-Blockchain נכנס, ההתקדמות שם היא מטאורית - זה קצת כמו מה שאנחנו רואים עם LLM-ים ו- AI.
• יש התקדמות גם בעולמות ה-MPC, ה-Zero Knowledge Proof, ה-Fully homomorphic encryption (FHE)  . .  
• יש כזה אוסף של עולמות שהם היו תיאורטיים ונחמדים, וגיקים של הנושא התלהבו מהם - אבל אף אחד לא השתמש בהם פרקטית.
• והיום הם כולם מתקדמים ממש בצורה מטורפת - ויוצרים יכולות שגם כמתכנתים אנחנו יכולים להעריך אותם כאיזה Building Block בתוך משהו שאתה בונה.
• ועדיין, זה לא קיים כמעט מחוץ לעולמות ה-Blockchain - אבל אני חושב שזה יקרה.
• אנשים יכירו את הדברים האלה, שיכולים לעשות דברים שהם מרגישים באמת כמו קסם לפעמים - ואז יבינו, “רגע, גם במערכת שלי אני יכול להרוויח מהיכולת לעשות חישוב בצורה שאני לא חושף את המידע שאני עושה עליו חישוב, או חישוב שהוא מבוזר” או כל מיני דברים כאלה.
• אז זה משהו שהוא מתפתח.

17:48 אז כמה Uncompromised צריך?
(רן) אז בוא נעשה רגע Recap: אמרנו, בתור התחלה יש לנו את “בעיית הכספת בשווייץ” - זאת אומרת, אנחנו לא רוצים שתיהיה ואנחנו לא יכולים לייצר כזאת כספת, זה לא Agile-י . . . אבל אנחנו רוצים כן את הביטחון שהיא נותנת, את האבטחה שהיא נותנת, של אי אפשר פשוט לבוא למישהו ולשדוד ממנו את המפתח, או שהוא לא יכול לאבד אותו. אז בתור התחלה נפצל את המפתח, ונדאג לזה שלא באמת היה קיים איזשהו מפתח במקום אחד, אלא המפתח נוצר על ידי שיתוף פעולה.אבל אז נתקלנו בבעיה של “אוקיי, אבל מה קורה אם אחד מהשחקנים נכשל?” - ואתה אומר, אוקיי, גם לזה יש פתרון: מספיק X מתוך Y, מספיק ש-9 מתוך 10 השחקנים, יש להם את המפתח, זה בסדר. אבל זה השתמש בנקודת ההנחה שכולם משתפים פעולה וכולם טובים וכולם “בעדינו” - מה קורה אם אחד מהם הוא Evil או Compromised, או כל דבר כזה - וגם בזה אתה מטפל.

• (אריק) כן.

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

• (אריק) כן, אז באמת כל מה שתיארת נכון, ויש בעצם . . . מתחיל לזה Design Space, של איך אתה רוצה לתכנן את ה-MPC שלך.
• וזה רק החלק הראשון, ה-MPC - אנחנו ניגש עוד לעוד חלקים בעצם ב-Funnel - אבל ברגע שעשית Secure-MPC, אז אמרנו באמת - שחקנים הם שמוודאים שאחרים הם Honest, ואתה בעצם לא יכול לייצר חתימה לא טובה כל עוד יש מספיק שחקנים שהם כן Honest - ואנחנו גם לא חייבים לפצל את המפתח להמון.
• כלומר, ברגע שאנחנו בונים מערכת גדולה מעל הדבר הזה -
• אז נגיד במקרה של Fireblocks - אני יכול לדבר על חלק מהדברים - אז חלק מהמפתח יושב אצלנו, וחלק מהמפתח יושב אצל הלקוח, ואתה רוצה לייצר איזה מצב שאנחנו לא יכולים לחתום בשם הלקוח.
• כי אנחנו ספק טכנולוגיה - אנחנו לא בנק, אנחנו רוצים לתת להם טכנולוגיה לעבוד, אז אנחנו לא רוצים להיות במצב שאנחנו יכולים לייצר חתימות בלעדיהם.
• ומצד שני, אנחנו גם לא רוצים להיות במצב שאם הם - שהם לא בהכרח חברת Security ב-Level שלנו - אם הם יאבדו את החלק - לא יאבדו, יותר אם מישהו יגנוב את החלק-מפתח שלהם - אנחנו לא רוצים שהוא יוכל לחתום.
• אז שוב, אפשר פה לעשות איזה Design - זה לא בהכרח אפילו דורש לעשות T-out of N, הרבה פעמים זה יכול להיות גם N-out of N, כשאני מטפל בבעיית העיבוד חלקי-מפתח, בכל מיני Backup-ים שונים וכל מיני דברים כאלה.
• אז השאלה בעצם היא מה אנחנו מקבלים בתוך הדבר הזה - כשפיצלנו את המפתח, פתאום אם אתה רוצה לגנוב את המפתח, אז אתה צריך לפרוץ לא רק ל-Laptop של הלקוח, שיכול להיות שהוא לא שמור כל כך טוב.
• אלא אתה צריך לפרוץ גם לשרתים של Fireblocks - כי אנחנו לא נחתום על משהו שהוא Malicious.
• ואז אנחנו מתחילים כזה להתרחק, כן? אנחנו אומרים, אוקיי, אז יש לנו פרוטוקול MPC - שהוא כבר יציב, הוא בודק את עצמו
• אבל אז יש את החלק של המפתח - צריך לאחסן גם אותו, נכון? צריך לשמור עליו.
• אז אתה נכנס לכל מיני טכנולוגיות של Key Management Systems וכאלה, נכון? HSMs, Secure Enclave, כל מיני דברים כאלה.
• אבל אם אנחנו רוצים ללכת עוד יותר קדימה בהקשר של הטכנולוגיה - כי זה לא רק מפתח, יש פה איזו פעולה.
• אז איך אנחנו יודעים שהפעולה - אנחנו רוצים לאשר אותה?
• כלומר, זה בסדר שכל החלקים משתפים פעולה - אבל יש איזו שאלה בכלל האם זאת פעולה שהיא טובה?
• אולי הפעולה שכולנו כרגע חותמים עליה ביחד זה גנבת-הכסף? . . . 

20:15 שלב הראבק ו-Secure Enclave
(רן) כן, הבנתי - זאת אומרת, אתה רוצה להכניס פה “ראבק” מה שקוראים - זאת אומרת, Role-Based Access Control (RBAC), הידוע בכינויו “ראבק” . . .

• (אריק) לא הכרתי את המינוח, אבל אני אוהב את זה מאוד . . .

(רן) כן, אז אתה אומר, אוקיי - “אני רוצה לאפשר לו להעביר 50 Bitcoins, אני לא רוצה לאפשר לו להעביר 50 אלף Bitcoins” . . . או “אני לא רוצה לאפשר לו למשוך - אני רוצה רק לאפשר לו להפקיד”, או בקיצור, “לעשות פעולה X, לא לעשות פעולה Y”.

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

(רן) כן, כמו שבבנק מנהל הסניף יכול לחתום עד כך וכך, ופקיד עד כך וכך, וכו’.

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

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

• (אריק) אז אוקיי, אז זה לא מסובך - ובהינתן אחד משני דברים: או שאנחנו לא מדברים על הרבה כסף, או שאנחנו מדברים על הרבה כסף, אבל זה שאתה תשיג את ה-Secret לא מאפשר לך אשכרה לעשות איתו משהו מיידי.
• ברגע שאתה ארגון שמנהל על ה-Blockchain מיליארד דולר, ויש לך איש DevOps
• אז אם הוא יכול פשוט ב...אתה יודע, כי יש לו הרשאות - כן, יש Role-based Permissions, אבל יש לו Root לשרת, יש לו Root ל-KMS, יש לו ניהול של ה-AWS, יש לו את כל הדברים האלה - בתכל’ס הוא יכול לעשות מה שהוא רוצה . . . 
• ואם אתה מתחיל לפרק ארגון מורכב כזה, אתה תמצא את עצמך עם הרבה אנשים שיכולים לעשות מה שהם רוצים - ואתה מקווה שאחד מהם לא אשכרה ירצה לעשות את זה . . 
• וזה לא משהו שאפשר לעשות
• (אורי) . . . כי אי אפשר לסמוך עליו . . 
• (אריק) בדיוק, כי אפשר להסתמך על זה - ואני חושב שקצת זה מה שהיה קורה פעם, לפני שחברות כמונו התחילו לקום.
• היה איזו בורסה, היה בה המון כסף - ואז הם אמרו “נגנב לנו המפתח!”, וכל בן אדם שהיה לקוח שלהם חשב לעצמו “רגע, רגע . . .  נגנב להם המפתח - או שהם גנבו את המפתח? אני קצת לא בטוח מה קרה פה” . . .
• אבל אנחנו רוצים לייצר איזו תשתית שהיא טובה וחזקה מספיק, ככה שאם אנחנו רגע מדברים ממש בהערכת סיכונים - גם Root בשרת לא ייתן לך לקחת את הכסף.

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

• (אריק) כן, כן.

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

• (אריק)  נכון . . .
• אז בעצם, מה שהכנסנו זה ברגע שנכנסנו לעולם הזה, Fireblocks נכנסה לעולם הזה של MPC, Secure MPC וכל הדבר הזה, אז התחילה להוסיף עוד שכבות - וזה בעצם סוג של “ללכת אחורה ב-Funnel” הזה של התהליך, עד לשלב שאנחנו יכולים לומר שהפעולה כבר לא תסכן את הכסף.
• וכל מה שנמצא בדרך - למשל, Policy Management - אם הוא כן פעולה שתסכן את הכסף, וכמובן ש-Policy Management זה כן - אז אנחנו מכניסים את זה למשהו שנקרא Secure Enclave [וואו, איזה פלאשבק לאינטל 2010 . . . ]. 
• כלומר, אנחנו בעצם רצים בסביבה שהיא “מיוחדת” - אנחנו לא רצים פשוט ככה “בתוך השרת”, כי אם נרוץ בתוך השרת, יש הרבה אנשים שיכולים לשנות.
• אנחנו רוצים לרוץ בצורה שאי אפשר לשנות את הקוד, שאי אפשר לשנות את הזיכרון, שאי אפשר, כאילו בעצם . . .  יש המון - אי אפשר לקרוא את הזיכרון, כי שם נמצא המפתח. אי אפשר לעשות הרבה דברים שאתה בעצם רוצה למנוע.
• ויש טכנולוגיות בדברים האלה - כלומר, כל הטכנולוגיות האלה של Secure Compute, אלו טכנולוגיות שנבנו בדיוק לדבר הזה, ומאפשרות לך להריץ קוד בסביבה שהיא מנותקת [פיזית, ברמת ה-Hardware]
• בוא נגיד שהיא רואה אפילו את ה-Operating System בתור “אויב” . . .
• (רן)  כן, זאת אומרת, “סביבה” - למה את מתכוון? לחומרה?
• (אריק) אז כן - זה ממש ברמת החומרה.
• יש כמובן גם אופציות ב-Cloud שהן יותר מבוססות Cloud ועושות את זה ברמת אבסטרקציה גבוהה יותר
• אבל אם אנחנו הולכים למחמירים - ואנחנו מהמחמירים - אז בעצם זה משהו שהוא ברמת החומרה.
• אפשר לחשוב על זה כעל חלק בזיכרון שהוא ממש מנותק ממערכת ההפעלה - כלומר, ה-CPU יכול לגשת אליה, אבל הוא ניגש אליה דרך . . . לפעמים זה אפילו איזה Chip-הצפנה בדרך, ואף אחד מחוץ למה שאמור לרוץ ב-Secure Enclave הזה לא רץ ב-Secure Enclave הזה, לא נוגע ב-Secure Enclave הזה.
• בטכנולוגיות הטובות ביותר, אפילו אם תנסה לקרוא את מה שרשום על הדיסק - אז הוא מוצפן, אז אתה לא יכול לקרוא את זה.
• כלומר, זה ממש אמור להיות מוגן ברמה הכי גבוהה. 

25:04 זמן טוב לדבר על Blackhat - ו-CMP
(רן) אוקיי, עכשיו זה זמן טוב לדבר על Blackhat? יש לנו מספיק Context? אז למי שלא מכיר, רק שנייה - Blackhat זה כנס שנתי מאוד מאוד גדול שקורה עדיין ב-Vegas? כן . . .  זה, אני חושב, הכנס מספר אחת בעולם ה-Security . . .(אורי) שתיים, שתיים . . . (רן) אוקיי, אחרי רברסים . . . ושם ניתן דגש גם על טכנולוגיות להגנה - אבל גם על דרכים לפריצה, זאת אומרת, כדי שנכיר את מה שנקרא “להכיר את האויב” [גם ברברסים! ד”ש לג’וזף]. הכינוי “Blackhat” ”זה מין כינוי כזה לפורצים. אז באת - אתה והצוות - והצגתם איזושהי תגלית - ספר לנו עליה קצת.

• (אריק) כן, אז קודם כל: אורן וניקוס - אני רוצה לתת להם את הקרדיט, הם עשו עבודה מדהימה.
• אז בעצם בתוך כל המנגנון הזה, אנחנו מסתכלים על כל המערכת הזאת ואנחנו חוקרים את התחומים האלה - זה מה שאנחנו עושים כחברה.
• כמו שהפרוטוקול MPC שלנו זה משהו שאנחנו בעצם כתבנו, שחררנו . . .
• שוב, אני רוצה לתת את הקרדיט לאנשים - ניקוס, אודי ורן קנטי בעצם הוציאו אלגוריתם חדש - CMP - זה ראשי תיבות של האנשים האלה [והנה המאמר - UC Non-Interactive, Proactive, Threshold ECDSA].
• אז בעצם אנחנו חוקרים את הנושא הזה, ובשלב מסוים אנחנו אומרים “רגע, אלגוריתם MPC, הוא בעצם מדבר באמת על זה שאף אחד לא סומך על אף אחד, וגם אם אתה תשתלט על אחד מהשחקנים, אתה לא אמור להיות מסוגל לעשות שום דבר”.
• ואנחנו רוצים למצוא - אולי כן אפשר?
• אז חקרנו אלגוריתמים שונים בתעשייה - ובעצם מצאנו בשני אלגוריתמים, שהם היו אלגוריתמים המובילים בתחום.
•  בעצם CMP היה טיפה פחות מוכר, או קצת חדש יותר - היו כמה אלגוריתמים מובילים, ביניהם GG ו-Lindell 
• אלו שני אלגוריתמים מאוד מוכרים, שהרבה מאוד חברות, גם בתחום שלנו, השתמשו בהם.
• ומה שבעצם אנחנו מצאנו זה שבאלגוריתמים האלה,  אם אתה עושה “משחק" כלשהו - והיתה שם, שוב, עבודה מתמטית-קריפטוגרפית יפיפייה של ניקוס - אם אתה עושה “משחק” כלשהו, אתה בעצם - במידה ותשתלט על אחד השחקנים - אתה תוכל לאט לאט “לדלות את הסוד” מהשחקנים האחרים.
• זה משהו שאסור שיהיה קיים באלגוריתם MPC - אנחנו מניחים שאף אחד לא מספר שום דבר לאף אחד אחר, זה כל הבסיס לדבר הזה.
• מה שבאמת הצגנו בBlackhat [הנה השקפים - Small Leaks, Billions Of Dollars: Practical Cryptographic Exploits That Undermine Leading Crypto Wallets] ו-DEFCON [לזה יש ההקלטה - EF CON 31 - Small Leaks, Billions Of Dollars - Nikolaos Makriyannis, Oren Yomtov] 
• זה כזה השילוב היפה ב-Vegas: שני כנסים שמגיעים אחד אחרי השני . . .
• זה . .  אני חושב שזה היה ארבע התקפות בסופו של דבר, שתוקפות מספר פרוטוקולים שונים בהכי-קיצוני שלהם, בחתימה אחת
• או יותר מזה - בסיבוב הראשון, בתוך החתימה הראשונה, כי MPC זה לרוב מורכב מסיבובים - אתה מסוגל להוציא מפתח, בעצם, משחקן אחר.
• וככל שהאלגוריתם שונה ואחר, אז זה יכול לקחת יותר חתימות - בחלק מאופציות ממש הרבה חתימות - אבל בעצם הצלחנו סוג-של-לשבור אלגוריתמים מסוימים של MPC.
• שוב, זה אלגוריתם שלנו - שהיה חשוף לזה, אבל זה כמו כל דבר ב-Security, כן? אנחנו מוצאים את החולשה הבאה, הראינו גם את הפתרונות לדברים האלה, ולאט לאט כל התעשייה מתקדמת ומוצאת פתרונות טובים וחדשים יותר.
• כן ראינו, בעצם, שחברות גם מאמצות את הפתרונות שהבאנו לזה וגם בעצם עוברות לאלגוריתמים קצת  חדשים יותר בחלק מהמקומות
• נוטשות אלגוריתמים שכבר הוכחו כלא טובים, בחלקם,  ועוברים לדברים אחרים.

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

• (אריק) כן, אז אני חושב שבאמת אחד הדברים ש... יש הרבה מאוד תובנות בתחום הזה, ואני חושב שאחד הדברים שחשוב להבין - וזה כזה סוג של לקח שבאמת נכתב ב . .  אולי “דם” זו לא המילה הנכונה, אבל מאמר אקדמי הוא לא Spec, אוקיי? 
• והרבה אנשים קוראים מאמר, וזה קצת מרגיש כאילו זה Spec - כי בעצם מתארים שם פעולות
• לרוב זה Pseudo-code כזה - כמתכנת אפילו אתה סוג-של-מבין מה קורה
• אבל יש המון דברים מתחת לפני השטח, שאלא אם כן באמת יש לך את המקצועיות והידע איך לקרוא מאמר כזה, אתה פשוט תניח שהן לא הנחות נכונות, כלומר שמשמיטים שם דברים.
• בסוף, מאמר אקדמי זה מאמר - המטרה . . . 
• (אורי) . . . הוא לא יביא את “מקרי הקצה” - הוא יביא את ההוכחה האקדמית שמשהו קורה, אבל . . .
• (אריק) אז לפעמים לגמרי, לפעמים זה מאוד תלוי מה המטרה של המאמר.
• לפעמים המטרה של המאמר זה לתת פרוטוקול מלא, לפעמים המטרה שלו זה שבכלל פשוט יש לו רעיון אחד חדשני, אבל הוא יודע שבשביל הרעיון הזה, הוא צריך לעטוף אותו בהמון דברים, אז הוא “עושה את העטיפה שצריך” כדי שהמאמר יתקבל לכנס הנכון . . . .
• ואז אתה קורא את זה, ואתה מניח שאם מה שקראת זה מה שיש אז הכל בסדר - אבל הוא בעצם מניח  שקראת עוד ארבעה מאמרים אחרים לפני זה כשתממש את זה, כן? . . . 
• אז זה למשל משהו שממש יכול להיות מהותי.
• מעבר לזה, הרבה פעמים בכלל המאמר מתייחס לאיזו סיטואציה בעולם, אוקיי?
• כלומר, הוא מניח שזה משחק חד-פעמי, אוקיי?
• זה מאמר - הכל Secure, הכל טוב, הכל מעניין, הכל מוכח - כל עוד אתה משחק את זה פעם אחת. 
• אבל אם תשחק את זה הרבה פעמים, אז כבר שום דבר פה לא עובד . . . 
• זה לא בהכרח יהיה כתוב בצורה הברורה שאתה מניח - כלומר, יש איזה הנחות של איך המערכת עובדת.
• האם אתה עושה Input Validation לפני האלגוריתם הזה? יכול להיות שהוא מניח את זה, יכול להיות שהוא לא מניח את זה . . . .
• כלומר, יש פה עולם שלם של בכלל איך אתה נכנס לדבר הזה.
• אז זה למשל איזור אחד.
• אני חושב שאיזור אחר שהוא גם מעניין . . . 

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

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

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

• (אריק) נכון, לגמרי, לגמרי . . .  והרבה גם ממה שפורסם ב-Blackhat - חלק מהדברים היו שם, כלומר המאמר היה בסדר, אבל ברגע שהשתמשת בו בעולם האמיתי זה לא עבד טוב.
• כלומר - הייתה בעיה, שצוינה בצורה מסוימת או שלא צוינה בצורה מסוימת - אבל ראינו שהרבה בעצם לא יודעים לפתור אותה.
• דבר נוסף שהוא מאוד חשוב - דיברנו על Secure Enclave, דיברנו על כל הטכנולוגיה שאתה שם, על MPC, על  כל הדברים האלה.
• אבל נגיד שיש שאלה של Supply Chain Attacks, כן? כלומר, אתה כותב קוד ואתה, מכיוון שאין לך הרבה זמן, אתה דוחף פנימה איזה 15 ספריות שונות, שעכשיו נמצאות בתוך ה-Secure Enclave שלך . . . 
• אז זה נחמד שאתה מאוד Secure מהתקפות מבחוץ - אבל מה אם יש לך Malware בתוך הקוד שנכנס, כן?
• כלומר, יש הרבה דברים שמבחינת ה-Security, פשוט  Security Practices בסיסיים, הם . . .
• שוב, ברגע שאתה שוב מתעסק במשהו כל כך מורכב, אתה צריך להקשיח אותם מאוד.
• ה-MPC שלך מקבל Input - מה אתה עושה עם ה-Input הזה? עד כמה אתה רגיש למישהו שמשחק עם ה-Input בצורה שהיא לא צפויה, כדי להתחיל לייצר התנהגות אחרת?
• כלומר, יש ממש הרבה דברים שאתה צריך לגעת בהם כשאתה מתכנן את המערכת הזאת
• היא ממש דורשת כזה “איזורי Expert” - אתה צריך להיות Expert בקריפטוגרפיה, אתה צריך להיות Expert ב-Blockchain, אתה צריך להיות Expert ב-Security.
• או לאסוף את כמות האנשים האלה שבעצם מסוגלים לאסוף את כל הדברים האלה למשהו קוהרנטי,  שגם עובד טוב ביחד
• כי יכול להיות איש Security מדהים ואיש קריפטוגרפיה מדהים - אבל בדיוק בתווך ביניהם, זה איפה שהכל מתפרק.
• וגם זה דברים, שבעצם במאמר שלנו - במאמר וההרצאה ב-Blackhat - ממש נגענו במקום הזה.
• כלומר, בנקודה הזאת, שבה “הקריפטוגרפיה פוגשת את העולם האמיתי”.

33:15 ובחזרה ל-Fireblocks
(רן) אוקיי, אז נסכם - אז Fireblocks, אתה אומר - התחלתם בבעיה הנקודתית הזאת, של איך להחזיק מפתח, איך  להחזיק מפתח בצורה שהיא Secure, ואחר כך להוסיף על זה הרשאות וכו’, וגם אמרת, לא נכנסנו לשם, אבל שאתם הרחבתם את השירותים שלכם מעבר לזה, לזה לא היה לנו זמן להיכנס פה.ואז צללנו קצת פנימה, לתוך עולם הבעיות האפשרי - ואיך אפשר, ככה ממש על קצה המזלג, לפתור אותן. זזה היה סופר-מרתק!ספר לנו אולי עוד קצת על החברה - אתם כרגע מגייסים? מחפשים? איפה אתם נמצאים בכלל? אמרת? . . .

• (אריק) כן, אז טוב - אנחנו נמצאים בתל אביב, מגייסים . . .

(רן) איפה זה תל אביב? . . . .

• (אריק) תל אביב בואכה רכבות למיניהן . . . .
• כמובן מגייסים  . . . Fireblocks, לא דיברנו על זה בכלל, אבל יש לנו כבר הרבה לקוחות
• חברה שהיא מאוד מצליחה.
• אני חושב שעד היום איבטחנו משהו כמו 4 טריליון דולר במערכת - כלומר, אנחנו מתעסקים באמת בכסף מהותי, בעיות מהותיות של לקוחות אמיתיים.
• וגם כל מיני אנשים - אני יודע שהרבה אנשים כזה,  “Blockchain” זה משהו שהם כזה לא בטוחים “כמה קורה שם משהו מעניין”.
•  אנחנו באמת עובדים עם החברות הטובות בעולם - חלקן פומביות לגבי הדברים שהן עושות ב-Blockchain,  חלקן עוד לא פומביות.
• אבל גם בכל השנים האלה, שמאוד יכול להיות שלא - בתור “טכנולוגים” - לא התעסקתם ב-Blockchain, כי זה היה נשמע כמו משהו שכבר “עבר, קרה ולא מעניין” . . . .
• הרבה חברות בנו בזמן הזה - בין אם זה חברות שבונות טכנולוגיה כמונו, ובין אם זה חברות מוצר.
• המנכ״ל של Shopify, ה-Founder של Shopify, טובי (Tobias Lütke)- לפני איזה חצי שנה הוא היה בכנס, והוא אמר “אנחנו בונים דברים טובים בקריפטו כרגע. כרגע זה לא נשמע מגניב - עוד מעט זה יהיה מגניב, ואתם תשמעו על זה אז”. [Crypto Conversations | The future of the digital economy with Brian Armstrong & Tobi Lütke]
• ואני חושב שזה מייצג מאוד את התעשייה - הרבה טכנולוגיה נבנתה פה ונבנית פה, ולאט לאט היא תצא לעולם, בקצב שהרגולציה ופשוט הטבע של האנשים יאפשרו לה.
• (רן) כן, בעקומת ה-Hype, אנחנו עכשיו במדרון המתון העולה  . . . 
• (אריק) נכון, לגמרי.

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

• (אריק) חלק קטן מאוד ממה שאנחנו עושים בחברה זה האזורים האלה של הקריפטוגרפיה.
• מעל זה, יש שכבות על גבי שכבות של מוצר - מאוד חדשני שפותר בעיות ללקוחות.
• כלומר, כל הדברים הרגילים שאנחנו מכירים - כשיש להם איזה “Flavor”, כאילו גם “Flavor FinTech-י”
• אנחנו היום הרבה יותר חברת פינטק מאשר סייבר . . . 
• זה התחיל מאוד Security-oriented, וזה עבר לפשוט לאפשר לבנות . . . 
• אנחנו, המטרה שלנו זה שכל עסק שרוצה לבנות - ואנחנו מאמינים שכל העסקים יגעו בעולם ה-Blockchain בעתיד - יוכל לעשות את זה, בלי להתעסק בכל הדברים שדיברנו.
• כלומר, שהם פשוט יקבלו מוצר טוב שהם עובדים איתו, הוא עובד כמו שצריך, הוא בטוח - והוא גם Easy to Use.
• אז זה לגמרי לבנות מוצר טכנולוגי לאנשים.

(רן) אוקיי, אריק, תודה רבה! היה לי ממש כיף, להתראות.

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

[קישור לקובץ mp3]פרק 467 של רברס עם פלטפורמה - הוקלט ב-5 בספטמבר 2023 (חג ספטמבר שמח!). אורי ורן מארחים באולפן בכרכור את רולי אליעזרוב מחברת OwnID לשיחה על Passkeys ותחום ה-Identity Management, שרולי נמצא בו כבר הרבה מאוד שנים.

01:20 קצת על רולי , Gigya ו-OwnID(רן) אז לפני שנצלול פנימה - כמה מילים עליך ועל החברה, רולי?

• (רולי) כן, אז כמו שאמרת - אני באמת Veteran של תחום ה-Identity: אני הקמתי חברה בשם Gigya ב-2007
• שבאיזשהו שלב, ב-2017 או 2018, נרכשה על ידי SAP
• ובעצם, מה שגם מיוחד בגישה שלנו - כשאתה מדבר על iIdentity, בדרך כלל זה חברות, החברות שנותנות פתרונות בתחום הן עם “DNA של IT”
• זה בדרך כלל נתפס כאיזשהו פתרון Security לבעיה של אות’נטיקציה (Authentication) בדרך כלל של ה-Employees או B2B
• ואנחנו - גם בחברה הקודמת וגם בחברה הזו, ואני חושב ש-Passkeys גם מתקשר לזה - מביאים את זה לרמת ה-Consumer
• זאת אומרת - פתרון . . . . אנחנו בעצם היינו מהראשונים שנתנו פתרון-מוצרי, שמשרת את ה-Consumer
• מכרנו לחברות - אבל זה לא היה לזיהוי של העובדים, אלא ל-Identity של הלקוחות.

(רן) לצורך העניין - לא זיהוי של עובדי הבנק, אלא זיהוי של לקוחות הבנק . . .

• (רולי) כן, והרבה פחות מבנקים, אפילו . . .  אתה יודע,  B2C הכי “Mainstream”

(רן) כן, אז זה מה שהיה ב-Gigya - והיום ב-OwnID?

• (רולי) כן, אז ב-Gigya בעצם “ארזנו” קונספטים (Concepts) קיימים שקשורים ל-Identity,
• למי שלא הבינו עדיין על מה אנחנו מדברים - על Registration, Login וכל ה-Data שנשמר מאחור 
• וה-Consent - מה אני יכול לעשות עם ה-Data, וכו'.
• אז פשוט ארזנו את זה ועשינו פודקטיזציה (Productization) של כאילו Plug & Play לכל חברה שרצתה להשתמש במשהו “מן המוכן”.
• אבל בעצם לא המצאנו שום דבר . . . 
• מה שעשינו ב-OwnID זה שאנחנו מביאים בעצם איזושהי “בשורה” - שאפשר לעשות Identity באופן שהוא הרבה יותר “נעים למשתמש”
• אף אחד הרי לא אוהב - לא להירשם, לא לעשות Log-in, אף אחד לא אוהב סיסמאות . . . 
• וזה מה שאנחנו עושים עכשיו.

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

• (רולי) . . . . אבל זה אתה, כי אתה סבבה עם להירשם עם Google או GitHub
• יש הרבה מאוד אנשים . . . . בואו נגיד, 50% משתמשים במה שנקרא Social Login או External Identity Provider בשביל להתחבר לאתר - ו- 50% עדיין ממציאים שם משתמש עם סיסמא
• מסיבות של “האח הגדול” או Privacy או כל סיבה אחרת

(אורי)  . . . אולי גם קצת שמרנות ולא יודע, לא הולכים על “הקל” אלא רגילים ל . . . .

• (רולי) נכון

03:58 הצעצוע החדש - Passkeys מביא את זה לרמת ה-Web(רן) אוקיי, אז בואו נדבר על “הצעצוע החדש שהגיע לשכונה” - Passkeys: מה הם?

• (רולי) כן, אז קודם כל זה שיתוף פעולה יוצא דופן בין שלושת הענקיות - Google, Apple ו-Microsoft - שהבינו את הבעייתיות שיש
• בעיקר אנחנו מדברים עכשיו על הנושא של האות’נטיקציה (Authentication), שזה ההזדהות
• אני חושב שזה, נכון להיום, בעיקר שם-משתמש וסיסמא - והבעיות שקשורות לסיסמא
• מעבר לזה שזה לא נוח, הן אינסופיות, גם מבחינת כמובן Security,
• שאגב - מייצר עוד Friction, בגלל הבעיות Security - הן מייצרות עוד Friction, יותר ממה שהיה קודם
• כי עושים את הסיסמא יותר מורכבת, מבקשים עוד Factor כמו SMS Message או Authenticator - אז בעצם הבעיה נהיית יותר ויותר חמורה עם הזמן 
• ככל שיש יותר כלים - כלי-פריצה - בשוק
• והם הבינו שצריך לעשות פה איזשהו שינוי
• כשאומרים “Password-less” - עד היום, אם אתה תראה פתרונות של, נאמר, שליחה של SMS, שזה קוד חד-פעמי, או Magic Link,
• וזה דברים שהם שבורים - הם גם לא נוחים וגם לא Secured
• אפשר לדבר, אם אנחנו רוצים, גם קצת לצלול לצד של ה-Security . . . 
• אבל מה שהם הכריזו . . . הם אמרו ככה: קודם כל, בכל Device כמעט היום יש - לפחות ב-Device-ים המתקדמים - יש Unlock-mechanism
• אם זה ב-iPhone אז יש את ה-Face ID, ב-Apple . . . . ברוב ה-Mac-ים יש את ה-Touch ID
• גם בWindows היום יש . . . אם זה לא ביומטרי, אז יש איזשהו Unlock, שרוב האנשים כאילו קמים מה-Desktop אז הוא ננעל.
• ואנשים עושים Unlock ל-Device שלהם - גם אם זה Mobile וגם אם זה ה-Desktop, כל הזמן.
• ולמה לא להשתמש באותו מנגנון, בשביל גם לאפשר, גם ברמת ה-Web, לעשות את האות’נטיקציה (Authentication)?

(רן) כלומר ”ה-Device כבר יודע מי אתה”. אתה משתמש בטלפון, פתחת אותו - הוא זיהה אותך . . . .

• (רולי) כן, עכשיו זה לא שהוא מדווח “מי אתה" - הוא רק אומר “הבנאדם הצליח לעשות Unlock ל-Device שלי” . . .

(אורי) אבל משתמשים בביומטרי גם כדי לפתוח אפליקציות . . . .

• (רולי) אוקיי . . . . עד היום, היה ממשק רק ל-Native Applications, ל-Unlock Mechanism.
• ומה שהוא עשה - או מה שהוא עדיין עושה - הוא בעצם שומר . . .  הוא נותן גישה לשלוף את הסיסמה מה-OS - ולשלוח אותה
• זאת אומרת - עדין קיימת סיסמה
• ב' - זה רק ברמת ה-Native Apps - אני בטוח שלשניכם יש אפליקציות ולכל השומעים שלנו, הקהל, יש אפליקציה של הבנק שלהם
• והם כל כך מאושרים מזה שהם יכולים עם ה-Face ID, או עם ה-Fingerprint, אם זה ב-Android, כל פעם לבצע פעולות
• אבל כשהם הולכים למחשב, או כשהם רוצים לעשות משהו אחר או מכל סיבה אחרת - הם צריכים את הסיסמה עוד פעם . . . .
• אז התשובה היא שיש את זה לרמת ה-Native Apps - והפרוטוקול הזה של Passkeys מביא את זה לרמת ה-Web.
• עכשיו, רק נחזור לנושא של שלושת החברות - הן אמרו “בואו נקרא לזה Passkeys”: בואו נעשה, יחסית, ממשק מבחינת API אחיד,
• של גם . . . למה בעצם זה “שלושת השחקנים”? כי Windows ו-Android ו-iOS של Apple - זה מכסה את רוב השוק
• ואז, אם אתה עושה אימפלמנטציה (Implementation) אחת, בתור מתכנת - אתה מקבל את כל ה-Device-ים.
• יש הרבה “אבל-ים”, אבל זה ה... שוב, כאילו, “Quick”.

07:30 מה פתאום הם משתפים פעולה?(רן) אבל בוא נעצור פה רגע - אני זוכר שהייתה תקופה שבה בכל אחד מהחברות האלה, רצו לקבל כמה שיותר משתמשים אצלן בפלטפורמה, ובגלל זה מאוד מאוד עודדו את ה-Social Login, אוקיי. למה הפסיקו? כאילו, מה פתאום הם משתפים פעולה עכשיו?

• (רולי) כן, אז בעצם זה חלקים אחרים באותן חברות . . . .
• אבל באמת, אני חושב שאתה מעלה נקודה נכונה - בעצם, איפה זה עומד מול ה... נקרא לזה ''Social Login''?
• אז ככה, ה-Social Login . . . 
• (רן) . . . . Facebook היו שם, מן הסתם . . . .
• (רולי) כן, Facebook המציאו את זה - והאחרים הבינו שזה דבר מאוד חזק.
• הכוח העיקרי . . . . יש לזה שני יתרונות לספק - ל-Facebook או ל-Google או ל-Twitter או מי שזה לא יהיה . . .
• 1 - זה ה-Affinity ל-Brand והקשר שלך
• כי בעצם, אם עכשיו אני נוטש את Facebook או סוגר את ה-Account, אז אני לא אוכל להיכנס לכל האתרים שנכנסתי אליהם
• אז יותר סביר שאני אשמור, שאני לא . . . שאני אשאר עם Facebook, יהיה לי יותר קשה לעזוב אותו.
• והדבר השני זה Data - אם אתה עושה היום Log-in ב-Facebook, כ-End-User, עכשיו Facebook יודעים, . . . .
• בוא נגיד באתר Travel כלשהו - טיסות
• אז Facebook יודעים שעכשיו אתה מחפש טיסות - וכל החבר'ה של הטיסות עושים Re-Targeting עליך . . . .
• שזה אחד החסרונות לאנשים, שאתרים שמוסיפים Social Log-in לא מודעים אליו.
• אז זה בעצם . . . .  קודם דיברנו על Down-side שקשור . . . מהצד של המשתמש - שהם מפחדים, שמרנים וכו',
• אז יש גם Down-side מהצד של האתר וזה שאפשר לעשות Re-Target
• בעצם, שחקני ה-Data האלה יודעים  . . . 

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

• (רולי) אתה צודק, נכון . . . . אז אתה מחזק את מה שאני אומר.
•  ו-Passkeys, אם אתה שואל בעצם, לחזור לשאלה שלך - אני חושב שזה Initiative שבחברות כאלה ענקיות הוא בא במקום אחר
• בטוח שהיה איזשהו דיבור - אבל מצורך אחר לגמרי, שהוא יותר “Device-י כזה”
• הוא בא פחות מהצורך ה-Business-י
• אז לדעתי זה פשוט Initiatives שעלו ו . . .

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

• (רולי) זה לא מדבר . . . .

(אורי) זאת אומרת, זה ספציפית, API לתוך המכשיר, אין . . .

• (רולי) “לעשות את העולם יותר טוב” . . . .

09:52 הטכנולוגיה(רן) אז בואו רגע באמת נדבר על הטכנולוגיה - איך טכנית זה עובד? אז נגיד פתחתי את הטלפון, הוא זיהה את הפנים שלי - ועכשיו אני רוצה לעשות Log-in לאיזשהו עמוד אינטרנט.

• (רולי) . . .  אתה כבר מגיע למוצר. אני יכול לתאר אחת את ה . . . 
• כי במוצר יש דרכים שונות לעשות אימפלמנטציה (Implementation) של זה . . . . 
• אני אענה שנייה על הטכנולוגיה.
• הטכנולוגיה היא בעצם שה-OS, ברגע שהוא מקבל את הקריאה הזאת
• יש קריאה של Set ויש קריאה של Get
• כש-Set זה אומר כמו פתיחת Account, זה פעם ראשונה
• הוא מייצר Secret Key ו-Public Key שומר את שניהם ברמת ה-OS ונותן . . . 
• (רן)  שזה פר... פר-אתר?
• (רולי) פר-אתר, כן - ונותן לך את ה-Public key.
• עכשיו אני יכול לשמור אותו ב-Database שלי - תסתכל על זה כמו ה-Username.
• בפעם הבאה שה-User חוזר . . .
• (אורי) “ה-User” זה המתכנת של האתר?
• (רולי) כן.
• בפעם הבאה שה-User מגיע, אני אומר לו Get - ואני אומר לו מה ה-Public Key
• אני אגב לא הטכנולוג - אני איש Product, אבל אני מספיק מכיר . . . .
• והוא הולך, בודק ורואה שיש לו באמת ה-Public Key הזה -
• והולך ל-Secret Key ומייצר Signature שהוא Based על ה-Secret Key הזה - ומחזיר אותו אליי.
• אני לוקח את ה-Signature הזה, שהוא Time-Based כך שהוא Expired, מה שהופך אותו לעוד יותר Secured
• ומשווה אותו עם ה-Public Key שיש לי
• ואם אני רואה שיש Match, אני אומר אוקיי - זה ה-User שבמקור עשה את ה-Set
• ולכן אני יודע שזה הוא - זה כמו ה-Username ו-Password.

(אורי) וזה - אתה אומר שזה Time-Based, אז זה, כאילו, יישאר לאורך ה-Session?

• (רולי) לא . . . . ה-Session - עכשיו, אתה מחליט, בתור אתר, ברגע שאני אומר לך “זה ה-User”
• אתה מחליט מתי הוא To Expire את ה-Session
• אתה יכול, עד שה-Cookie ימות, אתה יכול עד שהוא סוגר את ה . . . . אתה מחליט.
• אבל כאילו . . . . זה יעבוד - ההשוואה הזו, שאני בודק שזה באמת כמו ה-User - זה בעצם “Password זמני”,  שטוב . . . 
• אם אני איהיה עוד 10 דקות . . . אם למשל אני אקח את הדבר הזה והקשבתי ואני אנסה, אחרי שהבנאדם הלך, לעשות עוד פעם אות’נטיקציה (Authentication) - זה כבר לא יעבוד.
• ורק עוד משהו קטן, כי זה גם מתקשר למשהו שאולי נגיע אליו, בהקשר של דיסנטרליזציה (Decentralization) של Identity ו-Self-Sovereign Identity, שזה קונספט מדהים, שלדעתי העולם הולך אליו והוא מרתק.
• תחשוב על זה שבעצם הסיסמא הזו, שאמרתי שאנחנו מקבלים - ה-Signature - הוא גם Per-  . . . 
• לא רק שהוא Time-Based - הוא פר-אתר.
• אז תחשוב שזה כמו ש . . . טוב, האמת שנגיע לזה כשנגיע ל-Self-Sovereign Identity . . . 

(אורי) אבל זה בעצם Owned ב-Device - במערכת-הפעלה של ה-Device. . .  עכשיו אני ב-Facebook . . . .

• (רולי) מה קורה כשעוברים Device?

(אורי) לא, יש לך Facebook וכמה Device-ים, או לא יודע . . . . עכשיו, בוא . . .

• (רולי) נכון, כן . . .  נגיד, פתחתי Account, אתה אומר בטלפון, פתחתי חשבון באתר בטלפון - ועכשיו אני הולך למחשב. איך אני יכול לעשות Log-in?
• אוקיי, אז עכשיו אנחנו מגיעים ל . . . . בוא נגיד, אני אתן קודם את התשובה הפשוטה:
• אם זה באותו Ecosystem - לכאורה גם שם זה לא בדיוק . . . .
• לפחות ב-Apple, אם אתה מחובר עם שניהם ל-iCloud - זה יעבוד.
• כי ה-Keys נמצאים ב-iCloud,  ואז הוא בודק ש . . .
• (רן) ה-Private Keys . . .
• (רולי) כן, וגם ה-Public Keys . . .  
• אבל קודם כל - אתה גם צריך לעבוד עם Safari - ומה קורה אם אתה עם Chrome? . . .  אני למשל עם Chrome עם ה-Mac, 
• שלא לדבר על PC . . . 
• או שלא נדבר על המחשב של . . .  לא יודע מה - של בת-הזוג שלי, או של חבר שלי, או Public Device, או ה-iPad-של-המשפחה-שמסתובב-בבית . . . .
• (אורי) “אינטרנט קפה”! זוכרים את הדבר הזה? . . . .
• (רולי) נכון! לא יודע, יש כזה עוד? בניו יורק, הענקיים כאלה . . . .
• אז נכון - אז זה צריך לעבוד בכל הסיטואציות האלה . . . . ומה עם Device שאין לו ביומטרי?
• אז עוד רגע נדבר על כל הסיטואציות האלה ומה . . . . למה בעצם אולי כדאי לעבוד עם איזשהו Vendor שנותן פתרון מלא.

13:53 הפתרון ה-Product-י

• אבל אולי עכשיו אני יכול, אם אתה רוצה, להגיד את הפתרון ה-Product-י, שזה אומר, מה ה-Flow? איך זה נראה?

(רן) בוא רגע נבין מה יש לנו פה . . . . אז אם מקודם נגיד, דיברנו על Scenario של Social Login - שנגיד הייתי Logged-in דרך Facebook או Twitter או Google, שגם, לצורך העניין, גם היה יכול להיחשב ל-Social Login - הם היו יודעים עליי המון דברים, אוקיי? . . . היו, בגדול . . .  כל מה ש-Google יודעים עליי, כל מה ש-Facebook יודעים עליי - גם הם יודעים.פה, ב-Scenario הזה, כל מה שהם יודעים עליי, זה איזשהו Public-Key, נכון? איזשהו רצף-בינרי של מספרים . . . .

• (רולי) “השחקן הגדול” - “ה-Google”? אפילו את זה הוא לא יודע . . . 

(רן) אוקיי, אז האתר . . . .

• (רולי) האתר מקבל רק Public-Key, כן.

(רן) אז האתר מקבל איזשהו Public-Key, והוא לא יודע עליי שום דבר חוץ מזה, אוקיי? . . . .

• (רולי) נכון.

(רן)  . . . . הדבר היחיד, שאולי תיכף נגיע אליו, זה שאם עשיתי Log-in מ-Device אחר, אז הוא יראה את אותו Public-Key והוא יבין שזה אותו המשתמש - אבל עדיין, הוא לא ידע עליי כלום: הוא לא יודע מה ה-email שלי, מה שמי - אלא אם כן בחרתי לתת להם אותו . . . .

• (רולי) נכון.
• עכשיו באמת - זה מוביל אותי לאימפלמנטציה (Implementation) של הטכנולוגיה
• כי בסופו של דבר, רוב האימפלמנטציות (Implementations) הן בדרך שהוא כן יודע את כל הדברים האלה, אחרת . . . .
•  כי מה שהם עשו - Google כבר עשו אימפלמנטציה של זה, אתה היום יכול לגשת ל-Google Account שלך ולהוסיף Passkeys
• גם TikTok עשו את זה ואחרים . . .
• ומה שה . . . האימפלמנטציה היא שאתה קודם כל פותח חשבון בדרך הכי רגילה שיש
• נותן את כל האינפורמציה על עצמך, ממציא Password . . . 
• ואז אתה יכול או ללכת ל-My Account ולהוסיף את Passkeys כ-”Another Authentication Option”
• ואתה צריך בשביל זה להיות Logged-In.
• או שיש כאלה שעושים שאחרי שאתה עושה Log-In, הם שואלים אותך “האם אתה רוצה להוסיף Passkeys, כעוד דרך לאות’נטיקציה (Another Authentication Option).
• בעצם, הם די מחקים את ה-Experience שקיים ב-Native
• מה שאמרנו - שהוא פשוט לוקח את הסיסמא, מצפין אותה, ועם ה-Face ID מוציא אותה החוצה.
• אני יכול להגיד למה הם עושים את זה - כי זה פותר את כל השאלות שהרגע אתה אמרת . . . .
• זאת אומרת - כשהוא עובר Device, אז מקסימום מכניס סיסמה, וזה פותר . . . .
• ברגע שיש סיסמה, זה פותר את כל ה-Edge Cases . . . 

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

• (רולי) אבל (א) - אין סיסמה, עדיין . . . . וגם מבחינת Security . . . .
• הבעיה העיקרית של סיסמא זה שאנשים משתמשים באותן סיסמאות על פני הרבה אתרים
• ואם פרצו לאתר וגנבו את ה-Username וה-Password - הפורץ עכשיו עובר אתר-אתר ומנסה את זה עד שהוא מצליח . . . 
• אז כל עוד אפשר לעשות אות’נטיקציה (Authentication) עם סיסמא, עדיין לא פתרת את הבעיה.
• והדבר השני . . . .

(רן) לגנוב אצבע זה יותר קשה . . . . לא שזה בלתי אפשרי, אבל זה . . . 

• (רולי) גם לא עושים את זה  . . . . כי 90% מהפריצות זה כזה “Cross” - כשהם רצים עם רשימות של . . .  או שהם עוד משתמשים באותן סיסמאות, או כרטיסי אשראי וכאלה . . . .
• אבל הבעיה השנייה, זה שאחוז מזערי . . . . בעצם ברגע שה-Flow הוא כמו שאני תיארתי, שאתה עוד צריך ללכת ל-”My Account” בשביל זה . . . 
• ומה זה Passkeys? אף אחד לא משתמש בזה . . . .
• אז אנחנו פשוט נצטרך . . . . אם תרצה, אנחנו נוכל לדבר על למה אנחנו עושים פתרון, שהוא לוקח את הטכנולוגיה הזאת - עד הסוף.
• ועושה שינוי, כאילו, באמת . . . 

17:02 הלקוחות העיקריים(רן) כן, אז למעשה אתם - ב-OwnID - על מי אתם מקילים - על ה-Vendor-ים?, על בעלי אתרים? על המשתמשים? זאת אומרת, מי הלקוח העיקרי שלכם שם?

• (רולי) הלקוחות שלנו  . . . אגב, אנחנו עובדים רק עם חברות גדולות, זה ה-Business Model שלנו.
• יש לנו את Carnival Cruise ו-Nestlé ו-Bayer, שזה ענק תרופות
• ואסותא בארץ, ו-Carrefour . . . . יש לנו הרבה לקוחות גדולים. 
• והם משלמים לנו בשביל להוסיף - זה לא רק Passkeys - להוסיף ולהפוך גם את תהליך ה-Registration וגם ה-Log-in שלהם ל-Frictionless.
• וברגע שהם . . .  אני סתם אתן לך דוגמא - אנחנו בכלל לא מזכירים ב-User Experience . . .  הם מוסיפים אותנו לטפסים הקיימים שלהם, כעוד אופציה.
• אנחנו פשוט מראים כפתור שתלוי ב-Device - הוא מראה לך “Log-In with Face ID” או Log-In with” “Touch  ID, או מה שה-Device הזה מסוגל.
• ואנחנו . . . עוד פעם, אני לא יודע עד כמה אנחנו רוצים להיכנס לפרטים, אבל ה-User יכול לפתוח Account בלי להמציא סיסמא
• ואחרי זה, אם הוא הולך ל-Device אחר, אנחנו נעשה אות’נטיקציה (Authentication) רק של ה-Device.
• או למשל נשלח לו רק One-Time Code, רק לאותו Device, ואז נחבר את ה-Device לאותו Account.
• ובאמת, מעל ל-50% מהמשתמשים של האתרים שהוסיפו אותנו - ככה עושים היום אות’נטיקציה (Authentication)
• במקום 2% או 3% ב-Passkeys “הרגיל”.

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

• (רולי) . . . . כי יש הרבה חורים . . . 

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

• (רולי) בדיוק.

(רן) אוקיי, ואז למעשה, בכל Device קיים Private/Public Keys שונים, או שהם אחודים?

• (רולי) הם שונים . . . . 

(אורי) הם שונים - אבל ל-Account יכולים להיות כמה Passkeys.

• (רולי) נכון, לגמרי.
• ויש, אגב, עוד Scenario-אים - אנחנו דיברנו על ה-One-Time Code בשביל . . . . אני אתן לך סתם דוגמא - אם אתה הולך למחשב, שאתה לא רוצה עכשיו לקשר אותו ל-Account - של חבר שלך . . .
• אז איך תעשה עכשיו . . . איך תתחבר - אם אין Password? 
• אתה לא רוצה עכשיו לעשות את ה-Passkeys שלו . . . 
• אז אנחנו מציגים QR Code - ועם הטלפון שלך, בהנחה שיש לך טלפון, אתה סורק אותו
• הוא עושה Face ID - ואז אתר במחשב, או במה שאתה רוצה, שם הוא מתחבר.

19:24 רגע . . . Lock-In?(רן) האם המודל הזה לא מייצר איזשהו Lock-In ל-Vendor-ים הגדולים? זאת אומרת, עכשיו כשיש לי iPhone, אני לא רוצה לעבור ל-Android, כי כל ה-Passkeys שלי נמצאים עכשיו ב-iPhone  . . . .וזה לא רק להתקין מערכת הפעלה חדשה ולהתרגל לממשק שונה - זה גם להתחיל לייצר Log-In-ים חדשים לכל האפליקציות . . . .(אורי) רן, ה-Lock-In הזה קיים . . . [הוא איתנו בחדר, עכשיו?]. ה-Lock-In הזה קיים בכל מקרה, אז . . . .(רן) אני עשיתי לעצמי מסורת - בכל פעם כשאני קונה טלפון, אני עובר Vendor . . . 

• (רולי) באמת?  

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

• (רולי) אז אני חושב שזה חוזר למה שאמרתי לפני רגע - שאם אתה עושה את האימפלמנטציה (Implementation) הבסיסית, אז זה באמת Device-Specific
• או שיש Password - ואז זה You're Locked
• ואם תיקח פתרון כמו שאנחנו נותנים, שהוא הוליסטי - אז אתה לא . . . 
• אנחנו עושים וריפיקציה (Verification) ל-Device החדש - והוא יעבוד לך.

(רן) הבנתי, אז זאת אומרת שאתם עובדים גם בין Vendor-ים שונים?

• (רולי) כן, בדיוק.

(רן) אוקיי . . . . הרשתות החברתיות נכנסות לזה? או שזאת ממש רק חומרה, רק Device-ים?

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

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

• (רולי) אוקיי, אז מה שאנחנו רואים כאן זה הסרה של . . .  נקרא לזה Friction, בעניין של אות’נטיקציה (Authentication), וכל הקונספט של Registration ו-Log-In הם, איך שאני או אנחנו תופסים אותם, הם מאוד מיושנים. הם . . . .
• אנשים לא אוהבים לעבור אותם, אנשים רק מוכנים להזדהות - אבל הם לא מוכנים עכשיו להוציא את כל הזמן על למלא טפסים ולזכור סיסמאות ולמלא אותן . . . 
• ואני מאמין שבתוך בוא נגיד “שנתיים”, כשזה יהפוך להיות סטנדרט,  לא יהיה יותר כזה דבר Registration ו-Log-In.
• הבנאדם, קודם כל, במקום שרק 5%-10% מהמשתמשים יהיו מזוהים, לדעתי זה יגיע לרמה של 90% עד 100%
• כי זה יהיה ב-One Click - פשוט, אתה תגיע לאתר ב-One Click
• וזה גם יחליף את ה-Cookies - כי היום יש גם בעיה של Cookies, בגלל שה-Cookie מת וה-Browser-ים הורגים אותו, אז האתרים לא יכולים אפילו להמשיך לתת לך Consistent Experience
• כי אחרי שבוע, למשל ב-Safari, ה-Cookie נמחק . . . 
• אז אתה תיכנס לאתר, תעשה Face ID -בעשירית שנייה - ואז אתה מקבל  . . .  אתה מזוהה, אתה עובר חוויה . . . 
• עוד רגע, אני אדבר על ה-Data שקשור ל-Registration, אבל תקבל חוויה קונסיסטנטית (Consistent), לא תצטרך לעבור איזשהו תהליך אפילו, של זיהוי מעבר לזה.
• ובנושא של ה-Data, כי בעצם יש פה אות’נטיקציה (Authentication) ב-Registration ואיסוף של אינפורמציה.
• האיסוף של האינפורמציה יתבצע לא כחלק מהקונספט הזה שנקרא “Registration” - אלא On Demand, מתי שצריך אותו.
• ואז גם אנשים יתנו את זה - אתה עכשיו הזמנת את המשלוח בשופרסל, אז כשאתה מגיע לשלב של ה-Shipping, אז אתה מזין את הכתובת - ומאותו רגע הוא משויך אליך כבר.
• ואין כזה דבר “Guest Checkout”   . . . . וכל ה-Concept-ים האלה, אני חושב, יעברו מהעולם.

(רן) אז זאת אומרת שה-Benefit  המשמעותי לבעלי האתרים זה שאם עד עכשיו אחוזי הרישום היו באזור ה-10%, הזכרת מספר כזה של איזשהו Benchmark עולמי, אז ההערכה שלך שזה יהיה באזור ה-90%.דרך אגב - על מה זה נשען? זאת אומרת, יש כבר נתוני זמן-אמת לסיפור הזה? זאת אומרת, יש. . .

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

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

• (רולי) כן, יש את האנלוגיה של בנאדם שהולך למכולת השכונתית, והמוכר כבר מכיר אותו, ואומר “אה, הגיע הדבר הזה, שתמיד אתה מחפש ולא היה לי כבר חודשיים . . . .”.
• (רולי) זאת אומרת, ה-Relationship - וזה הבסיס, אני חושב, גם לחברה הקודמת וגם לחברה הזו שלי, שבין Consumers לבין Business, הוא הופך להיות דבר שהוא מאוד חשוב.
• אני חושב, שאם פעם המסר היה, שמבחינת הראייה העסקית הכל היה צריך להיות Easy, Simple - אז היום זה הופך ל-Trust, עם השינוי התרבותי שהעולם עובר.
• יש אובדן של אמון - ואני חושב שלקוחות יעבדו עם החברות שהם סומכים עליהן ושיש להם יחסים איתן
• ולא בגלל שה-Experience טיפה יותר נחמד.

25:06 כשזה קל, אז אתה לא שם לב(אורי) אני מכניס פה חשש לשיחה, בסדר? בעיקר כי אני מגיע מעולם הפרסום, ולא, זאת אומרת . . . . דווקא מהעולם שהוא Open Web - האימפלמנטיה (Implementation), שהיא מאוד קלה ופשוטה לעשות אות’נטיקציה (Authentication), יכולה פתאום לפתוח מקומות שלא היינו רגילים לעשות בהם אות’נטיקציה . . . .פתאום זה נהיה קל - אז עושים! . . . . אז פתאום, לא יודע מה - ל-Ynet יש את המזהה שלך, מה שהיום לא היה להם מזהה, עד היום . . . .

• (רולי) נכון . . . .

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

• (רולי) אתה מדבר גם על מה שנקרא PII בהקשר הזה, או בלי PII?

(אורי) לא - לצורך העניין, לשחקני הOpen Web, ואני לא מדבר על Facebook, או כל האתרים, או האפליקציות שאתה נרשם אליהן, כולל Amazon. אני מדבר על אתרי-תוכן לצורך העניין, או אפילו eCommerce - שאתה נכנס בלי כוונה לקנות, אתה לא צריך לעשות Log-In . . . . החוויה הייתה אנונימית - וככה גם הפרטים האלה לא היו עוברים לרשתות הפרסום, שעומדות מאחורי האתרים האלה.

• (רולי) חוץ מתקופה שהיו Cookies . . . . זאת אומרת, לא הפרטים עוברים, אבל . . .  אז זה ש”המשתמש הזה, עכשיו, קרא את כתבה הזאת”, היא החברה השלישית . . . 

(אורי) נכון, ולכן . . . .

• (רולי) . . . . הרגו את ה-Cookies . . . .

(אורי)  . . . ולכן הולכים ליותר ויותר 3rd-Party Cookies  שהולכים, וכל זה כאלה  . . . (רן) בעצם אורי, אתה אומר שאם לפני זה מעט אתרים ידעו עליי הרבה - אז בעתיד הרבה אתרים ידעו עליי מעט . . . אבל זו רמת הסיכון, אולי, מבחינת המשתמש, רמת הסיכון של Privacy.(אורי) זה לא כזה משנה אם זה מעט הרבה או הרבה מעט, אבל האם עכשיו . . . .  לא יודע מה, New York Times רוצים ממך שתעשה Log-In, כי אתה משלם גם עבור ה-Log-In הזה, וזה אחלה . . . . אפילו “הארץ”, אותו הדבר.אבל Ynet, לצורך העניין, לא מבקש ממך Log-In - ואם הוא יתחיל לבקש ממך Log-In, זה יהיה מסובך . . . . אוקיי, זה להכניס את ה-email שלי ואת ה . . . 

• (רולי) אז הם לא יבקשו . . . . אם זה יהיה מסובך, אז הם כנראה לא יבקשו . . . .

(אורי) עכשיו, כשמתחילים להכניס מנגנון, שהוא קל . . . .

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

(אורי) . . . . אז אולי כן יעשו את זה - ותיפגע הפרטיות, כי כשזה קל, אז אתה לא שם לב . . . 

• (רולי) אז קודם כל - חלקית אני מסכים איתך   . . . 
• אני משווה את זה פשוט ל-Cookie - זה בעצם כמו להחזיר את ה-Cookie, 
• או 1st-Party-Cookie אגב - לא 3rd-Party, 
• בגלל שהם לא יכולים להגיד עכשיו, בניגוד ל-3rd-Party-Cookie, שעכשיו כמה אתרים יכולים לדעת על אותו משתמש דברים
• פה, כיוון שה-Key הוא פר-אתר, אז Ynet לא יכולים להגיד לאתרים אחרים “הוא היה בכתבה הזאת” - כי האתרים האחרים, אין להם גישה ל-Public Key שלו . . . .
• אבל זה כן כמו 1st-Party-Cookie - זאת אומרת ש-Ynet יוכלו לדעת שזה אתה
• ם חזרת אחרי חצי שנה לאתר - הם יידעו שזה אותו בנאדם
• הם לא יידעו את השם אם הם לא ביקשו את השם
• וזה כמו Cookie שהוא נשאר לנצח . . . 

(אורי)  זה שווה שווה (==) ל-Email Address . . . .

• (רולי) לא, רק שזה לא Identifiable Information - זאת אומרת, הם לא יכולים . . . .

(אורי) זה כן - זה המכשיר בסוף . . . .

• (רולי) נכון, אבל אפשר . . . .

(אורי) סליחה - זה אתה, על המכשיר . . . 

• (רולי) נכון, אבל הם לא יכולים . . . . הם רק יכולים לתת לך חוויה קונסיסטנטית (Consistent), הם לא יכולים לעשות מעבר לזה שום דבר . . . .
• ורק להוסיף עוד דבר אחד, שזה . . . . 
• אבל אני חצי-מסכים איתך - אמרתי בהתחלה, שזה עם Consent
• זאת אומרת, אם Cookie, איך שאני רואה את זה, זה בעצם, ב-Scenario שאתה מתאר, זה מחליף את ה-1st-Party-Cookie -  עם Consent.
• זאת אומרת, זה לא יעבוד . . . . הרי ה-Face ID לא יעבוד אם אני לא יעשה Face ID  . . . .
• הוא גם שואל אותך - הוא עושה Prompt, אתה יכול לעשות Face ID - כן?
• זאת אומרת שיש פה איזשהו Consent.
• אני מסכים איתך שהרבה מהאנשים פשוט עושים מה שאומרים להם - אז זה לא רלוונטי אם יש Consent או אין . . . 
• אבל ב-Cookie לא היה Consent - וזה עשה בדיוק אותו דבר
• הם היו שמים עליך Cookie - ועכשיו כל החיים יודעים שאתה זה אתה.
• וזה האלטרנטיבה, זה “החדש”.

(אורי) עד כדי ''חיים של Cookie'', שזה . . . להבדיל מזה, זה חיים . . . 

• (רולי) נכון, זה חיים . . . כן, זה על ה-Device ו-”Forever''.

(רן) דרך אגב, מה קורה אתה מאבד את  ה-Device? כאילו, עשית Log-In לאיזה חמישה אתרים ואיבדת אותו?

• (רולי) אז אתה עושה Log-In עוד פעם . . . . תצטרך, ב-Device החדש.
• אז אנחנו חוזרים לפתרון, לדעתי השבור, שקיים בשוק, וזה . . .  שהוא לא שלנו . . . 
• כי שם באמת אתה צריך עכשיו עם סיסמה או . . .  אתה צריך איכשהו לפתור את זה.
• ועם שלנו אנחנו פשוט ישר בודקים - אנחנו אפילו לא כותבים לך “Error'', אנחנו אומרים לך “אני מזהה שזה מכשיר חדש, אני שולח לך קוד, תכניס אותו” . . . . מהמכשיר.

(רן) אה, יש לך את ה-email, אז ככה אתה שולח . . . .

• (רולי) כן.

(רן) אוקיי, אז ה-Hook שלך זה ה-email, זאת אומרת . . . .

• (רולי) כן, כן, עדיין.

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

• (רולי) לא הייתי אומר “איזורים שהם לא נכונים” . . . . אני כן הייתי אומר שאתה צריך לחשוב על Use Cases, מי . . .
• אז ככה - מסתבר שיש אנשים שמפחדים לעשות, שהם לא עושים Enabling ל-Biometrics על ה-Device שלהם
• כי הם חוששים שה-Data יעבור לאתרים, או לאפליקציות, או ל-Apple או למי שזה לא יהיה.
• והם פשוט לא מוכנים לעשות שום סריקה ביומטרית - אז אתה צריך אלטרנטיבה לזה.

(רן) זה חייב להיות Biometrics? זאת אומרת . . . 

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

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

• (רולי) נכון.
• (רן) אני יכול לשים את האצבע, אבל . . . .
• (רולי) בקרוב זה  . . . .  אנחנו רואים - הDevice-ים היותר מודרניים עוברים ל-Biometrics
• כי Biometrics זה באמת זה יותר קל ויותר Secured
• ואין לו בעיית Privacy, כי ה-Data - אנחנו כולנו יודעים, אנשים טכניים יודעים שה-Data הביומטרי לא עוזב את המכשירים, אצל החברות הגדולות, שאנחנו מכירים.

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

• (רולי) וואלה . . . 

(אורי) . . .   הם - נשחקות להם הטביעות-אצבע . . .(רן) מה לגבי הרגליים?

• (רולי) . . . מעניין לנסות פעם לעשות סריקה עם הרגל . . . 

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

• (רולי) נכון - אבל היא מוצפנת, ו-Apple לא יגשו אליה . . . .
• זה כמו מה שיש לך ב-Google Drive - אז Google לא ניגשת לזה.

(רן) אוקיי, אז יש פה איזשהו Leap-of-Faith . . .  אבל בסדר.

• (רולי) אני חושב שהחברות האלה - יש להן כל כך הרבה מה להפסיד, שאין להן סיבה להונות את הלקוחות שלהן
• כי הן יכולות להתרסק, חברות של Trillions of Dollars . . . 

(רן) כן, אבל טעויות יכולות לקרות . . . . אני לא חושב שיש להן סיבה, אבל טעויות יכולות לקרות, נכון?

• (רולי) נכון.

(רן) כמו . . . עיין-ערך “המאגר הביומטרי” בישראל [הי ברזיק . . . ] - אני לא אומר שזה לא משנה שאין סיבה לבוא ולהדליף אותו, אבל טעויות יכולות לקרות.

• (רולי) לא רק זה - זה גם גורם-סיכון, זו נקודת-תורפה.

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

• (רולי) לשעבר . . . .

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

• (רולי) לגמרי . . . 

(רן) גם עם Passkeys?

• (רולי) כן, לגמרי.

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

• (רולי) אנחנו ליד רוטשילד, ליד בית הכנסת הגדול . . . 
• בעצם, כולנו Veterans של ה . . . . אספתי איתי את השותף שלי ו”הכוכבים של Gigya”
• אז כולנו מכירים את התחום מאוד מאוד לעומק.
• ובאמת - אפילו גייסנו מאותו משקיע, העיקרי, שהשקיע ב-Gigya, אז זה היה צ'יק-צ'אק.
• וכן - אנחנו בעצם שמחים, עובדים בכמה . . . מתחילים לדבר גם בארץ עם חברות גדולות, ונשמח  . . . . 
• בעיקר חברות-הטכנולוגיה שרוצות להיכנס לזה, ורוצות פתרון הוליסטי, מודרני, לאות’נטיקציה (Authentication)
• שידברו איתי, רולי - rooly-at-ownid.com.

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

• (רולי) גדול . . . 

(אורי) האצבע של “פסוקו” . . . (רן) עכשיו צריך את המוזיקה של “פסוקו של יום” [רן אשכרה הוסיף . . . .]יאללה - יש לנו סגיר . . . תודה רבה, רולי! האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3]
פרק מספר 466 של רברס עם פלטפורמה, שהוקלט ב-22 באוגוסט (אוטוטו נגמר החופש הגדול?).אורי ורן שמחים ומתכבדים לארח באולפן את איתמר מחברת Codium כדי לדבר לדבר על AI (ועוד כל מיני Buzzwords, אבל במידה . . . ) ועל מוצר מדליק שחברת Codium מפתחת - אבל בעיקר על האתגרים הטכנולוגיים המעניינים שמאחורי הפיתוח של המוצר הזה, ועל למה זה צריך לעניין מפתחים, כי זה גם מוצר למפתחים. אז יש פה הרבה שאלות של איך לשלב Machine Learning ו-AI במוצרי תוכנה, וזה נושא שהוא די כללי ומעניין להרבה מאוד מהמאזינים.

01:38 כמה מילים על איתמר(רן) אז לפני שנצלול פנימה - כמה מילים עליך, איתמר?

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

(רן) אתה צוחק . . . 

• (איתמר) כן, אני יודע . . . 
• הייתי פעמיים CTO של VC-Backed Startups
• את החברה האחרונה שהיתה לי Alibaba קנתה, והיה לי את התענוג להתחיל את המרכז פיתוח של Alibaba בארץ [עד כאן], ביחד עם השותפים והשותפות. 
• זה היה מסע מלמד ומרתק ב-Alibaba.
• אחרי ארבע שנים עזבתי - ואחרי חצי שנה של מנוחה ו-Ideation, ביולי 22 פתחתי את Codium.ai, ביחד עם השותף שלי, דדי קרדו, שהיה עובד הראשון שלי, אי-פעם לפני 25 שנה . . .
• וזהו - מאז עברה שנה, אנחנו 20 . . . 
• זה קצת על עצמי - יש לי M.Sc. ו-B.Sc. מהטכניון, בתחום של Machine Learning
• והעבודה הראשונה שלי אי פעם היתה מפתח Web בשנות ה-90'.

(רן) ASP?

• (איתמר) זה היה PHP . . . 

(אורי) משהו עם “P” . . .(רן) כן, משהו עם “P” . . . מעולה, יופי, אז אחלה רקע - ובוא רגע נדבר קצת על מה זה Codium, ואחר כך “נעלה למעלה” ונדבר קצת יותר, . . .  בצורה יותר גנרית - מה המשמעות של לפתח מוצר שמכיל AI.אני מודה שגם כשאני הייתי בלימודים בטכניון, “AI” זה היה מיני סוג של דבר כזה שאף אחד לא מעיז להתקרב אליו, כי הבינו שזה לא יעבוד . . . . אז הנה - העולם השתנה לנו.נדבר אחר כך גם על מה האתגרים ואיך אפשר בעצם לשלב AI ו-Machine Learning בצורה מוצלחת בתוך מוצרי תוכנה.
03:25 ו-Codium  . . .(רן) אז כמה היו מילים על Codium, לפני זה?

• (איתמר) אני אספר - אבל פשוט פה אני עושה לך, לא נלך על השאלה ישר . . . 
• אז הסיבה שאני, אגב, קצת היה לי קשה להגיד “AI”, זה כי הרגשתי שזו מילה “שיווקית” מדי, למה שזה - Machine Learning.
• אבל אני כן מרגיש שלאחרונה כן יש כבר את ה”ניצוצות של האינטליגנציה” ומעבר ליכולת הבסיסיות
• שכן אני מרגיש קצת יותר בסדר להגיד עם זה.
• אז קודם כל, אני אציג את זה בשתי דרכים - אחת קצת יותר “עסיסית” ואז טיפה יותר טכנית.
• אז בצורה “העסיסית”, זה בעצם “יושב לידך” בתוך ה-IDE
• “מפתחת Mid-Seniority”, שמתמחה בבדיקתיות (Testability) של קוד ובלאתגר ובלעשות Review
• ולוודא שהקוד שנכתב הוא ב-High Quality - ובדגש על ה-Functional, “שזה עומד ב-Spec”.
• אני פה עומד ליד הלוח, ורואה שכתוב פה קוד “Quick & Dirty or Detailed spec” - והמטרה של Codium.ai זה לוודא שהקוד מתאים ל-Spec, בין אם הוא Detailed או לא.
• ככה, לוודא שה-Intent - בין אם הוא רשום בצורה מפורשת ובין אם הוא נמצא כרגע בראש של המפתח או המפתחת שמשתמשת ב-Codium.ai - עומד בציפיות.
• זה ככה הדרך היותר עסיסית.
• טיפה יותר טכני - אז  it's an AI Coding-assistant, that's focused on generating tests, on verifying that high quality, etc. . . . 
• (אורי) אז זה “Pair-Programming - שחוסך כיסא”?
• (איתמר) זה Pair-Programming שעושה את העבודה הזאת, שרוב המפתחים שונאים לעשות . . . .
• בואו ניקח לדוגמא Testing, שזה אחד הדברים העיקריים שאנחנו עושים,
• אנחנו עושים, אגב, Component ו-Unit Testing, ו-Automation, Regression.
• אז או שאתה שונא לעשות את זה ולכן אתה לא עושה את זה - או שאתה עושה את זה ועדיין שונא את זה . . . 
• זה 95% . . . יש את הקיצוניים האלה, יש את ה-5% . . . 
• (רן) תמיד יש מאזין אחד שמאוד אוהב לכתוב Test-ים - אז לא מדברים עליך . . . 
• (איתמר) אז לכן הסתייגתי מיד בסוף, יש את ה-5% - והם רובם אצלנו בחברה, לקחנו אותם . . . 
• (רן) או Freelancers אצלכם . . . 
• (איתמר) אז “אנחנו באים פה להפיץ אהבה”, ולקחת - לא בדיוק “לקחת כיסאות של מפתחים”, כמו “לקחת את העבודה שמפתחים ומפתחות שונאות לעשות”, שזה הבדיקתיות של הקוד (Code Testability).
• אתה רוצה ליצור - ופחות עכשיו “להתעסק במיש-מש” של לבדוק את הקוד.

(אורי) אני לא, כאילו, התייחסתי ל . . . אתם זוכרים את Pair-Programming?

• (איתמר) כן, כן, אני רק . . . 

(אורי) . . . זה כאילו . . . “ה-”Buddy” שלך, ל-Pair-Programming” - הוא רק לא יושב על כיסא, וכשנשענים ביחד להסתכל על קטע קוד, אז לא עוברות כינים . . . .

• (איתמר) כנראה שיצאה לי ככה התשובה, כי אני רגיל שחלק מהשאלות הבאות, אז אני מתחיל לקבל את ה . . . .
• “אז רגע - אתה בא להחליף אותנו!” ו-”אתה בא לוקחת לנו את התפקיד!”
• ואני ככה ישר, כנראה . . . 

(אורי) גם Pair-Programming אנשים לא כל כך אוהבים לעשות . . . . כאילו, יש 5% שכן אוהבים לעשות . . . .

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

(רן) אולי רק נחליף את ה-5% שאוהבים, ובזה נסגור עניין . . . 

• (איתמר) כן . . .

06:32 איך זה נראה בתכל’ס(רן) אז לפני שאנחנו מנתקים לאיתמר את החשמל, כי הולך להחליף את כולנו - בוא רגע נבין קצת יותר לעומק [בשביל מה שכרנו Killswitch Engineer?].אז פה אנחנו מדברים על test-ים, נכון? זאת אומרת, זה לא Code Generation “גנרי”, כמו Copilot, שבטח נדבר עליו גם בהמשך - אלא ספציפית Testing, וגם דיברת קצת על Spec.איך עושים את זה?

• (איתמר) טסטים הוא “המנה העיקרית” - אבל כש . . . אני חושב שזו דרך מאוד טובה לבדוק קוד.
• אני לא מעט פעמים שומע מנהלי ומנהלות פיתוח, שבעצם הם היו מעדיפים טסטים ורבוזיים (Verbose Tests), מבחינת דוקומנטציה (Documentation)
• דווקא דוקומנטציה בתוך הטסטים, מאשר Documentation של קוד.
• כי זו בעצם “דוקומנטציה חיה” - זה כמו כזה “Executable Spec” כזה.
• אז באמת, Test-ים זו דרך ממש טובה לוודא נכונות של קוד
• אבל רק רציתי להדגיש שזה כן חלק ממה שאנחנו מציעים
• למשל, אנחנו כן נותנים, לדעתי - לפחות מה שחושבים המשתמשים שלנו - שזה אחד הפתרונות היותר טובים ל-Code Explanation,
• שזו עוד דרך להעלות את ה-Integrity של קוד.
•  זאת אומרת, אם יש לך Auto-Documentation - אז עכשיו אני בא להיכנס לקוד 
• של מי? שלך - או שלי, של עצמי מלפני חודש, זה אותו הדבר . . . 
• ואני עכשיו מקבל, בלחיצת כפתור, דוקומנטציה (Documentation) מאוד מאוד מאוד טובה
• היא כנראה תהיה ב-Integrity יותר גבוה משל דוקומנטציה שנכתבה בעבר, ושאולי שונתה.
• אז יש מגוון של דברים  - אבל באמת ה-Testing הוא החלק העיקרי.

(רן) אז איך זה נראה, תכל’ס? Plug-ins בתוך ה-IDE? מה רואים? מה זה Codium? מה זה המוצר?

• (איתמר) מעולה, אז בואו נגיד, “המנה העיקרית”, ה-Interface העיקרי שלנו, זה IDE Extension
• זה המונח הנפוץ ב-VSCode
• או Plugins ב-JetBrains
• שבעצם נפתח ויושב כ-Tab נוסף - בואו נגיד “כמראה” ל-Tab שבו אתה כותב או כותבת את הקוד.
• אז בזמן שהקוד נכתב, בעצם נוצרים ה-Test-ים וההסברים וה . . . .
• ואגב - העצות לגבי הקוד, זה חלק העיקרי.
• אבל, אגב, זה ה-Closed-Source - אבל יש לנו גם Open Source, שאנחנו גם עושים לו Hosting
• שבעצם זו אפליקציה שמתחברת ל-Source Code Hosting שלך
• ל-Platform - אם זה GitHub או GitLab או Bitbucket
• ויותר משמשת בשלב ה-Gateway, בשלב הכניסה - ה-Merge של הקוד שלך לתוך ה-Trunk הראשי, לתוך ה-Branch הראשי
• אז שם היא עושה את הבדיקתיות (Testability) ואת העצות.

(אורי) אז במקום Pair-Programmer  יש לך “Pair-Reviewer” . . . .

• (איתמר) נכון . . . . אני כן אגיד שאנחנו באים להקל על ה-Review, בעצם to streamline it
• מאשר, עוד פעם . . . 
•  . . . “אני רואה שאתה עוד פעם מתגונן” . . . .  
• - מאשר אשכרה להחליף את הבנאדם או את ה-Reviewer.
• כן היינו רוצים שכשה-Reviewer מגיע לבדוק את הקוד - יש לו את העבודה הכי קלה, או הכי ממוקדת
• איפה באמת כדאי למקד את ההסתכלות
•  - ולא דווקא להחליף לחלוטין.
• אז זה בא לידי ביטוי בכל מיני Feature-ים שעוזרים לזה - אני לא, תגידו לי אם Too  . . . 

(אורי) לא, אני אוהב את הכיוון . . . יש, סתם . . . . ב-Outbrain, נתקלנו בזה לאחרונה, יש שני דברים שמאוד קשה - בטח עם צוות מפתחים גדול - לדאוג להם ולדאוג שאתה מכוסה, עם קוד חדש שאתה מעלה: זה Security ו-Privacy.אז זה כאילו “פאולים כאלה”, ש”מחכים שמישהו יעשה אותם”.והמשמעויות של שני הדברים האלה הן מאוד קשות - אתה יכול לפתוח פירצה, אתה יכול לעשות עבירת Privacy, או דברים כאלה - ואחר כך לך תדע . . . .ולפעמים גם ה-Reviewer שעובר על הקוד - הוא בעצמו, הוא לא “מומחה-Privacy”, וזו באמת מומחיות, Privacy ו-Security זו מומחיות  . . . אז אחד הדברים שעשינו - ואנחנו עובדים עליהם ומשפרים אותם - זה להשתמש ב-AI כדי לעשות את ה-Review. כאילו, יש לך “מומחה Privacy” - שהוא אוטומטי, או Privacy או Security - והוא מסתכל על הקוד שלך ואומר “עשית פאול, לא עשית פאול” . . . .(רן) זה משהו שפיתחתם בפנים?(אורי) כן . . . . כאילו - פיתחנו [.Episode A.I].(רן) לא מוצר-מדף?(אורי) לא, פיתחנו - כן. אבל צריך להבין שזה כמו “Immune system” - כרגיל: אתה מתחיל עם משהו, עם איזושהי יכולת, וכשאתה נופל - אתה משפר ומשפר. בסך הכל משפר Prompt-ים . . .

• (איתמר) אז אני חושב . . . אני רושם את זה לקחת לנושא אחר . . . .
• אגב, אני חושב שאם אתם תשימו על זה את הקשב שלכם ואת המאמץ, אז כנראה שאתם יכולים לעשות את זה.
• זאת אומרת - מה קרה? למה שאנחנו, חוץ מזה שיאמנו מודלים ואנחנו מתמחים בתחום וכדומה, “באים מהליבה”
• אבל זה עדיין - כאילו, בסוף מישהו, אם תשימו על זה תשומת לב - אז אפשר.
• אני כן חושב פה, להגנתנו, שבאמת תצטרכו לשים על זה הרבה קשב.
• אני אתן סיפור אחר מעולם אחר - אני חושב שכמעט כל החברות Support-handling, כל ה-Intercom-ים למיניהם
• דבר ראשון, כשיצא כל ה-ChatGPT, אמרו “או-קיי . . . .”
• כאילו, זה “הכי טבעי” - שאנחנו נתחיל להשתמש בזה בשביל להציע Feature-ים יותר מתקדמים
• וגם כל חברה שהשתמשה ב-Intercom וכדומה, ניסתה לפתח את זה פנימית.
• ובסוף זה קשה להגיע לרמה גבוהה, ולא להגיע . . . .
• ואגב אני אשמח לשמוע ממך [אורי], אולי - בסוף, על ה-Challenges שלך, בעיות של להטמיע מוצר AI
• חוסר קונסיסטנטיות (Consistency) ו-Hallucinations וכל הדברים האלה, שאולי תרצו שאני אעשה Double-Click עליהם . . . .
• גורם לזה שממש צריך להתמחות בתחום.
• וזה אחד הדברים שאנחנו ביום יום מאותגרים.
• אני אתן דוגמה, למשל - אפילו מישהו שבא לייצר איתנו Demo, מישהו שרוצה להדגים בתוך החברה
• כשאנחנו שומעים על מישהו שרוצה להדגים בתוך החברה את המוצר שלנו
• אז הוא בא והתאמן על זה קצת לפני שהוא מציג את זה ל-CTO, למה הוא צריך להכניס Codium.ai
• ואז הוא בא להציג את זה - וזה יוצא לו קצת אחרת . . . .
• טיפה - מספיק “הטיפה הזו”, וזה מבלבל.
• אז אנחנו מנסים להציג קונסיסטנטיות (Consistency) - אפילו לא רק קונסיסטנטיות בשביל האיכות של המוצר, אפילו קונסיסטנטיות כי אנחנו כבני אדם עדיין לא רגילים . . . 
• אוקיי, כשאני מדבר עם Chat אז אולי זה בסדר חוסר-קונסיסטנטיות (inconsistency)
• אבל בשביל בדיקת בדיקתיות-מוצר (Product Testability), אתה צריך טיפה יותר יציבות . . . 

(רן) כשזה Midjourney, לא אכפת לקבל בכל פעם תמונה אחרת . . . 

• (איתמר) נכון . . . 

(רן) . . . . אבל כשאתה מג’נרט טסטים (Tests Generation), אתה מצפה לקבל תוצאה ש . . . .(אורי) להיפך - כל הרעיון של טסטים זה קונסיסטנטיות (Testing Consistency) . . . . זה . . . 

• (איתמר) נכון - ולכן יש פה קושי וצריך להעמיק פה
• עכשיו, אם אני יכול “להקליק” על מה שאמרת - אז אצלנו למשל זה נקרא -  ה-Open-Source - נקרא PR Agent
• אפשר לדבר למה קראנו לו Agent . . . ו-It’s Tricky,
• “מונח טעון” עכשיו - Buzzword . . . הנה, זרקתי את הראשון שלי עכשיו . . . .
• אני לא זוכר אם זה הראשון או לא . . . .
• (רן) אמרת “AI” . . . .
• (איתמר) נכון, אז זה השני . . . .
• אז אחד מה-Feature-ים שם זה באמת לנסות לזהות בעיית Security.
• עכשיו אנחנו לא ממש ממתגים את עצמנו כ”חברת Security” וגם לא מתחייבים כרגע
• בגלל שבאמת - צריך לעשות את זה בצורה מאוד מאוד קפדנית, כדי לטעון שה-PR Agent באמת ימנע ב-99.999 מבעיית Security לעבור
• אז אנחנו כרגע לא . . . .
• ה-Messaging שלנו לא מתמקד על העניין של Security - אבל זה קיים שם.
• ואגב, אפרופו ה-Privacy - אחד הדברים שזה תפס, אולי זה הכי טריוויאלי שיש, אבל אם מישהו שבטעות דחף Key, אז זה יתפוס את זה . . . .
• כאילו, המוצר שלנו יתפוס מישהו שדחף Key עכשיו באחד המקומות, וכל מיני דברים כאלה.
• שוב, אנחנו לא כרגע משווקים את זה כמוצר שהוא “ב-99.999 פותר Privacy”.

14:33 אתגרים באינטגרציה של טכנולוגיות AI ו-Machine Learning בתוך מוצרי תוכנה(רן) כן, בואו נעלה “כמה רגליים למעלה” - היום בבוקר . . . בואו אספר לכם על שיחה שהייתה לי היום בבוקר: דיברתי עם חבר שלי, אילן - היי אילן! - והוא אמר לי משהו כזה: “תשמע, עם כל הטכנולוגיה שקורית היום, כל ה-GPT וכו’, נורא קל לבנות כל מיני מוצרים, ש . . . לא יודע, שעושים חיפוש וקטורי (Vector Search), שמאנדקסים דאטה (Data Indexing), בצורה שלפני זה לא היית יכול לאנדקס וכו’, ויאללה - בואו נבנה משהו כזה! בואו נעשה סטארטאפ!”ואני בטוח שכל אחד מהמאזינים של הפודקאסט שומע שלוש שיחות כאלה ביום, לפחות . . . .ומה שרציתי לשאול אותך, איתמר, בתור מישהו שנמצא בתחום של Machine Learning - והיום אתה גם יכול לקרוא לזה “AI”, כבר הרבה מאוד זמן, זה לא רק על ההזדמנויות הגדולות שיש היום - אלא גם מה האתגרים? אילו אתגרים שאתה נתקלת בהם, בדרך לעשות אינטגרציה לטכנולוגיות AI, לטכנולוגיות Machine Learning, בתוך מוצרי תוכנה.אפשר לדבר ספציפית על מה האתגרים ב-Codium, או דברים שעשית לפני זה . . . 

• (איתמר) מעולה, אז קודם כל - אני מתרכז באתגרים הטכניים, בסדר?
• כי יש אתגרים היום ב-Business, וגם במובן מסוים מוצריים . . . .
• אני אתן דוגמה למוצרי - אפילו אנשי-Product צריכים קצת להתרגל . . . .
• כאילו, זה לא שאין מוצרי Machine Learning כבר מאלפיים-ו . . . לא יודע, 2010, כבר כשהם נכנסו
• אבל בכל זאת - זה יותר ויותר הממשק, ה-Interface ללקוח, הוא נהיה לא-דטרמיניסטי
• וזה ממש דורש, כאילו, שיטות שונות על הצד של ה-Product.
• אני דווקא רוצה להתמקד בטכני - וגם שם, באמת שיש המון
• ואני רוצה להתמקד גם שם - על דברים קצת אולי . . . . “מגניבים / מעצבנים” . . . .
• אז הנה דוגמא ראשונה - נאמר ואתה עכשיו רוצה . . . מחליט שאתה רוצה להשתמש במודל - Large Language Model, כדוגמא למודל - של אחד הספקיות הגדולות, למשל OpenAI.
• ונוצר מצב, שהמודלים האלה מתעדכנים - ויותר מזה, הם גם “כביכול מתעדכנים”, בלי שהם באמת מתעדכנים . . . .
• יש הרבה שיח, נאמר ב-[רשת-שהייתה-ידועה-בשם-]Twitter, בחודש-חודשיים האחרונים, ש-GPT-4 נהיה טיפש יותר  . . . .
• ויש די הרבה Evidence, על הנקודות של אנשים שחקרו לפני ואחרי . . . .
• ואגב, ה-VP Product ו-Partnership של OpenAI כתב בפומבי ב-Twitter שהוא לא מבין למה אנשים אומרים את זה, שום דבר לא השתנה . . . .
• אני פה רגע שנייה אחת אשוויץ - ואגיד שהוא גם משקיע אצלנו . . . 
• והשאלה - מאיפה הקונפליקט? יש עדויות אל מול מישהו שאומר ששום דבר לא השתנה . . . 
• אז זה אתגר מאוד גדול.

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

• (איתמר) נכון. עכשיו אני, לשמחתי - ואתה יודע, זה כמו כזה, כשאתה אומר שאתה עובד במסעדה, ואתה יודע מאחורה מה קורה, “במאחורי-הקלעים” [איך מכינים את הנקנקיות . . . ] .  . .
• (רן) לא תרצה לאכול שם יותר. . . .
• (איתמר) אז אני, ב-Alibaba Cloud - אחד הדברים שפיתחנו זה מוצר AutoML 
• [גם כאן - 401 AutoML at outbrain with Assaf Klein]
• ולפעמים היינו לוקחים מודל, שיש לו Benchmark, שכן קיים לו Benchmark . . . 
• אבל אגב - זה מאוד קשה, ואני חושב שזה רק נהיה יותר ויותר קשה.
• זאת אומרת, ככל שאתה לוקח מודל, שמטרה שלו היא לעשות קלסיפיקציה (Classification), אז אתה כן יכול להצליח
• וגם שם יש קושי, אגב - כי מה ה-Benchmark שלך? אם הוא זהה, אם יש איזה קורלציה (Correlation) או מתאם חזק  ל-Benchmark של הלקוח
• אבל לפחות יש איזשהו Benchmark . . . .
• ואפילו זה נהיה יותר קשה - כי אתה לא עובר קלסיפיקציה (Classification), הGenerative AI כאילו מייצר תוכן . . . .
• אז יש איזשהו Benchmark - ועכשיו אנחנו רוצים לעדכן מודל
• ונאמר שיש מספר אחד - נקרא לו כרגע “Accuracy“ - והוא עולה מ-81 ל-82  . . . .
• אז הוא עולה מ-81 ל-82 - עבור ה-Benchmark שלנו . . . 
• ואולי עבור אחרים הוא יורד . . . .
• אגב, אולי יש את אותו Sample - יש שבעה Sample-ים, שעכשיו הפכו מ-Negative, כאילו משהו שה-Accuracy לא טוב, ל-Accuracy טוב - אבל יש שניים אחרים שנפגעו
• ובסך הכל - השתפר.
•  אז נוצר מצב, שאתה עכשיו משתמש במודל הזה שלנו, של Alibaba Cloud - ואנחנו סיפרנו לך את ה-Benchmark שהשתמשנו בהם
• והשתנתה תכונה מסוימת - אולי לטובה, אולי לרעה . . . .
• וזה קושי מאוד מאוד גדול - הולך וגדל - בגלל התכונות של המודלים האלה.
• אז זה, למשל, אתגר אחד, כדוגמא.

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

• (איתמר) אגב, אני רוצה לספר, ותגידו לי אם זו אולי יותר מדי חפירה בנקודה הזאת - זו לא בעיה חדשה, כביכול . . . .
• יש מאמר, דווקא מאיזו אוניברסיטה באוסטרליה [!Oi Oi Oi] - אני אומר כי זה דווקא כזה די נדיר בתחום שלנו, למי שמכיר
• שהם עקבו - אני לא יודע אם במכוון - אבל הם עקבו במשך שנה אחרי API-ים של Machine Learning Pre-BC, בפורצ'ארט-GPT [?]
• הם עקבו אחרי מודלים של Azure, של AWS ו-GCP - ועם אותו Sample לאורך זמן - והראו איך ה-Predictions משתנים . . . .
• עכשיו, אנחנו מדברים על מודלים עוד יותר  . . .  שיש להם Temperatures 
• כאילו, שאפילו במרחק של שנייה אתה יכול לקבל מודל אחר
• אז איך בכלל תמדוד, כשדברים משתנים לך מתחת לידיים?
• זה משהו שאתה חווה . . . .
• אני רק כן, כאילו, אולי לפני שנעבור, אתן עצה, כאילו מיטיגציה (Mitigation)
• אז כאילו, ההצעה הטריוויאלית זה קודם כל למצוא דרך למדוד את זה . . . .
• אבל דווקא אני רוצה לתת עצה שהיא קצת יותר כאילו, לא רק ב-Monitoring של זה, אלא זה איך להתמודד עם השינויים האלה
• אז בגדול, המודלים האלה - ככל שאתה שואל אותם שאלות יותר ספציפיות, ככל שהשאלות יותר ממוקדות, אז ככה גם אם עוברים שינויים, בדרך כלל השינויים בתשובה הם ב-Variance קטן
• אגב, גם דיברנו על זה, שגם באותו רגע, בלי שהשתנה המודל, יכולת לקבל תשובה אחרת, בגלל ה-Temperatures
• אז לשאול שאלות יותר מוקדות.
• אז למשל, אחד השונ-אים (Differences . . . .) - אתה צריך את המילה הזאת, היא קשה לי - בין Code Generator ל-Code Integrity
• אנחנו ב-Codium.ai בונים את ה-Code Integrity Solution, ולא Code Generation, שנותן לך פתרון כלשהו
• אנחנו Code Integrity
• אז להבדיל מ-Code Generation, כשאתה כאילו נותן לו איזשהו Prompt, והוא מוציא לך, פשוט קורא ל-LLM ומוציא תשובה כלשהי
• אנחנו, עבור בדיקה של איזשהו חתיכת-קוד, עושים בין 10 ל-12 קריאות למודל.
• וכל שאלה היא מאוד מאוד מפוקסת (Focused)
• עד כדי כך, שאנחנו אפילו יכולים לקרוא למודלים שונים - ועדיין לקבל תשובות די דומות, בגלל שהשאלה היא מאוד ממוקדת.
• (רן) סוג של גידור . . . 
• (איתמר) כן, בדיוק.

21:25 זמן וכסף(אורי) אז 12 קריאות למודל . . . 

• (איתמר) כן - כסף . . . .

(אורי) מה? לא, דווקא לא כסף - Latency  . . . (רן) ואתם משתמשים במודלים Online?  זאת אומרת, אתם מביאים מתוך . . . 

• (איתמר) כן, אז אנחנו משתמשים במגוון של מודלים
• ואולי, ככה, זה ישמע קצת אולי סותר את מה שאמרתי עכשיו, אם תבחינו בסתירה שעכשיו אני הולך להציג על העיצה שהרגע נתתי - אנחנו משתמשים במגוון של מודלים.
• בגלל ה-Properties - יש Properties למודלים האלה
• וכן - מודלים שיש להם יש להם חוזקות ב-Properties אחרים
• וזה לא ש-GPT-4, אגב, הוא הכי טוב על כל ה-Properties האלה
• אני אתן לכם, למשל, דוגמא אולי ל-Property שיפתיע אתכם, לפחות
• לאחרונה, אגב, שמעתי פחות אנשים מופתעים - כנראה זה התחיל להיות יותר מקובל, אבל אני כן מכיר שזה מפתיע
• שבעצם, GPT-3.5, בהרבה מאוד משימות תכנות, יותר טוב מ-GPT-4
• כאילו 3.5 יותר טוב מ-GPT-4 - במשימות תכנות.
• ואגב, זה מאוד תלוי איך אתה שואל את השאלה
• האם אתה שואל שאלה של תכנות שהיא על Reasoning, כשבזה נגיד GPT-4 ממש טוב
• או שיש לך שאלה מאוד ממוקדת - ועכשיו אתה מבקש את הקוד עבור הבעיה המאוד ממוקדת
• ושבזה אולי 3.5 יהיה יותר טוב
• אז אנחנו בעצם משתמשים במגוון מאוד רחב של מודלים, ועכשיו רק . . . 
• לכל אחד ה-Properties שלו
• ואגב - יש Properties של Obedience - כמה אתה “מסוגל להקשיב להוראות”, ולבצע אותן בדיוק, As-is
• זה לאו-דווקא להבין אותן - אלא לא רק להבין, אלא גם בביצוע של זה.
• אז זה חשוב, כי אנחנו בכל Integrity, אנחנו לא מנסים להביא לך איזה Boilerplate של קוד
• אם ביקשת משהו - יש לך או אפשרות - ככה או ככה, ואתה תתקן לבד.
• אני רוצה לתת לך את הביטחון, שה-Test-ים שנתנו לך באמת בודקים את מה שהקוד שלך אמור לעשות 
• אז חשוב לנו ה-Quality.
• לגבי ה-User Experience - זו באמת נקודה, הייתי רוצה להגיד “הייתה”, כי אני מרגיש שאנחנו לא שמענו הערות כבר כמה . . .  חודשיים-שלושה, על Latency, אז זה קצת בעבר.
• אבל כן, זו הייתה נקודה בעייתית.
• ובעצם, אנחנו עושים Applying לשיטה שנקראת Chain of Thought - זה לא Buzzword! אל תספור לי את זה . . . 
• זו שיטה אמיתית, שבה אתה משרשר . . . אגב, זו אחת הסיבות שקוראים לדעתי ל-LangChain - ה-Framework המפורסם של התחום - “Chaining”, 
• כאילו - זה משרשר סדרה של תשובות של LLM אחת אחרי השנייה.
• ובעצם, אנחנו משתמשים בתשובות הביניים כדי להתחיל “להתניע” - להחזיר ערכים למפתח או למפתחת
• [זה מזכיר במידה מסויימת מנגנון של Out-of-Order Execution במעבדים . . . .]
• עכשיו, אני אתן את הדוגמה הכי כאילו-בנאלית - שהיא לא מה שאנחנו עושים:
• גם ChatGPT, אם תחכה לסוף התשובה ואז תפלוט את זה - גם יהיה לך משעמם . . . .
• זו אחת הסיבות שהם גם רוצים לתת לך, לדעתי, “Intelligence” - או “הרגשה של Intelligence” וש”משהו נבנה”
• אבל גם כדי שתוכל להתחיל לקרוא . . .
• אז תחשוב על אותו דבר אצלנו - רק ברמה של “תהליך חשיבתי”
• זאת אומרת, שכשאני מייצר לך Test-ים
• דבר ראשון, אני עושה אנליזה ל-Behavior של הקוד
• אוקיי, יש שלב של אנליזה
• זה כמו שפת BDD כזאת - Behavior-Driven Development
• יש כאילו . . . . אני נותן לך את התוצר-ביניים - אני אומר לך “הנה כל ה-Behavior של הקוד”
• ועכשיו, אני מתחיל לייצר Test-ים עבור Behavior שאני . . . .
• אז לא הכל - אבל את לא מעט מתוצרי-הביניים אנחנו פולטים החוצה, ונותנים למשתמש להבין איך זה פועל
• אבל גם לשנות - זאת אומרת למשל, אם יש Behavior מסוים שנראה שלא כוסה, אז אנחנו נותנים להשלים במהלך התהליך, וכו’.

21:14 הזיות ושיפור מתמיד(רן) כן, אז דיברנו על אתגר אחד, שזה כשה-API משתנה לך או שהתוצאות יכולות להשנות לך, ככה, “מתחת לרגליים”, וטכניקה אחת שהזכרת זה . . . אני קראתי לזה “גידור”, אתה קראת לזה “תיהיה ספציפי” - תעשה הרבה קריאות ויותר “תהנדס את זה”, אל תיתן, כאילו . . . גם אם זה עבד לך פעם אחת “בפוקס” ב-Prompt, אל תסמוך על זה - תייצר הרבה Prompt-ים שונים, ,שתמש במספר מודלים, ולפעמים צריך לעשות להם Chaining וכו'. אבל זה רק אתגר אחד . . . עכשיו, אנחנו בטח לא נספיק להגיע להכל, אבל בוא נבחר עוד איזה ככה, אחד-שניים.מה האתגר הבא שאתה מכיר, מהניסיון שלך, כשרוצים לעשות אינטגרציה לטכנולוגיות-AI בתוך מוצרי-תוכנה?

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

(רן) הזיות . . . .

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

(רן) המאמר המפורסם של Facebook [Meta!] על למה נכון לאכול זכוכית, למשל, וכו’ . . . למי שלא מכיר את הרפרנס - אז Facebook הוציאו כלי שכותב מאמרים מדעיים, ובתור ניסיון אמרו לו להסביר למה זה נכון לאכול זכוכית -והוא כתב מאמר-מדעי מדהים, על למה זה נכון לאכול זכוכית . . . . כמובן שהכל בולשיט והכל אשליות - “הזיות”, סליחה! - אז כן, זו מחלה שקיימת. [והמסקנה המתבקשת - Meta takes new AI system offline because Twitter users are mean]

• (איתמר) מה שרציתי לשים עליו דגש - כי זה כן, כאילו, חשוב לשים לדגש - זה הזיות שיכולות לפגוע.
• עכשיו, “לפגוע” - יש כל מיני, ולכל מוצר הפגיעה יכולה להיות שונה.
• אבל כן - אני רק, בגלל שאין מה לעשות, הדלקת לי את הצורך רגע, לפטפט על . . . קצת לנסות להבין את ה-Hallucinations, ואיך יכול להיות ש . . . 
• היה שם . . . “הוא” המציא מאמר או הסבר ללמה זה הגיוני לאכול זכוכית וכדומה . . . 
• אז אני חושב שחשוב להבין, שבסופו של דבר, השאלה - ה-Prompt - יש בתוכה המון Knowledge
• כאילו - Information, knowledge ואפילו Intelligence.
• בעצם, אני טוען . . . . רגע, אני אקח אפילו צעד אחורה - אני טוען, שחלק מההתלהבות שלנו מ-ChatGPT
• נכון? - הרגע הזה, כשהסתכלנו על “החייזר הזה” ואמרנו “איך הוא כל כך intelligent?!”
• אז אני חושב שלא שמנו לב, שבעצם אנחנו . . . .
• לא כולנו ישבנו וחשבנו על פילוסופיה, שבעצם - בשאלה יש את רוב האינטליגנציה. אני לא צוחק . . .
• [כן, טוב - Saint Douglas אמר את זה קודם . . . התשובה, אגב, היא 42]
• זאת אומרת, לא סתם, אני  . . . 

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

• עזוב, בוא נלך לאלברט איינשטיין [יאללה] . . . 
• אני ארשה לעצמי רגע, אם היתה לי שעה, כאילו, אם היתה לי שעה לפתור בעיה, אז קודם כל, אני יושב 55 דקות להבין טוב מאוד את הבעיה [if he only had one hour to solve a problem he would spend 55 minutes defining the problem and the remaining 5 minutes solving it routinely].
• זאת אומרת, הרבה דברים  . . .  כאילו, אם עכשיו תשאל “תסביר לי מה ההבדל בין צפרדע לאבן”, אז זה ייתן איזשהו הסבר. זה כאילו . . . 
• אבל אם עכשיו אתה תבוא ותגיד לו עכשיו . . . בוא נלך על משהו טיפה יותר אינטליגנטי, לא לאכול זכוכית, או לא בין צפרדע לאבן . . . 
• אתה רוצה לדבר עם ה-ChatGPT על דברים מהותיים, כמו מה ההבדל בין אינטליגנציה ו-knowledge. אוקיי? 
• עכשיו, אם אתה יודע לשאול את השאלה, כאילו,”בצורה טובה” - אתה תקבל תשובות “סופר-אינטליגנטיות”
• אבל אם אתה תשאל שאלה טיפשית - אתה תקבל תשובות טיפשיות . . . .
• בעצם איך ש-LLM עובד, זה בהינתן השאלה, אוקיי? בהינתן ה-Prompt - זו לא חייבת שאלה, זה יכול להיות  . . . .
• בהינתן ה-Prompt - מה התשובה “שהכי Likely לענות על זה?” . . . 
• זה בעצם איך שהמודלים האלה עונים. 
• אז יש המון Knowledge ב . . . סליחה, המון אינטליגנציה, ואפילו הרבה ממנה, לא רק ה-Knowledge.
• האינטליגנציה היא בשאלה. תשאל שאלות מפגרות - תקבל תשובות מפגרות.

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

• (איתמר) אחת הסברות היא ש . . . . השאלה מי - האם זה ChatGPT או לא?
• אבל אחת הסברות שאומרים ש-GPT נהיה Dumber, כאילו, סליחה, נהיה יותר טיפש, זה בגלל שאומרים שהוא אומן על ה-Data עכשיו שהגיע מכל האנשים שהשתמשו . . .
• (רן) . . . וכולנו נהינו יותר טיפשים . . . .
• (איתמר) . . . . וכולנו לאט לאט מתכנסים . . . . הרי, אם בסוף אתה נותן ל-Machine Learning ללמוד Data של עצמו, אז ככה אחת אפשרויות שזה Model Collapse, כאילו, לכלום . . . .
• [הרחבה מומלצת באחלה פרק של עושים טכנולוגיה - הבינה המלאכותית ממלאת את העולם בזבל]
• אבל רגע אחד - אני רוצה להסב את השאלה שלך, וזה גם יעזור לי לסיים את הפואנטה הקודמת: אתה שואל שאלה . . . אתה שואל שאלה, ואתה אומר לו “אתה בטוח שאתה צודק?” . . . .
• ואיזה קטע! הוא פתאום מתקן . . . .
• אוקיי . . .  ואתה אומר “איזה יופי! איך הוא חכם!” . . . .
• אבל . . .  או “זה”, או “היא” . . .
• אבל מה הקטע? שבעצם העובדה שאתה ערערת - אתה נתת אינפורמציה נוספת . . . .
• אתה שאלת - “האם אתה בטוח שאתה צודק?”
• כאילו, וזה בעצם כל מה ששאלת זה - יש בזה עוד אינפורמציה . . . 
• זה כמו שאני חושף לך עוד קלף בפוקר, או . . . . וכדומה. 
• (אורי) עירערת לו את הביטחון עצמי . . . .
• (איתמר) נכון, אבל בעצם נתת אינפורמציה - חשפת אינפורמציה נוספת . . . 

(רן) יש את החידה המפורסמת בהסתברות - של שלושה וילונות, אתה בוחר אחד, ואז אומרים לך . . . חושפים אחד -האם תחליף? [אמ;לק - כן: Monty Hall problem]. אז גם פה, נתת עוד אינפורמציה, שאלת אותו “?Are you sure“, ואז פתאום “הוא” אומר “רגע, אולי אני בעצם לא כל כך בטוח . . . .”

• (איתמר) כן. חידה מדהימה - Monty Python, אם אני לא . . . .? [לא, עד כמה ש”Monty Python” יכולה להיות תשובה לא נכונה, שזה לא הרבה]

(רן) כן. משהו עם . . .  Monty Hall, נראה לי . . . .

• (איתמר) כן, כן, אני צוחק - זו חידה סופר-קריטית, סופר חשובה לנקודה הזאת. היא באמת, כאילו . . . 
• אתה - יש שלושה וילונות, ובאחד יש מכונית [!], ובשניים דחליל ועז [!!]
• אתה בוחר אחד - ואז חושפים לך או את העז או את הדחליל
•  ואומרים לך “אתה רוצה להחליף?” . . . .
• אם אתה מחליף, אז אתה עובר מ-33% ל-50% - זה שווה ממש לחשוב על זה, אם אתם לא מכירים את החידה . . . .
• (רן) טיפ שלנו - תחליפו . . . [אמ;לק - נוסף כאן עוד מידע שלא היה קודם, כי מי שחשף את העז ידע שהיא שם…]
• (איתמר) כן, ממש שווה . . . אם לא חשבתם, זה ממש . . .
• אז זה אותו דבר. ועכשיו, מה מעניין? נגיד שהוא, נגיד שהוא  . . .  נגיד שה-ChatGPT כן צדק, ועוד פעם תגיד לו “אתה בטוח שצדקת?” - יכול להיות שהוא יחליף את זה . . . 
• זאת אומרת, האינטליגנציה של “לדעת לשאול את השאלה”, אם עוד פעם . . . אתה כבר ידעת לקבל את התשובה השנייה ולהגיד “זה נכון”, ולא המשכת לשאול.
• אבל אם לא היה לך את האינטליגנציה, והיית שואל עוד פעם “אתה בטוח שצדקת?”,  יש סיכוי ש”הוא” היה אומר “אופס! סליחה, טעיתי!” - והיה ממשיך לתת לך תשובות לא נכונות . . . .
• אז . . .  ב-Bottom-line, רציתי להגיד - אם אני מקפל רגע הרבה חלונות, הרבה Brackets . . . 
• יצאנו מכל הסיפור הזה, ההבעיה של Hallucinations

(אורי) . . . אתה עולה ב-Stack . . . .(רן)  . . .  אנחנו כבר לא ב-Lisp anymore . . . .

• (איתמר) אז אני חוזר למקור, אני מקפל הרבה כדי שנחזור חזרה . . . . אז זו היתה השאלה של, אוקיי, Hallucinations . . . .
• אבל Hallucinations שיכולים להזיק
• לפעמים אולי קוראים לזה  . . . אפשר לקרוא לזה “Mission-Critical Hallucinations”
• אפשר למצוא לזה כל מיני שמות מהעולמות הישנים . . . 
• ופה, אני חושב שמאוד כן חשוב לשים Guardrails על Hallucinations מסוימים.
• למשל, בואו ניקח את העולמות שלנו - מה קורה אם עכשיו אני מייצר Test, שיכול לייצר נזק
• או שטסט ש . . . בואו ניקח פחות, Test ש . . . 
• (רן) . . . .שכורה Bitcoin . . . 
• (איתמר) . . . . כן, כן . . . או Test . . .
• ניקח שלב אחד אחורה - Test שפשוט גורם לכל ה-Test-ים שלי לא לרוץ, ואז המוצר שלי יהיה פחות איכותי.
• זאת אומרת, אחד ה-Feature-ים אצלנו במוצר - זה אחד ה-Feature-ים האהובים גם עלינו, גם על ה-User-ים - זה שאחרי שה-Test-ים נוצרים, אתה בתוך המוצר שלנו יכול להריץ אותם
• חלקם עוברים, חלקם נכשלים
• אגב - בכוונה, ואני יכול להסביר למה . . . 
• מתבצעת אנליזה אוטומטית, Agent-wise - כאילו זה Chain-of-Thought כזה - על הכישלון של ה-Test
• ואז, על בסיס הכישלון - מתקנים את ה-Test, או מתקנים את הקוד, אוקיי? . . . 
• אפשר לצלול על זה ל-Double-click אם אתם תגידו לי
• וכל הרעיון הזה הוא שאם היה Test אחד “סורר”, יכול להיות שהוא יהרוס את הכל
• בוא נגיד ה-Feature הזה, שכבר לא יהיה לו UI או UX - אז זה סופר קריטי.
• ואז יש גם את הדברים היותר חמורים - אז זה פה אני מוציא . . . . לדוגמא, אם תסתכלו על Wordtune, אז אתה לא רוצה שזה יקלל אותך, נכון?
• של AI21, או משהו כזה
• צריך ואפשר לשים כל מיני Guardrails
• זה סופר-קריטי, כאילו, להילחם ב-Hallucinations [ד”ש לדון קישוט?] והדרכים האלה.

(רן) כן, ופה אנחנו קצת היינו על הגבול שבין Hallucinations ל-Safety - וגם Safety זה סיפור גדול בכל הסיפור הזה, אגב ללעוס זכוכית . . . אז כן - אבל הדברים פה הם . . . . כן, לגמרי נמצאים שם על הגבול . . . 
33:53 מה ההבדל?(רן) אבל אנחנו, ככה, מתקרבים לקראת יותר הסוף - ורציתי שוב להנחית את החללית [איזה תותחים ההודים!] . . . .אז היינו ככה ב-30 אלף רגל, אוקיי, לא חייבים ל . . .(אורי) . . . רציתי לשאול אותך האם אתה בטוח? . . . .(רן) אוקיי . . .  עכשיו כבר לא . . . Not anymore . . . אבל כן, זאת אומרת, רציתי רגע לחזור לדבר על המוצר - עכשיו אני מפתח, ואני שואל את עצמי האם אני רוצה להתקין את ה-Extension הזה או לא. ויכול להיות שאני מכיר כלים אחרים בעולם של Code Generation . . . והשאלה שאני שואל זה - מה ההבדל? אוקיי? . . . זאת אומרת, האם לא ניתן לייצר Test-ים באמצעות Copilot, או כלים אחרים ל-Code Generation? בעצם, איזו ייחודיות יש ל-Codium על פני הכלים האחרים, שהם יותר גנריים - שאולי לא ספציפית מייצרים Test-ים, אבל כן מייצרים קוד? זאת אומרת, אתה תמיד יכול לעבור ולכתוב Test- ואז לתת לו “להשלים את החסר” . . . אז איך Codium עובד שונה מהכלים האלה?

• (איתמר) מעולה - אז הייתי רוצה לחלק את התשובה לשתיים:
• בחלק השני, אני רוצה להשוות בין מוצר של AlphaCode של של DeepMind, אם אתם מכירים
• אחד מארגוני ה-AI הכי חזקים בעולם
• שעל Context שנקרא CodeForces, אם אתם מכירים - הוא מגיע ל-45 Percentile
• זה נחשב “Mid-seniority”
• לעומת GPT-4, שמגיע ל-5th percentile from the bottom . . . 
• שזה נחשב “Newbie”
• וההבדל ביניהם זה שב-AlphaCode -  יש להם רכיב, יש להם Agent ספציפי, שמתמקד ב-Code Integrity, ב-Testing, אוקיי?
• והוא שונה מהרכיב של ה-Code Generation
• זה החלק השני של התשובה . . . .

(רן) כן . . . זאת אומרת, AlphaCode זו תחרות לכתיבת קוד?

• (איתמר) כן . . . לא, לא! סליחה . . . - CodeForces זו תחרות לתוכניתנים . . . .
• בוא נתמקד בחלק הזה, ורק בזה - בשביל המחשה של מה אנחנו עושים שונה.
• אז CodeForces זו תוכנית, או “תחרות לתוכניתנים”, אתם יכולים . . .  כל כמה זמן יש שם את התחרות . . . .

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

• (איתמר) נכון, ויש שם Rating - כמו שיש Rating בשחמט, למי שאוהב את זה . . . .
• ואתה מתחרה כאילו מול המחשב יותר מאשר מול לאנשים - ובסוף יש לך איזשהו Rating.
• ו-OpenAI התחרו עם GPT-4 על ה-Context הזה, של CodeForces
• (רן) והגיעו ל-5% התחתונים . . . .
• (איתמר) התחתונים!
• להבדיל, אגב, מ-GRE ו-Medicine ו-History . . . 
• (רן) . . . ששם ב-85% העליונים . . . 
• (איתמר) בעליונים! כאילו, יש רק 15% יותר טובים מהם, של אנשים.
• ופה יש 95% . . .  איך זה יכול להיות?! הרי אנחנו נורא אוהבים להשתמש ב-Copilot וב-ChatGPT
• למי שמרשה - ומי שלא - עושה את זה גם ככה, נכון? . . . .
•   אז איך זה יכול להיות?
• אז יש לנו פה . . . .

(רן) אז (1) - בתחרות עצמה יש Bias - כי מי שבא להתמודד, הוא כבר כנראה ממש טוב . . . 

• (איתמר) נכון, אבל הם עשו איזשהו . . . 

(רן) . . . .אבל עדיין - הם מגיעים נמוך.

• (איתמר) נכון, אז הם עשו איזשהו Rating . . . כאילו, ב-Rating שלהם הם נחשבים “Newbie”’, ממש ככה.
• אבל סבבה - גם אם לא, אז בוא נסתכל, כי הנקודת-ייחוס שלי אגב . . . . זו נקודה טובה, אבל נקודת-היחוס שלי זו מערכת אחרת, שנקראת AlphaCode
• ו-AlphaCode זה, למי שמכיר - DeepMind, שיצאו עם AlphaGo, שניצחה תחרויות של Go וגם את אלוף העולם
• וגם את AlphaFold, על כיפול פרוטאינים (חלבונים, Proteins) וכל מיני דברים כאלה
• ועכשיו, לפני שנה או חצי שנה, הם הגישו גם כן . . . התחרו - והם עשו פי-9 יותר טוב מ-GPT-4 . . . 
• עכשיו, יש להם פחות או יותר שני רכיבים  . . . זה לא רכיב, זה שתי תתי-מערכות במערכת שלהם - 
• אחת שמייצרת קוד - שבנוי מאוד דומה ל-GPT-4
• זה מה שאתם רואים, כנראה, פחות או יותר, ב-Bard
• ב-Codey - לפני שבועיים, כי הקראת קודם את התאריך, אז אפשר לתת נקודת-ייחוס 
• [תכל’ס Feature חשוב בפרקים בתקופה הזו . . . .]
• אז יצא מודל של קוד ב-GCP, שנקרא Codey, אז משתמשים . . . 
• אבל ממול זה יש מערכת - זה לא בדיוק מודל . . . .
• כמו שאמרתי לכם, גם אצלנו המערכת היא לא Per-se קריאה למודל - “תחזיר תשובה”
• מה ש-Code Generation עושה . . . 
• יש שם מערכת שלמה של Analysis - גם Static וגם Dynamic וכל מיני דברים כאלה, וכמה קריאות למודלים
• אז יש להם מערכת כזאת.
• והשילוב שלהם ביחד גרם לניצחון הגדול, זה מה שאני אומר

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

• (איתמר) ממש ככה . . . אמרת לי בהתחלה, שיש פה בחוג המאזינים אולי גם כמה Data Scientists שמקשיבים לנו, חוץ ממפתחים . . . . 
• אז ב-2016 או 2018, היתה מערכת שנקראת Generative Adversarial Network (GAN)
• בעצם היתה שם מערכת של Generative שמייצרת תוכן - ו-Adverse שבודק אותו
• אחת שמדפיסה כסף - ואחת שאומרת האם זה מזויף
• וביחד הם מצליחים עוד לשפר אחד את השני.
• אז אתה חושב, שאנחנו קצת מחזירים את ה-Concept הזה
• לא אנחנו - AlphaCode הראו את זה
• שבעצם, יש מערכת שמייצרת קוד - ושנייה שבודקת
• וביחד, יש פה ממש “סגירה של Loop”, שגורם לקוד שהולך ומשתפר . . .

(רן) סימביוזה . . . .

• (איתמר) בדיוק,

(רן) הנה עוד Buzzword! . . . 

• (איתמר) מדהים . . . אבל זה חלק מה-Buzzwords האלה, שלא נחשבים לגמרי Buzzwords, כי הן Program-fit . . . .

(רן) כי זה מביולוגיה, זה בסדר . . . 

• (איתמר) כן, זה כמו Program-fit, שהוא Buzzword אבל הוא גם אמיתי כזה . . . . אז סיביוזה, סבבה.
• אז המודלים ה-Generative-יים - אין להם, בפשטות שלהם היום - אין להם את המנגנון הזה, של “הפידבק החוזר”
• וזה מה שאמור . . . .
• אז לצורך העניין, הרבה מאוד מהלקוחות שלנו, בין אם זה מפתחים חינמיים או Enterprise Teams וכו’ - אז הם משלבים את שני הכלים האלה, ביחד.
• לנו לא משנה אם בנאדם כתב את הקוד או Generative Tool, כמו Copilot וכו’ כתבו את הקוד
• אנחנו נעזור לתת את אותו Adversarial, כביכול
•  אז זה שוני מאוד גדול
• ב-Stack, ב-UX/UI, ב-Output-ים . . . .
• אגב, רק שלא ישמע - יש לנו עוד דרך ארוכה להשתפר
• יש מקומות שאנחנו חזקים יותר, כמו ב-Backend, מאשר ב-UI Per-se
• ויותר ב-Component Testing מאשר Integration Testing . . . 
• רק כדי לסבר את האוזן רגע, לא . . . 

39:27 סיכום - וסיפור קצר . . .(רן) כן, טוב - אז אנחנו ממש ככה לקראת הסוף, ויש מלא דברים שרצינו לדבר עליהם ולא הגענו לדבר עליהם . . .א' -יש עוד מלא אתגרים . . .(אורי) . . . ונראה לי גם חסמנו את כמות ה-Buzzwords היומית . . . (רן) הגענו ל-Cutoff שלנו, כן . . . .אז גם בנושא של איך לשלב טכנולוגיות AI בתוך מוצרי-תוכנה, לא דיברנו בכלל על איך זה לפתח כלי למפתחים, איך זה לעבוד עם IDEs שונים, והאתגרים ההנדסיים שקורים שם - אז אולי נצטרך לדבר שוב, איתמר, אבל בכל אופן, תודה רבה שבאת.ממש לפני סיום - כמה מילים על החברה: איפה אתם נמצאים, פיזית? האם אתם מחפשים לגייס? מה עוד היית רוצה שאנשים ידעו עליכם?

• (איתמר) מעולה, אז קודם כל אנחנו יושבים במגדלי חג'ג' ברחוב הארבעה.
• ואנחנו 20 איש - וגדלים.
• אנחנו מגייסים הרבה . . . . אני מקווה שלא ישמע יותר מדי פלצני, אבל הרבה לפי, כאילו, Talent.
• מחפשים כאילו אנשים חזקים, כי אנחנו מאמינים שהבנץאדם עושה את התפקיד ולא התפקיד עושה את הבנאדם.
• ויחד עם זאת - יש Job Descriptions שפתוחים
• אבל במקום לתאר אותם, אני רוצה דווקא לספר איזה סיפור מאוד קצר:
• אז אור הילטש, אני לא יודע אם אתם מכירים, אני מניח שכן 
• [אפשר להתחיל כאן - פרק #275 – אור הילטש ודאטא נדל"ני]
• חוץ מזה שהוא חבר אז הוא גם “אושיה”, אז אני מניח שאתם מכירים . . .
• אז הוא עשה לי שיתוף ב-Screenshot, שיש איזו קבוצה של CTO ו-VP R&D בישראל
• כאלה מוצלחים - אז אני לא שם . . . 
• (רן) לא יודע - אני שם, אז אני לא בטוח לגבי ההצלחה . . . .
•  . . . אז הוא עשה לי Screenshot, והראה שמישהו כתב “שמעתם על החברה הזאת, Codium.ai - החצופים האלה, שבנו מוצר שנראה שבינתיים הולך להם די טוב - ואין להם CTO ו-VP R&D! איך יכול להיות, איך זה יכול להיות? יכול להיות שאתם קצת מיותרים?” וכו’ . . . 
• אז כן, למרות שיש לנו בצוות, לדעתי, ארבעה CTO-ים לשעבר או VP R&D לשעבר
• אנחנו, למשל ה-Founder-ים - אני לקחתי תפקיד, עברתי מ-CTO ל-CEO, מאתגר את עצמי בזה
• השותף שלי הוא ה-CPO . . . .
• אז אין לנו כרגע למשל VP R&D - ואנחנו פתוחים . . . .
• זה לא משהו דחוף, אנחנו מסתדרים די טוב
• אבל מאוד מאוד מאמינים שבסופו של דבר, למרות שעד כאן הלך לנו די טוב, אנחנו כן פתוחים למשל ל-VP R&D וגם ל-CTO.
• אז מי שרוצה לאתגר את עצמו איתנו - מוזמן לבוא ולהתקשר אליי.

(רן) יש מי שכותב Test-ים? הכי חשוב . . . 

• (איתמר) כן, בטח . . . 
• קודם כל, אתה יודע - חייבים . . . אנחנו משתדלים להשתמש במוצר של עצמנו
• גם במוצר שהשקענו בו את רוב הזמן, שזה ה-Extension או Plugin ב-IDE
• אבל גם אותו מוצר שמתחבר ל-GitHub ול-GitLab, שעושה לך את ה-Gateway האחרון וכדומה
• (רן) . . .  שנקרא PR Agent
• (איתמר) שנקרא PR Agent . . . הוא Open Source, אגב - אפשר להשתמש בו ב-Hosted הזה שלנו
• וזה עושה לך Automation של Description, של Review
• כדי שבסוף יהיה לך קל To Streamline the Process
• [רק אומר ש-Whisper תמלל את המשפט הזה ככה - “כדי שבסוף יהיה קל ל-Streamline את הפרוסס” . . . תחשבו על זה מה שאתם רוצים]
• אנחנו משתמשים בזה בעצמנו
• ויחד עם זאת, יש לנו כן - וזה אולי נקודה מעניינת, אבל נגמר לנו הזמן - יש לנו QA, אבל הוא מפתח . . .
• כי ממש . . . הוא חייב להיות, כי אנחנו בונים כלי מפתחים - אז הוא ממש משמש כמפתח, 
• אבל יש לו גם תפקיד מעניין של “להתנסות על Open Sourcing”, וככה גם לעשות קצת Dev Advocate . . .
• אז יש לנו - למרות שאנחנו כלי למפתחים -Automation של Testing במובן מסוים
• אבל עדיין יש לנו Tester . . . 

(רן) כמו שבחברת משחקים משלמים לך כדי לשחק -  פה משלמים לך כדי לפתח . . . .

• (איתמר) נכון, כן, בדיוק.

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

[קישור לקובץ mp3]
פרק מספר 465 של רברס עם פלטפורמה, הוקלט ב-15 באוגוסט 2023 (אם הטכנולוגיה השתנתה בשבוע וקצת שחלפו - ככה זה . . . זה מה שאנחנו יודעים היום).פרק נוסף בסדרת הקרבורטור, שבה אורי ורן מארחים את נתי שלום כדי לדבר (בעיקר) על תשתיות -  וספציפית היום (מעבר לשלום עולמי) על איך אפשר לעשות “Inferencing בקצה” (Inference on the Edge).

01:40 רקע

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

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

• (נתי) אז אנחנו אומרים, קודם כל, שיחידת קצה - זה מצלמה, זה יכול להיות סנסורים (Sensors), זה יכול להיות מחשב . . . זה שנמצא ליד בבית-חולים ויושב ליד המכשיר הרפואי, זה יכול להיות ממש מיני-Data Center.
• (רן) . . . טלפונים, שעונים . . .
• [טוסטר משולשים?]
• (נתי) . . . . טלפונים, רשת סלולרית . . .  כשאתם רואים את המכולות האלה מתחת לאנטנות? אז זה יחידת-קצה.
• (נתי) אז בעצם נוצרים הרבה מאוד מכשירים, שהיום עוברים איזשהו תהליך של דיקיטיזציה (Digitization)
• זאת אומרת שהם בעצם הופכים להיות מחומרה, שהיא  יחסית מנותקת 
• ו”מתישהו” בא טכנאי לטפל בה - פעם בכמה שנים - ועושים להם שדרוג, מאוד יקר בדרך כלל.
• זה משהו שבעצם . . . הם מחוברים כל הזמן לרשת - בדרך כלל ב-Wi-Fi או ב-5G, או בכבל אופטי שמחובר ל-Base Station.
• וזה בעצם שינה את כל ההתייחסות לדבר הזה.

• אני אתן את הדוגמה שכולכם מכירים - הטלוויזיה שלכם בבית
• לפני כן, הייתה טלוויזיה שמחוברים אליה כבל עם איזו קופסא, והייתם קונים את הקופסא הזאת מ-HOT או מ-Yes, ומקבלים [נניח] שירותי Streaming.
• היום, הטלוויזיה עצמה מתעדכנת באופן אוטומטי - כמו הטלפון
• כי היא בעצם מבוססת על Android, מחוברת ל-Wi-Fi - היא נהיית חלק מ . . . “עוד מכשיר” שנמצא היום ברשת.

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

• (נתי)  . . . זה מה שקורה בטלוויזיה . . . . אבל בקיצור, זה . . . .  ממש רואים את השינוי הזה קורה . . .

(רן) יש לי webOS! זוכר את webOS?

• (נתי) בטח . . . .

(רן) אז ל-LG יש webOS - זו מערכת ההפעלה לטלוויזיות של LG.

• (נתי) עוד מעט תגיד לי שהם מביאים גלידות גם וכאלה . . . 
• אז באמת, יש איזה תהליך דיגיטליזציה (Digitalization) - התהליך דיגיטליזציה התחיל כבר לפני כמה שנים
• באמת בעיקר בעולמות של Consumer Business - זאת אומרת, טלוויזיות, טלפונים, וכיוצא בזה.
• ה-Wi-Fi שלי בבית הוא Google Wi-Fi, אז הוא גם כאילו . . .  כל הזמן אני מסתכל ואני רואה שהוא התעדכן, אני אפילו לא יודע שהוא התעדכן.
• דברים שבעבר הייתי צריך להוריד איזה Package מהאינטרנט, לעשות Upgrade, לחבר עם USB וכאלה דברים.
• (רן) לחבר USB, להקיש משהו . . . .
• (נתי) היום אתה פשוט סורק את ה-QR Code, מתחבר, מזהה אותו - ובעצם הטלפון שלך הופך להיות תחנת שליטה של ה-Wi-Fi, שמתחבר לאינטרנט, עושה לו את הסנכרון
• ואני יכול לראות את כל הנתונים של ה-Wi-Fi בבית - מי קולט יותר, מי קולט פחות, מי מחובר למה . . . .
• “כל ה-Mesh הזה”, מה שנקרא.

05:00 תחנות הקצה יותר חכמות - אז מה?(רן) אז תחנות הקצה יותר חכמות . . . .

• (נתי) בדיוק, תחנות הקצה הופכות להיות חכמות - והיום זה חודר גם לעולמות של Enterprise ו-Defense, כל “התעשיות המסורתיות”.

(רן) אז זה זה “ה-Enabler” שלנו . . . 

• (נתי) זה ה-Enabler, בדיוק . . .

(רן) . . . . זה מה שמאפשר את המהפך . . . .

• (נתי) אז זה השלב הראשון.

(אורי) בכלל, כש . . . עוד לפני ה-Internet of Things, תחנות הקצה היו אנלוגיות לגמרי, לא שום דבר דיגיטלי  . . . . ה-Internet of Things הפך אותן לחיבור - לא יודע מה, IP כנראה . . . - לעולם.

• (נתי) בדרך כלל IP, כן . . . .

(אורי) . . .  ועכשיו הן גם מתחילות להיות חכמות, ה-”Things” . . .

• (נתי) נכון - אז בעצם ההסתכלות ברמה . . . 
• בוא נגיד ככה - מי שמסתכל על זה ובא מעולם ה-Cloud Infrastructure, ומסתכל על זה כ-Extension של ה-Cloud . . .
• זאת אומרת, ה-Cloud עד היום היה הרבה מאוד מחשבים שמרוכזים ב-Data Center-ים מאוד גדולים.
• בעצם, החווה של Data Center-ים האלה - זה היחידות קצה אלה.
• אבל בעצם הם כולם “סוג של-Cloud” - 
• אמזון אפילו מתייחסים אליהם כ-Region.
• גם Azure, כשאתה מסתכל על משהו שנקרא Azure Stacks
• זאת אומרת שגם הענן עצמו ייצר את ה”יחידות מחשוב” האלה, שאפשר להתקין אותן באתרים מרוחקים.
• והם מתחברים - ומתנהגים כמו עוד יחידת מחשוב, מבחינת ה-API וה-FSLM . . . .

(רן) אבל זה סוג של PoP, נכון? זה Point of Presence . . . .

• (נתי) זה סוג של PoP . . . .

(רן) זה לא טלוויזיה.

• (נתי) לא, זה לא טלוויזיה . . . . אז אני אומר, זה באמת קיבל כמעט . . . 
• לכן אמרתי - מי שבא מעולם ה-Cloud Data Center, מסתכל על זה כעל Extension של ה-Cloud.
• מי שבא מעולם ה-Consumer, מסתכל על זה כמכשיר חכם.
• זה ממש שתי זוויות ראייה שונות לאותו דבר, לאותו מגע.

06:30 בסוף יש אפליקציה(אורי) אבל זה הכל שאלה . . . . בסוף יש אפליקציה, איזושהי פונקציונליות שצריכה לקרות - ותחליט אם טוב לך לעשות אותה בקצה או טוב לך לעשות אותה בשרת . . . 

• (נתי) או, אז זו בדיוק הנקודה - עכשיו אני, ופה נכנסת המילה הזאת שאני צריך לפרש, שנקראת “Inferencing”, ותיכף נסביר גם איך AI נכנס פה לתמונה וכל מיני דברים כאלה . . . .
• אז בעבר, היתה לנו מצלמה שמשדרת ב-Streaming למרכז - בדרך כלל זה Cloud, איזשהו Cloud - ששם נעשה העיבוד של התמונה הזאת
• ובסוף אנחנו מוציאים איזה תובנות 
• אם זו מערכת Security אז האם זה אויב או לא אויב, האם יש פה איזו חדירה או פריצה למערכת . . . 
• ואפשר, אם זו מערכות Firewall, אז סורקים Packet-ים, ובסוף מזהים אם זה Malicious Attack או לא.
• אבל רוב העיבוד הזה היה נעשה בדרך כלל במרכז של קבלת ההחלטות - והדבר הזה היה יחסית “טיפש”, והעביר את הנתונים האלה.
• פה נכנס הנושא של AI - מה ה-AI הביא לנו? הוא הביא לנו יכולת באמת לזהות אובייקטים בצורה הרבה יותר חכמה
• אני יכול לזהות אם זה חתול או כלב, זו הדוגמא הקלאסית.
• אני יכול להשתמש בזה כדי לזהות, למשל, בקווי ייצור, אם מכונה הולכת להתקלקל - כי אני מתחיל לראות שהיא  . . . 
• או מכונית, לצורך העניין - אני רואה שפתאום ה-Log-ים שהיא מוציאה מתחילים להיראות דומה ל-Pattern-ים של תקלה.
• ואז אני יכול לצפות את זה מראש - וכולנו יודעים שהשבתה של קו ייצור, אם אני כבר מגיע להשבתה, אז זה עלויות מטורפות
• לעומת אם אני מזהה את זה לפני ועושה תיקון Pre-emptive ו . . . .
• (רן) מה שנקרא Predictive maintenance  . . . . 
• (נתי) . . . . Predictive maintenance . . . 
• (אורי) לדעתי היה לנו . . . .
• (נתי)  . . . . יש חברה מאוד מצליחה בארץ שעושה את זה, שנקראת Augury, בחיפה, שמתעסקת בזה.
• (אורי) . . .  לדעתי ראיינו . . . נכון? מישהו מ . . . . [לא חושב . . . . אבל צריך בהחלט]
• (רן) זכור לי במעומעם . . . .
• (אורי)  . . . וגם מ-Lightricks  . . . 
• [זה כן - 417 Developer Growth with Barak Yoresh from Lightricks]
• שעושים את כל העבודת ה-AI במכשיר, ולא בשרת . . . 
• [כזה - Qualcomm Ventures Invests in Augury to Power Industrial Market Transformation with AI and 5G]
• (נתי) נכון, אז תכף נגיע למה זה נהיה עכשיו יותר מגמה.
• אז בגדול, הסטטיסטיקות מדברות על זה שקצב הנתונים - בגלל כל מה שאמרנו כרגע - המכשירים האלה מייצרים הרבה יותר Data ממה שהם ייצרו בעבר.
• אנחנו מדברים על רזולוציה של תמונות שהיום היא כבר לא 4K, אני לא זוכר כבר . . . . לא 8K ואפילו יותר.
• אנחנו מדברים על נפחים . . . . 

(אורי) מה הבעיה? יש 5G - הוא “נולד בשביל הדברים האלה” . . . .

• (נתי) אז הסטטיסטיקה היא שקצב גידול ה-Data, לעומת קצב גידול ה-Access - ה-Access זה ה-Network - הוא כבר לא מדביק אחד את השני.
• זאת אומרת, ה-Data גדל בקצב של בערך פי שלוש יותר מהקצב של ה-Access.
• וגם ב-5G רואים שהתמונה בהתחלה, היא שבאמת 5G נותן איזשהו Capacity - ואחרי זה איזושהי ירידה
• כי פשוט כבר זה מגיע לאיזושהי רוויה ביכולת שלו להכיל את כמות ה-Data.
• אז אם מסתכלים על הגרפים, רואים בעצם איזשהו . . . ש-5G לעומת 4G נותן איזושהי קפיצה - אבל אחרי זה הוא יורד
• ואחרי שהוא יורד, באזור 2027, הוא כבר הרבה מתחת למה שצריך מבחינת כמות ה-Data שאמורה לזרום דרכו.

09:44 התחממות גלובאלית ו-Latency(אורי) בוא נוסיף לזה עוד שיקול . . . . איך קוראים לזה? התחממות הכדור . . . Emissions.

• (נתי) נכון, נכון . . . .
• אז יש באמת הרבה גורמים, שגורמים לזה שאנחנו בסופו של דבר מוצאים את זה שהגישה הקיימת, של לעבד את הכל בענן, ו-”Device-ים טיפשים” - לא מחזיקה מים.
• יש נושא נוסף, שהוא Latency
• אז המספרים הם כאלה, כשעל המכשיר עצמו זה 2 msec; 
• בינו לבין ה . . .  אם נניח אנחנו מדברים על ביזור גיאוגרפי, אז בינו לבין איזושהי תחנת Data Center קרוב זה יכול להיות באזור ה-5 msec.
• אחרי זה זה לענן - בדרך כלל ל-Data Center-ים שהם מרכזים יותר גדולים, אנחנו מגיעים כבר לאזור ה-10 msec.
• וכשאנחנו מדברים על ביזור שהוא יותר ספורדי, אז אנחנו יכולים לדבר על אזור ה-50 msec.
• עכשיו, להרבה אנשים זה לא אומר הרבה, אבל יש הרבה מאוד מערכות - בטח מערכות של בקרה ושליטה וכאלה דברים, ובטח כשאנחנו מדברים על מכוניות ו-Connected Cars, שה-Latency הזה הוא סופר-משמעותי.
• ולכן היתרון הנוסף של עיבוד בקצה הוא בעצם יכולת לקבל החלטות יותר קרובות ל-Real Time.
• (רן) . . . . וגם לפחות נקודות כשל . . . ככל שאתה עובר יותר תחנות, ככה . . . 
• (נתי) בדיוק.
• עכשיו, יש פה איזו סתירה אינהרנטית (Inherent) - וזה בעצם מה שכל העולם של Inferencing בעצם מדבר עליו.
• הסתירה האינהרנטית היא ש-AI בעצם בא ואומר: “אני יכול באופן לא-תיאורטי, להיות הרבה יותר חכם באיך שאני מעבד את המידע הזה - אני יכול להיות אינטליגנטי, אני מפרק את ה-Data ל-Feature-ים, אני יודע לזהות אם זה איזשהו . . . שוב פעם, ‘חתול או כלב’, ‘ספינה או ספינת אויב או לא ספינת אויב’, אני יכול לקבל הרבה יותר החלטות חכמות”
• אבל מצד שני, AI, כמו שאנחנו יודעים, דורש משאבים - משאבי-מחשוב הרבה יותר משמעותיים.
• ופה האתגר הכי גדול של העיבוד בקצה - איך אני מצליח להביא יכולות עיבוד יותר, הייתי אומר, “חזקות ומשוכללות”, שבעצם AI צורך
• אבל עדיין שומר על עלויות.
• למה עלויות הן מאוד מרכזיות בזה? אז אתם תעשו את המכפילים . . . .
• ב-Verizon למשל, יש לך, רק על היחידות של ה-5G, יש לך בערך 30 אלף יחידות
• אז כל דולר שם, אם אוטומטית תוסיף אותו, תכפיל אותו ב-30 אלף - אתה מגיע למספרים מאוד גדולים.
• הם הראו שרק ה-Efficiency של Energy - זאת אומרת, היכולת שלי לחסוך ב-Energy שם - הוא כבר 70% מהעלות של להחזיק רשת היום
• והיכולת לחסוך שם - היא הופכת להיות מאוד משמעותית.
• אז המכפילים משנים את כל המודל ה-Economy של הדברים מהסוג הזה
• ולכן האתגר פה הוא לא רק איך להעביר את העיבוד לקצה - אלא איך לעשות את זה עדיין בעלויות שהן יחסית נמוכות.
• וזה מייצר איזו משוואה, שהיא יותר מורכבת, בוא נגיד, מהדברים האלה - וזה גורם לאבולוציה . . . . או שלא הייתי קורא לזה אבולוציה - להתפתחות שהיא כמעט התפוצצות, במידה מסוימת
• של הרבה מאוד, מצד אחד, GPU חדשים ו-CPU חדשים, ו-Hardware מסוגים שונים, שהוא מאוד Optimized ל-Workload מסוים
• [אוקיי, לעצור הכל ולהקשיב לזה - The GPU Song (GPUs Are Fire)]
• וזה מייצר הרבה מאוד פרגמנטציה (Fragmentation) בקצה
• זאת אומרת, אם בעולם ה-Data Center יש איזו “מוגנות” מסוימת - זאת אומרת, יש לך וריאציות, אבל אתה מגיע ל”גג”, כמה סוגים של XL, Medium וכאלה, עם קצת וריאציות.
• בגלל המתח הזה, שבין עלות ל-Performance, כל הזמן יוצאים עכשיו Device-ים חדשים.
• זה מזכיר נורא את מה שקרה ב-Mobile Phones, ב-Smartphones, בדור הראשון שלו, פחות או יותר.

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

• (נתי) נכון . . . .

(רן) וב-iOS זה קצת יותר קל, אבל עדיין די מאתגר - יש המון רזולוציות, המון סוגים של Capabilities . . . לפעמים יש לך SIM, לפעמים אין לך SIM, לפעמים יש לך גישה ל-Gyro, לפעמים אין לך - אבל אתה צריך לקחת בחשבון המון המון וריאציות.וזה מאוד מאתגר, בתור מפתח אפליקציות . . . .

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

14:29 רץ על הקצה(רן) רגע, אבל שנייה - לא הסברנו מה זה Inferencing . . . .

• (נתי) אז Inferencing זה בעצם . . . המילה הכי פשוטה בעברית לזה היא בעצם “עיבוד בקצה”
• יכולת לזהות אובייקטים בצורה אינטליגנטית.
• בסופו של דבר, אם אני אחזור חזרה למודלים של AI, אז יש ב-AI שני חלקים:
• יש חלק אחד של Training.
• ויש חלק אחד של עיבוד.
• החלק של ה-Training זה המערכת  . . . .
• אני אלך אולי צעד אחורה, למי שהמושג AI וכל המודלים האלה של Training ומודלים הרבה פעמים מבלבלים אותו
• בסופו של דבר, התוספת - השינוי הגדול שה-AI הביא - זה במקום, לצורך העניין, לעשות שאילתא ולקבל תשובה על מה שאני שואל, אז זו יכולת לקבל “קירוב של תשובה”.
• והאינטליגנציה היא בדיוק במילה הזאת, “קירוב”
• שזה ה-Vector Database וכל מיני דברים
• שבעצם מאפשרים לי להגיד “אין לי את מה שאתה מבקש - אבל אני יכול לתת לך משהו משוערך”.
• אז חלק מזה בכתיבת טקסט - אני עושה Prediction למילה הבאה שאתה תכתוב.
• חלק מזה בעיבוד תמונה - אני יודע מה הפיקסל הבא שאתה תראה.
• ומשם בעצם מתפתח עולם שלם של אלגוריתמים, של בעצם . . . . הם כולם צופים את מה זה ה-Next step הזה בתמונה; מה זה ה-Next step הזה בכתיבה; מה זה ה-Next step הזה . . . .
• והרבה פעמים ה”הסקת מסקנה” הזאת - היא בנויה על תהליך שנקרא Training או Reinforcement
• כל מיני תהליכים שבסופו של דבר, מאפשרים למערכת לעשות את ה-Prediction הזה בצורה יותר מדויקת, ולאפס את המשקולות.

(רן) אז Inferencing עושה כמו Serving . . . 

• (נתי) נכון, אז אני אגיד אותו - ואני אחזיר חזרה את זה לעולם של AI והחלוקה בין Training לבין Inferencing
• כי Inferencing, בדרך כלל, זה כבר תוצאה של Training
• זאת אומרת, לקחתי את החתול וכלב, הרצתי הרבה מאוד תמונות, אם אני עושה תהליך של Reinforcement או תהליך של Data שנכנס למערכת
• הרצתי הרבה מאוד תמונות כאלה, הגעתי למשקולות הנכונים
• ויש לי עכשיו כרגע אלגוריתם, שיודע לקבל תמונה ולהגיד אם זה חתול או כלב.
• עכשיו, הרבה פעמים, האתגר הבא שלי, למי שמכיר את TensorFlow - אז יש TensorFlow ויש TensorFlow Lite 
• זה גם לקחת את המודל הזה - וגם להקטין אותו, כדי שהוא באמת יוכל לרוץ ביחידות-קצה, קטנות יותר.
• ואז בעצם מה שיקרה בתחנת-הקצה זה תהליך יחסית פשוט - Input שנכנס זה תמונה ו-Output שאומר: קלאסיפיקציה (Classification) -
• זה תמונה כזאת, זה תמונה כזאת, זה תמונה כזאת . . . . 
• וזה נקרא Inferencing - המילה Inferencing, או “Edge Inferencing", הוא בעצם אומר “אני לא עושה את ה-Inferencing ב-Cloud, אני עושה אותו בקצה”.
• אז כשמו - כן הוא: זה בעצם יכולת העיבוד בקצה.
• כמו שאמרתי, מאחוריו מסתתר עולם שלם של טכנולוגיה - של איך מביאים את הדיוק הזה
• מצד אחד, של העיבוד, Cost, אנרגיה - כל הדברים הללו איכשהו  צריכים להסתדר, ויש המון המון קונפליקטים בתוך הדבר הזה.
• ולכן נהיה פה עולם חדש ומאוד מעניין, שמתחיל להיווצר - של סטרטאפים, של יצרני חומרה, של . . . . לא רק “nVIDIA-יות” לצורך העניין.

17:32 “אחת-לשכחתי” ופרטיות בקצה(אורי) אז יש לנו באמת, לא יודע מה - Lightricks, שמזהים ועושים עיבוד של התמונה במכשיר שלנו, או Augury, שעושים את זה ב-Device-קצה, ב-Sensor בעצם . . . . .אבל קודם כל, השאלה היא  האם זה פתר לנו באמת את הבעיה? כי המודל, קודם כל, צריך “לדחוף אותו” - אז אנחנו מסתמכים על זה שאנחנו דוחפים מודל “אחת-לשכחתי” . . . .

• (נתי) נכון . . . 

(אורי) . . . כי אם אתה צריך לדחוף מודל כל הזמן, אז . . . .

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

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

• (נתי) נכון . . . .

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

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

(אורי) Outbrain מלמדת מודל כל חמש דקות, אוקיי . . . .(רן) ובוא אני אוסיף לך עוד פרמטר, שאני חושב שאתה גם מכיר - Privacy : היכולת להשאיר Data של המשתמש - אצל המשתמש. זו יכולת שהיא מאוד חשובה. הצורך להביא את ה-Data של המשתמש לתוך ה-Data Center אמנם עושה את עבודת ה-Machine Learning יותר קלה - אבל גם מסכנת את ה-Privacy של המשתמש. ובאמת, יש לא מעט . . . אני ראיתי חברות עם מוצרים שממש מתעסקים בתחום הזה - של לעשות Inferencing בקצה, אך ורק לצורך שמירת Privacy.הם גם בונים את המודלים בקצה, לצורך העניין . . . .

• (נתי) כן . . . אה, את אומרת גם את ה-Training?!

(רן) כן, גם ה-Training קורה שם, במידה מסוימת . . . .

• (נתי) וזה, אתה אומר, מסיבות של Privacy?

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

• (נתי) זה Distributed Training . .

(אורי) זה כשה-Training מתבצע על Sampling ? . . . 

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

(רן) . . . אז או שה-Data . . . או שה-Training ממש נעשה בחלקו על ה-Device, או שאתה מעביר ל-Data Center . . . 

• (נתי) . . . שקרוב ל-Device . . . 

(רן) . . . . Data שהוא אגרגטיבי (Aggregated), שהוא Anonymized וכו’ - ואז כן, ה-Training נעשה ב-Data Center. אבל עדיין - יש לך פה Risk.אז אני אומר - גם השיקול של Privacy, ובטח יש עוד שיקולים אחרים למתי לעשות את ה-Inference בקצה או לא בקצה.
20:39 תשתית מודרנית של עיבוד(רן) אז כאילו, אלה השיקולים, נקרא לזה, “העסקיים” . . . 

• (נתי) נכון.
• (נתי) עכשיו - אני מסתכל על זה ברמה של איך נראית, בדרך כלל, היום תשתית מודרנית של תהליך כזה של עיבוד.
• אז יש לך בעצם, בקצה, יש לך את ה-Device
• תמיד יש עליו איזשהו Software.
• היום ה-Software הוא בדרך כלל משלב יכולות AI.
• ו-Streaming לתוך איזשהו . . . זה מה שנקרא “Far Edge” ו-”Near Edge” - ו-”Center”.
• זה מתחלק לשלושה Tier-ים, שבעצם כשמם כן הם . . . 
• אבל הם ביחס שמה-Data Center החוצה.
• אז Far Edge - זה אומר שהוא קרוב לקצה.
• זאת אומרת, זה אומר שהוא  הוא Near to the Edge - אבל רחוק מה-Data Center
• (אורי) . . .  מה שנקרא “The last mile” . . . 
• (נתי) כן, בדיוק . . . אז “Last mile” זה מושג יותר, הייתי אומר, “נפוץ”, מעולם ה-Networking וכו’.
• והיום, בעולמות של Datacenter-ים מבוזרים, אז קוראים לזה “Far Edge” ו-”Near Edge”
• כש-Far Edge, בדרך כלל, מייצג יחידת עיבוד בינונית, או אפילו קטנה.
• ו-Near Edge הוא ממש Data Center.
• אם תסתכלו על זה, בדרך כלל, נניח בעולמות של TelCos, אז קוראים לזה “NFL Cities”
• זאת אומרת, זה מרכזים שהם Hub-ים, שיש בהם, יחסית, ריכוז גדול של אוכלוסייה.
• אז למשל, הרבה פעמים ה-Telcos יהיו מפוזרים . . . הסיבה שקוראים לזה “NFL cities” זה כי האיצטדיונים איכשהו פזורים באופן לא אקראי, במרכזי אוכלוסין גדולים . . .  אז יש קורלציה.
• אז ה-Far Edge - הוא קרוב ליחידת-קצה
• ויש לנו את ה-Functional Edge - זה ממש ה-Device עצמו, המצלמה, או ה-Sensor . . .

(רן) הטלפון, השעון, הטלווזיה . . . . [ואז זה Photo-Far-Edge? #סליחה]

• נתי)   . . . הוידאו . . .  בדיוק, כן.
• אז ה-Far Edge . . . עכשיו לפעמים יש Far Edge שהוא גם ה-Functional Edge, אבל הרבה פעמים הם שתי יחידות שונות.

(רן) אז Far Edge - זה יכול להיות “המכולות” שנמצאות מתחת לאנטנת סלולר . . . 

• (נתי) בדיוק, נכון.

(רן) . . . זה יכול להיות כל איזה 70-100 קילומטרים . . . .

• (נתי) נכון, וזה בעיקר . . . 

(אורי) ה-CDN-ים מתחילים לתת שירות כזה, של Processing . . . .

• (נתי) זו נקודה סופר-חשובה - היום יש, מה שנקרא היום WebAssembly גם
• מי שלא שמע [את 351 Bumpers 52, למשל] - אז זה סוג של טכנולוגיה, שבעצם בעיקר נפוצה ב-CDN-ים מודרניים
• שבעצם מאפשרת יכולת גם של הרצת קוד עם ה-Data
• וזה באמת נועד לעשות איזושהי לוגיקה של Streaming, עיבוד . . . 

(רן) כן, נכון - רק לא WebAssembly - WebAssembly זה ממש בתוך הדפדפן . . . 

• (נתי) כן, לא - אבל יש טכנולוגיה של Web Assembly, שהיום יודעת לרוץ, ממש ב-Storage.
• תיכף אני אזכר בחברה שאנחנו עובדים איתה היום ש . . .  Fastly, למשל.
• אז  Fastly עושים הרבה שימוש ב-WebAssembly לעיבוד בקצה
• כי תחשוב - כשאתה עושה Streaming ואתה אומר “אוקיי, עכשיו אני רוצה לעשות קליפ, או אני רוצה לעשות . . .  רק לסנן את התמונה, או לסנן את . . . “
• אני יכול לעשות הרבה מאוד מהדברים האלה - איפה שה-Data נמצא
• ואני לא צריך לשנות ולשמור עוד Storage בשביל הדבר הזה
• אני פשוט יכול ב-Real-Time לשנות את התמונה - ועדיין להשאיר עותק אחד של זה.

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

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

24:10 מערכת ניהול - Orchestration & AI - ורעיון לסטארטאפ הבא

• (נתי) שנייה, בואו נלך צעד אחד אחורה . . . .
• אז דיברנו על מושגים של Functional Edge ו-Far Edge ו-Near Edge ו-Data Center.

(רן) . . . בקטגוריה הזאת . . . .

• (נתי) בקטגוריה הזאת . . . 

(רן) ו-Near Edge?

• (נתי) אז הם, בדרך כלל, יהיו “Near-too-Far”  . . .  זו נקודה נכונה, כי CDN-ים בדרך כלל יהיו איפשהו באמצע בין Near ל-Far
• כי הם כן יחסית פזורים גיאוגרפית קרוב ל-Latency של הלקוח.
• אבל מצד שני, הם לא “Near” - שזה מעט מאוד Data Center-ים יחסית . . . 
• (אורי) זה הרבה Data Center-ים קטנים.
• (נתי)  . . . זה הרבה Data Center-ים קטנים . . . - אז הם איפשהו באמצע, אני חושב, יותר קרובים אולי ל-Far מאשר Near.
• (אורי) אולי PoP יותר . . . 
• (נתי) נכון, נכון - אז בגלל זה אני אומר: הם איפשהו באמצע, אני חושב, בין Near ל-Far, 
• אני מדמיין Far כמשהו שהוא ממש “במכולה”, מתחת לזה
• ו-CDN הוא איפשהו באמצע.
• אז איפה הייתי? . . . 
• (נתי) אז עכשיו הגדרנו את המושגים של איך נראית ארכיטקטורה End-to-End של יחידת הקצה.
• על זה יש לנו, בדרך כלל, מערכת ניהול, שזה Orchestration
• שבעצם, עכשיו יש לי הרבה מאוד יחידות קצה - איך אני עושה Continuous Update? איך אני מעדכן את המודלים? איך אני מנהל את הדבר הזה? . . .  
• אז זה רכיב נוסף שיש עליו.
• ויש, כמובן, מערכת AI מרכזית - שהיא אחראית גם על ה-Training של המודל ועדכון שלו אחרי זה ביחידות-הקצה
• וגם אחרי זה - לקלוט את העיבודים מיחידות הקצה, ולהתחיל לעשות קורלציות ולזהות טרנדים שהם Cross-Devices, Cross-Regions וכאלה דברים.

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

• (נתי) אז זה האתגר . . . .
• אני חושב ש... 

(אורי) רק על ה-Monitoring ועל הדוחות . . . . 

• (נתי) אני חושב שלכל יזם היום ששומע את זה - צריך לקפוץ לו איזשהו רעיון לסטארטאפ הבא . . . .
• יש פה הרבה מקום ליזמות בעולם הזה - כי באמת הוא ב-“iPhone 1”, פחות או יותר  . . . . איפה שאנחנו נמצאים היום בעולמות האלה.
• וזה גם שילוב של AI וזה גם שילוב של אתגר של Compute . . . 
• בקיצור, זו צומת-דרכים שיש בה הרבה מאוד אתגרים שמשתלבים ביחד - וזה שווה-ערך להרבה מאוד הזדמנויות.
• וזה אני חושב ככה, מקום שאני ככה, מתעסק איתו יחסית הרבה בזמן האחרון
• ותיכף אני אגע באמת איפה אני מתעסק ומה אני עושה שם - אבל רציתי קודם לתת איזושהי תמונה כללית לאיך שנראה היום בעולם הזה ולמה הוא נושא שהפך להיות מעניין פתאום.

26:50 קול-קורא לתשתית גנרית ו-Edge-as-a-Service(רן) בסדר, אז בואו, אולי נדבר לך על איזשהו Use Case, או שנדבר על מה שאתה עושה ביום-יום . . . 

• (נתי) כן . . . .
• אז אני, בלי לציין שמות לקוחות, כי אני לא יודע אם מותר לי, או בואו נגיד רוב הסיכויים שאסור לי . . . 
• אבל אני נמצא היום, מי שלא מכיר - הייתי ה-CTO ו-Founder של Cloudify - ו-Cloudify נרכשה על ידי חברה שקוראים לה Dell, שרובכם מכירים כבר . . . .

(אורי) חברה קטנה . . . 

• (נתי) חברה קטנה, כן . . . .
• אז בתור חברת חומרה, היתה להם בעבר זרוע שנקראת VMware, הם מכרו אותה בהרבה מאוד ביליונים ל-Qualcomm [אני חושב שזה היה ל-Broadcom . . . ]
• והם נשארו קצת בלי השכבה הזאת
• ו-Edge הוא איזשהו Extension או Growth Engine טבעי, שאמור . . . . שהם בעצם נכנסים אליו.
• ואנחנו ממלאים את החלל של מערכת הניהול של יחידות הקצה האלה, וחיבור שלהן גם לשכבות של הענן.
• לצורך העניין, זו היכולת באמת לחבר את ה-Near ואת ה-Far ואת ה-Cloud
• ולתת איזו מוטת-שליטה אחידה בין כל היכולות האלה.

(רן) אז אתה לא מוכר Laptop-ים  . . . .

• (נתי) אני לא מוכר Laptop-ים, לא . . . . ממש לא.

(אורי) חשבתי אולי להחליף . . . .

• (נתי) אז בעצם האתגר הוא . . . אם תחשבו על זה,  יש כמעט היום, בהרבה מאוד מהרצפות ייצור ומה-Datacenters ובבתי חולים, איזשהו מחשב Dell שיושב שם
• שמנותק כזה ומאובק  . . .
• ומדי פעם בא איזה טכנאי, שעושה לו איזה . . .  מכניס USB ומעדכן אותו.
• והאתגר הוא בעצם להעביר את זה ליחידות המודרניות האלה
• שזה בעצם אומר שהוא כל הזמן מחובר, הוא כל הזמן מנוהל, יש לך מוטת-שליטה מרכזית, שדרכה אתה בעצם יכול לנהל את כל הדבר הזה.
• אז אני מתעסק עכשיו בזה - ומן הסתם, היות ו-AI נכנס לקצה, אחרי מה שדיברנו ב-Inferencing, אז בעצם אנחנו גם מנסים לתת מענה לתוך הדבר הזה.
• אבל - וזו הנקודה שאני חושב, שמחברת את מה שאמרתי קודם לזה - המקום שאנחנו עוצרים, זה באמת לייצר איזשהו משהו, שאני חושב שהוא קצת חדש, בזה שאנחנו רוצים לתת תשתית גנרית, שתאפשר לכל מי שרוצה לתת “שירותי Inferencing”, לבנות אותו על התשתית הגנרית.
• דומה למה שה-Cloud עשו ל-Data centers.
• זאת אומרת, אם בעבר אמרו, בעיקר לסטארטאפים בעבר, “אתם תתרכזו בלבנות SaaS ואת ה-Business Logic שלכם - וה-Data Center עלינו” . . . 

(רן)  . . . . [?!Inferencing at the Edge - as a Service . . . . [IatEaaS?

• (נתי) כן, רק שאני לא אתן את ה-Inferencing, אלא אני נותן את התשתית, עד השלב Inferencing:
• כל מיני Stack-ים שהם Optimized לזה.

(רן) אז Edge as a Service . . . . [אז EaaS? יותר טוב, עדיין קשוח . . . .]

• (נתי) Edge as a Service, זה יותר קרוב לזה . . . 
• זה שהוא “Inferencing-Enabled“, נקרא לזה ככה.

(רן) לא הגיטריסט, היינו צריכים להגיד . . . . [אעפ”י שזה דווקא רעיון לא רע . . . .](אורי) אבל הרעיון הוא - נגיד, של החברה הקטנה הזאת, Dell - לתת בסוף, כאילו, Motherboard, לשים אותו בתוך ה-Edge-Device שלך?

• (נתי) אז הרעיון הוא, אני אומר . . . זה מאוד דומה למה שקרה בעולם ה-Datacenter-ים, לסטארטאפים.
• הרעיון בא ואומר כזה דבר - להפיץ את החומרה
• אני זוכר שדיברתי עם ה-CTO של איזו חברה, ברח לי השם שלו כרגע, ואז הוא תיאר לי את הכאב-ראש שיש בדבר הזה.
• (אורי) גל? זה גל?
• (נתי) גל! נכון, בדיוק.
• אז להתקין עכשיו חומרה אצל לקוח, לחבר את זה לענן, לדאוג לזה, לעשות Continuous Update לתוך הדבר הזה - זה כאב ראש  . . . 
• מי צריך עכשיו להתעסק עם כל התהליך הזה של ה-Shipment והתקנה וכאלה דברים?
• (רן) “לך תתקין Datacenter חדש בקופנהגן . . . “ למה שתעשה את זה? לך תשכור  . . . . [ודווקא לשם עוד תמצא מתנדבים . . . ]
• (נתי) בדיוק, בדיוק.
• אז הרעיון הוא של-Dell לצורך העניין במקרה הזה, יש כבר את הרשת Distribution, הם כבר יודעים להפיץ את החומרה
• ועכשיו מה שאנחנו מוסיפים, דרך האינטגרציה (Integration) של Cloudify, לתוך המוצר הזה שנקרא NativeEdge, זה בעצם את ה-API ל-Developers, שיכולים עכשיו לגשת לזה כמו אל עוד יחידה בענן
• ובעצם להתרכז בכתיבת התוכנה.

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

• (נתי) נכון . . . אז יש . . . .

(אורי) לפעמים זה לא “Device” - זה יכול להיות מצלמה . . . .

• (נתי) נכון.
• אז אני אומר, יש פה שתי שכבות של Device-ים - 
• יש שכבות שהן כבר מה שנקרא “צבועות” Dell, שהפכו אותן ל-Device-ים ל-Edge
• שהן Optimized מבחינת מחיר ויכולות
• ויש “3rd-party Device”, שזה משהו שיחסית חדש שעובדים עליו
• שבעצם זה סוג של Bring Your Own Device
• מתוך הנחה שבגלל שיש פרגמנטציה (Fragmentation) כזאת בשוק, אז אין שחקן אחד שיהיה לו את כל ה-Portfolio של מה שלקוח צריך
• או לצורך העניין, השחקן או החברת סטארטאפ שצריכה עכשיו לתת - הרבה פעמים תיהיה לה “דעה” למה “צריך” להיות בקצה - בגלל שיש פה תחרות.
• לצורך העניין, אם אני Mobileye, אז מאוד חשוב לי שה-Device הזה יהיה $6, קופסא קטנה כזאת שיושבת במכונית, 
• והוא חייב להיות $6 - כי אם הוא לא יהיה $6 , אז אני לא יכול להכניס אותו לקווי-הייצור של המכוניות . . . 
• וזה - אין “שחקן אחד שיכול לשחק על כל המגרש”.
• ולכן מאוד חשוב פה לבנות את זה בצורה כזאת, שהיא פתוחה ל-Ecosystem
• וכשה-Ecosystem מתחלק ל-3rd Party Devices ויכולת Bring Your Own Device,
• כאילו להביא את היכולות שלך לתוך המערכת - ועדיין שתיהיה לך את אותה מוטת-שליטה,
• ומצד שני, שיהיה לך המקרים הגנריים, איזשהו פתרון גנרי, שלא תצטרך בכלל לחשוב על הדבר הזה.
• אז אני מתחיל להתעסק עכשיו בתוך הדבר הזה, ויש פה, ובאמת - זה סוג של “קול קורא” אם תרצו, לאנשים שמתעסקים בתחום הזה
• אני בעיקר מעוניין לדבר, לא למכור בטוח . . . אבל בעיקר לדבר ולשמוע איך אנשים אחרים חושבים על הבעיה, מתעסקים עם הבעיה . . . 
• באיזה חברות יש בארץ ומה שהן מתעסקות עם זה . . . 

(רן) בוא, תן לי רגע לחדד ולאתגר - בעצם, מה שאתה בונה, מה שאתה מתאר שאתה בונה,  זה Compute at the Edge, זה לא בהכרח Inferencing at the Edge.זאת אומרת, אתה בעצם מאפשר להריץ איזשהו Workload, כנראה סטנדרטי, כי ה-CPUs הם די פשוטים - לא בהכרח Inferencing, כי Inferencing, בדרך כלל יש לו אתגרים משלו: זה בדרך כלל, בהרבה מקרים, צורך GPUs, ו-Data . . . 

• (נתי) נכון, אז מה שאני . . .  אתה צודק לגמרי.
• מה שאני כן נותן, זה למי שבונה פתרונות Inferencing
• זאת אומרת, (א) ה-GPU כבר Built-in, ונניח אם אנחנו באחד ה-Stack-ים באים עם Kubernetes, אז אנחנו דואגים שה-Stack של Kubernetes - בדרך כלל זה יהיה K3s
• [להרחבה - 394 Rancher with Lior Kesos]
• אבל זה יכול להיות כל Kubernetes שהוא Optimized לרוץ ב-Footprint נמוך
• וכבר יהיה Tuned לתוך ה . . . לעבוד עם ה-nVIDIA GPU או עם ה-Qualcomm GPU או עם כמה מהיצרנים ש . . . 

(אורי) אבל בעצם, מה שרן אומר זה ש-Inferencing הוא אחד ה-Use Cases של Compute at the Edge  . . . 

• (נתי) נכון - רק שזה כבר לא . . . זה הופך להיות כמעט . . . Use Case שכמעט אי אפשר לחשוב על יחידת-קצה בלי Inferencing
• כי אתה רוצה את היכולת לזהות מהר דברים ואתה רוצה את ה-Latency ואתה רוצה את ה . . . 

(רן) . . .  זה אולי אחד - אבל הכי חשוב, ואולי גדל . . . 

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

(אורי) אני חושב שהוא פשוט “הטריוויאלי ביותר” להעברה מה-Center ל-Edge . . . 

• (נתי) נכון, בדיוק . . . 

(אורי) . . . . כי פשוט הרבה דברים אחרים עושים ב-Edge . . . 

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

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

• (נתי) כן, אני זוכר ש . . . 

(רן) בצוללת יש GPU? . . . (אורי) מה?(רן) בצוללת יש GPU?(אורי) כנראה שכן . . . [ביטחון מידע!]

• (נתי) אגב מערכות בקרת-אש - אני זוכר שדיברנו פעם בעברי, היה לנו פרויקט מול חיל הים, אז מערכת בקרת-אש - אתה יכול להבין ש-Latency שם הוא . . . 
• אז היה לנו בעיה ש . . . נניח, עבדנו עם JVM לחלק מהדברים, אז בגלל . . . .
• (רן) Garbage Collection . . . .
• (נתי) כן, בגלל Garbage Collection, היה מדי פעם - פעם בעשרת-אלפים פעמים - היתה איזו קפיצה של Latency
• וזה הרג את הפרויקט הזה בסוף . . . 
• כי המערכת חייבת להיות גם עם Latency נמוך - אבל גם מאוד דטרמיניסטית
• כי אתה לא יכול . . . אתה לא רוצה שעכשיו יהיה לך איזה Drone שרץ אליך, ופיספסת בדיוק בשנייה להפעיל את המערכת-בקרה הנכונה - ובסוף חיסלו אותך בגלל זה . . . 

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

• (נתי) היום ספינה, למי שלא מכיר - ספינה היא חתיכת Data Center . . . 
• בטח ספינה צבאית, אני לא מדבר בכלל משחתות וכאלה . . . וצוללות וכאלה דברים . . .
• זה כבר ממש Data Center חכם, עם הרבה מאוד יכולות עיבוד
• בגלל כל הנושא של ל”א [לוחמה אלקטרונית], מערכות בקרה . . . 
• זה כבר לא הדברים האנלוגיים שראינו.

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

• (נתי) אז אני חושב שזה באמת דוגמאות מאוד טובות לשימוש - אבל אני בכוונה לא הלכתי למקומות האלה, כי זה קצת רחוק להרבה מהאנשים
• כי זה באמת מייצר את ה-Cutting Edge, נקרא לזה ככה, אם אני אשתמש במושג Edge . . .
• (רן) “לחתוך את הקצה” . . . 
• ויש הרבה יותר, כן . . . . יש הרבה יותר מקרים שהם . . . הייתי קורא לזה יותר “Mainstream”, שאנחנו חשופים אליהם היום
• קחו רק בתחום ה-Manufacturing, רפואה, אנרגיה . . . 
• אז באנרגיה יש לך היום הרבה מאוד קולטים של שמש, סולאריים
• ועכשיו צריך לנהל את הדבר הזה . . . 
• יש חברה אגב, SolarEdge, שנמצאת בארץ, שמייצרת את הדבר הזה
• אז הטרנד היה שכל חברה כזאת הייתה צריכה גם לבנות את המערכת ניהול שלה - וזה תקורות מאוד גדולות.

(אורי) תאר לך ש-SolarEdge לא הייתה עושה את זה ב-Edge . . . .(רן) . . . או לא הייתה משתמשת בשמש . . . 

• (נתי) לגמרי . . . 

(אורי) אבל לא נראה לי שחסר להם אנרגיה . . . 

• (נתי) אז אני חושב שבגלל שזה הופך להיות נחלת-הכלל
• ושוב פעם, אני אתן את הדוגמא למה שקרה שה-Datacenter-ים עברו לענן - זו מגמה מאוד, לדעתי, דומה.
• המקרה הזה של Edge הופך להיות צורך מספיק גנרי - שעכשיו חייבים להוריד את החסמים של כניסה אליו.
• והדרך להוריד את החסמים זה את כל ה-Distribution הזה, וניהול של Distribution וניהול של חומרה, וניהול של זה . . . . 
• צריך להיות מאוד דומה לאיך שאנחנו מתנהלים בענן.
• זו, פחות או יותר, השכבה שאני חושב שחסרה כרגע - כדי שבאמת כל יצרני ה-Inferencing וכל מי ש . . . 
• כל סטארטאפ שעכשיו רוצה לבנות מנוע AI, שיודע להחבר Sensor לאלגוריתמים ולמודלים שלו, יוכל לעשות את זה בתקורות הרבה יותר נמוכות מזה שהיום רק יצרנים מאוד מאוד גדולים יכולים לעשות כאלה דברים.
• ופה אני אומר - יש פה איזה חיבור שיכול להיות מאוד מעניין,
• אני מאוד מקווה שאני אוכל למצוא עוד אנשים שמתעסקים בתחום הזה בארץ.

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

• (נתי) בדיוק, ממש ככה. ממש ככה, אני ממש מתעניין באמת.
• זה עולם חדש, אני לומד בו, אני לא . . . 

(אורי) עולם הרכב . . . 

• (נתי) עולם הרכב -  ויש לנו אפילו עם Hyundai איזשהו מהלך מעניין
• באמת בהקשר הזה, שהם מנסים - אני לא יודע אם זה יקרה, זה כרגע רק בדיבורים - אבל הם מנסים גם להפוך את זה לאיזשהו “Hub ל-Startup-ים” ישראלי 
• שבעצם יקימו מרכז כזה ש-Startup-ים יוכלו להריץ את הפתרונות שלהם, ובעצם זה יהיה סוג של-Ecosystem שהם יוכלו להשתמש בזה כאיזשהו-Ecosystem, שאומר “אוקיי, זה כן מתאים לנו, לא מתאים לנו, אנחנו רוצים להשקיע בחברה הזאת, אנחנו לא רוצים להשקיע בחברה הזאת” . . .
• [לא מנסים - זה קיים כבר מ-2018, ד”ש לניר חן]
• אז ברגע שאתה מאפשר כזה דבר, אז פתאום אפשר גם להריץ פתרונות של מעבדות Innovation, ו-Ecosystem של Startup-ים  . . . 

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

• (נתי) נכון.

(רן) . . . למשל, הגדלים של ה-Cluster-ים לא יעלו על . . .  לא זוכר, 5,000 Node-ים?

• (נתי) נכון.

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

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

(רן) ועדיין - עדיין אתה צריך Pod-ים - זאת אומרת,  אתה באמת צריך את כל הסיבוך הזה של Kubernetes ש...

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

(רן) בסדר . . . .

• (נתי) כשאתה מתקרב ל-Far - זה כבר פתוח . . . .
• ואז אתה יכול . . . .  יש פתרונות כמו WebAssembly ולהריץ Functional
• בטח ב-Functional Edge  זו כבר הופכת להיות שאלה מאוד מאוד פתוחה . . . .
• אני מעריך ששם אנחנו נראה פתרונות אחרים מ-Kubernetes, לתוך הדברים האלה.
• יש פתרונות שהם סוג של AWS) Lambda) ב-Edge, שמריצים רק JavaScript-ים ועוד דברים יחסית . . . 
• שבעיקר מדברים עם החומרה ונותנים כל מיני פונקציות שעושות כל מיני קונפיגורציות (Configurations) על חומרה
• אבל לא צריכים לוגיקה מורכבת.

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

• (נתי) אז כן, אז אני אומר . . .  אני חושב שבאמת באיזורים האלה של ה-Far Edge, אנחנו נראה טכנולוגיות אחרות . . .

(רן) אבל זה לא משהו שאתם עובדים עליו? . . . 

• (נתי) אנחנו כרגע כן מסתכלים על WebAssembly כאיזשהו . . . אחת מהטכנולוגיות האלה שיכולה, כנראה, לתת מענה לסיבות האלה
• כי ה-Footprint שלו (א') הוא מאוד נמוך 
• והוא פורטבילי (Portable), בין הרבה מאוד Device-ים
• זאת אומרת, יש לו את התכונות של JVM - ומצד שני, אין לו את ה-Overhead של JVM.
• והוא גם מתקמפל (Compile) מאוד טוב ל-Binary, ב-Run-time ממש.
• אז יש לו הרבה מאוד תכונות שהופכות אותו, כנראה, למאוד אופטימלי - לא סתם Fastly בחרו ב-WebAssembly ומקדמים את זה כסוג של . . . הייתי אומר, “ה-Kubernetes ל-Edge” החדש.
• הוא לא דומה בכלל ל-Kubernetes כמובן, אבל בגדול זו התצורה.
• אז כן, אני חושב, וזו נקודה מאוד חשובה - שהיתרון של ההומוגניות של Kubernetes הוא כבר עומד בעוכריו ברגע שמגיעים לזה
• בגלל ההומוגניות, אנחנו משלמים הרבה מאוד מחיר על Complexity
• ואנחנו משלמים הרבה מאוד מחיר על גמישות מאוד גבוהה
• ובקצה אנחנו כנראה נראה התפתחות של טכנולוגיות כמו WebAssembly
• שהן יהיו מאוד מאוד Optimized לדבר הזה - וזה כנראה לא יהיה Kubernetes
• לפחות לא בתצורה שאנחנו מכירים כרגע.

41:49 יש עוד יצרנים?(אורי) תגיד, נתי - חוץ מ-Dell, עוד יצרנים נכנסים לעולם הזה?

• (נתי) שאלה מצויינת [--> למה אתה מבאס?] . . .
• אז אני חושב שכמו שאני רואה את זה, אנחנו רואים את זה - אתם יכולים לדמיין שכל יצרן חומרה רואה את הדבר הזה, ומנסה לעשות עכשיו Hedging לתוך העולם הזה.

(אורי) Hedging ל-Edge-ים . . . 

• אז Hedging, אני בכוונה . . . No pun intended.
• אז יש לך החל מ-Intel, שבאים ומנסים לפתח Software Stack לתוך ה-Chip-ים שלהם
• והיו להם הרבה מאוד ניסיונות כושלים בעבר להעלות Up the Stack . . .
• הם חושבים שהם יצליחו, אבל זה כיוון אחד.
• אז יצרני ה-Chip-ים - כולם מנסים לייצר, ליישר קו עם nVIDIA - כש-nVIDIA בעצם היו הראשונים שהלכו “Chip-to-Application”, או משהו כזה.
• אני לא זוכר בדיוק את הסלוגן שלהם, אבל הם עלו “Up the Stack” והם בנו ממש חבילה שהיא לא רק ה-Chip עצמו - היא ממש Optimized מהתוכנה
• לצורך העניין - “Kubernetes, עד ל-GPU”.
• ויש להם פלטפורמות שלמות - למכוניות, ל-Device-ים
• ויש להם Ecosystem שלם שהם בונים.
• אז יש את יצרני ה-Chip-ים - Intel וכיוצא בזה.
• יש יצרני חומרה - כמו Dell, כמו HP, IBM - שמתחילים להיכנס לדבר הזה
• ובעצם מוסיפים את ה-Layer של הניהול
• וכמובן אופטימיזציה (Optimization) ל-GPU
• והם באים יותר למקום “ניטרלי” -  כאילו באים להגיד “אנחנו עובדים עם כולם” . . . 
• “אנחנו נותנים לך General-Purpose Device”
• כמובן ששחקני ה-Cloud כבר שם מזמן, ברמה כזו או אחרת
• יש להם יתרון - וחיסרון.
• היתרון שלהם הוא שיש להם כבר את הביזור של ה-Datacenter-ים והם יודעים לעבוד עם הרבה מאוד Hardware.
• החיסרון הגדול הוא שיש רגישות מאוד גדולה לתחרות מהשחקני-ענן ביחידות-קצה
• כי זה ממש להיכנס ל-Business שלי ול-Data שלי וללקוחות שלי
• ולכן אני חושב . . .

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

• (נתי) הם מהווים איום מאוד גדול - לאותם סטארטאפים ויצרנים
• כי באותה מידה שהם נותנים פתרון - הם גם יכולים לייצר את הפתרון בעצמם . . .
• ולכן אני חושב, שפה תהיה כניסה של שחקנים חדשים, שייתנו פתרון יותר ניטרלי - והניטרליות תיהיה . . . 
• מי שייתן את המערכת היותר פתוחה - אני חושב שהוא זה שבסוף יזכה בנתח יחסית משמעותי בתוך המערכת הזאת.
• קצת דומה למה שקרה עם Datadog בעולם של Monitoring למשל, או Snowflake בעולם של Storage
• לא Storage, סליחה - בעולם של Data Warehouse.
• אז מי שיידע לפצח את הניטרליות הזאת ואת ה-Multi-Cloud  הזה, ולתת פתרון שהוא לא Bounded למישהו אחר - הוא כן יוכל לתפוס פה נתח משמעותי לדעתי.
• למרות ששחקני-Cloud, שבפירוש יהיה להם נתח לא קטן בתוך הדבר הזה . . . 
• אבל יהיו הרבה - עדיין, בשונה מה-Datacenter-ים -יקח זמן עד שהם ישתכנעו “להישען” על ה-Cloud
• כיצרן - שהם ישענו עליו בתוך הפתרון-קצה שלהם.

44:48 אז מה הולך בתעשייה היום?(רן) טוב, דרך אגב - אמרת שהיית בכנס בתחום, מה הכנס?

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

(רן) זה קשור ל-Universal Studios? אוקיי . . . 

• (נתי) כן, Universal Studios, בדיוק - ה-Entertainment Business שאנחנו מכירים.
• ושם, הרבה מהעיבוד הוא עיבוד-תמונה, ביחידות הקצה
• זאת אומרת, הם בעצם צריכים לעשות Streaming ב-Real-Time לתמונה - כדי לתת לך חוויה הוליסטית.
• ואז הם מייצרים סוג של חדרי-משחק כאלה, מנותקים פחות או יותר מהעולם
• זאת אומרת, זה ממש Air-Gap
• למי שלא מכיר את המושג Air-Gap - זה אומר שהוא לא מחובר לאינטרנט, והם צריכים לתת באמת יכולת של ניהול של הרבה מאוד Device-ים מהסוג הזה.
• אז זו אחת הדוגמאות.

• היו שם כמה עשרות של לקוחות כאלה - וזה היה מאוד מעניין לראות כמה דברים:
• אחד, זה כמה מהם בנה את הפתרון בעצמו - מה שאומר שחסרה השכבה הגנרית הזאת שדיברתי עליה . . . 
• כי היא איזשהו Void שקיים היום בשוק
• כמה לכולם התוצאה של הפתרון שהם בנו בעצמם - היא מאוד דומה . . . 
• זאת אומרת - זה רק מחזק את זה שיש פה איזה שכבה של “80% גנרי” - ו-20% שהוא ספציפי.
• וכולם נתקעים בבעיות - שאני חושב שעוד לא חשבו עליהן
• של איך באמת לוקחים את המשהו הזה שהם בנו - ומחברים אותו והופכים אותו למשהו שהוא מודרני Style-Cloud.
• אני חושב ששם אני רואה עדיין פער מאוד גדול בין סוג תעשיות מסוים
• למשל, ה-Manufacturing הוא Lagging behind
• האנרגיה - טיפה יותר
• ו-eCommerce - מאוד חושב Cloud כבר, ו-DevOps
• וממש אפשר לראות את ההבדלים בין התעשיות - באיך שכל אחד חושב על הבעיה ואיך הוא חושב על הפתרון
• כמה הוא חושב על זה - זה נקרא  . . . .כאילו, בין אחד עם Silos ממש
• ויש לו אנשי אופרציה, טכנאים שיושבים על הקצה ומחברים אותם ומחווטים אותם ואחראים על זה.
• לבין כאלה שאומרים “לא, לא - זה חלק מה-IT!”
• ואנחנו נמצאים באבולוציה הזאת  . . . 
• אני חושב שדי ברור המגמה - זאת אומרת, בסוף, כמו שנתתי את הדוגמה של ה-Consumers ומה שקרה לעולם ה-Consumers, יקרה גם בעולם ה-Enterprise.
• בסוף, כולם יהפכו להיות Device-ים דיגיטליים
• ובשנייה שזה דיגיטלי ו-Software-Driven, אז אנחנו נראה . . . . אין שום סיבה שלא ננהל אותם כמו תשתיות ענן רגילות.

47:30 סיכום(רן) בסדר גמור . . . אז סיכום קצר: אז דיברנו על Near Edge, Far Edge ו-Functional, נכון? . . . זה הרחוק ביותר . . . 

• (נתי) נכון.

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

• (נתי) נכון - ודיברנו על Cutting Edge, שזה מה שאני מקווה, רוב האנשים שמקשיבים לזה . . . .

(רן) על Hedging Edge!

• (נתי) על Hedging Edge גם, כן . . . ונחזור ל-Living in the Edge  . . . 
• [ובדיוק 20 שנה ל-Vulture Street ו-Rockin’ Rocks . . . .]
• שזה ישראל - ישראל 2023.

(רן) לחזור לחיות את החלום.
טוב, תודה רבה נתי! האזנה נעימה ותודה רבה לעופר פורר על התמלול!