פודקאסט מספר 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 . . . המשתמש צריך לאשר את כל הטוב זה?
- זה אכן נושא מאוד חם, והחברה כבר מימיה הראשונים עבדה בקו מחשבה שתאם את מה שאנחנו רואים היום (עם ה-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) עם ביצועים מדהימים.
- היינו צריכים גם לבחור Database, כי היה ברור ש-Database רלציוני הוא לא האבסטרציה המתאימה למה שאנחנו צריכים - אין שאילתות מורכבות ומצד שני יש דרישה ל-Write Throughput גבוה ו-Latency נמוך, אז חיפשנו מודל Key-Value שיאפשר יכולות כאלה.
- אז התחלתם לפני 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, וצריך סבלנות עם הגרסאות החדשות.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול
אין תגובות:
הוסף רשומת תגובה