יום שבת, 27 באפריל 2019

367 Guilds at Outbrain

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



הפרק בחסות Wix Engineering (המנוע שמאחורי Wix ומשהו כמו 50% מהחברה), שהם גם ספונסרים של Reversim Summit 2019 (רמז, כן. שריינו תאריכים ובואו בהמוניכם).

  • דניאל שטרלניכט - בן 31, 10 שנים רשמית בעולם ה - Front-end (ועוד 10 לא רשמית, אם סופרים מהאתר הראשון בגיל 14); התחלה עם בלוג בשם עיצוב גרפי וטכנולוגיה (עדיין קיים, פחות פעיל), ועבודה בחברת WebsPlanet, משם ל - Conduit, משם ל -Outbrain, גיחה ל - Microsoft וחזרה ל-Outbrain בתפקיד Front End Guild Master.
  • גיא - בן 40, מפתח Back-end כבר למעלה מ-15 שנים, התחלה עם 9 שנים בחברת Schema (אופטימיזציה לרשתות סלולר, מסטודנט לארכיטקסט ראשי), ולאחר מכן כבר 7 שנים ב - Outbrain, היום כארכיטקסט ראשי ו - Back-end Guild Master.
  • ולמען הגילוי נאות - אורי, רועה-גילדות ו-CTO ב - Outbrain.

אז גילדות . . . רן נתקל לראשונה במונח דרך Spotify (לא כרשימת השמעה מומלצת - צמד הסרטונים המעולה שלהם מ-2014). מה זה? למה זה טוב? מי צריך את זה?
  • לפני שנדון במה זה, חשוב להבין מה הצורך - הנושא הפך ל”חם” כשהחברה הגיעה לסדר גודל של ~600 עובדים (מתוכם ~150 ב - Engineering).
    • 150 נשמע מוכר? קוראים לזה Dunbar number.
    • מעל גודל מסויים מתחילים להיווצר תת אירגונים, ובין ארגון לארגון נוצרים פערי ידע, דגשים שונים, תרבות פיתוח שונה וכיוצא בזאת, ונוצר צורך “ליישר” - גם ידע וגם תרבות.
    • גם במודל הקלאסי ש-Spotify הציגו יש מודל מטרציוני, שבו הגילדה מאחדת “מקצועות”, ובניצב אליה נמצאים ה-Squads, שמאוגדים סביב מוצר או KPI מסויים.
    • מבחינת כרונולוגיה של השראה, מעבר ל-Spotify יש בארץ את הדוגמא של Wix שמימשו את המודל, כך שהיה עם מי להתייעץ.
    • מלבד האיים הטכנולוגיים וחוסר שיתוף הידע, מבחוץ היה מאוד בולט שצוותים באופן כללי היו בטוחים שאצלם פנימה הכל מצויין, וכולם מסביב לא מבינים כלום ועושים הכל פחות טוב.
      • סקר Tech - Excellence פנימי שנערך על תפיסת ההתקדמות וההערכה הטכנולוגית של העובדים הראה באופן בולט בדיוק את זה - כל אחד היה בטוח שהצוות שלו מעולה וכולם מסביב, ובכן - פחות. זה הדליק נורה אדומה.
    • המחיר המיידי של מצב כזה הוא שמאוד קשה לדחוף משימות רוחביות (Cross-group) - ככל שזה תלוי “בצוות שלי” הכל עבד בסדר, אבל עבור שינויים ארגוניים רוחביים (החלפת מערכת Monitoring או Deployment, הפחתת תלות בספרייה שכולם משתמשים, וכו’) נתקענו. חסרו דרך או מנגנון, וראינו את הצורך בגילדות.

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

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

אז איך נראות גילדות ב-Outbrain?
  • ראשית, מבחינת הלוגיסטיקה - ההחלטה הראשונית היא להקצות זמן: 
    • 90% מהזמן של מפתח שייך לצוות ולפעילות השוטפת
    • 10% מוקדשים לגילדה, כשדניאל וגיא יכולים לתכנן אותם לצרכים רוחביים
      • חצי מהזמן הרוחבי הזה מוקצה לפעילות משותפת - אחת לשבועיים נפגשים להרצאות, סדנאות, שיתופי ידע מאירועים שונים וכדומה
      • חצי נוסף מוקדש ל”מילואים”. לפעמים זה יכול  Task Force שמורכב ממפתחים מכל מיני צוותים שעובדים על משימות לטובת הכלל, למשל - שינוי מבנה ה-repositories, עבודה על POC לטובת טכנולוגיה חדשה, או אפילו ראיונות למגוייסים חדשים.
    • נוסף על הפעילות השוטפת, הגילדה אחראית גם על הכשרות - כשמפתח מתחיל את הקריירה שלו ב-Outbrain הוא מתחיל ב-Boot camp, כשהגילדה היא זו שאחראית עליו - הכרת התשתיות ודרכי העבודה, וכמובן קבלת פידבק.
  • גילדות ה-Back end וה-Front-end עובדות דומה, וחשוב לשים לב לכך שהגילדות הן גלובאליות.
  • למשל - גילדת ה-front-end ערכה אירוע של “שולחנות עגולים” - קבוצות של 5-6 מפתחים עם אפליקציה שמגרילה נושא לשיחה - וכל אחד מביא את הצד שלו לדיון. אחרי רבע שעה מחליפים נושא ושוב.
  • דוגמא נוספת - אתגר ב-CSS: חלוקה לזוגות, כשהמטרה היא לממש לוגואים של חברות הי-טק ישראליות ב-CSS. יצא יפה, שוחרר ל-GitHub - והיום זמינים שם לוגואים של יותר מ-30 חברות.

האם כל עובד החברה שייך לגילדה? האם אפשר להיות משוייך ליותר מגילדה אחת? אילו סוגי גילדות יש בכלל?
  • בגדול, יש 3 גילדות רוחביות - Front-end, Back-end ו - Data Science.
  • ארגון ה-Product (ואנשי UX) מהווה מעיין גילדה נוספת.
  • אנשי Operations שייכים גם כן למעיין ארגון “אורגני”, כשארגון ה- Cloud Platform מכיל נציגים של גילדות ה-Front-end וה-Back-end.
  • ויש עוד חיות היברידיות מעניינות . . .
    • בין ה-Front-end וה-Back-end יש מפתחי full-stack, שעושים גם וגם; באופן דומה יש מפתחים בין ה-Back-end וה - Data Science ששותפים לשתי הגילדות.
    • בדר”כ יש גילדה מרכזית, דומיננטית, ולשנייה מגיעים מדי פעם כדי להתעדכן, להקשיב ולשתף ידע.
  • מה לגבי מנהלי הגילדות - יש עוד תפקידים במקביל?
    • גיא הוא גם הארכיטקט הראשי, ומנהל גם צוות של שעוסק בשיפור חווית המפתח (Developer Experience - יש אפילו חולצות!) - הרבה מתכתב עם גילדת ה-Front-end (משם צפות הבעיות…).
    • דניאל משקיע 100% מזמנו בגילדת ה-Front-end.

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

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

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

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

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

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

כשפוגשים אנשים שנתקלים בפעם הראשונה בחברה בנושא של גילדות - האם יש להם איזשהו A-ha Moment (או WTF . . .)?
  • תגובה אחת - וואו, זה חלום; תגובה שנייה - זה לוקסוס של עשירים לקחת את האנשים הכי טובים למשימות רוחביות . . .
  • לגבי “האנשים הכי טובים” - זו נקודה שהמנהלת HR ב-Outbrain העירה עליו שנקודת המפנה במלחמת העולם השניה עבור חיל האוויר האמריקאי הייתה כשהטייסים הכי טובים עברו לתפקידי הדרכה.
  • הגילדה היא מנגנון - למשל במקרה של גיא כארכיטקט ראשי, יש רצון ליצור במקביל ל-Top Down של הארכיטקטורה גם מנגנון Bottom-up של הדרכה, על מנת שהמפתחים ירגישו קשר וחיבור יותר רחב.

האם יש חפיפה עם גורמים חיצוניים לגילדות - מרצים חיצוניים? פרויקטים שנחשפו החוצה ואולי לא היו מבוצעים אחרת?

יש עוד תוצרים מעניינים לגילדות - 

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

הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

יום שני, 8 באפריל 2019

366 Clicktale, tech stack story

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

הפרק בחסות Next Insurance, שהם גם (במקרה) ספונסרים של Reversim Summit 2019 (שזה לא במקרה - שריינו תאריכים ובואו בהמוניכם).

  • שחר בן 40 מרמת גן, נשוי +2 - בתחום משנת 2000 ובארבע (וחצי) השנים האחרונות ב-Clicktale.
    • בשלוש השנים הראשונות ניהל את קבוצת ה-Back-end ובשנה וחצי האחרונות הוא ה-CTO של החברה.
  • חברת Clicktale נוסדה בשנת 2006 ע”י ד”ר טל שוורץ (ממייסדי מרכז היזמות של הטכניון והמרצה המיתולוגי של קורס הייזמות) ואריק יבילביץ’ (שהיה סטודנט בטכניון), על בסיס הרעיון שניתן “להקליט” את מה שמשתמשים עושים באתרים (את הקוד או את ה-Events ואת הבחירות) ולהשתמש בזה
    • למשל - “לנגן” וכביכול “לעמוד מאחורי הכתף” של המשתמש, ואז לנתח התנהגות של אלפי משתמשים כאלה יחד ולראות מה עובד יותר או פחות.
    • מכאן - התפתחות לאנליטיקות, דו”חות וניתוחים מתקדמים.
    • השירות ניתן כ-SaaS, אין Agent on premise שאוסף נתונים על השרתים של הלקוחות, אלא Tag -  האתר המארח מוסיף את קוד ה-JavaScript שעושה מעיין Bootstrapping לעצמו ומוריד את כל שאר הקבצים שצריך, מייצר Hooks לכל ה-Events שצריך על ה-Client ושולח את הנתונים (בצורה מדודה ומכווצת) לשרתים של Clicktale לעיבוד.
    • רגע! התראת Privacy slightly smiling face  . . . המשתמש צריך לאשר את כל הטוב זה?
      • זה אכן נושא מאוד חם, והחברה כבר מימיה הראשונים עבדה בקו מחשבה שתאם את מה שאנחנו רואים היום (עם ה-GDPR למשל), ומקפידה למחוק מאפיינים של משתמש הקצה הספציפי - להתמקד רק במה שהמשתמש רצה ועשה ולא במי הוא בדיוק.
      • הדוחות הסופיים הם סטטיסטיים, עבור KPI מוגדר - השימוש הקלאסי הוא לקחת פלחים מוגדרים (Segments)  וגנריים, ולהמשיך לפלח אותם לרמת דיוק שקיימת רק במוצר - משתמשים עם התנהגות שמצביעה על היסוס (Hesitation), מפות חום של אירועים שהסתיימו ב-Conversion לעומת כאלו שלא - ותוך זה להסיק מסקנות לשיפור ה-UI.
      • שיפורי Funnel למיניהם - אבל גם למשל שיפור של תהליך הזנת פרטים עבור חברת ביטוח או אתרים למימוש זכויות וכו’.
    • רק לשם ההדגשה - ההקלטה אינה של “וידאו” אלא של לוגיקת התנהגות המשתמש שעוברת בצורה דחוסה לניתוח, עם ה-HTML הספציפי שהמשתמש ראה וה-Events שקרו בזמן השימוש הספציפי.
    • המידע טקסטואלי ועובד עיבוד - במוצר יש “נגן” שמציג את הנתונים כמעיין וידאו (מאפשר לנתח ולהתקדם או לחזור), אבל זו אינה הקלטה אלא הצגה של “סיפור דרך”.

אחד הנושאים שעלו כפוטנציאל לשיחה בהכנה לפרק היה נושא ההתמודדות עם מגוון הדפדפנים וה-Events השונים. זה לא הולך לקרות בפרק הזה.
מה כן? נתמקד ב-Stack הטכנולוגי שבו עובדים ב-Clicktale.
  • החברה נוסדה ב-2006 - האפשרות הנגישה ביותר הייתה לעבוד עם NET. ועם #C (רפרנס מתחייב לחומוס מניפסטו של מייקל אייזנברג) - הכל היה בסביבת Microsoft (למעט אולי RabbitMQ - מוצר ישראלי אגב).
    • המוצר התחיל כמעיין Freemium והתפתח לסדר גודל של עשרות אלפי לקוחות (SMB).
    • השלב הבא היה עבודה מול סדרי גודל של Enterprise - וכאן נכנסו שיקולים כמו SLA של השרת מול הדפדפן של הלקוח, Up-time וזמינות של המערכת (היכן שאסור להחזיר הודעות שגיאה), רמות אבטחה הרבה יותר מחמירות וכו’ - כמו גם צידוק כלכלי למבט אל מחוץ לעולמות של Microsoft - והעלויות הנלוות אליהם עם המכפלות הגדולות של השרתים.
    • מבחינת כמות אנשים - בשלב הזה היו בחברה סביב 100-120 עובדים (30-40 ב-R&D), ומבחינת שרתים מרכזיים סדר גודל של 40 (אולי לא נשמע הרבה, אבל הארכיטקטורה הייתה מונוליטית, והיה צריך פחות או יותר את השרת הכי גדול ש-IBM הסכימו למכור באותו רגע). 
      • זה כמובן השתנה משמעותית במעבר לענן (עם מאות ואלפי שרתים).
  • אז ההחלטה לשנות את ה-Stack הטכנולוגי מובנת אבל כמובן שלא פשוטה - איך זה קרה?
    • הכל התחיל עוד לפני שיפתח הגיע, ולא בהכרח בצורה פורמאלית קלאסית (Steering committee וכו’) אלא יותר יחד עם הצורך - עם לקוחות כל כך גדולים, חייבים להפריד מהמונוליט לפחות את רכיבי ה- Data pipeline כדי להתמודד עם ה-Spikes.
      • בשלב הזה גם העלות של עבודה עם Microsoft באה לידי ביטוי לא רק כעלויות ישירות אלא גם בזמני תגובה ואיתחול של מכונות Windows, מעבר לתשלום הכספי המיידי.
      • אפשר לפרק את המונוליט גם בסביבת Microsoft ועם NET. - אבל אז עדיין נתקלים במחסום העלות כשצריך לשלם על כל שרת בנפרד, וזה כבר לא משתלם (שוב - גם בזמני אתחול, up time, עדכונים . . .).
      • עוד גורם - מבחינת Web Server ו-SLA של זמני תגובה, כבר הגענו לעשרות mS של זמן תגובה, ועבור לקוחות גדולים זה מתחיל להיות יותר מדי.
    • האם מדובר רק במעבר טכנולוגי או בשינוי של ארכיטקטורת המערכת?
      • גם וגם - בשלבים הראשונים היה ניסון לפרק את הקיים “ולחקות” כל יחידה בפני עצמה, אבל ככל שהביזנס גדל היה צריך לשנות את הארכיטקטורה על מנת לעמוד בעומסים ולהתמודד עם צווארי הבקבוק שהתגלו, כמו גם בהרבה דרישות עסקיות חדשות שיותר קל להתאים אליהן מערכת מבוזרת לעומת מונוליט (מבודד שינויים, מקטין סיכונים).
  • סיכום ביניים - נקודת הזמן היא לפני כ-4.5 שנים עם ~120 עובדים מהם ~30 מפתחים, ~40 שרתים מפלצתיים ומונוליט מבוסס NET. וטכנולוגיות Microsoft ועם לקוחות שדורשים משהו שבנקודת הזמן הזו אי אפשר לתת - למה מחכים? אז מפרקים את המונוליט ומשנים טכנולוגיה . . . 
    • החלטה אמיצה. מה עכשיו?
    • השלב הראשון היה חשיבה על הארכיטקטורה - והיה ברור שהמקום להתחיל הוא ה-Data Pipeline. 
      • היה תהליך מקביל עם ה-Database האנליטי, שעבר מ-SQL Server ל-Vertica.
    • ההחלטה הייתה להתחיל עם Ingest - החלק שמקבל הודעות מה-Client (אחרי שגם את ספק ה-Cloud צריך לבחור) וצריך להעביר את המידע קדימה במינימום זמן.
    • היו הנחות בסיס שבאו מלמעלה (יפתח . . .), כמו הכוונה לעבוד עם Linux, אבל יש גם הרבה החלטות מעבר, כמו למשל - איזו שפת פיתוח?
      • ההנחייה הייתה לבחור משהו שיעבוד עם JVM, לאו דווקא ספציפית לכיוון Java אלא יותר מבחינת עושר הספריות הרלוונטיות - כשיש דרישה ל-Concurrency מאוד גבוה ו-Latency מאוד נמוך.
      • לשלב הגמר הגיעו Golang ו-Scala - שנבחרה לבסוף.
        • ההבנה הייתה שאם בוחרים ב-Golang ורוצים לממש את האלגוריתמיקה שלנו, עם עיבודים מורכבים על אלפי הקלטות, ב-Go - זה לא הולך לעבוד. 
      • זאת, לעומת Scala שאיפשרה את שני העולמות - כל מי שמפתח מעל Spark יודע כמה קל (ובמעט שורות קוד) יחסית לכתוב את האלגוריתם, ומצד ה-Concurrency יש גם את Akka (פלטרפורמה של Actor modeling שכתובה ב-Scala) עם ביצועים מדהימים.
        • בזמנו רק Boost הציג ביצועים טובים יותר, אבל זה גם היה מאלץ לכיוון כתיבה ב-++C, ולא רצינו ללכת לשם, אז בחרנו ב-Akka HTTP (מה שהיה אז Spray).
    • היינו צריכים גם לבחור Database, כי היה ברור ש-Database רלציוני הוא לא האבסטרציה המתאימה למה שאנחנו צריכים - אין שאילתות מורכבות ומצד שני יש דרישה ל-Write Throughput גבוה ו-Latency נמוך, אז חיפשנו מודל Key-Value שיאפשר יכולות כאלה.
      • בחרנו ב- Aerospike - מעיין Redis על SSD שמגיע לביצועים מאוד גבוהים ולא מאבד מידע במקרה (חלילה) שנופל השרת (לא שהם נופלים, אבל בכל זאת).
        • כיום גם Redis תומכים באותו הדבר, אז הבחירה היום עשויה להיות יותר מורכבת
        • בחרנו בגרסה בתשלום של Aerospike ולא בקוד הפתוח - מנהל ה-DevOps הגיע מעולם ה - Ad-Tech ש-Aerospike מאוד נפוץ בו, והוא מאוד העריך את התמיכה שלהם על סמך ניסיון העבר. החלטנו שזה שווה בשיקולי עלות-סיכון, ובדיעבד מרוצים מההחלטה.

  • אז התחלתם לפני 4.5 שנים עם החלק של ה Data Ingestion (הזרקת דאטה, יש מקומות שמכנים את זה Gateway - החלק שקולט את ה-Events מהלקוחות); בשלב הבא Data Processing (ובדרך שינוי Database) - ולאט לאט מפרקים את המונוליט ומשנים טכנולוגיה. האם המעבר שיטתי או שמתי שצריך לשכתב רכיב אז כבר עושים את זה ב-Scala?
    • עבדנו בצורה שיטתית - המעבר לענן בפני עצמו גורר שינויים טכנולוגיים רבים, וגם כחברה פיתחנו במקביל מוצר נוסף, משלים למוצר הראשי, וגם גדלנו מבחינת היקף הפעילות - כל זה אומר שהיינו צריכים להיות מאוד זהירים ושיטתיים, ועברנו לפי הרכיבים והעדיפות (היכן שהתועלת תיהיה המשמעותית ביותר).
  • בשלב הראשון צריך שכבת תאימות בין הקוד הישן (#C) לבין הקוד החדש
    • נקודה כאובה, כי הספריות ב-#C (יחד עם האהבה אליה כשפה) שאמורות לתקשר עם Aerospike או Kafka, או אפילו Avro - הכל לא סטנדרטי וצריך לפתוח Bug לפרוייקט (שאף אחד לא יתקן לעולם . . .)
    • הפקנו מכך הרבה לקחים - בהמשך העדפנו לשכתב רכיב ל-Scala (או Java) ולא לעבור את זה שוב
    • הרבה מזה נובע משימוש - יש יותר חברות שעובדות עם JVM ופחות עם NET., והמוטיבציה לתחזוקה של הספריות גבוהה יותר.
  • איך מתנהלים מול העובדים? הרבה מתכנתים חזקים ומנוסים, שעכשיו מזיזים להם את הגבינה (ומישהו צעיר בצוות יכול פתאום להכנס הרבה יותר מהר ולקחת להם את המקום)
    • התהליך היה משותף, אנשים ראו את היתרונות (וגם את הסעיפים החדשים ב-LinkedIn שיהיו להם שימושיים לקריירה . . .).
      • הפידבקים על הקורס “מבוא ל-Scala” שארגנו היו לא משהו, לא כי המרצה לא היה טוב אלא כי החבר’ה כבר למדו לבד ועברו את שלב המתחילים. 
      • קיבלו פיצוי בדמות קורס מתקדם של Akka, ושם הם כבר קיבלו הרבה ערך מוסף.
  • בחברות יש מפתחים שעובדים על ה-Business Logic, וגם את אנשי התשתיות (הפיסיות) שתומכים בהם - איפה הם היו בתהליך?
    • מבחינת תשתיות תוכנה - לא היינו מספיק גדולים בשביל להקדיש צוות רק לתשתיות, אז אלו בעצם אותם אנשים.
    • יחד עם זאת - יש את צד ה- DevOps והפלטרפורמה שעליה רצים, וכאן כמובן היה שינוי ותהליך למידה אולי אפילו יותר קיצוני, עם עושר טכנולוגיות שהם היו צריכים ללמוד.
      • כמה שניסינו לצמצם את ה - Stack הטכנולוגי, עדיין איכשהו על כל טכנולוגיה בעולם הפיתוח צריך 3-4 בעולמות ה - DevOps.
      • זה אחד מיתרונות המקצוע - דורש הבנה של המון טכנולוגיות והמון שינויים.
  • התחלנו עם בערך 12 אנשים בקבוצה, ובהמשך התהליך כבר גדלנו ל - 24-25, כשהגיוסים החדשים כבר היו של אנשים שמכירים את הטכנולוגיות החדשות והוסיפו ניסיון.
    • מעיד בדיעבד גם על נכונות הבחירה והכיוון, כי בשוק יש הרבה חברות שעובדות באותו Ecosystem, מה שתמך במעבר ואפשר את “ייבוא” הניסיון מבחוץ.

אז איפה אתם היום?
  • מבחינת גודל החברה - ב - Slack יש 220-230 אנשים, הרוב בישראל ויש גם בארה”ב ובאירופה (בעיקר אנליסטים, מכירות וכו’).
    • גוף ה - R&D כבר בסדר גודל של 60-70.
  • מבחינת Data - כבר עברנו את רף ה - Petabyte (אזהרת אנכרוניזם - מי ששומע את הפרק כמה שנים אחרי ההקלטה כנראה יגחך) - גם האנליטי וגם מה שמשמש לדוחות.
  • מבחינת Throughput - ה - Pipelines כבר יודעים לטפל במעל 10Tb לשעה, ואפשר להגיע להרבה יותר (לא נדרשנו מעבר לזה בינתיים).
  • מבחינת לקוחות - ירדנו לחלוטין מאלפי ה - Freemium לסוגיו, ועובדים עם סדר גודל של כ - 250 ארגונים (Enterprise), שכל אחד הוא שם גדול כלשהו.
  • מבחינת שרתים, הכל אלסטי אז זה משתנה - בשיא מגיעים לכמה אלפי שרתים, בשפל מדובר בכמה מאות.
    • הנטייה היא להשתמש ב - Instances קטנים (רצים על AWS), גם על מנת לחסוך בעלויות.
  • מבחינת SLA שהלקוחות דורשים - עם Spray Web Server ה - Latency הממוצע הוא סביב 1-2ms, ו -  Aerospike מאפשר פחות מ - 1ms בכתיבה.

משיחות עם מפתחים שעובדים היום ב - Scala, יש תחושה שהשפה קצת “נרדמה” - האם שוב מדגדג לבחון שינוי?
  • מי אמר Golang?!
  • אצל המפתחים יש דיונים בנושא, ויש כאלה שמשחקים עם Clojure או Lisp - כחלק מהנטייה הטבעית של מפתחים לחפש את מה שמעניין וחדש.
  • מנקודת המבט של שחר - האם חסר משהו? לא נראה ש - Scala הלכה לאחור מבחינת מענה לצרכים, כרגע זה בעיקר נושא לשיחות בארוחות צהריים.

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

ועכשיו - טיפים של אלופים! אם מסתכלים על חברה עם כמה עשרות מפתחים, מה (בראייה לאחור) כדאי לעשות?
  • להקפיד על Monitoring ו - Alerting - להבין איך בדיוק המערכות עובדות, כי גם אם עשיתם בדיקות עומסים, ב - Production זה יראה אחרת.
    • ה - Data בשלב ה Production לעולם יהיה שונה ממה שניתן לערוך עבורו סימולציה (ההתנהגות דינמית ויש המון פרמוטציות) - חייבים למדוד.
    • הרצה Side-by-Side, ומעבר מדורג לטכנולוגיה החדשה כשרואים שהכל יציב.
    • קרה שחזרתם אחורה? לא זכור משהו ספציפי, דווקא עם Kafka שמאוד נפוץ וברור יחסית - כשהיו בחירות לא צפויות פתאום קרו דברים שלא צפינו, ולפעמים גם חזרנו אחורה עם חלק מהקונפיגורציות.
  • להכיר את ה - Data . . . כל מקרי הקיצון, כל סוגי המידע שיכולים להגיע לשדות השונים, מה יכול להגיע חסר, היחסים בין חלקי מידע, השפעות על חלקים אחרים במערכת (גם שלושה שלבים לאחר מכן).
  • אל תסמכו על אף אחד או על מה שקראתם בבלוגים . . . ה - Spec לפעמים משקר
    • לפעמים הופתענו לטובה ולפעמים לרעה, כשלא ברור איך הגיעו לתוצאות הללו - POC זה לא השתחזר. . . ).
    • מקרה חיובי - Spray, שאיתו הצלחנו להוציא יותר מ - 10K בקשות לשניייה, עם ליבה בודדת של CPU, לאחר שממה שקראנו הציפינו להרבה פחות.
  • טיפ כללי - כשבוחרים טכנולוגיות, חשוב להתרכז במשהו חדש, אבל לשים לב אולי לא בהכרח להכי חדש, כי כן צריך Scale מסויים שיבטיח שמספיק אנשים “התגלחו” קודם על הטכנולוגיה.
    • לדוגמא - חברה גדולה יכולה להחזיק מומחה Angular, לחברות יותר קטנות לא תמיד יש את הפריבילגיה למעטפת שיכולה להתמודד עם ה - Disruption, וצריך סבלנות עם הגרסאות החדשות.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול