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

יום ראשון, 7 באפריל 2019

365 Carburetor 26 - open source politics

פרק מספר 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 (או MIT License שהוא די מקביל) ויחייב את החברה לשיתוף שהיא לא יכולה לעמוד בו.
    • השוני הגדול הוא בעיקר בזכויות ההפצה (Re-distribution) ושימוש כ-SaaS.
  • העיקרון הבסיסי הוא שהפרויקטים הללו דורשים הרבה מאוד השקעה, חדשנות וטכנולגיה, ועומדות מאוריחהם חברות גדולות שבסופו של דבר צריכות מודל עסקי על מנת להתקיים ולהרוויח (ולהנפיק…).
    • לא צריכה להיות סתירה בין זה לבין טובת המשתמש, שעדיין נהנה ממוצר באיכות מאוד גבוהה בחלק הפתוח
    • שונה מפרוייקטים שמבוססים לחלוטין על  תרומות קוד של משתמשים, מה שעובד לרוב רק כשיש חברות שמאגדות את הפרוייקט על מנת להפיק ערך באופן אחר (שוב - דוגמת Kubernetes ו-Google).

אז בחזרה לשאלה המקורית -  למה רעדו אמות הסיפין?
  • המרכיב הראשון הוא עניין האמון - ברגע שיש שימוש משמעותי במוצר צריך להתחיל לשלם. מה זה “משמעותי”? בדיוק . . .
    • אם אני עושה שימוש משמעותי בקוד הפתוח, אבל גם מאפשר להשתמש בו בחינם (או לקבל תמיכה בחינם וכו’), נוצרת פגיעה בחברה שפיתחה את הקוד, ולא נהנית מרווח בשלב בו הוא הופך ”לגיטימי”
    • אם נוסף על כך את העובדה שזה קורה בפרויקט שבו לא תרמתי למוצר מלכתחילה, ורק אפשרתי שימוש משמעותי בחינם - נוצר משבר אמון עמוק.
    • אז AWS.
  • משמעות ההודעה של AWS היא שעבור מוצרי קוד פתוח שהם לא באמת תרמו לפיתוחם, הם חותכים את קווי המוניטיזציה - על מנת להנות מהשימוש הרב בהם (להנות מהרווח הנגזר מהשוק שגדל, בלי להשקיע בשלב הראשון של יצירת ופיתוח השוק).
    • נותנים שירות ותמיכה לחלק החינמי של השירות - ובפועל מתחרים בחברה המפתחת על התמיכה במוצר (החינמי) שלה, אותה תמיכה שהרווח הפוטנציאלי ממנה היה הבסיס והתמריץ לפיתוח.
    • הדרך של החברה להגיע למשתמשים הייתה, למשל, לאפשר שירות במודל SaaS על התשתיות של AWS (שמרוויחה כבר בשלב הזה, אבל זה ממודל אחר), ולהרוויח מתמיכה. בשלב הזה נכנסת AWS שוב, ומתחרה בחברה המפתחת על תמיכה במוצר הקוד הפתוח שלה.
  • מעבר ל- Elastic Search היו מקרים דומים גם עם MongoDB ו - Redis, וגם עם InfluxDB - שהגיבו ע”י שינוי מודל הרשיונות שלהן. יש הרבה דוגמאות כאלה עם AWS, שמאוד עקבית במדיניות הזו.

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

אז הכל היה כבר קודם - מה קרה עכשיו ששונה?

  • הסכנה לטווח הארוך היא פגיעה בשוק הקוד הפתוח לטווח הארוך - משקיעים מתחילים לשאול איך (ואם בכלל) אפשר למנוע מ-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, ועוד.
    • אין (או לפחות לא אמור להיות) קונפליקט בין הצורך של המשתמש לבין היות המוצר פתוח - אנחנו לא רוצים להינעל על ספק, ולא רוצים לעבוד עם קופסאות שחורות.
יצא פרק קצת פוליטי (לכבוד הבחירות?!), אבל אנחנו אופטימיים slightly smiling face 

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