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

פודקאסט מספר 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) עם ביצועים מדהימים.בזמנו רק 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, וצריך סבלנות עם הגרסאות החדשות.הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

פודקאסט מספר 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) עם ביצועים מדהימים.בזמנו רק 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, וצריך סבלנות עם הגרסאות החדשות.הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

פרק מספר 365 (מספר קוסמי!) של רברס עם פלטפורמה - קרבורטור מספר 26: אורי ורן מארחים את נתי שלום (היזם של חברת Cloudify) לשיחה התקופתית על קוד פתוח, עננים, תשתיות ואירועים מהתחום מהזמן האחרון.קצת רקע להיום: ב - 11 למרץ 2019 פורסמה הודעה של AWS על התאגדות משותפת עם מספר חברות (בינהן Expedia ו-Netflix), על מנת לקחת מוצר בשם Elastic Search (חברה שהיזם שלה ישראלי, תזכורת לפרק 362 עם אורי כהן, וגם התגובה של שי בנון המייסד) וליצור עבורו מודל הפצה חדש (Re-distribution), מה שמרעיד את אמות הסיפין בתחום ומעורר לא מעט שאלות.נתי גם אמר את זה קודם . . .הנושא הציף קודם כל את הבלבול שקיים סביב המודל העסקי של חברות קוד פתוח והאופן שבו הן מייצרות רווח - נכון עבור Elastic אבל באותה מידה גם עבור Redis או GitHub וכו’.כל המוצרים של החברות הללו מגיעים מחברות ממומנות ולמטרת רווח ישיר, בשונה למשל מפרויקט כמו Kubernetes, שגוגל מעודדת על מנת לעודד צריכה של Google Cloud (ומשם לייצר רווח “משני”).יש מספר דרכים לרווח ישיר ממוצר קוד פתוח - רישיון שימוש (Subscription license)שירות כ-SaaS (ותשלום לפי צריכה)שירות מנוהל (Managed Service) - דומה ל-SaaS, רק שיש אפשרות גם להריץ בעצמךתשלום על תמיכה ו-Extra Featuresנקודה עדינה, כי יש גבול דק שקל לעבור ולהפסיק להיות “באמת” קוד פתוח. כל ה-API למפתחים חייבים להיות פתוחים, אבל תחומים של Clustering או Security למשל כבר נחשבים כ”איזורי מוניטיזציה” - זה כבר לא POC או פיתוח אלא שימוש משמעותי שמצדיק תשלום.ההבדל המשמעותי לעומת “קוד סגור” הוא היחס שבין הספק ללקוח - צריך לשלם, אבל לא מיד ברגע שנוגעים במוצר אלא רק כשיש ערך ברור.חשוב לשים לב שגם צד הלקוח מעוניין הרבה פעמים בתשלום כלשהו עבור שימוש משמעותי - יוצר מחוייבות לתמיכה (או לפחות תחושה כזו) ואומר שיש מישהו מאחורי המוצר שיכול לתמוך במקרה הצורך.זו מערכת מבוססת אמון (Trust system) - ויש מגוון סוגי רשיונות שמגדירים מה מותר לעשות עם החלק הפתוח (החינמי)הרשיון “המתירני” ביותר נקרא Apache 2.0, שמאפשר כמעט הכל (כולל re-distribution) והרבה ארגונים משתמשים בו, גם מתוך חשש מרישיונות כמו GPL למשל, שאומר שאם מבצעים שינוי בקוד חייבים לשתף גם אותו (מה שעשוי להיות קשה לשליטה ובעייתי באופן כללי לארגונים גדולים).למיטבי לכת (ושמע) - היה פרק שלם גם על זה עם עו”ד(!) דביר גסנר (ב-2012, ועדיין), ועוד אחד על רשיונות קוד פתוח (פרק 211 מ-2014), וגם זהר זקס הרחיב על הנושא בפרק 317 על Zusammen. הרבה שיעורי בית.בשורה התחתונה - חברות פחדו ממצב בו מפתח בודד יעשה שימוש בקוד עם רישיון שמעבר ל-Apache 2.0 (או MIT License שהוא די מקביל) ויחייב את החברה לשיתוף שהיא לא יכולה לעמוד בו.השוני הגדול הוא בעיקר בזכויות ההפצה (Re-distribution) ושימוש כ-SaaS.העיקרון הבסיסי הוא שהפרויקטים הללו דורשים הרבה מאוד השקעה, חדשנות וטכנולגיה, ועומדות מאוריחהם חברות גדולות שבסופו של דבר צריכות מודל עסקי על מנת להתקיים ולהרוויח (ולהנפיק…).לא צריכה להיות סתירה בין זה לבין טובת המשתמש, שעדיין נהנה ממוצר באיכות מאוד גבוהה בחלק הפתוחשונה מפרוייקטים שמבוססים לחלוטין על  תרומות קוד של משתמשים, מה שעובד לרוב רק כשיש חברות שמאגדות את הפרוייקט על מנת להפיק ערך באופן אחר (שוב - דוגמת Kubernetes ו-Google).אז בחזרה לשאלה המקורית -  למה רעדו אמות הסיפין?המרכיב הראשון הוא עניין האמון - ברגע שיש שימוש משמעותי במוצר צריך להתחיל לשלם. מה זה “משמעותי”? בדיוק . . .אם אני עושה שימוש משמעותי בקוד הפתוח, אבל גם מאפשר להשתמש בו בחינם (או לקבל תמיכה בחינם וכו’), נוצרת פגיעה בחברה שפיתחה את הקוד, ולא נהנית מרווח בשלב בו הוא הופך ”לגיטימי”אם נוסף על כך את העובדה שזה קורה בפרויקט שבו לא תרמתי למוצר מלכתחילה, ורק אפשרתי שימוש משמעותי בחינם - נוצר משבר אמון עמוק.אז AWS.משמעות ההודעה של AWS היא שעבור מוצרי קוד פתוח שהם לא באמת תרמו לפיתוחם, הם חותכים את קווי המוניטיזציה - על מנת להנות מהשימוש הרב בהם (להנות מהרווח הנגזר מהשוק שגדל, בלי להשקיע בשלב הראשון של יצירת ופיתוח השוק).נותנים שירות ותמיכה לחלק החינמי של השירות - ובפועל מתחרים בחברה המפתחת על התמיכה במוצר (החינמי) שלה, אותה תמיכה שהרווח הפוטנציאלי ממנה היה הבסיס והתמריץ לפיתוח.הדרך של החברה להגיע למשתמשים הייתה, למשל, לאפשר שירות במודל SaaS על התשתיות של AWS (שמרוויחה כבר בשלב הזה, אבל זה ממודל אחר), ולהרוויח מתמיכה. בשלב הזה נכנסת AWS שוב, ומתחרה בחברה המפתחת על תמיכה במוצר הקוד הפתוח שלה.מעבר ל- Elastic Search היו מקרים דומים גם עם MongoDB ו - Redis, וגם עם InfluxDB - שהגיבו ע”י שינוי מודל הרשיונות שלהן. יש הרבה דוגמאות כאלה עם AWS, שמאוד עקבית במדיניות הזו.התגובה הסטנדרטית של AWS במקרים כאלה היא שהם רוצים לתת שירות טוב יותר למשתמשים - ועבור הלקוחות יש לכאורה שירות יותר טוב במחיר יותר נמוך.האם באמת יש כאן Win-Win? שאלה טובה, נחזור אליה.אז הכל היה כבר קודם - מה קרה עכשיו ששונה?נחזור לכותרת של הפוסט - “Keeping Open Source Open – Open Distro for Elasticsearch”נכתב ע”י Adrian Cockcroft, ארכיטקט Cloud ב-AWS, בעבר גם ב-Netflix, ביקר בארץ באמצע מרץ (Keynote speaker ב- AWS Summit 2019, אפשר גם להשלים בוידאו).מאז היו עוד פרסומים.נתפס כמעיין “הרצחת וגם ירשת?” . . . יש כאן  מתקפה על חברות הקוד הפתוח בטענה שהן לא באמת מספקות קוד פתוח (כי הן מרשות לעצמן לרצות להרוויח), והצגה של AWS ככזו (בזמן שרוב המוצרים שהיא מפתחת בעצמה אינם בקוד פתוח כלשהו).הטענות שעולות בפוסט הן ש-Elastic במשך הזמן הוסיפו סעיפים שהופכים את הקוד ללא באמת פתוח, יחד עם הדוגמא של Java (סיפור ה-End of Life מבחינת אורקל, כש-AWS “ראו את טובת המשתמשים” והחליטו להמשיך ולתמוך).בשורה התחתונה - לא רק לקחו “פרי בשל” של חברה אחרת, אלא גם הטיפו מוסר. אין כאן שום דבר לא חוקי, אבל נראה לא משהו בכלל.הסכנה לטווח הארוך היא פגיעה בשוק הקוד הפתוח לטווח הארוך - משקיעים מתחילים לשאול איך (ואם בכלל) אפשר למנוע מ-AWS לעשות מהלכים כאלה בעתיד?התשובה הפשוטה - להשתמש ברשיונות פחות פתוחיםרואים את זה כבר עם Elastic ועם MongoDB, שמתחילות להגן על עצמן מפני הפרות אמון כאלו, מה שהופך את הדיון לכללי יותר, עבור כלל התעשייה: איך בונים יחסים של Win-Win בין ספקי הקוד הפתוח לספקי תשתיות הענן (Cloud Providers)?האם הכיוון הוא חרם צרכנים? - מי בדיוק יחרים? . . .אם חברות הקוד הפתוח לא ישתמשו ב-AWS, הם יעשו את זה בעצמם. נראה ש-AWS מפסידה בעצמה כי ככל שיותר חברות קוד פתוח ישתמשו בתשתיות של AWS כך היא תרוויח.זו לא באמת שאלה של מי צודק, אלא שאלה של טובת הצרכן לנוכח ניגוד האינטרסים.שווה לשאול מה קורה עם מוצרים שאינם קוד פתוח - תוכנות Microsoft למשל.כאן ב-AWS ידעו למצוא מודלים של Win-Win עבור כל הצדדיםלכאורה ההבדל היחיד הוא שבמקרה של קוד פתוח יש פירצה משפטית (או מערכת מבוססת אמון) שמאפשרת לעקוף את זה, וניצלו אותה.יכול להיות שהדרך היא להסתכל באותה צורה גם על חברות קוד פתוח וגם על חברות “מסורתיות” (ראה מקרה Oracle).ההבדל הוא שבמקרה של קוד פתוח, AWS לכאורה מספקים את השירות בחינם (הם עדיין מרוויחים על התשתיות).כל זאת - בזמן שעל AWS רצים יותר שרתי Windows מכל מערכת אחרת (ע”פ Adrian Cockcroft ב-AWS Summit בתל אביב), וכולם מרוויחים יפה.בזמן שעל Azure רצים עם Linux . . .כל ההבדל הוא הפירצה, והיכולת לנצל אותה.אין משקיע שישקיע בחברה ללא כל סיכוי לרווח כלשהו. המודל אינו התנדבות מלאה (לא מודל בר-קיימא בכל אופן).זה בסדר להשתמש בקוד פתוח ולא לשלם, וזה אכן נכון ל-90% מהמשתמשים. השאלה מה קורה כשמגזימים.אם למשל Outbrain משתמשים ב-Hadoop בלי לשלם (לשימוש פנימי), זה כנראה בסדר - כי הם לא מוכרים את המוצר, ולא מתחרים ביצרן - וזה גם כנראה נלקח בחשבון במודל העסקי של היצרן.זה לא המקרה עם AWS, וזה ההבדל הגדול - זה לא שימוש פנימי אלא תחרות ביצרן: הצעה של חלקים גדולים מאותו שירות לאותו בסיס לקוחות, עם התשתיות האדירות של AWS ובלי הוצאות (וסיכוני) הפיתוח.המעניין הוא ש Adrian Cockcroft מתייחס לזה, וטוען ש-AWS עושה שירות טוב ליצרני הקוד הפתוח, בכך שהיא מעניקה מעיין “חותמת כשרות” למוצר (ותורמת לעלייה משמעותית בשימוש בו).צודק - החברות אכן לא נפגעו כלכלית בשורה התחתונה, לפחות כרגעפחות - אם כל ספקי הענן יתנהגו כמו AWS, חברות כבר ל יוכלו להיבנות על פי אותו מודל עסקי שעליו נבנו Elastic ודומיה (מי ישקיע בזה בכאלה תנאים?), והשוק יתייבש. בראייה ארוכת טווח זה כבר לא טוב גם למשתמשים של AWS.אם מסתכלים על חברות ענן באופן כללי, נראה שיש הבנה והכרה בערך של קוד פתוח - רואים את זה מ-Google כבר לאורך הרבה זמן, ו-Microsoft בשנים האחרונות (כולל הרכישה של GitHub), יחד עם מלחמת Android-IOS התמידיתבסך הכל, שנת 2018 הייתה טובה מבחינת ההכרה בערך חשיבות הקוד הפתוח - ההנפקה של Elastic, הרכישה של GitHub, הרכישה של Red Hat, ועוד.אין (או לפחות לא אמור להיות) קונפליקט בין הצורך של המשתמש לבין היות המוצר פתוח - אנחנו לא רוצים להינעל על ספק, ולא רוצים לעבוד עם קופסאות שחורות.יצא פרק קצת פוליטי (לכבוד הבחירות?!), אבל אנחנו אופטימיים  הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

רן, אלון, ודותן בפרק מספר 57 של באמפרס (364 למניין רברס עם פלטפורמה) - סקירה של טכנלוגיות ודברים מעניינים האחרון, נכון ל-1 באפריל 2019. מתחילים בגדול - מכירים CAP Theorem? ההנחה עד היום הייתה שבמערכות מבוזרות אי אפשר לשמור במקביל על Consistency, Availability  ו - Partition Tolerance, אלא לכל היותר על 2 מתוך ה-3 בו זמנית. עכשיו מגיעה תפנית בעלילה,  דווקא מכיוון הפיסיקה התיאורטית - מדענים פרסמו ניסוי מחשבתי, שאומר שבמידה וניתן לעבור את מהירות האור,  ניתן לשמור על שלושתם במקביל!כיוון מעניין, בעיקר מבחינת מחשוב קוונטימה זה אומר לגבי Spanner? לא צריך את כל השעונים האטומיים? . . . לא, צריך רק לעבור את מהירות האור וזהו.למתי מתוכנן? צריך לבדוק עם איינשטיין (לא של Salesforce - אלברט עצמו, כי אם כבר עוברים את מהירות האור יש מצב שאפשר לחזור אליו).בהמשך לזה - באמצעות ענן של Quantum Computing, ולמשך חלקיק שנייה, נראה שהצליחו להפריך את CAP Theorem, ובתהליך נוצרו חלקיקים חדשים, שזכו לשם CAPP - CAP Particles.המאיץ ב-CERN מכוייל עכשיו כדי לאתר את החלקיקים החדשים - העולם הפיסי מתחבר לעולם התוכנה, וזה כבר לא רק ניסוי מחשבתי. המודל העסקי של Google בסכנה (בחמישים השנים הקרובות)?חדשות מכיוון פייסבוק והתשתיות (להקה חדשה?) - למי שזכור את ה- HipHop compiler, שנכתב ב-Facebook ומקמפל קוד PHP ל ++ C (קוד מאוד מהיר) - אז עכשיו הוכרז על פרויקט חדש בשם HipContain.מבטיח תכונות חדשות כמו Security ו-Startup Time מהיר (sub-ms), מזכיר קצת את ה AWS Firecrackerאז יש Container Engine ב-PHP - נראה שלשם הולך העתיד, אין ספק.קצת חדשות מהארץ  - בזק מכריזים על התשובה שלהם ל-S3: שירות ענן חדש בשם B4 (אין קשר לסובארו) Bezeq is a Better Bang for the Buckלא ברור לגמרי לאן זה מכוון, כנראה בעיקר לשוק הבינלאומי - דותן ניסה וננעל כיוון שה-Region לא התאים, אלון ניסה עם VPN ודווקא כן עבד. לגידי גוב בטוח עובד.נראה שלבזק יש סכסוך כלשהו עם הרשויות האמריקאיות על רקע האמירה של הנשיא טראמפ על הכוונה לחוקק חוק שאוסר על אחסון מידע מחוץ לגבולות ארה”ב.הפתרון עשוי להיות ספינה עם קונטיינרים ועליהם הדאטה, כך שזה לא שייך לאף מדינה  - אחרי ספינות ההימורים והאלכוהול, עכשיו יווצר שוק של ספינות דאטה, רעיון מהפכני לכל הדעות.בהמשך לאייטם של רן על AWS שמאפשרים להשהות workload ב-EC2 (באמפרס 56) - הפיצ’ר הורחב, ומאפשר לעשות את זה לכל הענן.למה זה טוב? ניתן לממש ענן שומר שבת! הלקוח הראשון שמימש הם B&H, שעוצרים עם כניסת השבת ומחזירים את הענן מאותה נקודה בדיוק בצאת השבת.עובד עם לו”ז כללי, לא ממש עוקב אחרי הכוכבים - אינטגרציה פשוטה עם השירותים של Amazon, בלי צורך לשנות את הקוד (בדיוק רצה לולאות For? היא תעצור, ותמשיך מאותה נקודה בצאת השבת).רעיון לשיפור - להגדיר דרגות חומרה על פי ספירת כוכבים להגדרת מועד צאת השבת המדויק (API פשוט): יש כאלה שיסתפקו בשלושה כוכבים, ומי שבטח ירצה ללכת על בטוח ולא לחדש את הענן לפני שזוהו חמישה כוכבים, וכו’. נפנה לרב ונבדוק.אגב - זה לא רק לשבת: מתחילים לראות בלוגים שמדברים של מימוש אפשרי עבור Work-Life Balance: הפיתוח עוצר בשש בעבר וממשיך רק בבוקר. הימור שלנו - לא ירחק היום שבו האיחוד האירופאי יעביר חקיקה בנושא.פרויקט קוד פתוח חדש ומעניין, שהתחיל כפרויקט צד של יוצאי גוגל: מימוש מנוע חיפוש עם יכולות דומות לאילו של המנוע של גוגל (גם אם לא באותו Scale) - והכל ב-Bash (מעבר לדברים הבסיסיים שמותקנים על כל Linux).דוגמא מאלפת לאילו דברים יפים / נוראיים אפשר לעשות עם Bash.לא שימושי בשום צורה - לא ביצועים ולא Scale - ועדיין הוכחת יכולות מרשימה.סביר להניח שהתחיל כהתערבות בסגנון “אין מצב שאפשר לממש מנוע חיפוש ב-Bash” והרבה אלכוהול. . .עדיין בסביבת Google  - כנראה ש Kubernetes הוא ה Orchestration Engine הנפוץ בעולם, ועדין אחד הקשיים העיקריים של משתמשים חדשים הוא, ובכן - הגייה נכונה של השם . . .הרבה נוטים להגות Kubernetecs (קוברנטיקס, מקרה מתועד אפילו באחד הפרקים האחרונים כאן), כנראה שזה מתגלגל יותר טוב על הלשון.כמו כל חברה רצינית, בגוגל ביצעו Usability testing, והגיעו למסקנה שהקהל כנראה צודק ושהגיע הזמן לשנות את השם רשמית (משהו בסגנון “עגבניה היא ירק כי הציבור חושב ככה”) - מעכשיו יש לומר Kubernetecs, ותוך דור או שניים זה יהיה פשוט גם למי שכבר התרגל להגייה הקודמת.אבל זה לא סוף הסיפור - עכשיו צריך לשנות את הקוד בערך בכל העולם, ומסתמן שהקהילה מתפצלת בין אלו שיש להם זמן לזה ואלה שמעדיפים לא לשנותכל מי שלא מפחד לשנות ויש לו תשתית בדיקות מלאה עובר ל-Kubernetecs, ויש הרבה שממשיכים לתחזק סביבות עם Kubernetes. בהצלחה לכולם.ועוד תת פיצול - אלו שמדגישים את השינוי עם הדגשת ה-C החדש Kubernetecs - ואלו שלא.וכמובן שמישהו כבר מיהר וקנה את את הדומיין Kubernetic - נראה שצפה את השינוי אבל טעה באיות.מה כבר הבעיה לשנות את הקוד? ב-Go לא בעייה, ב-Rust לעומת זאת . . . תיכף נגיע לזה. לא קשה תיאורטית, אבל פרקטית זה יותר מורכב.ואם כבר חזרנו לויכוח העתיק של Rust vs. Go - יכול להיות שהידיעה הבאה תבטל את הויכוח: יש compiler מ-Go ל-Rust ולהיפך (Transpiler).יש את Rustiler שמקמפל Go to Rust ויש את Gopiler שמקמפל Rust to Go.במה זה כתוב? נשאיר כתרגיל לקורא . . . תבדקו לבד.תופעה מעניינת - כל מעבר כזה יוצר אופטימיזציה שמתבטאת בקובץ Binary קטן יותר בשפת היעד!גורר תופעה שבא אנשים משתמשים ב-Transpiler לכיווץ.אם מריצים המון פעמים (Go-Rust-Go-Rsut-…) נוצר Binary file בגודל 0kb.החוכמה היא לעצור רגע לפני ה-0, ולקבל את הקובץ המינימלי השימושי - פריצת דרך מדהימה.חדשות נוספות מעולם ה-Google AutoML (שאכזב קצת את אלון אבל בכל זאת נחמד) - עכשיו יש את ה-AutoCode:אין מה להשקיע בצורה שבה כתוב הקוד - רק צריך להכין משהו בסיסי, להעלות ל Google Functions (הגרסא של Google ל - Lambda של AWS), ומשם כבר יש אופטימיזציה לקוד יעיל, Bug-proof והרבה יותר הגיוני.יכול לקחת כמה דקות (תלוי בגודל הקוד ובלוגיקה), אבל עובד מעולה. גוגל מדברים על שכתוב של הקוד שלהם עם AI.מזכיר אייטם קודם שהיה כאן על כלי של פייסבוק לתיקון קוד אוטומטי (Getafix) - אבל לא בצורה הזו (כמו Lint למשל), כנראה שזו ההשראה. אפשר להירשם באתר ולחכות (כרגע על Alpha, לא זמין לכולם).וגם Angular 9 עומד לצאת - והפעם עם מהפכה תשתיתית: ה-Framework כולו עובר ל-Dart. כן.מבחינת ביצועים זה מטורף.התרגלתם לכתוב Frontend ב-JavaScript? כולם ככה - ועכשיו עוברים.כבר הספדנו את Dart כמה פעמים - ניסה להיכנס לדפדפנים, היה Transpiler ל-JavaScript, אבל באיזשהו שלב Google ירדו מזה ועברו ל Flutter - ועכשיו זה חוזר שוב.מעניין האם יהיה איחוד, עכשיו כשיש בסיס טכנולוגי אחיד - משהו בסגנון React Native מבוסס Angular עבור מובייל. גאוני - Flutter ו-Dart יחליפו סוף כל סוף את JavaScript ותיהיה שפה הגיונית.דרמה! שמעתם על המהומה סביב הגירושין של ג’ף בזוס? לא קשור ישירות אלינו ולא לרמת פודקאסט איכותי כמו רברסים, אבל אתם מוזמנים בכל זאת לעבור על המכתב המדהים של ג’ף בזוס, אבל בשורה התחתונה - הם מתגרשים, ומסתבר שהיה הסכם שבמקרה כזה צריך להחליט מה קורה עם Amazon ועם AWS.מסתבר שההחלטה היא לפצל את החברות - AWS עוברת לידי אשתו מקינזי, ו-Amazon נותרת אצל ג’ף.בתור ה-CEO החדשה של AWS, נראה שהמהלך הראשון של מקינזי יהיה להגדיל רווחיות ע”י העלאת מחירים (ופה זה כבר כן נוגע לרובנו).בתגובה - Amazon החליטה לרדת מהענן. כן.תכל’ס היא כנראה אף פעם לא הייתה שם לגמרי אף פעם - יש הרבה שירותים של Amazon שיושבים על הענן, אבל זה בעצם עוד לקוח Enterprise גדול של AWS עם מעבר איטי, שעכשיו עוצר ועוזב. לא יקרה ביום אחד אבל זה הכיוון.יש כבר כתבות שמדברות על פנייה של מארק צוקרברג לג’ף בזוס עם הצעה לארח את Amazon על הענן של פייסבוק, שעד עכשיו לא פתחו את שירותי הענן שלהם החוצה.ואיך לא - Werner Vogels מגיב בטוויטר (האייטם הקבוע בכל פרק של באמפרס) ואומר שהוא לא יודע על מה מדובר - הוא בחופשה על מנת לקדם את הליכי הגיור שלו ולא מכיר את הפרטים. נראה שהוא גם לא מרגיש בנוח עם זה על רקע תהליך הגיור ועשרת הדברות וכו’.האם קשור לענן שומר השבת? יש מצב ששווה להגיע אליו עם Pitch.וורנר מתארח ברברסים עם כיפה וציציות? כבר קרו דברים . . .חזרה מהצהוב לחדשות רציניות, והפעם בישראל -חיל האויר הישראלי עולה לענן: בעקבות הסטורית התקלות של מטוסי הF35 בארה״ב — פרויקט התוכנה היקר בעולם, הוחלט בחיל האויר הישראלי, כחלק מפרויקט ההשבחה, להעביר את כל השירותים החישוביים של המטוס לענן במקום על המטוס עצמו. לצורך כך נבנית תשתית תקשורת לווינית חדשנית שלא הייתה קיימת בעבר, כולל תשתיות P2P בין המטוסים (לא רק לווייני).חיל האויר כבר החל בגיוס של אנשי דאטה תחת הסיסמה: ״הטובים לדאטה״.מפקד חיל אויר בתגובה: ״הטייסים והטייסות שלנו יעידו שהמטוסים שלנו טסים מעל העננים ובין העננים כל הזמן. זה היה רק עניין של זמן עד שאנחנו נשים את המוח של המטוס גם בענן. אנחנו מאוד גאים להיות החלוצים בתחום.״אבחנה מעניינת - אם כבר המטוס בעננים זה לגמרי הגיוני שגם הדאטה יהיה שם, הלוקאליות הרבה יותר גבוהה וה-round-trip יותר נמוך: במקום לרדת לקרקע וחזרה נשארים בעננים.מדהים שזה נחשף ולא נשמר בסוד - כנראה מעיד על עד כמה PR חשוב על מנת להשיג את הכשרונות בתחום, אחרת לא רואים סיבה לפרסם משהו כל כך סודי וגדול.העתיד בעננים, וזה כנראה גם הרבה יותר מאובטח. צריך רק לשנות את השם לחיל האוויר והעננים והחלל. והירח.בשלב הבא - חברות מסחריות מפריחות כדורים פורחים עם ענן מחשוב בפנים?אז Data center שקוע בים כבר יש, Data Center ב-containers על אונייה זה אייטם טרי מהיום, ועכשיו אלון מציע כדורים פורחים. לכו על זה.זוכרים את עסקת GitHub - Microsoft? אז זה היה כנראה עניין של זמן, אבל עכשיו GitHub הורגת את אטום, ומעבירה את כל מפתחי אטום ל vscode. משיחה פנימית עולה, שכל המפתחים של אטום שעברו לפתח את vscode מחוייבים לעבוד בווינדוס 10 על… NotePad (!) לפחות כמה שעות בשבוע. מאוד תמוה, נשמע כמו סוג של עונש.מייקרוסופט בתגובה: ״אנחנו רוצים שירגישו את הכאב, וככה יעזרו לנו לבנות מוצר יותר טוב״אחד מהמפתחים בתגובה: ״סתם מתנכלים לנו כי היינו העורך היותר טוב״.מייקרוסופט כנראה צודקים - אם הם לא יפתחו על Win10 איך הם ילמדו? אמנם מדובר באנשים בוגרים, אבל זה רק כמה שעות, לא נורא. קנו אותם - שיתנהגו בהתאם.אולי עכשיו נראה NotePad משוכלל, וזה יהיה הדבר החדש - או שנבין מי הם משתמשי Win10.זה גם הסבר אפשרי לזינוק בגרף המתשמשים?חדשות ממלחמת וואטסאפ-טלגרם: לאחרונה טלגרם תפסה תאוצה ונגסה בשוק של וואטסאפ בגלל המודעות להצפנה וההייפ סביב הקריפטו. בתגובה, בשנה האחרונה וואטסאפ הקימה צוות מומחים שהצליח לפרוץ את ההצפנה של טלגרם וגם של וואטסאפ עצמה.היום וואטסאפ הודיעה גם על הפריצה החסרת תקדים - וגם על הפתרון: הם הולכים לתרגם את האנגלית קודם לנאוואחו (בדומה לצבא ארה”ב במלחמת העולם השנייה) ואז להצפין, מה שלטענתם יתן להם יתרון תחרותי ענק כי דוברי הנאוואחו האחרונים בעולם הם כיום עובדי וואטסאפ.מי אמר Job Security? מי מרים את הכפפה ועובר לרש”י?אולי זה הפתרון לשבירת ההצפנות ע”י מחשוב קוונטי? זה הזמן ללכת ל-npm וליצור חבילות קידוד מנאוואחו, הזדמנות מטורפת. רק לזכור להכין את ה-Backdoor.לינוס טורבלדס (Linus Torvalds) בארץ!תוך ההפסקה מלינוקס (והתקפי הזעם והחזרה בחצי כח), לינוס חוזר קצת שונה - והוא עושה טור בעולם עם סדנאות שליטה עצמית לגיקים -  ועכשיו גם בתל אביב!הכותרת של הסדנה: ״אין אנשים רעים. יש רק קוד רע״ברכות לקופיריייטר, יש מצב לאופנה של Bumper Stickers?מיקום הסדנאות עדיין לא פורסם - אולי במצפה רמון? או בגוגל קמפוס (Do no evil)?נטפליקס חוסכים עלויות - נטפליקס הודיעה שכדי לחסוך עליות ולמקסם רווחים הם עוברים לטורנטים. מהיום נטפליקס יפרסמו סרטים באתרי טורנטים רגילים, לצד הלא חוקיים. הפורמט החדש: A.Star.Is.Born.1080p-WEB-DL.Certified.2019-NETFLIXבפורום של נטפליקס אחד המשתמשים כתב — ״קליק אחד למעלה ואני מקבל את אותו סרט רק לא חוקי, אני לא מבין את הפואנטה, למה אני צריך לשלם בעוד אחרים יכולים לקבל תוכן גנוב?? זה לא פייר??״. נטפליקס הגיבו שהם מודעים לבעיה ולכן הוסיפו את המילה Certified בשם של הטורנטבנוסף - עד שימצא פתרון הם עוברים למודל מצפוני, שבו אנשים משלמים out of good will.לא צריך שרתים - Serverless עד הסוף, וחוסכים בעלויותהCFO הודיע לבורד — אל תזלזלו בטוב לב של אנשים. יש המון אנשים טובים בעולם.נאמר אף פעם ע”י אף CFO? הנה . . .בסופו של דבר זו פשוט הכרה אמיצה במציאותיש מלא מפתחים לגייס? אפשר להתחיל משהו . . .גוגל עוברת לירוק ובריא - גוגל הכריזה בכנס בריאות ותזונה בינ״ל שהיא תפסיק לקרוא לשמות של אנדרויד לפי סולם א״ב ממתקים — כלומר סולם שבו היא מתחילה באות A ועולה בא״ב האנגלי כאשר בעבר הקפידה לבחור שמות של ממתקים —  והיא עוברת לפירות וירקות, כדי לייצר וויב מוקדם לשינוי בריא, מתחילים מהתחלה.כבר יש לנו את השם של האנדרואיד הבא: Android Appleד”ש לטים אפלואחד אחרון - מונגו ידידינו מאבד המידע: חוקרים גילו שהוא אכן מאבד מידע, ועכשיו מדווחים על כלי AI שיודע לאבחן אובדן מידע מ-MongoDB ולשחזר אותוהחברה הודתה שהכלי עובד - והכריזה שאפשר לקבל החזר! לקיחת אחריות מבורכת.האם אפשר לשלב את המנוע בתוך MongoDB, ואז להפסיק לאבד מידע? יש מצב שהם עובדים על זההאיבוד והשחזור צריכים להיות מאוד מהירים בשביל זה (Eventual consistency זה לא, אבל גם משהו)לכל מי ששרד עד כאן - התאריך הוא 1 באפריל 2019, וכל הנאמר הינו המצאה פראית.שוב - נכון להקלטת הפרק. למציאות יש נטייה להתאים את עצמה לפעמים . . . פרקי 1 באפריל קודמים - 38, 47 . . . - המצאת שפות תכנות, תוכניות הגירה לבכירים בעולם התוכנה, Frameworks חדשניים ופיקטיבים לזמנם, וחלק פשוט הקדימו אותו.וכמובן שיש כנס! זה לא 1 באפריל  הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

Users want to see their data fast, immediately, now. Whether you’re working with an ORM or writing native SQL, you probably had a “scratching-my-head-trying-to-figure-out-why-this-query-is-so-slow” moment. The team at EverSQL analysed more than 30,000 SQL queries from thousands of different companies, to lay down the most common mistakes developers do when writing SQL queries. This talk will focus on writing SQL the right way, the fast way.MP3

When was the last time you wrote an algorithm to plan your diet? As programmers we do amazing things in our everyday job, but rarely do we use our knowledge at home. In this talk I will introduce genetic algorithms and share how I coded a genetic algorithm from scratch and used it to generate my weekly schedule and to create a smart diet planer. We will go through the different stages of the algorithm and understand how they affect the algorithm’s solutions. Let me show you a different side of genetic algorithms and you will discover a new way to solve your everyday problems.MP3