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

פרק מספר 67 של באמפרס (390 למניין רברס עם פלטפורמה) - רן, אלון ודותן נפגשים שוב ב-27 במאי 2020 אחרי מלא זמן ללא באמפרס - תקציר העונה הקודמת (Previously on Bumpers) - ארני חזר למולדת? תודה (שוב) לזהר זקס, הבאמפרס הקודם היה לרגל 1 באפריל למי שלא שם לב (המציאות הייתה אפילו יותר מוזרה מהרגיל מאז אז יש מצב שפיספסתם), וקצת אחרי הקלטת הפרק הקורונה תפסה גם בישראל, אז לקח זמן עד שהילדים חזרו לבתי הספר (בינתיים?) ואפשר לקבל כמה שעות שקטות ולהקליט.אז - באמפרס: רן, אלון ודותן עם סקירה של קצרצרים על טכנולוגיות ודברים מעניינים מהזמן האחרון (ולרגל הפער - אולי גם קצת יותר ותיקים יותר הפעם) - ספרים, פרוייקטים, Repos ב-GitHub וכו’ (פרס למתמידים עד הסוף - יש גם מצחיקים!)רן - נתחיל עם דו”ח ש GitLab פרסמו בשם The Future of Work is Remoteאולי היה פחות מעניין בשנה שעברה, אבל מאוד מעניין עכשיו בגלל התקופה, כי כולנו והתעשייה מסביב עובדים מהביתמה האינטרס מאחוריי היוזמה? GitLab היא חברה מבוזרת לחלוטין, למיטב ידעתי (רן) אין להם משרדים בכלל (או משהו ממש משני), ומבחינתם הם רוצים לבנות את עצמם כ”החברה המבוזרת”נכון שהם לא הראשונים, אבל הם ממתגים את עצמם כ”חברת ה-Remote” ורוצים להיתפס כ-Thought Leaders בתחום - אז יצרו את הסקר הזה, כשבגדול - התגליות אינן סופר מפתיעות אבל שווה לקרוא:המוטיבציה לעבודה מהבית - אם אולי בעבר המוטיבציה העיקרית לעבודה מרחוק הייתה היכולת להיות Digital Nomad - ללא בית, יכולת לעבוד מכל העולם, גם אם זה אומר לטוס לתאילנד, לשכב על החוף ולהמשיך לעבוד - היום המצב הוא לא כזה (לא בטוח שזה היה המצב גם בעבר, אל זו הייתה התדמית).באופן מפורש - רוב האנשים שעובדים מהבית עושים זאת בשביל הנוחות שלהם - יותר זמן עם המשפחה, פחות זמן על הכבישים, יותר זמן לספורט וכו’.לא מפתיע בטירוף - אנחנו שלושתינו (רן, דותן, אלון) בסיטואציה הזו (אולי פחות שוכבים על החוף בתאילנד, וגם אם היינו עושים את זה לא היינו אומרים . . .), אבל זה נחמד לראות את זה במספרים.הדבר השני שתפס את תשומת ליבי (רן) הוא מה שהם מכנים “Remote work levels the playing field”, ובעברית - שיוויון הזדמנויות.בהתחלה חשבתי שזה בסגנון “מי שגר בקריית שמונה ורוצה לעבוד בחברה שממוקמת בתל אביב, אז עכשיו הוא יכול וקודם לא ממש”, אבל הם מדברים על משהו אחר (אולי גם זה, אבל לא רק) - הם בעיקר מדברים על אנשים עם מוגבלויות מסוגים שונים - נכות פיסית, מוגבלות נפשית כלשהי, מחלה וכו’ - שעכשיו מרגישים שהרבה יותר קל להם להשתלב בחברה שהיא מבוזרת.לא נדרש ה-Commute, בבית הרבה יותר לתפקד, אולי יותר קשה במצבים חברתיים מסויימים שכאשר עובדים מרחוק יותר קל בהם - הם ממש ציינו מספר של 12% שמבחינתם זהו היתרון.דו”ח מעניין, יש עוד מלא סעיפים.ספרייה בשם Diagrams (או Diagram as Code) - ספריית Python 3 (רק 3) שמאפשרת לכם לכתוב קוד ב - Python, להריץ אותו - וזה מג’נרט (Generates) דיארגמה - ודיאגרמות די יפות.אפשר לבחור את ה-Theme (למשל AWS, או ארכיטקטורה) ואז יש כל מיני ספריות שיודעות לייצג את האלמנטים האלה בצורה יפה, ואתם למעשה כותבים קוד Python-י, שדי קל להבין אותו (ה-API עצמו הוא מאוד ב-High-level - אתם יוצרים Lists ו-Instances של Classes, אבל בסוף  זה הכל מאוד קריא) . . . מריצים - ונוצרת דיאגרמה.נחמד  וניתן להרחבה: אתם יכולים לכתוב ספריות משלכם עם אלמנטים משלכם, אם למשל חסר לכם אלמנט לדוגמא של GPU או Hard disc שלא קיים, אתם יכולים פשוט לצייר אותו בעצמכם (בהנחה שיש לכם את הכשרון) ולהוסיף את זה כמחלקה בתוך הכלי.בזמן האחרון יוצא לי הרבה מאוד להתעסק בנושאי Data Science ו-Machine Learning בשביל פרויקט שאני עובד עליו, והאייטמים הבאים הם מהאיזור הזה - סדרה של סרטונים די-קצרצרים ומאוד נחמדים, שמסבירים כל מיני אלמנטים ב - Data Science בצורה אינטואיטיבית ונחמדהדברים כמו K Nearest Neighbors או Confusion Matrix ו-K means clustering, וכו’זו סדרת סרטונים באורך של לא יותר מחש דקות כל אחד, כשכל וידאו מסביר את אחד ממושגי הייסוד בצורה ויזאולית, וזה נחמד אם אתם רוצים להיזכר או להכיר מושגים חדשים ברמה יחסית שטחית אבל מספיק טובה בשביל שיחה.זה לא שאתם עכשיו הולכים לממש K Nearest Neighbors לפי הוידאו, אבל זה מספיק טוב בשביל להכיר, והייתי ממליץ.החסרון היחיד - לדובר יש מבטא סיני כבד, ואעפ”י שזה באנגלית קצת קשה להבין; מצד שני יש כתוביות  אז אפשר גם לקרוא, ואחרי שמתרגלים לאנגלית שלו אז אפשר לגמרי להבין.מסתבר שיש אנשים (דור Y?) שעבורם להקשיב ולקרוא את הכתוביות במקביל עוזר להתרכז . . נסו.שני מאמרים שמהווים Intro עבור Framework בשם Keras - אחד ה-Frameworks הבולטים בעולם הזה, יש לו כמה מימושים (ואחד הבולטים בהם הוא של TensorFlow) - זה API שאומר “ככה אתם בונים מודלים של רשת נוירונים”, למיטב ידיעתי (רן) הוא עוסק רק ברשתות נוירונים אבל יכול להיות שיש עוד איזורים.החל מגרסא 2, TensorFlow יישר את עצמו לפי הממשק של Keras כשגם ל Pytorch יש גרסא ל-Keras וגם ל-Framework המקביל של Microsoft יש ממשק כזה (Databricks) - וניתקלתי בשני Tutorials נחמדים שמסבירים איך אפשר לעשות דברים ב-Kerasאחד מהם מגיע מהפרספקטיבה של Researcher: נניח שאתה צריך לממש שכבה מיוחד כלשהי במודל (למשל רשת נוירונים עם שכבה מאוד ספציפית ואלגוריתם מאוד מיוחד משלך) - המדריך הזה מלמד קצת על ה-Internals של Keras ואיך לכתוב Custom Code, בין אם זה Custom Layer או Custom metric או Loss Function וכל הדברים האלהה-Tutorial השני בא מפרספקטיבה של מהנדס: הוא רוצה להשתמש ב - Keras, בכלים הקיימים - לא לכתוב Components חדשים אלא להשתמש במה שקיים - והמדריך הזה בא ומראה בצורה מאוד יפה איך בתור מהנדס, Data Science Engineer, אתה יכול להתשמש ב- Keras.ואחרון בעניין הזה - המלצה על Weekly חדש שרן הצטרף אליו (וממנו הגיעו רוב הלינקים הקודמים) - אם אתם מתחום ה-Data Science ו-Machine Learning אתם אולי כבר מכירים ואם אתם רוצים להיכנס לתחום אז אני ממליץ על Data Science Weekly Newsletter, שזה ובכן - Weekly שמגיע כל שבוע עם קישורים, כמו הרבה אחרים - וערוך ברמה גבוהה.(אלון) משהו בקורונה הזה גרם לך לעבור להיות Data Scientist ולהתעסק הרבה ה-Python . . .(רן) זה התחיל קצת לפני הקורונה ולא קשור - אבל התחלתי לעסוק בעבודה בפרויקט שקשור לזה, ולעזור לצוות של Data Scientists להרים איזשהו פרוייקט - אז נכנסתי “לגוב האריות” והתחלתי ללמודקראתי גם ספר, שאני לא ממליץ עליו… אקרא עוד כמה ואז אדע על מה אני ממליץ(אלון) תכל’ס, באמפרס יותר מתאים לדברים שאתה לא רוצה להמליץ עליהם . . “זהירות! מהמורה! דלג!” (Bumpers Anti-Patterns Edition?)(רן) מה שקרה זה שהוצאת ספרים בשם Springer פרסמו בתחילת תקופת הקורונה הרבה מאוד מהספרים שלהם (שבדרך כלל מאוד יקרים) להורדה בחינם (לעותקים אלקטרוניים) - הורדתי משהו כמו 20 והתחלתי לקרוא (בינתיים אחד, אז יש עוד הרבה עבודה . . .), וחלק באמת בתחום של Data Science, לא כולם - וזה ספציפית ספר קצת “חלבי” ולא ממש מומלץ, כבר מסיים ועובד לספר הבא, אם תיהיה המלצה כמובן שנוסיף בחום.אז מכאן זה מגיע - בזמן האחרון יצא לי להתעסק הרבה בתחום של Data Science, עם Python ככלי, בעיקר כדי לעזור לאחד הפרויקטים שקורים אצלנו בעבודה.דותן - לפני שבוע או שבועיים יצא Deno . . . מישהו שמע?(רן) כן, כבר די הרבה זמן באוויר, Benjamin כתב על זה כמה פוסטיםאז 1.0 יצא לפני שבוע או שבועיים (13 במאי 2020)(אלון) רק שבועיים? מדברים על זה כבר שנתיים.(דותן) כן, אז עכשיו זה זה באמת 1.0, וכל הרשת התמלאה בכל מיני Hype מטורף של “לזרוק את Node ולעבור ל-Deno”, כמו הרבה פעמים שדברים כאלה קורים.(אלון) אז זה מה שצריך לעשות?(דותן) כן, המלצה חמה - זרוק ועבור. עכשיו תתחיל לתקן . . .אז Deno זה “Runtime ל-JavaScript”, זה ה-Tagline הפורמלי (ב-TypeScript), מהיוצר של Node.js שיצא משם, ישב בבית שנתיים ובנה לאט ובשקט (או ברעש) - וזה הגיע לגרסא 1.0.מה יצא? Runtime שבנוי ב-Rust, שיותר קל לעשות לו Maintenance, יותר Secure וכו’ - נראה שהוא לא עשה המון מהטעויות שהוא עשה בפעם הראשונה, לפחות ככה הוא מעיד . . .חזק לכיוון של TypeScript ומרגיש קצת כמו Go מבחינת ה-Dependency Management. עוד משהו (ואולי זה רק האלמנט של השעה . . .) - אני מרגיש שמבחינת Ecosystem ומודולים זה בכיוון של “ספרייה אחת טובה במקום עשר ספריות בינוניות”, שזה גם שינוי מרענן מ Node.js(אלון) חכה חכה . . . זה JavaScript(דותן) כן, אולי זה באמת עניין של השעה . . .(אלון) ברגע שזה הופך פופלארי מיד יש לך ארבע ספריות לכל דקה . . .(דותן) זה מאוד תלוי בקהילה שנוצרת - אם נוצרת קהילה בצורה מסויימת, אם לוקחים את Rust למשל, שם פחות מקובל שאם אתה רואה ספרייה קיימת אז מיד לשכפל אותה או לעשות משהו טיפה שונה שעושה בדיוק את אותו הדבר, פחות מסתכלים על זה בעין יפה.מה שקורה זה שאתה נכנס לעולם של Rust (כמו אח של ארני), שקיים כבר לא מעט שנים, ומחפש ספרייה שעושה Web Framework כלשהו ואתה מוצא 1-2 כאלה, שביניהן יש הבדל מאוד משמעותי גם ככה.זה מאוד נחמד, והאיכות בדרך כלל מאוד גבוהה(רן) היוצר הוא אגב Ryan Dahl . . . ולגבי ה-Ecosystem של החבילות - זה Pain-point שקיים כמעט בכל Ecosystem, בין אם זה Java או Python או Ruby וכו’מקום שבו זה יחסית יותר קל הוא מקום שבו יש “אבא חזק” כמו למשל ב - #C שאני מניח שאתם מכירים, אז שם יש קצת יותר בהירות כי אעפ”י שיש המון דברים בקוד פתוח, יש איזשהו Vendor אחד מרכזי שדוחף קדימה.מה שעושים ב-Go זה מעניין (הזכרת את הדמיון קודם) - אני לא זוכר אם יצא לנו לדבר על זה בפודקאסט, אבל יש אתר יחסית חדש (מהשנה האחרונה) שנקרא pkg.go.dev, שבא ורוצה “לעזור לך לבחור את החבילה הנכונה”.יש מלא חבילות ואתה תמיד יכול לגגל ולמצוא את ה HTTP Router שהכי מתאים לך, אבל איך תשווה ביניהם?  להרבה מהם יש פיצ’רים דומים ו-Performance דומה, והרבה מהם ברמת תחזוקה די קרובה . . . ואתה לא תמיד יודע בכלל מה להשוות (אילו פרמטרים).הם באים ונותנים איזשהו דירוג או Curation סוג-של-חצי-אוטומטי (לא יודע עד כמה) לכל החבילות, ואומרים “אתה מחפש Logger? אלו ה-Loggers שיש בדירוג הזה”, ועוזרים בכל הנושא של Discoverability של החבילות.אני חושב שתמיד יש את הדילמה כאשר אתה יוצר איזשהו Ecosystem - האם אתה רוצה  להיות ב”מודל Microsoft” שבו אתה מכתיב אילו חבילות קיימות ויש נגיד אחת טובה, או כמו שציינת (דותן) ב-Rust

פודקאסט מספר 389 של רברס עם פלטפורמה - אורי ורן מארחים באמצע מאי, עם סימנים חלקיים של חזרה לשיגרת קורונה (דמיינו סאונד של שיעול קל) ואחרי המון זמן חזרה באולפן בכרכור את רועי אושרוב, פרק שנקבע לפני המון זמן בעולם אחר של לפני הקורונה (עוד דחיית קורונה בקטנה) - והנושא קרוב לליבנו: דיברנו בעבר הרבה על Continuous Deployment וזה יהיה הנושא העיקרי להיום (וסביר שעוד כמה נושאים נוספים באיזור).קודם כל - רועי: חלק מהמאזינים כבר מכירים, עוקבים ב-Twitter, Twitch ו/או השתתפו ב-Meetup (יש את CD/XP Israel ואת R&D Leaders), ובכל זאת קצת רקע - אז רועי אושרוב - מתכנת, אב לשלושה בנים נמרצים (עוד מעט חוזרים ללימודים…)מתכנת מזה למעלה מ-20 שנה - התחלה (מקצועית) עם Visual Basic ומאז עוד כמה שפות (וכן - לפני 20 שנה זה כבר לא היה Cobol, פה זה המתקדמים . . .) - היו #C ו-Java ו-++C ו-Python ו-Ruby . . . בימים אלה נכנס חזק ל JavaScript.בארץ עזרתי להקים את קבוצת Agile-Israel- ה-User Group הראשון שהוקמה כבר לפני יותר מ-10 שנים (כשארכיטקטים ב-Microsoft צחקו על “המשוגע עם ה-Agile וה-TDD")כתבתי בזמנו ספר שנקרא The Art of Unit Testing, שבימים אלו אני מוציא את המהדורה השלישית שלו - אם הקודמים היו ב-#C אז החדש הוא כבר ב-JavaScriptגם כי כולם עובדים היום ב-JavaScript וזה קהל יעד מעניין - וגם כי רציתי קצת יותר ללמוד את עולם ה - Functional Programming וזה משהו ש-JavaScript (גם) מאפשרוזה גם מאוד מאתגר לנסות להעביר את העולם הזה לעולם החדש.המהדורה הראשונה וגם השנייה היו מבוססות #C - והשלישית היא בעצם Re-write כמעט שלם - אני כרגע בפרק הרביעי, ואנשים פשוט “קורעים” אותי עם ה-Reviews ואני לומד המון תוך כדי, זה ממש כיף.חשבתי שאני יודע JavaScript לפני כן, ועכשיו אני יודע כמה אני לא יודע - אומרים שאם אתה רוצה ללמוד משהו, תלמד אותו? אז בספרים הראשונים למדתי #C ובספר הזה אני לומד JavaScriptזה עולם יותר מסובך ויותר מאתגר - Multi-Paradigm: אם #C הוא Object-Oriented אז כאן גם Object וגם Model . . . מאוד מעניין.באיזשהו שלב נסעתי לחו”ל, Relocation לנורבגיה למשך 2-3 שניםהיה מאוד מעניין ומאתגר - עבדתי שם בתור יועץ.לאחר מכן נסענו ועבדתי בניו-ג’רזי, ומשם עברנו לקליפורניה - ולפני בערך שנתיים וחצי חזרנו לארץ (הילדים גדלו, והיינו צריכים לקבל החלטה של Fork או Merge בחזרה ל-Master . . .)עשיתם Unit Test  לפני כן? ה- Integration test היה לצאת ולראות האם אנחנו יכולים לחזור . . .אז חזרנו ומעכשיו עד סוף החיים יש את ה What-if? - חלק מהחוויות של ה-Relocation.המעבר לנורבגיה לא היה מטעם העבודה?לא . . . בזמנו היה לי בלוג וכתבתי את הספר והרצאתי בכנסים - וגם לימדתי בנורבגיה בערך פעם בחודש; זה הכניס הרבה מאוד כסף והיה מאוד כיף - ובאיזשהו שלב חשבתי על מה יקרה אם במקום שבוע בחודש אלמד ארבעה שבועות בחודש? . . .גם כסף וגם מקום נחמד . . .”אתה משוגע” . . . פרסמתי בבלוג שלי שאני מחפש עבודה בנורבגיה, יצרו איתי קשר מכמה חברות, מצאנו את החברה הנכונה לעבוד בה - ואז הגענו לנורבגיה והבנו שזו הייתה טעות כלכלית מטורפת . . .נורבגיה זה המקום השני הכי יקר בעולם - ואז הגיע החורף . . . היינו צריכים ללמוד איך לנהל שלושה ילדים בשלג, שבדר”כ יותר גבוה מהילדים: לקחת לבית ספר, להלביש, והכל בלי עזרת הורים ומשפחה מסביב - כיף גדול, ממליץ בחום (או בקור).זה היה אתגר שאני שמח שעשינו - למדנו המון על עצמנו בתור משפחה וגם על תרבות אחרת - אמנם גם שם עבדתי בהיי-טק, אבל כאן בארץ, כשאנחנו עובדים בתור מתכנתים אנחנו בתוך תרבות ישראלית, וכשאנחנו יוצאים מהארץ אנחנו בהרבה מקרים צריכים ללמוד חוקי התנהגות אחרים לגמרי - ולקח לי המון זמן ללמוד את החוקים האלה.התרבות הסקנדינבית ולאחר מכן התרבות האמריקאית, הפולטיקה של איך לשכנע אנשים, איך להגיד לא בלי להגיד לא, המון דברים מעניינים . . . אתגר מעניין ולמדתי המון, אפילו בלי קשר לטכנולוגיה.(אורי) לא רק להגיד לא בלי להגיד לא - זה איך לשמוע “לא” בלי שאומרים לך “לא” . . .(רועי) דווקא יש לי סיפור מצחיק על זה - כשגרתי בארה”ב, היה לי מנהל אמריקאי “עם הכפתור סגור עד החלק האחרון בחולצה”יום אחד הייתה לנו שיחה, ואחרי רבע שעה של שיחה, כשהרגשתי ממש טוב עם עצמי, הבנתי שהוא בעצם מנסה לתת לי פידבק שלילי, שעשיתי משהו לא בסדר.אחרי 20 דקות של שיחה, פתאום הייתי צריך לשאול אותו - רגע, אתה מנסה להגיד לי שעשיתי משהו לא בסדר?התשובה “באמריקאית” הייתה כמובן “אני לא חושב שהייתי אומר את זה ככה, אבל יכול להיות שיש אנשים שהיו קצת נפגעים . . . אבל עוד פעם, זה עניין של תרבות, לא בטוח, אני חושב שעשית את הדבר הנכון, אבל . . .”.בקיצור - הוא התכוון ל-”כן”, ולקח לי המון זמן ללמוד איך אנשים באמת מנסים לדבר בדרגות האלה, וזה קצת כמו ללמוד שפת תכנות, ללמוד את הניואנסים האלה.בהקשר הזה - הנורבגים הם יותר “קשים לקריאה” מהאמריקאים, או יותר קלים?הנורבגים יותר קלים, הם הרבה יותר Straight to the point - למרות שבהתחלה הם מאוד נחמדים ומחוייכים הם בסופו של דבר יותר סגורים, אבל הם יגידו לך אם הם חושבים שאתה טועה.הם עדיין יהיו מאוד עדינים - יחסית לישראלים זה הבדל מאוד גדול, ועדיין קשה (לנו) להבין אותם.אז הזכרנו על קצה המזלג את הנושא של Continuous Delivery -  יש שיגידו Continuous Deployment ואנחנו מנסים לפעמים להבין את ההבדל בין שניהם אז אולי ננסה לדבר גם על זה - למעשה, הנושא היה במרכז הפוקוס של לא מעט סטארטאפים לפני משהו כמו עשר שנים . . . בהמשך לשיחה מקדימה שעשינו, אני חושב שמה שמעניין באפיזודה הנוכחית זה שהיום זה כבר מעניין את כולם - לא מעניין רק את הסטארטאפים אלא גם את הארגונים הגדולים ביותראם יצא לך להאזין לאחת השיחות האחרונות שלנו עם נתי שלום פה בפודקאסט, הוא כינה את זה שם כמעיין "שרשרת אספקה” או “מערך ייצור” של חברות, כש-Contentious Delivery זה חלק בלתי נפרד מהדברים האלה, וחברות שלא ילמדו לעבוד עם ה-Flow המודרני הזה למעשה יכחדו - והוא לא מדבר על סטארטאפים, אלא על חברות מהגדולות ביותר בעולם, שהבינו את הנושא.אני (רן) מעריך שזה משהו שמעסיק אותך ביום יום . . .כן . . . אני אקדים ואגיד שכשחזרתי לארץ . . . אחד הדברים שעסקתי בו כשגרתי בארה”ב היה ייעוץ לארגונים מאוד גדולים בעולמות של Contentious Delivery ו - DevOps ו - Extreme Programming - ולמדתי לקחים, גם של מה אפשר או אי אפשר לעשות, איך לקדם שינויים ארגוניים מאוד מסובכים ברמה הבירוקרטית ועם המון בעיות - לא במקומות עם 50 אנשים אלא עם 50,000 עובדים.כשחזרתי לארץ, היו בערך 50,000 מיטאפים ישראליים - כשיש אחד על Python ואחד על Lambda ואחד על Semicolon, ואחד על Angular ואחד על פסיקים ועל נקודות . . .  אבל אין מיטאפ שמדבר או קהילה שמדברת על מה שמחבר בין הדברים האלה.יש מיטאפים על Agile, אבל מה שהצחיק אותי (עצוב, אבל בכל זאת) היה שכשדיברתי עם חלק מהאנשים בקהילת ה-Agile בישראל (שהשתנתה מאוד, חלק לטובה וחלק פחות) - חלק מהם אמרו, כשדיברתי איתם על Contentious Delivery, ש”זה לא אנחנו, אנחנו Agile”, מתוך איזושהי הנחת יסוד שכשמדברים על Agile Coaching או על Agile Consulting מדברים על התהליך ה Scrum-י או על SAFe וכל הדברים האלה - ו - Contentious Delivery זה חלק מהעולם של ה- Ops וה - Infrastructure וה - Pipelines . . .זו הבנה, לדעתי, שגויה לחלוטין של אחד מהדברים הבסיסיים ביותר של איך אנחנו אמורים לעבוד - השמן בגלגלים, מה שגורם לנו להיות אג’יליים, אלו אותם Engineering Practices, אותם מנהגים שבאים מלמטה, ובלעדיהם כל התהליך הזה מלמעלה הוא בסך הכל “עלים של ורדים שאתה מפזר על מיטה של קוצים” (מטאפורה נוראית, אני יודע, Work with me here . . .).אני (אורי) יכול מאוד להזדהות עם מה שאתה אומר, בכמה אספקטים - באיזשהו מקום Agile או Agile Practices - יכול להיות גם שיחד עם כמות חברות הייעוץ שיש סביב זה, נוצר המון Buzz מסביב ואלו בסוף Practices - אפשר ללמוד אותם, לתרגל אותם וכו’.כשמדברים על DevOps ו - Contentious Delivery ודברים כאלה - אז זה כבר משהו שצריך ליצור סביבו תרבות, זה לא רק “נעשה את הישיבה הזו ואת הישיבה הזו, נתעד ככה או נתעד אחרת”.(רועי) זה עוד יותר קשה - אתה ממש צריך לשנות התנהגות של אנשים(אורי) התנהגות של אנשים, תרבות ותפיסת עולם של מה חשוב, למי יש אחריות על מה והוא צריך לקחת את האחריות הזו - ויש פה הרבה עניין של Trust בהורדה של האחריות אל המפתח, ולא כל הנהלה יכולה לעשות את זה.(רועי) ואם ה-Trust הזה נלקח לפני שנים רבות על ידי איזשהו ארגון שהחליט לעבוד בצורה מסויימת, עשה מעיין “הפרדת רשויות” - והיום אנחנו נמצאים במצב שבו ארגונים מנסים לקחת חזרה את השליטה אבל אבל אנשים לא רוצים לתת את השליטה חזרה לפיתוח, כיוון ש”ככה לא עושים דברים” . . . למה “ככה לא עושים דברים”? “כי תמיד עשינו דברים בצורה אחרת”“למה עשינו דברים בצורה אחרת”? אף אחד כבר לא זוכר . . .(אורי) כן . . רן, אני לא יודע אם אתה מרגיש כמוני, אנחנו עשינו את הדברים האלה ב-2011 ב-Outbrain ביחד, עם הרבה דחיפה שלך (רן) למקום הזה, ומשם Outbrain ככה - ונראה לנו שככה העולם . . . אין כבר אנשים שלא עושים Contentious Delivery . . .(רועי) זה מה שאתם רואים . . .זה מה שאנחנו מרגישים - שזה כבר לא Novelty, ואם זה כל כך מושרש ומוטמע אצלנו אז כנראה שכבר כל העולם ככה, ואנחנו מופתעים לראות כמה זה לא ככה.(רועי) אני חושב שאתם חיים בסוג של בועה, אמנם מאוד טובה, שבה אתם נמצאים כמה שנים קדימה לעומת כל מיני ארגונים.הרבה ארגונים שאני עובד איתם, ובעצם כנראה יש כאן איזשהו עניין של הטייה כי בדרך כלל קוראים למישהו כמוני כשארגון לא מצליח בדברים האלה ולא כשהוא מצליח, אז אלו הארגונים שאני אראה . . .קוראים לי כשרוצים לכתוב Unit Tests טובים ויש Unit Tests ממש גרועים, או כשרוצים לעשות שינוי בתהליך של Contentious Delivery והתהליך לוקח חודשים ויש המון Bottlenecks באמצע - אלה החברות שאני רואה.מה שאני רואה זה שזה קיים בהמון חברות - כמעט בלי קשר לתעשייה שבה אנחנו נמצאים - ה - Patterns או ה Anti-Patterns שאני רואה כמעט תמיד קשורים לאנשים, כמעט אף פעם לא טכנולוגיים, הטכנולוגיה זה בעצם החלק הכי פשוט - ללמוד Kubernetes זה לא הבעיה שלנו . . .(אורי) Contentious Delivery ו - Contentious Deployment היו הרבה לפני Kubernetes (רועי) בוא נתחיל ככה - Extreme Programming, שלדעתי זה נושא שפעם היה והיום עומד לקבל במה בחזרה ובגדול, זו בעצם מתודלוגיה שהתחילה לדעתי באיזור 1996, והאדם שהביא אותה לעולם, לפחות מהזוית שלי , זה Kent Beck - הוא כתב ספר שנקרא Extreme Programming Explained וספר שנקרא Test Driven Development: By Example - שני ספרים שקראתי בזמנו ולמדתי מהם המון - הוא התחיל את העולם הזה.מכאן, Extreme Programming (או XP) מדבר על כל הדבר הזה - אחד מהם היה Contentious Integration, אחר הוא Test Driven Development וגם Pair Programming ו Refactoring ו - Shared Code Ownership - הרבה דברים שאנחנו היום רואים אנשים שמנסים לממש - הם באים מהעולם הזה.כשאתה (אורי) אומר “הדברים האלה לא חדשים” - אני מסכים איתך, הם לא חדשים, אבל להמון ארגונים הם חדשים כיוון שאותם ארגונים התחילו את הלמידה שלהם באותו Timeline שבו Scrum “ניצח” ו - SAFe “ניצח”, ואז מדברים רק על התהליכים החיצוניים שקיימים מעבר לרמת ה - Engineering של הצוות: יש איטרציות וכו’, אפילו Kanban ברמה כזו או אחרת - אבל אף אחד לא מדבר על מה קורה על מנת לגרום לדברים האלה לקרות.עכשיו Contentious Deployment התחיל לקבל איזושהי במה, כיוון שיש איזושהי הבנה שבלי הדברים האלה “שלמטה” אנחנו לא יכולים לקבל את הדברים “שלמעלה”.לצורך העניין - בלי Unit Testing או TDD, מאוד קשה לשבור דברים לחתיכות מאוד קטנות, וכשאני לא יכול לשבור דברים לחתיכות קטנות הם בחתיכות יותר גדולות, ואז לוקח לי יותר זמן לדלוור (Deliver) אותן, ואז האיטרציות לוקחות יותר זמן, ואז אני חייב איטרציות . . .מצד שני - אם אני שובר לחתיכות מספיק קטנות, אולי אני בכלל לא צריך איטרציות, אולי אני משלה את עצמי בתהליך הזה . . .יש המון דרכים לחשוב על זה, אבל אני מסכים איתך - זה לא חדשות, זה לא משהו שמישהו בא ואמר “חבר’ה, SRE זה הדבר!” . . . SRE זה שם קיים למשהו שקיים כבר הרבה זמן כמו ש DevOps זה משהו שקיים כבר הרבה זמן.לטעמי, הנושא של לקרוא למשהו “DevOps” זה סוג של Anti-Pattern . . .(אורי) DevOps זה “האנשים שהולכים ליותר מחמישה כנסים בשנה”, לא?(רועי) זה Anti-Pattern כי אנחנו קוראים DevOps, לצערי, לקטיגוריה של אנשים שפעם קראנו להם Integration או Infrastructure או Ops או Configuration Managers, וזה לחלוטין התחיל בתור משהו אחר - DevOps היה אמור להיות השם החדש למה ש Agile ניסה להיות, נגיד את זה ככה.היום ארגונים ו - Coaches ויועצים לקחו את זה לעולם שבו יש לי “אנשי DevOps” . . . ברגע שיש לך “אנשי DevOps”, התחלת להפסיד . . . הפרדת הרשויות מתחילה כבר בשם - “אני איש DevOps ואתה לא, אז אני עובד על ה - Pipeline ואתה לא”.(אורי) אני חושב שיש משהו שאני זוכר מההתחלה - רן, גם אתה היית שותף פעיל לדבר הזה - כשהחלטנו שהולכים על זה, כינסנו את כולם ואמרנו “חבר’ה, הנה התאריך - 20 ומשהו באוקטובר - זה התאריך שבו יוצאת הגרסא האחרונה של

פודקאסט מספר 388 של רברס עם פלטפורמה - הוקלט ב-24 למרץ 2020 (שבוע שני לחופשת הקרונה), רן “מארח” את שלומי נוח (כל אחד מהבית שלו, שומרים נגיעה).שלומי מגיע די הרבה ו(בין השאר) גם עובר על ארגון כנסי רברסים בשנתיים האחרונות (בוידאו מראים עכשיו את החולצה של הכנס, דמיינו).שלומי עבד עד לא מזמן ב-GitHub, שהיא חברה מבוזרת, ויצא לו הרבה פעמים גם לפני כן לעבוד מרחוק עם/בחברות מבוזרות - וזה הנושא של היום (בעולם בכלל).וכרגיל לפני הכל - קצת על שלומי:אני מפתח שנשאב לעולם ה-Databases (התחלת ספר מד”ב קלאסית), ועוסק בפיתוח בעולם הזה: Tools, Infrastructure, כותב הרבה Open Source.חלק גדול ממה שכתבתי נכתב מהבית - עבדתי בארבע השנים האחרונות ב-GitHub, שהיא חברת Remote-first, ששמה דגש מאוד חזק על עבודה מהבית, וגם לפני כן פה ושם חלקית או מלא מהבית בכל מיני סיטואציות ואופנים.היום אני בחופש, מבלה עם כל עם ישראל (והעולם) את ימי הקורונה בבית.יש בעולם אמנם חברות שבחרו לעבוד בצורה מבוזרת והן יודעות את התורה (אולי) - ועליהן אנחנו רוצים פחות לדבר היום.הרבה מאוד חברות, בעיקר בתחום שלנו אבל גם בתחומים אחרים נאלצות להתחיל לעבוד מרחוק - מה שדי נכפה עליהן. חלק רואים את זה כברכה, חלק כקללה - ועבור האחרונים אנחנו מנסים לעשות לימונדה מהלימון הזה, ושלומי בא לחלוק מהניסיון והידע שלו: טיפים, דרכי עבודה - איך אפשר לעבוד בצורה יעילה כשכל החברה מבוזרת.אתה צודק לגמרי (תמיד תשובה נכונה) - הרבה חברות פשוט אולצו לעבור לעבוד מהבית, בלי ניסיון קודם - לא של האנשים ולא של הארגון עצמו.החלק המעניין הוא שלנו, כמפתחים ועובדי היי-טק, יש את כל הכלים הנכונים לעבוד ב-Remote - אנחנו כבר עובדים עם Zoom או BlueJeans ועובדים עם Slack (או מה שלא תיהיה אפליקציית הצ’אט) ועוד כלים שנותנים את האופציה הזו - אבל זו תיהיה טעות לקחת את התרבות הארגונית הקיימת היום ורק לזרוק עליה את הכלים.שני דברים שארצה לדבר עליהם זה - כאוס תקשורותי (או: עומס יתר)יצירת Silos, שזה דבר שכולם (?) מודעים אליו - איך אנחנו מצליחים לתקשר ב-Remote ועדיין להיות מסוגלים לשתף את כל המידע.דוגמא אחת שאני ראיתי של “לקחת את דרכי התקשורת הרגילים במשרד ורק “להפוך אותם ל-Remote”, משהו בסגנון “חבר’ה - כל הפגישות אותו הדבר, רק עוברות ל-Zoom”: לא משתנה הלו”ז, לא משתנה מספר הנוכחים, סדר ההכנה או מה קורה לאחר מכן. הכל אותו הדבר, רק במקום להכנס לחדר ישיבות כולם נכנסים ל-Zoom. זו דוגמא אחת, ואני מניח שיש יותר קיצוניות - כמו הקישור הזה למייל שנשלח ע”י ה-Wall Street Journal . . מצאתי את זה בטוויטר של David Heinemeier Hansson, ה-CTO של Basecamp, שנמצא בעיצומה של מלחמת חורמה נגד חברות שיכולות לשלוח אנשים לעבוד מהבית ולא עושות את זה.למי שאין כוח לכל הפודקאסט של היום, אפשר לקחת את הציטוט הזה שנשלח לעובדי ה-WSJ - ולעשות ההיפך. כבר התחלתם טוב.בגדול, הבקשה היא להיות זמינים לחלוטין ל-Slack ול-Google Hangouts, עם מקסימום של מספר דקות מצומצם לתגובה (יש פינג - חייבים לענות תוך כמה דקות); יש להודיע למנהל בכל פעם שמתחילים ראיון או לוקחים הפסקה או נמצאים בפגישה או מה שזה לא יהיה; לשמור על הטלפון הנייד זמין בכל רגע נתון; ועוד פנינים.אני חושב אחרת, ומה שחשבתי הוא לנסות ולפרק את הראיון לכלים שיש לנו, ולדבר על כמה כלים שנכונים או לא נכונים ארגונית ואיך לדעתי כדאי להשתמש בהם.איזשהו Preview קצר לדברים עליהם נדבר - תקשורת כתובהתקשורת וידאוניהול של משימות שוטפות - Issues וכאלה, ואולי נגיע גם לדבר על טלפון (למי שעוד זוכר שיש גם פונקציה כזו במכשיר הנייד שלכם), או איך לא להשתמש בו.החלק הראשון - תקשורת כתובה, ובמיוחד Chat - גם אנחנו במשרד, כמו בהרבה חברות, תמיד משתמשים ב-Slack וזה לא חדש לנו. אבל - יכול להיות שכאשר כל החברה עוברת לעבוד באופן מבוזר, יש לשנות את האופן שבו משתמשים ב-Slack . . . נתחיל מזה.ל-Slack יש אכן את הפוטנציאל הכי גדול לבנייה - או להרס; כמות ה-Notifications שאנחנו יכולים לקבל היא הגדולה ביותר מבין כולן.רק בתור התחלה שווה להסביר למה Chat כל כך שונה במצב שבו אנחנו עובדים ב-Remote: אם כולנו יושבים במשרד ואתה (רן) רוצה לבוא אלי פיסית ולשאול שאלה, אתה יכול להגיע אלי, לראות שאני לא נמצא ולהבין שאני אולי בישיבה או משהו, אז אתה חוזר ואולי תבוא שוב אח”כ.אם אתה רואה שאני בדיוק בשיחה עם חברת צוות אחרת, אתה מבין שאני עסוק - אם זה ממש דחוף אז תידחף ואם לא שוב תחזור למקום שלך ותנסה מאוחר יותר.בצ’אט, אין את הנראות הזו - אם אני עכשיו פונה עכשיו למישהו, אני לא יודע מה בדיוק המצב שלו: אולי הוא כבר משוחח עם  מישהי אחרת? אולי הבנאדם כרגע מבשל ארוחת צהריים לילדים (כי כולנו כרגע נמצאים בסיטואציה הזו שהילדים בבית)? אולי בדיוק הגיע השליח מהסופר? אנחנו לא יודעים באיזו סיטואציה נמצא הבנאדם, ואולי הוא בכלל במצב שבו שלושה אנשים אחרים פונים אליו בצ’אט ברגע זה.אותו בנאדם יכול להימצא וירטואלית בכמה מקומות בזו זמנית - זה שעושים לי Ping לא אומר שאני פנוי עכשיו לענות לזה.חסרה למעשה “שפת גוף”? או פשוט איך “לקרוא את הסיטואציה”? מה האדם עכשיו עושה, אולי הוא מטפל במשבר Production סופר-קריטי או שהוא בדיוק יצא להפסקה - אתה לא יכול לראות.החוק הראשון של הצ’אט הוא לא ל-Private Pings - אני רואה הרבה שכשמישהו רוצה לדבר עם מישהו אחר, הוא פשוט עושה Ping בערוץ פרטי, ואני חושב שזה הדבר הראשון שצריך להסיר, מכמה סיבות - עומס - כשמגיע Ping “אישי”, אתה מרגיש מחוייב לבנאדם - וזה מגיע מכל מיני אנשים במקביל, כך שהכמות מכל הערוצים במקביל יכולה להיות מאוד גבוהה, וקשה לעקוב אחרי זה ולבקר את זה.ייצור Silos  - כל שיחה שמתנהלת בערוץ פרטי היא שיחה שסגורה לשניכם, ואי אפשר עכשיו להוסיף אנשים לשיחה (בדיעבד).זה גם לא נכון טכנית - אם אתה רוצה לשאול שאלה מקצועית, היא צריכה להישאל במקום שבו אולי מישהו אחר ירצה לענות או יוכל להרוויח מהתשובה גם כן, או לפתח דיון, ובערוץ פרטי זה לא קורה.(רן) לטעמי, אנשים שמדברים ב-Private נוטים גם להיות פחות ברורים ופחות פורמאליים, פחות להסביר את ה-Point of View ולשאול שאלות יותר פתוחות כמו “למה זה לא עובד לי” בלי לתת את ההקשר או “זוכר את מה שדיברנו עליו בשבוע שעבר? - זה לא עבד” וכאלהזה יוצר את העומס הקוגניטיבי של להבין על מה הבנאדם מדבר ואתה צריך לשאול עוד שאלות כדי להבין (“תעזרו לי לעזור לכם”), וזה נוטה לקרות יותר בערוצים פרטייםבערוצים פרטיים יש הרבה יותר “Round trips” - שיחה במתחילה ב”היי” (“היי” בחזרה”) ואז “אפשר לשאול אותך שאלה?” (“כן”) . . . כבר הפרעת לי פעמיים, אולי פשוט תשאל את השאלה, וכשאני אוכל להתפנות לזה אני אענה?אני פחות רואה מישהו בערוץ פומבי ששואל “היי, אפשר לשאול שאלה?” - זה לא יקרה (אם כי בערוצי ה-IRC של פעם היו מקרים…), או לפחות פחות קורה.גם כשאתה שואל שואל שאלה או רוצה לעדכן באופן כללי, בערוצים פומביים אנשים נוטים להיות יותר Self-contained, להסביר את עצמם ואת נקודת המבט שלהם (“ניסיתי את זה ואת זה ולא עבד, עכשיו אני תקוע, מי יכול לעזור?”).יש עוד שתי סיטואציות שבהן אנשים פונים בחדרים פרטיים - לפעמים מישהו רוצה לשאול שאלה שנראית לו אולי מעט טיפשית, והוא מעט נבוך לשאול בחדר פומבי, אז שואלים בפרטי.זה מובן ואנושי, גם ב-GitHub זה קרה.כמעט תמיד (אלא אם הרגשתי שזה באמת יביך את הפונה) החזרתי תשובה שאומרת “בבקשה שאל אותי בחזרה בערוץ של ה-Databases, זו שאלה מעניינת”.יכולתי לעשות את זה כיוון שהייתי בתפקיד בכיר, וכאן יש עניין תרבותי - אולי למישהו פחות בכיר יהיה לא נעים לענות ולבקש לפנות בערוץ אחר. צריך להיות כאן משהו תרבותי שמעודד את השיחות בערוצים פומביים, לתת את הכח לאנשים לצאת מהמבוכה ולשאול במקום פומבי.(רן) דבר אחד שאפשר לעשות הוא דוגמא אישית - ברגע שאתה עושה את זה בעצמך, גם אחרים רואים שזה לגיטימידבר נוסף שאני רוצה לחדד - יש כאן בעצם שני מחסומים פסיכולוגיים: האחד זה לענות ולבקש לשאול במקום פומבי והשני הוא אצל השואל, שאולי מרגיש שהשאלה טפשית ולשאול בפומבי עלול להיות מביך עבורו.גם כאן לטפל ולהראות שכל שאלה היא לגיטימית - וגם אם במקרה יצאה שאלה טפשית, אל תענו לזה בצורה כזו, שימו לב לכבד את הבנאדם ולתת לו להרגיש שהשאלה במקום.חוץ מזה- גם אם השאלה אכן טפשית, סביר להניח שאותה שאלה “טפשית” מקננת במוחם של עוד חמישה מפתחים, את לפחות חסכתם את הזמן עבורם.(שלומי) עוד משהו מעניין תרבותית הוא שאם יש לאדם שאלה שנניח קשורה ל-Databases (שזה מה שאני עושה), הוא לא יכנס לחלל העבודה שלקבוצת ה-Databases ויצעק “מי יודע איך אני מקנפג את ה-Timeouts ל-Client שלי?”, כי זה לא מכובד ולא מנומס. הוא יפנה באופן אישי למישהו וישאל אותו בשקט.בצ’אט זה בדיוק הפוך . . . הדבר הנכון הוא כן לגשת לכלל הקבוצה ולשאול, ואז מי מהם שפנוי באותו רגע יוכל לענות לך בלי מחוייבות, כי לא שאלת או הפרעת למישהו ספציפי, ולכל אחד יש את ההזדמנות לענות, שזה דבר חשוב תרבותית וארגונית.מעודד את חלוקת העומס והידע בקבוצה.(רן) אצלנו גם משתמשים ב - Stack Overflow for Teams, שזו מערכת QA פנימית לנושאים פנימיים שלנו (כמו הפומבי, רק Instance פנימי), ויש לנו Plug-in ל-Slackזה מאפשר לענות מיד “חבר, זו שאלה לגיטימית ל-Stack Overflow ולא ל-Slack”, כיוון שזו לא שאלה נקודתית אלה משהו שהוא “ever-green” ומסוג השאלות שיחזרו על עצמןהחיפוש בStack Overflow for Teams יותר קל ומאפשר לתת תשובות יותר מנומקות ולשאול שאלות הבהרה, בזמן שה-Threading בתוך Slack הוא קצת יותר מוגבל - נכון שאפשר לפתוח Thread אבל זה יותר מוגבל.הרבה פעמים יש דילמה לגבי מהו ה-Venue הנכון לתוכן - האם נכון לשאול שאלה בערוץ פרטי או לא? האם נכון לשאול את השאלה במקום פומבי? האם Stack Overflow זה המקום או שזה בכלל Bug וצריך לפתוח Issue? אולי זה משהו שצריך לתעד ואז צריך לפתוח Wiki? יש הרבה פעמים את הדילמה הזו.מדי פעם נראה שדיון מתחיל במקום אחד, וצריך רגע להבין האם הוא באמת במקום הנכון - גם אם זה התחיל ב-Slack, נכון להעביר ל - Stack Overflow, וצריך מדי פעם לעשות Review לדברים האלה.שוב - אנחנו משתמשים ב- Plug-in ל-Slack ואז אפשר ליצור את ה-Draft של השאלה ורק צריך להשלים ולכתוב כמו בנאדם (להוריד את ה-”?Hi, can I ask a question”)אגב - ראינו זינוק משמעותי בשימוש ב-Stack Overflow הפנימי מאז שאנחנו עובדים מהבית - וזה לא מפתיע.(שלומי) מה שחשוב במקרים הללו הוא לעשות את הקישורים בין “הנה, פה התחלתי את הדיון והוא ענה לי - ואז עברנו לכאן” - חשוב שמכל מקום יהיה אפשר לקפוץ למקום אחר.ב-GitHub, בגלל שניהלנו את הדיונים ב-Issues, היה לנו Plug-In ל-Slack שבכל פעם שהוספנו לינק ל-Issue, הוא “הלך” ל-Issue והוסיף הערה שמראה את “מראה המקום ב-Slack”, כך שתמיד אפשר “לקפוץ” קדימה ואחורה בין ההקשרים השונים.(רן) אולי משהו שהוא קצת יותר ייחודי לתקופה הזו, מעבר לעבודה מבוזרת שוטפת, זה עצם זה שהרבה מהמשק שובת (עד פרסום הפרק נראה שכולו . . .), הילדים ובן הזוג בבית (למי שיש), אולי יש איזושהי חלוקת משמרות - וזה משהו ייחודי ולא גנרי לעבודה מרחוק. איך זה משפיע לדעתך על התקשורת?(שלומי) זה משפיע באופן אקוטי על החלק של הזמינות - לעניין ה-Ping, אם פניתי אישית למישהו, לדעתי בעיקר בתקופה הזו שבה כולנו מבולבלים ותחת עומס ומוטרדים עם ילדים ושליח וארוחות צהריים - אי אפשר לצפות מאדם להיות זמין עד כדי 2 דקות.כולם צריכים להבין את הסיטואציה שבה הקולגות שלנו נמצאים - זו בדיוק הסיטואציה שלנו . . . טלפונים מההורים, מישהו בדלת וכו’ - ויש למעט ב-Pings.אם כבר עשיתי Ping למישהו, אני לא יכול לצפות לתשובה תוך X זמןבתרבות של GitHub, שאני מודה שזה אולי קצת רדיקלי, אין הנחה שאם אני עושה Ping למישהו אני אקבל תשובה באותו היום. זה קצת יותר קיצוני, אבל חייבים לקבל את זה שבנאדם אולי לא יענה - אולי יש ישיבה, אולי היא עסוקה, אולי רק בעוד חצי שעה או שעה או רק אחה”צ יענו לי.אם רוצים לעשות לזה Mitigation כי זה קצת ראדיקלי, אפשר להגדיר לאנשים “שעות קבלה”, למשל שלומי עונה בין 13:00-14:00, ואז אני יודע ששריינתי לעצמי זמן שבו אני זמין ב-Slack.מעבר לזה צריך לשחרר, וכמה שאפשר למעט ב-Pings - גם לצפות פחות וגם להשתמש פחות: דברו יותר בחדרים הפומביים, שם מי שזמין יוכל לענות, ופחות תניחו שהבנאדם הספציפי שפניתם אליו יוכל לענות ברגע זה.(רן) האם נתקלת בסיטואציות בהן עצם זה שפנית בערוץ ציבורי גרמה לזה שכל אחד חשב שמישהו אחר יטפל בנושא? יש את התופעה במפורסמת שבה “אם נופל בנאדם ברחוב ואתה היחיד שרואה ברור שתלך לעזור, אבל אם נופל בנאדם ברחוב הומה אף אחד לא יעזור לו”. האם נתקלת גם בדברים כאלה?זה נקרא The Bystander effect וה”דוגמת בית ספר” היא מקרה Kitty Genovese, אם כי ספציפית על זה יש בספרים של Gladwell, גם ב-Revisionist History ובעוד סיפורים טענות לגבי העובדות. (שלומי) זה פתיר בקלות - בדרך כלל בכל קבוצה יש לנו “On-call rotation”, והגדרנו שמי שנמצא כרגע On-call הוא ה-Owner הראשי, האחראי האולטימטיבי לזה שהשאלה תענה.יכול להיות שמישהו אחר יענה בינתיים, אם הוא למשל לא זמין או ב-Time zone אחר, והוא גם יכול לעשות Delegation - אבל הוא למעשה ה-Moderator של החדר באותו רגע (אחלה תפקיד, יש הזדמנויות גדילה בכנס).(רן) דיברנו על Pings - בוא נדבר רגע על Notifications- בנייד, בדסקטופ, באפליקציות אחרות . . . מה דעתך?(שלומי) דעתי היא קצת יותר רדיקלית - לדעתי צריך לכבות Notifications בטלפון.אנחנו בתקופה שבה Whatsapp לא מפסיק לצפצף: הילדים, ההורים של הילדים, הגן, בית הספר, כולם מנסים לארגן מפגשי Zoom בין הילדים, מה שזה לא יהיה.ההודעות לא מפסיקות, וצריך להפריד בין המחשב, שהוא סביבת העבודה שלנו ובו ההודעות ממשיכות לקפוץ (עם או בלי סאונד) - לבין הטלפון.רק כאנקדוטה - אותי ראש הצוות שלי ב-GitHub הכריח לכבות Notifications בטלפון אחרי שעניתי לו בשישי בלילה לאיזו שאלה שהוא שאל. 

רן, אלון, ודותן (ואורח מיוחד!)  בפרק מספר 66 של באמפרס (387 למניין רברס עם פלטפורמה, קורונה + 20 בגימטריה) - עם קצרצרים וסקירה של טכנלוגיות ודברים מעניינים האחרון, נכון ל-1 באפריל 2020. כנס חדש בישראל! (בהנחה שבזמן שאתם מאזינים העולם עדיין קיים ולא נסגר לרגל הקורונה) - כנס מתָחזקים ומִתְחזקיםהוועדה המארגנת כוללת אחד בשם דותן נחום והוא חושף פרטים - קודם כל הכנס בעל שם עם ניקוד, אחרת לא תבינו - מדובר בכנס לאנשים שמתחזקים קוד, ויודעים לקחת את כל מי שסביבם ולחזק אותם, כי לתחזק קוד זה לא דבר פשוט.יש כמובן גם אתרבין ההרצאות המתוכננות (מחפשים דוברים - הגישו  מועמדות!) - “קוד לגסי (Code Legacy) - בעד ונגד” (האם נכון להכניס קוד Legacy חדש או לא?)“איך להגיד ״לא״ לטסטים” (הרי כולנו מעבירים את רוב היום על הדילמה הזו)עצה ממומחה“סורס קונטרול (Source Control) מודרני ו SVN”או - Git מול SVN, שחוזר בגדול עכשיו עם כל בעיות ה-Security של Git.ולמהדרין - אם אתה כבר פותח חברה, קח ארון ושים שם את כל השרתים שלך. הכי טוב.“תנועת האג׳ייל ולמה זה טוב”כן, זה דו-משמעי. לא צריך ניקוד.“סטנדאפ (Stand-up meetings) - אפשר יותר מפעם אחת ביום”(אלון) ואפילו מומלץ! עד אחה”צ אתה הרי כבר שוכח על מה דיברו בבוקר.יש כבר מאמר שמראה שבגלל שזה קצר אז יש ארגון שמנסה ארבע פעמים ביום. קריאה מהנה.קלוג׳ר (Clojure) בארגון צומח - לעוד 5 שנים מוצלחות”“לכל כלי יש אתר - למה הכי טוב לפרמט קבצי קונפיגורציה וקוד באתר פומבי ברשת”הרי יש כל מיני כלים, והרעיון הוא שהכי נוח לקחת את כל קבצי הקונפיגורציה, להעלות לרשת, לפרמט (Formatting), להעתיק בחזרה ולהחזיר לקוד - לא צריך להתקין כלים חדשים.(אלון) סוג של HTML-based configuration? לא - למשל אם יש לך קובץ json, רק להעלות לרשת, לקבל פורמט ולהחזירזה לא שיש מה להסתיר, חבל להכביד עם עוד כלי בינארי - יש כבר הכל בחוץ“הצפנה בעד ונגד”יש עכשיו טרנד של להצפין כמה שפחות, כי זה ממש יקרבעידן של Quantum computing גם ככה הכל הולך להישבר אז למה זה טוב?“איך עברנו לססמאות קצרות וחסכנו 5GB בשנה על אחסון”חברה שמציגה חסכון אדיר על ידי מעבר לסיסמאות קצרותנכון, יש עקרונות של סיסמאות ארוכות, אבל האם מישהו אי פעם עצר לחשוב כמה מקום זה תופס ב-Database?!טרק מיוחד של Design & UXחביב במיוחד על רן - תמיד אפשר ללמוד מההיסטוריהבין הרצאות גאוסיטיס (GeoCities) - המיטב: כל ה Best Practices וה - UX שהאתר הזה גילה ויצר - ומה אפשר לעשות איתם היוםבטרק של Work-Life Balance: ל”ראות את הילדים בערב - בעד ונגד”יש כאלה שעברו לשבוע-שבוע . . .ועוד יותר רלוונטי עם כל עניין הקורונה - יש כאלה שמעדיפים לראות את הילדים רק עם Zoom.מוזמנים להציע נושאים נוספיםולאורח המיוחד - ארני (ארנון) פוגל (Arnie (Arnon) Fogel) שמבקר בישראל והצטרף להקלטה! כבוד גדול שמח לגלות שהטכנולוגיה הזו של הפודקאסט תפסה גם בעבריתלא הרבה יודעים אבל אח שלי הוא Werner Vogels - התחלנו את הקריירה יחד בגיל 12 עם אפליקציה למשחת שנים עבור בן-דודמפה לשם זה גדל, עד שחצי North-Minnesota הייתה אצלנומשם עברנו לתוכנה לחוט דנטלי . . .באיזה שלב אחיך עבר ממכירת אמצעים דנטליים למכירת ספרים דיגיטליים ב-Amazon?המעבר היה פשוט - יום אחד הוא ישב ב-Subway וראה מישהי שיושבת וקוראת את הדף הראשון בספר (זה שריק לגמרי), ואז מגלגלת אותו והופכת אותו לקיסם שיניים.זה בא במקביל לגל ה”Combo” - מדפסת-סורק, מצלמה-טלפון, כל אלהמפה לשם - ספרים שמנקים איתם שיניים? מהפכני!ומכל זה נולד כל העניין של Cloud-Computing - והיום Werner Vogels הוא ה-CTO של AWS - והתפוח לא נפל רחוק: היום ארני נמצא ממש בחזית הטכנולוגיה. עדיין מוכר קיסמי שיניים?לא - יש לי אתר ב Etsy, של קיסמי שיניים מעוצבים אישית עם ברכה“שלא תדע עששת”? זה שלימשווק יחד עם Beyond Meatועכשיו אתה עוסק בשיווק קורונה?למה ככה?! מדדו לי חום בשדה והייתי בבידוד 11 ימים עד אתמול . . . ויתרתי על היומיים האחרונים כדי לבוא להקליט איתכם.אם סופרים ב- Hexadecimal זה יוצא בסדר.עברנו על חשבון ה-Twitter שלך ומצאנו כמה דברים מעניינים שנשמח אם תוכל להתייחס אליהם, למשל - Space Computing vs. Cloud Computing - האם זה באמת הולך להיות השלב הבא?אם נחזור רגע לניסוי הזה של אח שלי - הוא התחיל עם זה שהיו להם מלא מחשבים שלא עושים כלום, ואז הוא הגיע לבזוס, שהוא כל כך קמצן  שאפילו את התחתונים הוא לפעמים משכיר בתור ממחטה.הוא הציע לו להשכיר את המחשבים בינתיים - ובזוס הסכים.אז אני (ארני) הלכתי ל-Elon ואמרתי לו: “אתה העלת לשמיים מלא לוויינים בגודל של קרטון חלב, ולאף אחד אין מושג מה עושים עם הדבר הזה - בוא נריץ עליהם עבודות ונראה מה יקרה, אולי יצא מזה business”.באיזה שלב זה נמצא? יש כבר לקוחות Beta ל-Space Computing? אפשר לקחת CPU בחלל ולהשתמש בו?כבר היום משרד הבריאות הישראלי משתמש בזה לחיזוי התפשטות הקורונה, בגלל זה אתם כאן top of the line עם זה(בהנחה שעד מועד השידור האנושות תתקיים והשמש תזרח).גם המערכת הזו שאומרת מתי מגיע אוטובוס בישראל, שעבור האינטגרציה שלה הגעתי לכאן היום - המערכת הזו מחשבת את תנועת האוטובוסים תוך שימוש ב Space Computingוכל זה קורה ממש מתחת לאף שלנו . . . מדהים.נושא אחר שעלית עליו הוא ההבדל בין HL ל - ML, כלומר - Human Learning לעומת Machine Learning.ספר לנו קצת על זה  . . .אני חושב שאנחנו עומדים מול טרנד חדש של “כמות מול איכות” - מחשבים לומדים בסך הכל מאז שנות ה-70, והם לומדים טוב בסך הכל ב 5-10 שנים האחרונות - אבל אנשים לומדים כבר 25,000 שנים, וזה הרבה יותר זמן ללמוד.הרבה יותר למידה התבצעה פה, וזה חבל לא לנצל את זה . . (רן) אני באמת זוכר מהקורס שלי בבינה מלאכותית - רשתות נוירונים מדהימות קיימות כבר במוח האנושי, אז למה בעצם אנחנו מנסים להמציא מחדש את הגלגל עם רשתות נוירונים ממוחשבות, מה הטעם?מעולה - הרמנו בדיוק שירות מעל Human Learning: אם אתה רוצה לנסוע ממקום למקום, למשל בניו יורק (שם הרצנו פיילוט), אז במקום להתקשר ל-Waze ולבזבז חשמל ולאבד את המגע האנושי, לנו יש סט של נהגי מוניות שאיבדו את העבודה שלהם בגלל Uber - והם פשוט עונים לך בטלפון ומכווינים אותך (“אח שלי קח ימינה, ואז שמאלה”, “אל תקשיב לאין כניסה, זה רק 2 מטרים ותגיד לשוטר שעשית רוורס” וכו’).ככה משתמשים ב Human Learning במקום Machine Learning.אתה מדבר כאן בעצם על פיצ’ר שלא קיים ב - Machine Learning: היכולת לאלתר, למשל לדבר עם שוטר ולהמציא סיפורים. זה ה - Holy Grail של Machine Learning ואתה משיג את זה בדרכים הרבה יותר אפקטיביות עם Human Learning.כן, באנגלית זה נקרא “cutting corners”, לא יודע אם יש לזה מילה בעברית. באמת אין ביטוי כזה (פה לא חותכים - מעגלים…), אבל שווה לבדוק. אנחנו מאוד Strict בישראל ולא חשבנו על זה.מה שכן מאוד חשוב לנו כאן זה העניין של הכשרות - הרבה פעמים יוצא שאני מגיע לאתר ואני לא כל כך בטוח לגבי הכשרות שלו. האם יש בשורות חדשות בנושא לדעתך?אנחנו ישבנו על נתוני תעבורה של אתר שנקרא B&H, מכיר? ודאי שם קניתי את המצלמה הדיגיטלית הראשונה שלי . . .מסתבר שאתה לא לבד . . . הרצנו על זה מודל של Big Data, וגילינו שהם סגורים בשבת וגם עושים המון כסף. זו קורלציה מאוד חזקה, אז אנחנו הולכים לשווק סגירה בשבת גם לאתרים של חילונים וגויים, כדי שיהיו מצליחים גם הם כמו B&H.וזה עובד ממש מעולה - כל בתי הספר ב - Washington DC עכשיו סוגרים את האתר שלהם בשבת.ממילא אין לימודים אז למה צריך אתר? אתה יכול לחסוך כ-20% מהוצאות הקירור, חשמל וכו’, חיסכון אדיר.אם אתה לא צריך לקרר בשבת - ויכול להשתמש בשרתים בתור פלטה של שבת אז אתה ממש במקום טוב.אנחנו מתחילים עכשיו לשווק קיגל מה-Data Centers שלנו - ה - Cloud Kugel, או CK.אלון מתרגש כי בבית סבא היו עושים קיגל . . . בטח זוכר את הקיגל הראשון שהוא עשה על ה Sinclair Spectrum שלו.זה מאוד מעניין - כל האספקט הכלכלי של זה . . . תמיד חשבנו על מנוחת הנפש, אבל יש כאן גם אספקט כלכלי טהור, ונראה שממש תפסת אותו בביצים והשתמשת לטובתך . . .התייחסת קודם לנושא של הצפנות ו-Quantum Computing, וראיתי בטוויטר שלך שזה גם נושא שמעניין אותך, כולל לא מעט בלוגים.לאיפה כל הנושא של הצפנות ו-Quantum Computing הולך לדעתך?במילה אחת? פאקקט. אין הצפנות יותר ב-Quantum Computing, אנחנו פרצנו הכל. אני יודע עכשיו להגיד לך שהארבע ספרות האחרונות של כרטיס האשראי שלך הן 1234, וגם את השם של הכלב הראשון שלך, בוני. והחיה הראשונה שלך הייתה דג זהב.אמור לרדת בעריכה . . . בכל זאת גם לנו יש מגבלות של Security, אבל הרעיון מובן.אם ראית במקרה את הסרט Avengers: End Game, אתה יודע שיש הרבה מקבילים ליקום.אם אני רוצה לפרוץ ב Quantum Computing לסיסמא שלך, אני יכול פשוט לגשת ליקום שבו הסיסמא שלך היא 1234 (כי אתה טמבל שם), ולהביא את האיזור הזה של היקום האחר לפה, וככה אני יודע כאן מה הסיסמא שלך.מדהים. ו -By far לא החלק העלילתי הכי הזוי בסרט.איך זה עובד? יש לזה Docker?ב-Quantum Computing לא קוראים לזה Docker אלא Loop Worm: אלו תולעים מחורי תולעת שמאפשרות לעבור את מהירות האור, אם אתה יודע קצת פיסיקה מודרנית.הקוונטים לא עוברים - ה-Docker הוא לוויתן ויש לו מסננת בגרון, אז הקוונטים לא עוברים.לעומת זאת ב-Loop Worm זה הרבה יותר חזק.ממש מעניין - זה אומר שבכל היקומים המקבילים שבהם אני לא טמבל, אתה לא תצליח לפרוץ?רגע, בודק את כל הסיכויים שזה קרה . . . יש 45 מיליון אפשרויות ורק באחת מהן אתה לא טמבל.זה בהחלט מציג פרספקטיבה חדשה לכל עולם המחשוב, זה לא פחות ממהפכה.בהקשר הזה - רצינו גם לדבר על התיאוריה עליה אתה מדבר בבלוג שלך - ה-PAC Theorem. מה המשמעות של זה?ב-CAP אתה אומר שאתה לא יכול להיות גם פה וגם שם בו זמנית, אבל ב-Quantum אתה כן (תלוי איפה את מסתכל).יש המון Databases שהם Immediately consistent ו-Transactional - והם מחזיקים את הדאטה בו-זמנית, כל עוד אתה לא בודק שהדאטה שם.ברגע שאתה בודק, יכול להיות שזה נמחק באותה שנייה בגלל שבדקת - זה נקרא Schrodingers Database.בשנייה שאתה מסתכל, יכול להיות שכבר אין Data . . .באיות הנכון זה בכלל Shardinger?מכיוון שרובנו רק כותבים ל-Database ולא קוראים, יש בזה הגיון . . .כמו שאמר לי פעם איש אחד בחברה שלי, כשרציתי לשחזר מידע - “כתוב על הקופסא מערכת גיבוי, לא כתוב שיחזור”. נקודה טובה.זה קצת מזכיר את NullDB, רק ששם אתה כותב למקום אחד ולא יודע אם זה כתוב, ואצלנו זה כותב להמון מקומות ואתה לא יודע אם זה כתוב.הלוגיקה לא בינארית - יכול להיות שה-Bit נכתב או לא נכתב.(אלון)  קצת מזכיר את  MongoDB . . . יש לכם שת”פ איתם?אני לא יכול לספר, ה-CTO של MongoDB אמר פעם ש”נכנס יין - יצא סוד”, ואני רוצה להראות לו שזה לא ככה אז אני לא יכול לדבר.היום כל אחד יכול לעשות MongoDB ולראות האם הוא מצליח לקרוא.יש כאלה שאפילו עושים MongoDB ב-Production? זו שמועהאבל רק עם רפליקות.דרך אגב - המארינס הכניסו לאימונים שלהם שאם אתה ב-Seals, אתה חייב לעשות Auto-Sharding ב-MongoDB, וזה מראה שהוא באמת אמיץ ולא מפחד משום דבר.בהחלט מרתק, ארני ישאר עימנו לנושאים הבאים.ועוד אייטמים - הכרזה מדהימה של Azure על הגרסאות הבאות של ה-Cloud: יש את Azure ME

פודקאסט מספר 386 (מתקרבים לפנטיום?) של רברס עם פלטפורמה - אורי ורן מארחים בכרכור (בלי משקפיים) את תומר מחברת Natural Intelligence לשיחה טבעית על העיקרון של מוצרים פנימיים של חברה (שנועדו לשמש את החברה עצמה) - מתי נכון לקנות מוצרים כאלה ומתי נכון לבנות אותם (Build/Make vs. Buy).קצת על תומר - בן 37, גר בתל אביב, נשוי + 2 - והיום VP Product ב - Natural Intelligence, כמעט שנתיים בחברה.לפני כן כמה סטארטאפים קטנים יותר, בעיקר באיזור החיוג של Cyber Security, Analytics, Dataהיום ב - Natural Intelligence מתעסק בעיקר בעולמות של המוצרים הפנימיים ופחות בעמודי האינטרנט שהם Consumer-facing, יותר בכיוון ה-Back-office.למעשה הנושא של Build vs. Buy הוא “בדמך” . . .לגמרי - ובשנה האחרונה זה בשיא.קצת לגבי מה אתם עושים . . .החברה Natural Intelligence לא לגמרי צעירה - קיימת כבר למעלה מ-10 שנים, מעל 450 עובדים.מפעילים מאות אתרי השוואות שהמטרה שלהם היא לעזור לצרכנים מכל רחבי העולם לקבל החלטות נכונות יותר לגבי שירותים שונים, בדרך כלל שירותי Online.החל מהשוואות לשירותי ביטוח דרך Home improvements, פיננסים, שירותי B2B - כמעט לכל ורקיטל שיש לו “Service on a Click” אנחנו נביא ל-Consumer את ה - “Top 10 options” באיזור חיוג שלו כדי לעזור לו לבחור - זה בעצם מוצר ה-Consumer-facing שלנו.יש עולם מוצרי שלם עם Roadmap משלו מאחורי זה, שמאפשר את כל האופטימיזציה של החווייה הזו - ה-Data וה - A/B Testing וה - User acquisition וכו’ - וזה ה-Roadmap שאני מנהל ביחידה שלי.אני מניח שלפחות את חלק מהאתרים האלה אנחנו ראינו - ואולי אפילו לא ידענו שזה מה שאנחנו רואים . . . איך זה נראה - כמו בלוג-פוסט שמישהו לכאורה כתב? איך נראה אתר כזה?שאלה טובה . . . גם וגם.בהרבה מאוד אתרים שלנו יש דוגמא טבלאית בצורה כזו או אחרת.חלק מהאתרים הם Non-branded - למשל אם תחפש VPN ותגיע ל-”Top 10 options for VPN” באיזור ניו-יורק או איפה שלא תיהיה.חלק מהאתרים הם כן Branded - ואז זה יופיע בצורה של טבלה או כתבה או בלוג שמשווה כמה אפשרויות טובות עבור אותו שירות.הקוספט בסוף הוא אותו הדבר - לזקק עבור הצרכן כמה אופציות טובות שרלוונטיות אליו - למיקום הגיאוגרפי, למגדר או לכל מאפיין אחר שלו.מי הם הלקוחות?היום יש בעצם שני סוגי לקוחות, כשאנחנו רואים את זה כמעיין משולש - אנחנו ועוד שני פרטנרים:שותף ראשון הוא הצרכן - משתמש הקצה, שלא משלם לנו אבל הוא זה שנהנה מהחוייה ומהאתרשותף שני הוא הלקוח המשלם - אותם Brands שנמצאים אצלנו בתוך האתרים - כל מותג עם הסיפור העסקי שלו - הרבה מאוד Deals וסיפורים עסקיים שונים.אחד האתגרים שלנו, לפחות בצד של ה-Business, הוא לאזן את המשוואה בין טובת ה-Consumer לבין ה-Business, שצריך להחזיק את עצמו.אני מניח שהתוכן הזה מיוצר (מג’ונרט, Generated) בצורה בעיקר (אם לא רק) אלגוריתמית, ובעצם המהות של זה היא נושא מעניין לפודקאסט - לא על זה נדבר היום, אבל אני מניח שיש מאחורי זה טכנולוגיה עמוקה ומעניינת ששווה לדבר עליה בהזדמנות.לגמרי . . . אפשר גם לנחש מהו מקור השם בהקשר הזה . . .מה שאנחנו כן הולכים לדבר עליו זה יותר זה החלק שהזכרת קודם של ה - Back office: כל אותם מוצרים שגורמים לכל זה לפעול, מעיין “מערכת ההפעלה של החברה”.בכל חברה מגודל מסויים יש סט כזה של מוצרים - החל מ-Dashboards פנימיים דרך מערכות לניהול קמפיינים (שתכף נדבר עליהם) ועוד - יש לא מעט כאלה.איפה התחלתם לפגוש את הנושא הזה? היכן הגיע המפגש הראשון שלך עם הדילמה הזו של Build vs. Buy?המפגש הראשון היה בתרגיל בראיון שעשו לי כשהגעתי לחברה . . . התרגיל היה “שרטט על הלוח איך נראה ה-ETL של ה - Data Pipeline, ה-Revenue Data של החברה - עד שבסופו של דבר Business user יודע לצרוך אותו.בעצם ב-Sub-text נאמר שיש פה איזשהו מוצר שקנו לפני כמה שנים - מעיין Drag&drop GUI שמאפשר לבנות ETL “ללא מפתחים”…איך קראו לזה? נדלג, חברה ישראלית לשעבר . . . יש לא מעט בתחום אז קשה לנחש, אבל בסדר.בעצם אותו Drag&drop פשוט וקל להפעלה, שיהיה כמובן “מאוד אינטואיטיבי וירקיע שחקים יחד עם החברה” הפך פתאום לאיזשהו Bottleneck מאוד משמעותיהצוות שהטמיע כבר לא נמצא, כמות ה-ETL וה-Processes שהצטברו הפכו כל מסך כזה לבלתי-ניתן-להכלה ע”י עין אנושית.מאחר וזה ממש ב-Core של ה-Infrastructure,יש הרבה Processes אחרים שתלויים בזה ויש המון מוצרים עם אינטגרציה על זה - וזה הפך ל-Showstopper.מה היה גודל החברה בשלב הזה?היינו עם Business די דומה בגודל, הרבה פחות אנשים - סדר גודל של כ-250 - אבל כבר אז זו הייתה בעיה קשה.וכשהתחילו להשתמש באותו המוצר - מה היה גודל החברה?הרבה פחות . . .סביר שזה מוצר שאולי גם היום טוב עבור חברות קטנות, אבל כשהגעתם לסדר גודל של כ-250 עובדים המוצר כבר לא החזיק מים . . .יכול להיות שזה באמת היה טוב בזמנו, אבל באיזה שלב אתה צריך להסתכל ולהגיד לעצמך “זה כבר לא משרת אותי”.(אורי) העולם הזה, של כלים פנימיים - יש בו שני דברים: הראשון הוא גדילה (אתה גדל, יש יותר עבודה וצריך לפתח יותר כלים ואוטומציות כי יש יותר אנשים שיכולים לעשות טעויות); השני הוא (לפחות בחווייה שלנו ב-Outbrain) שיש Domain עסקי מסוים “שיושב” אצל איזשהו צוות והאנשים באותו צוות מתחילים לפתח גם כלים.הם מפתחים את הכלים וחוזרים להתעסק ב-Domain העסקי שלהם ובלהזיז אותו קדימה.האופרציה מתחילה להשתמש בכלים - כשלאט לאט הכלים האלה הופכים למעיין “בן-חורג” - והם תמיד הדבר האחרון שמתייחסים אליו כשבונים Roadmap או תוכנית עבודה(רן) ומחלידים . . .(אורי) לגמרי - עד שלב שהם הופכים ללא-שמישים, כי אתה גדל כל הזמן ואף אחד לא מתחזק אותם, והם לא מצליחים לעמוד בעומס.(רן) לפעמים אתה עושה טובה ונותן לסטודנט או לעובד החדש בצוות לתחזק אותם - ולפעמים גם זה לא.אז הוצגת (תומר) בפני השאלה של בניית ETL - ואז התקבלת לעבודה ואמרו לך “אוקיי, בוא תבנה ETL”?לשמחתי לא אני בונה את ה-ETL אחרת הייתה קטסטרופה, אבל בהחלט התחלנו לאפיין את כל ה-Infra החדש של ה-Data ETL שלנו מ-Scratch.כמעט כל השנה שעברה הוקדשה ל”להרוג את הייצור הזה שהבאנו” ולהשתמש במוצר שמפותח פה.כזה שמתאים ל-Scale, ל-Business case, ל-Time-To-Market שאנחנו נדרשים אליו מה-Business users, כדי לייצר pipeline חדש של Data-source חדש.מאז אנחנו נתקלים בשאלה הזו בהמון מקרים…ואם נסתכל רגע שוב על אותו מוצר - זה היה לפני שנתיים? מאז למעשה כבר כל החברה עברה Migration? כל ה-ETL עברו לשם?כן.ובראייה לאחור - אם היית עכשיו מתחיל מאפס, בהסתכלות על מוצרים אחרי שיש בחוץ - היית עושה את אותו הדבר, או שאולי בכל זאת היית בוחר במוצר חיצוני במקרה הזה? האם בשלב הזה בדקתם מוצרים חיצוניים אחרים? אולי Open-sources?בשלב הזה ידענו שאנחנו רוצים לעשות משהו שיותאם מאוד ל-Use-case שלנו ולמבנה העסקי שלנו, שכלל לא רק ETLהיה בזה גם מוצר יותר גדול שכלל אוטומציה מלאה של כל ה-Funnel של Revenue Dataזה מורכב כיוון שה-Revenue לא נוצר אצלנו אלא אצל ה-Brands שמופיעים אצלנו ב-charts - אני צריך לגשת לכל אחד מ(מאות) הלקוחות ולהביא מהם את ה-Conversions וה-Commissions ולהזרים את זה אלי.זה היה חלק ממערך גדול יותר, שהבסיס שלו היה איזשהו ETL שעד אותו רגע היה תקוע במוצר שכבר לא כל כך ידעו איך להשתמש בו.(רן) אני חושב שהרבה חברות באות עם גישה של “אוקיי, אז אנחנו עכשיו צריכים משהו - אם זה ב-Core שלנו אז נפתח את זה אנחנו; אם זה לא ב-Core שלנו, אנחנו נקנה את זה” - וזה אולי נשמע טוב על הנייר רק שהשאלה הראשונה כאן היא האם זה באמת ב-Core או לא? למשל - האם ETL זה חלק מה-Core? יש הרי ETL מהמדף, אבל אם כל אחד מהם שניסינו מאט לנו את ה-Business - גם אם זה לא ב-Core, זה הופך ל-Core . . .מתי נפל האסימון בחברה ש-ETL זה אולי לא המוצר שלנו אבל זה מה שמניע את ה-Core ולכן אנחנו חייבים לפתח את זה?אנ חושב שזה בדיוק בשלב של הבגרות של החברה שבו היא מתחילה לגדול, ואז היא מבינה שה-Scale הוא כבר דרישה דרמטית.חברה קטנה שמתחילה - כל המשאבים שלה והפוקוס הפיתוחי והמוצרי חייב להיות במוצר, וחייבים להשקיע בלקוחות הראשונים ובמשקיעים הראשונים, אין את הלוקסוס להשקיע “בפריפריה”.כשהחברה גדלה, ויש לה כבר את המוצר הבסיס עומד ואין כבר לחץ של משקיעים (?) ולחץ של לשמור את חמשת הלקוחות הראשונים באוויר - הזה זמן להתחיל לדאוג למה שיקרה בעוד שנה או שנתיים מהיוםאיך אתה תומך ב-Scale יותר גדול, ביותר לקוחות, ביותר משתמשים פנימיים(אורי) כשאני מדבר על זה עם יזמים - על Build vs. Buy - אני אומר להם “תזכרו תמיד שמתישהו תצטרכו לבנות, ותראו שאתם לא מפחדים להביא את הידע” - הרבה פעמים מפחדים לבנות כי אין את הידע - אבל הנקודה להתחיל להתעסק בדברים האלה היא הנקודה של Product-Market fit.עד ה - Product-Market fit אתה קטן ואתה לא עושה Scaling וחשוב לך להיות מהיר כמה שיותר ולהתעסק ב-Core שלך כדי להגיע לאותו Product-Market fit.שלב ה - Do things that don’t scale של Paul Graham (שווה להקשיב גם כאן) ברגע שהגעת לשם - יאללה, צריך לתחיל לחשוב על כל אותם דברים שהם Scale, וזה נוגע קודם כל ל-Scale הטכנולוגי (שבכלל יהיה אפשר לעשות את זה) - ולעלויות . . .(רן) מאוד מתאים למה שתומר אמר קודם - שהחברה נתקלה באתגרי scale והחליטה שה-ETL הקיים לא מתאים יותר.וקצת לאתגר אותך (את אורי) - השותף שלך ב-Outbrain - ירון - אמר פעם שנכון שיש Product-Market fit, אבל זה אף פעם לא סוף המשחק: עכשיו מחפשים את ה Product-Market fit הבא, וכל הזמן עושים על זה איטרציות.זה לא שיש נקודה שבה אתה קם בבוקר ואומר : “יופי, הגרפים מתחילים לעלות, יש Product-Market fit!” - זה חיפוש מתמיד.(אורי) נכון - אבל בשלב מסוים אתה מתחיל לגדל Core Business שמתחיל להוות “פרה חולבת” שהולכת ומשמינה (זו התקווה), ואם אתה לא תטפל בדברים שקשורים ב-Scale, אתה תעצור את ה-Business הזה.אתה צריך להיות מסוגל לתמוך בגדילה הזו של ה-Core, וכמו שירון פעם אמר לי: “אנחנו כבר חברה מספיק גדולה, כבר יכולים ללכת וללעוס מסטיק ביחד”.יש לנו את ה-Core שימשיך לגדול ולעבוד, אבל אנחנו צריכים להיות מסוגלים לפתח גם את הכיוונים הבאים ולעבוד עליהם בצד.(תומר) באיזשהו שלב פשוט ה-Core מתרחב עם הזמן - התפיסה של מהו Core ומהו Enabler להצלחת החברה הבוגרת, שכבר אינה סטארטאפ קטן, הולכת ומתרחבת.הרבה דברים הם Enablers על מנת להמשיך ולגדול למדרגה הבאה.(אורי) בהרחבות של Core, אם לצורך העניין יש לך סט Features בסיסי של המוצר - עכשיו כשאתה מביא את הפיצ’ר הנוסף, הוא לא כמו בפעם הראשונה כשבנית אותו עבור חמישה לקוחות ויכולת לעגל פינות באתגרים של Scale - עכשיו כשהפיצ’ר הזה יצא לשוק, הוא יצא למאות ואלפי לקוחות.פיתוחים ב-Core - צריכים להבין שהם מביאים איתם עוד משהו - זה לא Tech-debt אלה מעיין enablement . . . “אתה כבר צריך לחיות ב-Scale”(תומר) סוג של Biz-Debt - משהו שהוא כבר חלק הכרחי של ה-Business.ויש עוד שאלות בהקשר הזה (של תומר), למשל - A/B Testing: האם כלי לניתוח A/B Testing צריך להיות חיצוני או פנימי? אני חושב שחברה שרק מתחילה את דרכה בעולם ה-Online כנראה שתשתמש באיזשהו כלי חיצוני שזמין לה, כי יש לה דאגות אחרות על הראש (Google Analytics למשל).תוך כדי העבודה ב-2019 על ה-Roadmap, כשאמרנו שאנחנו צריכים לבנות כזה כלי והשאלה הייתה האם לבנות או לצאת החוצה, היינו כבר בתפיסה שזה חלק מה-Core של העבודההאופטימיזציה וכו’ - זה חלק מה-Core.לפני 6-7 שנים זה אולי לא היה ברשימת הדברים שהם חלק מה-Core של המוצר.(רן) אתה אומר שאולי לפני 6-7 שנים זה לא היה חלק מה-Core אבל ההגדרה של ה-Core הולכת ומתרחבת וגם את זה צריך לקחת בחשבון.דיברנו קודם על מקרה שבוא היה מוצר שקניתם ובסופו שלדבר החלטתם לבנות - האם היה לכם גם מקרה מהסוג ההפוך, של מוצר שבניתם והחלטתם שאתם רוצים להפסיק לבנות והחלטתם לקנות?אנחנו עכשיו בהתלבטות כזו, עם משהו מאוד פשוט - פונקציונאליות של Fetching, מה-API החיצוניים אל תוך ה-Data Lake שלנו.פיתחנו Fetcher פנימי, in-house, שניגש לכל מיני מקורות מידע - אם זה Marketing channels או הלקוחות שלנו - והביא את ה-Data בקבועי זמן כלשהם.אנחנו נתקעים שם בבעיות של Time-to-Market - ה-Business unit רוצה מידע בקבועי זמן מסויימים מ-Channel חדש (נגיד Outbrain לצורך הדוגמא) - ועכשיו אני צריך להשקיע בזה אנשי פיתוח ו-Engineering, שלא יעשו משהו שתואם לליבה העסקית אלא ב-Fetching ל-API.וזה - כשיש כלי מדף שזה בדיוק מה שהם עושים, וגם אנשים שהם לא חלק מה-Engineering ואולי יותר זמינים (Availability) יוכלו לעשות איזשהו Drag&drop, יתחברו ל-API וזהו.בימים אלו אנחנו מתלבטים האם לעשות סוג של “אחורה פנה” ולהתחיל להביא Data מסויים באמצעות כלי שלישי ולאו דווקא באמצעות כלי Fetching שפיתחנו בעצמנו.דיברנו על שתי דוגמאות, עכשיו ננסה לעשות הכללה, לראות מה הם הקווים המנחים ואיך אתה מחליט . . .הראשון היה “האם זה ב-Core או לא?”אילו עוד פרמטרים אתה לוקח בחשבון כשאתה מתלבט האם לבנות מוצר פנימי או לקנות משהו?אני חושב שהצלחנו לגבש כמה שאלות שמנחות אותנו בתהליך ההחלטה או ה-Evaluation של הצורך שעלה מה-Business או הצורך הטכנולוגי שלנו.אחד מהם זו באמת שאלת ה-”Core או לא”’  וגם עד כמה ניהיה “נעולים” לתוך אותו מוצר - כמה שכבות של Processes או מוצרים אחרים “יתלבשו” עליו, ואז אני נשאר עם איזשהו 3rd-party שתקוע בליבה של שנים קדימה.מה  שקרה לנו בעולם ה-Data…(רן) אתה קונה אוטו, ומרכיב עליו גגון - ועל זה יש אוהל, וסככה וכו’- ואז כשאתה רוצה להחליף את האוטו, אתה מגלה שזה לא גנרי, ואי אפשר “סתם” להחליף את האוטו.(תומר) או שהמחיר של החלפת האוטו הוא כל כך יקר שזה פשוט מגוחך.(אורי) אבל הסיכוי להחליף אוטו, שבדרך כלל יש לו ארבעה גלגלים, וגג וחיבור סטנדרטי לגגון . . . הסטנדרטיזציה במוצרי מדף תיהיה יותר גבוהה ממה שאתה תבנה בפנים.(תומר) זו בדיוק השאלה השלישית - האם ה-Business case שלי הוא ייחודי לי או שהוא גנרי מספיק? האם יש איזשהו צורך שכנראה עדיף לי לפתח In-house את המענה אליו, או שזה use-case שיש להרבה חברות כמוני ולכן אין סיבה להתמודד עם זה מאפס, ועדיף לקחת משהו שקיים בחוץ - כמו Fetching.(רן) … או A/B Testing - כל החברות עושות זה. האם הצרכים שלי ב-A/B Testing דומים לשאר החברות? אם כן אז סביר להניח שאני אמצא מוצר מתאים, אבל אם הצרכים שלי מאוד ייחודיים אז חבל לחפש כי כנראה שלא אמצא משהו מתאים ועדיף כבר לפתח בפנים.(תומר) כן - ושאלה שמתחברת לזה היא לא על הייחודיות שלה-Business case אלא על הייחודיות של ה-Best Practice אצלנו בחברה, בעיקר באוטומציות.כשאנחנו באים לאטמט (To Automate, ל”עשות אוטומציה”) תהליכים ידניים של Back-office או של Business או אופרציות כאלו, אנחנו תוהים האם יש לנו איזשהו Best Practice שאנחנו צריכים לשמר אותו על ידי פיתוח פנימי.נתקלנו בזה המון תוך כדי אוטומציה של user acquisition למשל, בעיקר Bidding מול Ad-words או Bing Ads  -איך אני מאטמט את תהליך ניהול הקמפיינים? האם אני לוקח איזשהו כלי חיצוני (ויש המון כאלו שמאפשרים Bidding אוטומטי), או שאני מפתח פנימית?שם, החלטנו שבכל המקרים באמת החברה התמחתה לאורך השנים בכל מיני תהליכים של user acquisition ששווה לחקות אותם באופרציה הפנימית שלנו ולא להסתמך על כלי חיצוני.(רן) זאת אומרת שיש מעיין Business-Intelligence, הרבה חוכמה (know-how) שאולי לא ”קודדה” עד עכשיו, אבל שווה לקחת את הזמן ולקודד אותה כי סביר להניח שזה לא משהו שתמצא מבחוץ.אילו עוד פרמטרים אתה לוקח בחשבון?הכל מתחבר אחד לשני . . . Time-to-Market זה גם משהו שאנחנו שואלים את עצמנו - האם יש לי בכלל שיקול Time-to-Market דרמטי בסוגייה? יכול להיות שזה צורך שהוא חשוב אבל לא כל כך דחוף, או שזה צורך דחוף ולכן “מחר בבוקר” צריך להעמיד איזשהו פתרון - ואז השאלה היא מה יהיה יותר מהיר: פיתוח של שני אנשים “בתוך הבית”  שיכולים לרוץ מהר או דווקא אינטגרציה עם חברה חיצונית שאולי תיהיה יותר מהירה.(אורי) יש Time-to-Market ויש Time-to-Scale - המקום של כלים פנימיים מגיע הרבה פעמים ביכולת לאפשר Scale.אני יכול להגיע לשוק ולפעמים אני רוצה להגיע לשוק ולבדוק משהו, לאו דווקא כדי לרוץ ולשווק אותו - אז עבור חמשת הלקוחות הראשונים, על מנת שיהיה משהו לבדוק, אני יכול גם לאפשר מצב שבו אנשים יעשו משהו בידיים, סוג של POC, ובשביל זה אני לא אבנה כלים.כשאני מתחיל לחשוב אח”כ איך אני עושה לזה Scale, ברור שאי אפשר להעמיד צבא של אנשים שיעשו הכל ידנית.(תומר) התלבטות נוספת שאנחנו מתלבטים איתה ממש בימים אלו היא שעד היום רוב התקשורת מול ה-Brands שנמצאים אצלנו באתרים נעשתה ע”י אנשי ה-Business בדרכים שגרתיות של מיילים, טלפונים וכו’ - והחלטנו שאנחנו רוצים להעביר את כל התקשורת הזו לאיזושהי פלטפורמה מנוהלת מודרנית.סוג של CRM? אולי Marketo? יכול להיות, אבל יש לדוגמא גם מוצר שעליו הסתכלנו בין היתר של Salesforce בשם Communities, שהוא משלים ל-CRM ומאפשר את התהליך של user-login-כניסה, אפשר לצפות בביצועים שלו, באילו אתרים שלנו הוא נמצא, לראות Performance dashboard שלו - וכמובן אפשרות לצ’ט עם ה-Account Manager שלו וכן הלאהזו מעיין פלטפורמה שתיהיה חלק עיקרי בתקשורת שלנו מול הלקוחות וגם כאן יש שאלה - ברור שאם אני אקח כלי חיצוני, Salesforce לדוגמא - מחר בבוקר אני יכול יחסית בפשטות להביא

פרק מספר 65 של באמפרס (385 למניין רברס עם פלטפורמה) - רן, אלון ודותן עם סקירה של טכנולוגיות ודברים מעניינים מהזמן האחרון.רן - חברת Shopify (חברת eCommerce קנדית) מציגה קונספט מעניין של Dev Degree: מציעים למפתחים בתחילת דרכם (לפני השלמת התואר) לעבוד אצלם, כשהם הם מממנים את הסיפור הזה.שיתןף פעולה עם כמה אוניברסיטאות באיזור, כשהסטודנטים לומדים ועובדים במקביל, במימון החברה.עוד סינגל לכך שחברות צמאות לכוח אדם ומוכנות לשלם הרבה עבור זה - גם בכסף וגם בזמן - Internship מאוד ארוך, במקרה הזה של 4 שנים.בעיית כוח האדם קיימת בכל העולם ומעניין לראות פתרונות יצירתיים - יש הרבה תוכניות של העסקת סטודנטים אבל זה בהחלט די קיצוני.מעניין אם יוזמה כזו תוכל להתרומם גם בישראל.אחד השחקנים המובילים של Go - איש בשם Brad Fitzpatrick - עוזב את Google ולמעשה עוזב את ה Core Development Team של Go.מדובר במפתח עם הרבה מאוד קרדיט בעולם של Go וגם הרבה לפני כן.משתמשים ב Memcached? אז זה קוד שלו מאחת החברות הקודמות.כתב עוד לא מעט מערכות מבוזרות מעניינות.עכשיו החליט שהספיק לו - אחרי 12 שנים וחמישה חודשים . . .הבלוג כולל עוד כל מיני סטטיסטיקות מעניינות שהוא אסף על התקופה הזו - Commits, Code reviews ועוד.אחד האנשים שכתב הרבה מהסביבות הפנימיות, ומשאיר את ה-Community במצב מאוד טוב ובריא - אומר שיהיה נחמד להשתמש בשפה ולא רק לפתח אותה.מצד אחד עצוב, מצד שני מגיע לו הרבה קרדיט על תרומה משמעותית.ולענייני Security - רן קיבל לפני כמה שבועות שיחה מעניינת ממספר פרטי . . .שיחה באנגלית, לא נשמע בריטי או אמריקאי, מבטא כבד . . . נשמע כמו התחלה של שיחה על כנס כלשהו.הדובר עדכן על כך ש”מחשב ה-Windows” ככל הנראה נפרץ ומבצע “פעילות חשודה”. האדם שהתקשר אמר שהוא “מטעם Windows” וביקש לבצע מספר פעולות.בהתחלה נשמע הזוי ו”על מי מנסים לעבוד?” - ומצד שני אולי יהיה נחמד לשחק עם זה קצת… לא שווה את השיחה?רן המשיך ומדי פעם שאל שוב מהיכן מגיעה השיחה (מה זאת אומרת? “מ-Windows!”, בסיאטל…)מישהו ב-Microsoft כנראה היה עונה Redmond“איך אתה יודע שהמחשב שלי?” - “הוא רשום על שמך”. מוזר, לא היה כנראה מחשב Windows רשום על רן כבר הרבה שנים…ואז היה צריך לגשת לאיזשהו אתר - ואז הגיעה שיחה אחרת יותר חשובה והיה צריך להפסיק את המשחק.כנראה שהשלב הבא היה להוריד משהו ולהריץ אותו - ואז אכן המחשב יהיה פרוץ. סוג של חיזוי עתידות…לעיניינו - השקעה די מרשימה: מצאו שם וטלפון, חייגו מחוץ לישראל (לא בטוח - בהמשך האייטם)האם זה משתלם? מה אחוזי ההצלחה ומה עושים עם זה?(דותן) קרה לנו מקרה דומה לפני שנה ולפני שנתיים - ותמיד אלו היו שיחות אל מישהו שמתעסק ב-DevOps או Infrastructure או משהו קשור - יכול להיות שמטרגטים מקצועות?ולמשהו יותר חמור - פוסט של רן בר זיק, שבו הוא מתאר את הכשלים שהיו באפליקצית אלקטור היה הרבה בחדשות, אז רק תקציר - מדובר באפליקציה שנמצאת בשימוש מפלגת הליכוד על מנת לנהל את הקמפיין ולהיות בקשר עם הבוחריםמדובר במעיין פורטל / אפליקציית ווב שבמאגרי המידע שלה יש גישה לכל מאגר הבוחרים בישראל - משהו כמו 6.5 מיליון אזרחים, כתובות מספרי טלפון . . .  כל זה כל כך קל לפריצה שזה די גובל בפשע.שימוש בכלי הפריצה “דפדפן”, כפתור-ימיני View source ומשם מהר מאוד אל סיסמאות ה-Admin . . . זה ספציפית כבר לא קיים (?), אבל כנראה היה פתוח לא מעט זמן ואפשר פשוט להוריד את כל פנקס הבוחרים של ישראל.יש על זה כמובן פרק ב-CyberCyber - האגרון 2: פנקס הבוחרים המלא דלף לרשת דרך הליכודאולי משם הגיעו הפרטים של רן מהאייטם הקודם?בכל אופן, רמת החשיפה של כל אזרחי ישראל הרבה יותר חמורה כרגע, כולל לא מעט פרטים - וזה כשל אבטחתי נוראי ברמה הלאומית, גם ברמת המידע שנחשף וגם בקלות בה ניתן היה להשיג אותו.כל כך קל שזה מכעיס. רק צריך ללבוש קפוצ’ון . . .עכשיו זו פשוט פצצת זמן שממתינה.(דותן) רגע - אז אפשר להצביע דרך הדבר הזה? להכניס רשומה . . .גאוני.אפשר לחשוב רגע על מגוון המחדלים שכנראה היו פה - כל מאגר הבוחרים נמצא במקום שמוגן בסך הכל ע”י סיסמא (ב-Clear text כמובן)ה-URL של הסיסמאות פשוט זמין בתוך אחד מעמודי ה-Web הלא מוגניםבגדול - ביטוי המפתח הוא “מישהו תכנן”. לא נראה ככה . . .המון דברים שגם אם עושים מהר וחפיף - מי שומר סיסמאות ב-Plain text בדף Web? מסתבר שיש.תעודת עניות להמון גורמים בשרשרת.חשבתם שזה נגמר? אחרי החשיפה: פרטי 6.4 מ' ישראלים ממשיכים לדלוףוזה פשוט לא מפסיק . . .לנשום עמוק . . .בשבוע שעבר התקיים כנס GopherconILהכנס התקיים כבר, אבל תוכלו לצפות בהרצאות המוקלטות, לכשיפורסמו.גם רן וגם אלון דיברו בכנסרן דיבר על go-grpc-channelz (דיברנו על זה בבאמפרס 61) - מספק visibility לתוך gRPC, שהיא מערכת RPC רובסטית וטובה, אבל גם מורכבת - והפרויקט מספק עוד Visibility, בעיקר לתוך ה-Clients (לאן מחובר, איך עובד ה-Load balancing, וכו’), והכל בממשק וובי די פשוט.מעיין הרצאת Ignite של 10 דקותאלון דיבר על Go is Getting Rusty - לאורך השנים דיברנו הרבה כאן על Go ו-Rustהאם צריך בכלל להשוות בינהן, קצת על מה זה Rust ולמה זה מעניין . . בקרוב הוידאו.אחת הדמויות הבולטות בעולם ה-Go נכח גם - Dave Cheneyביקר בישראל, היה ה-Keynote speaker וגם העביר סדנא שנזכיר עוד מעט.בעניין דומה ל Go ו-Rust - פוסט של חברת Discord שמדבר על למה הם עברו מ-Go ל-Rust באחד ה-Services שלהם.כתוב יפה, מסביר כל מיני מגבלות (ה-Garbage collection של Go…)הנושא לא מפתיע - כל מי שעובד עם שפה שהיא Garbage-collected חייב להיות מודע למגבלות של ה-Garbage collector. נכון שיש כאלו כמו של JVM שמאפשרות קצת Tuning ואולי במקרה של  Discord היה אפשר להשמש ב-Java או ב-Kotlin כדי לספק את הצרכים שלהם עם ה - Garbage collector, מה שב-Go כמעט שאי אפשר לעשות.בסופו של דבר, אם חשוב לכם Raw Performance ושלא יהיו עיכובים אפילו לא באחוזון ה-99 ועם Latency מאוד נמוך (פחות מ-1mS) - יכול להיות ששפה שהיא Garbage-collected לא תתאים לכם.צריך להכיר את המגבלות של הכלים - שפות שהן Garbage-collected בדרך כלל יותר קלות לפיתוח אבל יש להן מגבלות, וכאן הן מוצגות מאוד יפה ונראה שהמעבר ל-Rust מוצדק.(אלון) אני חושב שחלק מהעניין נובע מההשוואה של Go ל-++C, וזה לא כל כך נכון - אולי לפעמים מגיעים ל-Performance שמתקרב ל-++C, אבל זה לא שם בהרבה מקרים ולא באמת תחליף בהרבה מקומות.(רן) תלוי בהקשר - במקומות שבהם אתה כותב ++C אבל לא מגרד את יכולות הניהול זכרון אז זה לא כל כך משנה; במקרה הזה היה להם הרבה מאוד דאטה - Caches גדולים ואינטנסיביים אבל עם מעט מאוד מקרי Revocation - ואז ה - Garbage collector עדיין נאלץ לעבור על כל האובייקטים וזה לקח הרבה זמן.אלון - בהמשך ל Dave Cheney ו - GopherconIL - הוא העביר גם Workshop (יותר הרצאה-מאוד-ארוכה)כתב על זה- Practical Go: Real world advice for writing maintainable Go programsחלק מספר שהוא כותב - ואלו משהו כמו עשרת הפרקים הראשונים.מגוון נושאים - הצהרה על משתנים ושמות משתנים, מתי להשתמש במה, הערות, Style . . .מסביר איך עובד nil, שזה משהו קצת הזוי ב-Go (מסתבר שלא כל ה nil-ים זהים…)ועוד רשימה ארוכה . . . מאוד ארוך אבל מעיין - נכנס לאיך הוא רואה את הדברים וזו נקודת פתיחה מעניינת לכל מי שכותב ב-Go.(רן) גם השתתפתי בסדנא וקראתי (באמת ארוך) - כתוב יפה מאוד ומסביר דברים יפה ולא חוסך בדוגמאות.מה שכן - לא בהכרח הייתי ממליץ למי שרק עכשיו לומד את השפה אלא למי שכותב כבר כמה חודשים ואז הדברים יהיו יותר הגיוניים.הוא כותב על דברים שהם Battle-tested, ומי שרק לומד את השפה לא בהכרח צריך להבין את כל מקרי הקצה של טיפול ב-Channels למשל, אבל בהחלט קריאה מומלצת.יש כאן ענייני שמות משתנים, החלק של ה-nil ועוד כמה דברים שיכולים כן להיות רלוונטיים, ואולי אחר כך רק מי שכותב ממש ב-Go יכול להמשיך.שפת תכנות חדשה שמיקרוסופט הוציאו בשם veronaמוגדרת כ “Research programming language for concurrent ownership”לא ברור מה המוטיבציה לשפת Research חדשה, אבל לקחו הרבה עקרונות מ-Rust וניסו לבנות שפת Research.מדובר ב-Research במובן של שפות או בהקשר של Data Science? לא לגמרי ברור(דותן) נראה כמו מחקר על שפות תכנות - עוד סוג של Meta (שפת תכנות שחוקרת שפות תכנות, ד”ש ל Inception)(רן) חושב ש-Scala הייתה קצת כזו בתחילת הדרך, ומחבר השפה (Martin Odersky) אמר שיש בה כל מיני דברים שהוא תמיד רצה לנסות בשפות ועכשיו יש לו מגרש משחקים לנסות . . . אולי זה מסביר את זה.בכל מקרה, לא ברור אם יצא מזה משהו, אבל יש כאן הרבה עקרונות מ-Rust (וגם מ-Pony, שאנחנו פחות מכירים - מפתחים שהיו פעם חלק מחברה ואז המשיכו לבד, משהו כזה)המימוש של verona עצמה הוא ב++C.שירות של AWS בשם Amazon Braket - והפעם: Explore and experiment with quantum computingמה אפשר לעשות היום, כשחישוב קוונטי זה עדיין לא משהו עם הרבה יישומים בימים אלו?לא לגמרי ברור, אבל אולי מישהו מהתחום יביןנסו את Lex Fridman כאן:  Scott Aaronson: Quantum Computing(רן) אני יכול לנחש שאולי להריץ איזשהו סימולטור ל - Quantum Computing(דותן) או שאחרי ההכרזה של Google על Quantum supremacy מישהו ב-AWS רצה מהר להריץ על משהו עם “Quantum”.(רן) אפשר לראות תועלת בדבר כזה, גם אם אין לך גישה למחשב קוונטי אמיתי - אפשר ללמוד ע”י סימולטור את השפות והעקרונות. זה לא יפרוץ RSA בשעתיים, אבל אפשר ללמוד עקרונות ברמה טובה.בקיצור - אם אתה באמת צריך, בסוף זה ירוץ ב - GCP. . . ואם כבר GCP - נראה שהייתה שם התלבטות האם לנטוש או לא, והחליטו כן עם זה (זאת אומרת לא לנטוש), ובכל הכח - ולהיות a top-two cloud player by 2023זה לא ממש עתיד רחוק עבור מטרה כזו, וזה אומר שהם כנראה הולכים לשים הרבה משאבים על זה. יש להם - אבל גם לאחרים יש.נראה מה יהיה עם העננים - ומעניין איך זה בכלל יצא החוצה (נראה כמו דיון פנימי די סודי של Google)שירות חדש - Pulumiהכותרת היא Modern Infrastructure as Code - מתחרה ל Terraform - פתוח, חינמי וכו’.בשונה מ Infrastructure-as-a-YAML, שכבר אמרנו מה אנחנו חושבים עליו.נראה מעניין, כולל גם השוואה בינם לבין Terraform(דותן) זה דווקא נראה כמו פרויקט שקצת מעצבן אותי - עושה מעיין Singularity ואומרים שהם יכולים לעשות משהו מעבר ל “Declarative” של Terraform, עם עטיפה מוצרית והכל - אבל אם כבר מדברים על חופש, למה אני לא יכול פשוט לכתוב את כל זה בעצמי? כל העניין ב - Declarative הוא שאני רוצה שתיהיה מסגרת שגם תגביל אותי.(אלון) אני חושב שחלק מהעניין הוא שאתה גם Cross-Cloud עם זה . . .

פרק מספר 384 של רברס עם פלטפורמה - קרבורטור מספר 28: אורי ורן מקריבים צפייה בגמר הכוכב הבא לאירוויזיון ומארחים בכרכור את נתי שלום (Cloudify) לשיחה השנתית על תחזיות לשנת 2020 (ה-10 וחצי חודשים שנותרו). מצמידים לכל דבר הסתברות ומקסימום מתקנים ב-1 באפריל.נתי מתמקד בענייני Infrastructure ו-Cloud, אז צפו שפחות נתמקד ב-iPhone הבא וכו’.מבוסס על מקרה אמיתיחלק ראשון (ולא בהכרח טריויואלי למי שמגיע מעולמות ה-Enterprise) - עד כמה רחוק ארגונים יילכו עם Public Clouds?אורי בטח יזדהה עם תיאוריית ה”זה לא הולך לקרות כל כך מהר” (הקרבורטור הקודם על k8s and multi-cloud), אבל מכל הארגונים שאני (נתי) מדבר איתם זה על האג’נדה - והשאלה היא רק “כמה מהר?”וכן - אנחנו מדברים על ארגונים ”מסורתיים” - פיננסיים וכו’ - עם “רגולציה מפה ועד להודעה חדשה” והמון סיבות למה לא לעבור.עכשיו הם פתאום נמדדים על עד כמה מהר הם עוברים. זה עדיין לא קל להם, אבל השיחה היא רק על איך עוזרים להם לעבור, כי אין כבר משהו אחר.במקביל - מבחינת שחקני ה-Private Cloud בעולם הזה (בעיקר OpenStack) - נראה שהקרב כבר הוכרעמדהים איך בתוך 10 שנים הטכנולגיה הגיע ל-Peek מאוד גבוה ואז כמעט ונעלמה במושגים של טרנדים טכנולוגיים, לפחות בהיקפים האלה.באופן מפתיע, VMWare שכולם כבר הספידו מקבלים עוד כמה שנים של Graceזה תמיד נראה זמני ושה-Public Clouds מתישהו ינגסו גם בהם, אבל בינתיים הם מנסים “להיות חברים”גם זה שינוי מאוד משמעותי עבורם - כולל כמה רכישות משמעותיות וניסיון ללכת All-in על Kubernetes. (רן) אתמול הייתי בכנס שבו אחד המרצים היה איש Heptio לשעבר שעכשיו עובד ב-VMWare (אחת הרכישות המוקדמות שלהם בתחום).יש גם את ההשקה של AWS סביב VMWare - היכולת להריץ VMWare API על תשתיות של AWS, מה שפונה ללקוחות שכבר משתמשים ב- VMWare וכבר יש להם את ה-Skill-set והידע ולא רוצים “לאבד” אותו במעבר לענן הציבורי - ובכך “להרחיק את המעבר” ולשמר את הלקוחותבינתיים זה עובד להם לא רעחלק מזה נובע מכך ש-OpenStack נשלט על ידי RedHat - שבכלל רוצים לקדם את OpenShift ו-Kubernetes ו-OpenStack פחות מעניין אותם, מה שדי תורם למוות האיטי שלו.(אורי) אז מה באמת הבשורה ארוכת הטווח של VMWare?אין להם לדעתי (נתי), לפחות כרגע.הם קונים זמן, אבל האסטרטגיה שלהם היא סביב Kubernetes - ההנחה היא שארגונים, גם כשיעברו ל-Public Clouds, עדיין זקוקים לעזרה עם התשתית, ואנחנו (VMWare) נותנים פתרון שמקל על Enterprise להשתמש בתשתיות של Public Clouds, על ידי מעטפת ו-Dumbing-Down של התשתיות - לקחו את התשתיות המורכבות וייצרו שכבה “שמנרמלת את הסיבוכיות”.זה היה המהלך שלהם בעבר והם טוענים (במידה רבה של צדק) שהצורך הזה קיים גם (ואולי אפילו יותר) בעולם ה-Public Cloud.עוד שאלה לנקודת הזמן שבין 2019 ל - 2020: האם בראייה שלך הגענו ל-Game-Over: האם Kubernetes ניצח את עולם ה-Virtual Machines?המשפט שיוצא ממני הכי הרבה הוא “The only constant is change” . . . אין דבר כזה “Game Over” ואין דבר כזה ש”Kubernetes יכבוש את העולם”כולנו בוגרי Docker ובוגרי Ruby on Rails ועוד הרבה טכנולוגיות, והדינמיקה הזו (של לימוד טכנולוגיות חדשות כל הזמן) אפילו מתעצמת בעולם של Public Clouds, כך שיהיו עוד דברים.היום Docker הוא עדיין יחסית מסובך (ביחס לערך שהוא נותן) - ויהיו עוד אלטרנטיבות, שמישהו כנראה כבר עובד עליהן באיזושהי צורה.סביר להניח ש-AWS פחות אוהבים את זה ש-Docker הפך לסטנדרט כי זה קצת מייתר אותם והם ינסו לדחוף . . .למה?כיוון שהיתרון של AWS לעומת GCP למשל הוא שהם פיתחו הרבה מאוד IP סביב ה-Hypervisor של KVM, בעוד Google שהגיעו למצב ש-90% מה-Workload שלהם רץ על Containers ואז אין צורך בכלל ב-Hypervisor - ובכך הם “קפצו מעל” העולם של ה-Virtual Machines.בשלב הזה AWS יצאו עם הכרזה על Serverless - מעיין Pivot מחדש לעולם של containers ושל Kubernetes.שעוד לא לגמרי תפס . . .אם מסתכלים על Containers - זה כבר תפס; אם מסתכלים על Kubernetes, הוא יחסית במקום לא רע בכלל (במדדי Adoption), גם מבחינת כמות התורמים, גם מבחינת איכות הקוד ובכלל איכות הפרויקט; ב-Enterprises הוא במקום לא רע בכלל.ועדיין - יש סימן שאלה לא קטן סביב השאלה של כמה זמן זה יחזיק.כמו כל דבר - אימפריות נופלות בסוף (לאט?)בזמן האחרון דווקא די מהר . . . אם היינו עורכים את השיחה הזו לפני 2-3 שנים על Docker ועל Swarm למי שעוד מכיר, היינו מדברים על למה זה יותר גדול מ-Kubernetes.בדיעבד Swarm הצליח קצת פחות ו-Kubernetes די ניצח את הקרב. היו סימנים, ועדיין.אחנו עוסקים בתחזיות ועדיין מעניין לשמוע - אתה אומר שכל ה-Enterprises הגדולים עובדים לענן וזו כבר לא תחזית אלא משהו שכבר קורה. למה? כסף?שאלה חשובה, ואולי למי שבא מעולם הסטארט-אפים היא טריוויאלית, ועדיין - רובם פשוט נכשלו בניסיון להקים Private Cloud.בנו תוכניות מאוד אגרסיביות - ולא הצליחו, מכל מיני סיבות (אין Skill-set, אין את -DNA, . . .)ומה לגבי חברות שכבר יש להן?אף אחד לא באמת מרוצה, בלשון המעטה . . . גם ברמת העלויות (הגבוהות מהמצופה) וגם ברמת היחידות העסקיות והתוצרים שמצופה מהן להביא לשוק - הם תקועים עם תשתית מאוד לא אג’ילית וכשהם רואים את ה-Public Clouds ואת המהירות שבא הם מאפשרים להביא מוצרים לשוק עם ה-IT שלהם הם מתוסכלים.בשלב הזה הארגון, ברמת ה-Business, עומד מול השאלה של האם לתת ליחידה העסקית להשיק מוצר מהר או מכתיב להם “לחיות” עם ה-IT שיש - ואז זה האינטרס הפנימי של לחיות עם ה-IT הקיים אל מול Delivery מהיר?הרי ברור שברמת השורה התחתונה העסקית יותר חשוב להביא את הפתרון מהר לשוק.כאן נכנסת גם “חרב הרגולציה”, שעדיין מחזיקה את הארגונים האלה על Private Cloud.גם כאן וה-Public Clouds עשו הרבה מאוד עבודה בתחום הזה ויצרו פתרונות כמו GovCloud כדי להפוך גם את הנקודה הזו ללא רלוונטית.וחוץ מזה יש גם פתרונות Private Cloud - כמו AWS Outposts ואת Azure Stack.כמעט כל הסיבות שהיו לשימוש ב-Private Cloud הפכו ללא רלוונטיות, והמעבר ל-Public Cloud הפך לכמעט “לא בעיה”.אז גם Enterprises רוצים לעבור ל - Private Cloud. מה התחזית ל-2020?בהקשר הזה יש הרבה מאוד שיח לגבי Multi-Cloud - כבר לא Public Cloud כן או לא אלא שיחות (גם אם רובן הן ציניות) לגבי “למה צריך Multi-Cloud?” ו”הרבה יותר טוב לעבוד עם Cloud אחד שיפתור לך את כל הבעיות בעולם”.גם כאן חשוב לציין שיש הבדל בין Multi-Cloud (כמה Public Clouds) לבין Hybrid Cloud (בהקשר של Private & Public).כאן הטענה שלי היא שזה לא שארגון יושב ובוחר “אני הולך להיות Multi-Cloud” - אלא דומה יותר לבחירה “בעולם הקודם” בין Unix ל-Windows - היו ארגונים שהחליטו שהם Windows-only, והמציאות הכתיבה להם להיות גם Linux, בין אם זה בדלת האחורית או בדלת הקדמית (רכישות וכו’, היה בפרק על Multi-Cloud גם כן).בדיוק באותו אופן זה קורה עם Public Clouds - יש ספקי ענן ויש שירותים של ספקי ענן, לדגומא BigQuery שאנשים אוהבים ורוצים - אז גם אם אני עובד עם Azure, אני עדיין רוצה לעשות את ה-Analytics עם GCP.באופן דומה יש את Windows שרץ יפה עם Azure ונתמך ע”י מיקרוסופט ויש לזה Affinity מסויים.כמו בשיחה על Outbrain , אין לנו ספק אחד שטוב בהכל.(אורי) בוא נודה על האמת - ארגונים גדלים גם ברכישות . . .נכון. סיבה אחת היא שלא כולם שווים, והשנייה היא אכן רכישות.בשני המקרים זו מציאות שנכפית - זה לא שמישהו מחליט ללכת על Multi-Cloud אלא זו מציאות שארגונים מתגלגלים אליה, ואתה מוצא את עצמך בעולם של Multi-Cloud.לכן אני חושב שזו מציאות שאם לא תתכנן שלשם אתה הולך, בין אם תרצה או לא תרצה - תמצא את עצמך בכאוס שבו יש הרבה מאוד דברים לא עקביים (Consistent) ותגדל לתוך מציאות שאין לך עבורה פתרון.(אורי) ואז האם האמירה היא לא שהמציאות של Multi Cloud זה דבר שקורה (וגם בין Private ל-Hybrid), או כי רכשתי חברה או כי אני עושה פרוייקטים בטכנולוגיות חדשות כשעדיין “מה לעשות שה-Mainframe שלי ישאר כמו שהוא וה-Transnational Data שלי ישאר ב-Oracle כי אני בנק וככה זה”.כן, זה ה-Hybrid Cloud והיו לנו כמה שיחות עם לקוחות שאמרנו לנו “יש לנו שנה לעבור ל-Public Cloud”.במשך שנה עשינו את אותן שיחות והצלחנו להעביר רק 3 אפליקציות -90% עדיין לא עברו וזה כנראה הולך לקחת כמה שנים טובות - ויש מצב שחלק בכלל לא נרצה להעביר.המציאות של Public vs. Private, במיוחד עבור מי שכבר מושקעים ב-Private, תלווה אותנו גם לאורך זמן - אבל יש מגמה עם ראש חץ מאוד ברור - מקרים של Green-field ילכו ויכתבו מראש לסביבה של Public Cloud ודברים שהם Legacy או יותר מורכבים עם עם רגולציה משמעותית (Security) עדיין ישארו ב-Private - אבל זה ילך ויצטמצם.הסיפור הזה על Hybrid ו - Multi-Cloud אותנו לנושא הבא - Networking: אם פעם הכל היה יושב “אצלך” ב - Data Center והייתה לך שליטה על כל ה - Networking, עכשיו את גם צריך איזושהי דרך לשלוט ברשת כולה, שכנראה מפוזרת בכל מיני מקומות בעולם ואצל Vendors שונים ברחבי העולם . . .השינוי הוא הרבה יותר מזה - וזה משהו שאנשים עוד לא לגמרי מפנימים, כי אני חושב שיש כאן גם הרבה מקום לחדשנות ולחשיבה הזו, וחלק מהחברות כבר מנצלות את החשיבה הזוה - Cloud הפך ל - Network.בעבר ה - Network היה אוסף של Switches ו - Wires ו - Firewalls, והיית צריך להרכיב את כל הרכיבים האלה יחד כשהקו היה מעיין קו אינטרנט שכולם היו מתחברים אליו או איזשהו LAN פנימי.היום לכל אחד מה - Public Clouds יש Point  of Presence שדי קרוב אליך - ואתה במרחק נגיעה מתשתית שכבר יש בה הכל: את הראוטר, ה-Firewalls - הכל נגיש ב-API ואתה כבר לא צריך לרכוש Devices נפרדים, רק לעבוד עם ה-API ולקנפג (Configure) אותם נכון.יש חברות שבנו עולם שלם סביב הדבר הזה - למשל Cato Networks בארץ (של שלמה קרמר, ממייסדי Check Point), שבנו מוצר שכל התפיסה שלו הייתה סביב ה-”Last Mile” לתוך ה-Cloud, כך שכל הגישה שלך וכל התקשורת בין המשרדים והתשתיות עובדים דרך “ענן וירטואלי”.בנו מזה פתרון וקראו לו SD-WAN (ועכשיו קוראים לזה אולי בשם אחר) - וזו תפיסה אחרת של Networking: כבר לא חיבור בין Devices, כשה-Cloud הוא עוד End-Point, אלא ה-Cloud הוא ה-Network, ועכשיו אני צריך לפתור את בעיית ה-”Last Mile” ואיך לקנפג תשתיות שכבר קיימות בענן במידה לא מועטה.היום בענן יש כמעט את כל סט שירותי הרשת

פרק מספר 64 של באמפרס (383 למניין רברס עם פלטפורמה) - רן, אלון ודותן בבוקר גשום של תחילת ינואר (זהירות בשטפונות!) עם סקירה של טכנולוגיות ודברים מעניינים מהזמן האחרון.רן - שפה חדשה (לפחות לרן) בשם CUEשפת קונפיגורציה עם כמה פיצ’רים מעניינים, מימוש ב - Go ע”י מישהו ב - Google איפשהו באירופה.נניח שיש לכם תוכנית שמקבלת קובץ קוניפיגורציה (כקלט), או שאתם עובדים עם Kubernetes שצריך לקבל עשרות (או מאות) קבצי yml. - כנראה שיש לכם כמה בעיות בסיפור הזה:קודם כל - יש הרבה חזרות ואתם רוצים לעשות re-use לאיזשהו “אי של קונפיגורציה” במקום אחר, או אולי לקבע משתנים מסויימים שרלוונטיים בכמה מקומות/חוץ מזה - ולידציה: גם Data Types (אם אתם מצפים ל String כדאי שלא תקבלו Integer וכו’) וגם מבחינה לוגית (המינימום קטן או שווה למקסימום; גיל של אדם הוא לא 500 וכו’)את הבעיה הראשונה (יכולות re-use) שפת CUE לא כל כך פותרת . . . בשביל זה יש שפות אחרות (כמו Dhall למשל)שפת CUE כן פותרת יפה את הבעיה השנייה - היכולת להגדיר סכמה ולעשות ולידציה לסכמה הזו.לדוגמא - אפשר לקחת בנאדם ולהגדיר שיש לו שם פרטי, שם משפחה וגיל, ועל כל אחד מהם אפשר להגדיר גם Data Types וגם ולידציות סכמטיות (הגיל לא גדול מ-120 ולא מתחת ל-0, שם פרטי חייב להיות קיים אבל שם אמצעי לא חובה וכו’), הכל ניתן להגדרה בקבצים שונים.החלק המעניין בכל הסיפור - בסופו של דבר CUE לוקחת הכל ועושה איחוד, במובן של Graph unification: אתם למעשה מגדירים סדרה של אילוצים (הגיל לא קטן מ-0 וכו’) והתוכנית בסופו של דבר צריכה לקבל איזשהו ערך ממשי - ועושה ולידציה על הערכים הללו, ע”י איחוד של של כל האילוצים בקבצים השונים.אם יש סתירה - צועק . . .מאוד מזכיר תכנות לוגי - מי שכתב פעם ל - ProLog או שפות לוגיות אחרות ימצא המון דימיון בין זה לבין הגישה של CUE לקונפיגורציה - יש אוסף של Constraints ושל עובדות ובסופו של דבר נעשה איחוד על כל הגרף הזה, והתוצאה היא איזשהו ערך מעשי לכל אחד מהמשתנים והאם הוא עומד בכל אחד מהאילוצים הללו.(אלון) חייב להגיד שזה מעצבן ברמות קיצוניות - שונא Text-based configurations, כי בסוף אתה צריך לפתח כלי כדי לתחזק את זה . . . אני בגישה של Configuration as Code תמיד, וכל ה - “.yml-י ענק” האלה, שמצריכים כלי לניהול ה - .yml ועוד שפת תכנות לנהל את הכלי שמנהל את ה - .yml ועוד שפה לשפה . . . חזרנו לקוד מההתחלה, אז למה?(דותן) אתה רומז ל - Kubernetes? לא רק . . .לכאורה ה - use case הראשון הוא Kubernetes, אבל יכולים להיות אחרים.בחלק מהמקרים אתה אכן בונה את ה - Service ואתה מגדיר את הקונפיגורציה אז אתה לא חייב לסבול; מצד שני - אם אתה משתמש בכלים אחרים (כן, לדוגמא Kubernetes), האם באמת יש לך ברירה?אתה יכול להשתמש בשפות אחרות שמייצרות .yml או .json, אבל גם שם תצטרך לפתור את אותן בעיות . . .(אלון) ברור, אבל אני כועס על כל מי שמפתח לי משהו שה - Interface  שלו הוא .yml, כי בסוף זה ניהיה מפלצת - ה”קונפיגורצית פח” הזו שאי אפשר לשלוט עליה ולוקח שבועיים לעדכן משהו ומצריכה “100 ולידציות”, במקום Configuration as Code שכבר היה מתקמפל ויש את כל מה שכבר קיים בשפות תכנות והיית יכול גם להוסיף טסטים על הקונפיגורציה, Canary ומה שבא לך - במקום זה אנחנו ממציאים טקסט, ועליו שפת תכנות, והיא לא מספיק טובה אז ממציאים עוד שפת תכנות - ובסוף תנהל הכל ב - Go. אז מה עשינו בזה?(דותן) קצת מזכיר את התקופה של ה - .xml - לפני 15-20 שנה - הייתה XSD כסכמה של ה-xml . . ראיתי גם משהו מאוד דומה ל-XSD בעולם של Kubernetes, משהו שמוסיפים על ה-yml-ים ומייצר עוד yml-ים, עם Rules וכו’ - לגמרי אותו הדבר, רק ש-yml יותר “קליל” מבחינת ה-syntax אבל זה לא אומר שבמהות זה לא אותו הדבר בסוף.(אלון) חזרנו לאותה בעיה . . אני מוכרח להודות שה-Plug-in של VScode ל-Kubernetes הוא להיט - מוצא ועושה מלא ולידציות וכו’.לא ברמה של CUE כנראה ועדיין  -אם אני מרים Service של Configuration as Code וזה משהו מורכב של יותר מ-4 שורות - עזוב אותך . . בוא ניהיה ריאליים: ברוב המקרים שינויים כאלה מגיעים עם גרסא.לפעמים רוצים לשנות משהו קטן, אבל אני מעדיף Code על פני Text Configuration ברוב המקרים.(רן) אתה לא בהכרח בדעת מיעוט - אני חושב שיש מקרים שבהם זה לגמרי ולידי, אבל לא בכל המקרים אפשר להכיל את זה.לתחזוקה של Configuration as a code יש הרבה יתרונות, אבל במקומות שבהם יש ממשק עם “פחות-מתכנתים” (אנשי Ops? . . .) לפעמים צריך לספק קונפיגורציה שלא כקוד, ולפעמים יש מערכות שלא אתה כתבת (Kubernetes) שאתה צריך להתממשק אליהן, ואתה לא בעל הבית.פרויקט מעניין אחר שהוכרז באחד הכנסים האחרונים של GitHub, שמטרתו לשמר פרויקטי קוד פתוח לדורות הבאים - GitHub Archive Programכמה מאות או אלפי הדורות באים (או כמה שהקורונה ייתן) . . .התחילו עם פרויקטים שלהם ואחר כך אפשר היה גם להגיש נוספים - העבירו לכמה מדיות שונות (כולל הדפסה על נייר) - והצפינו בבונקר אי שם ליד גרינלנד בקרבת הקוטב הצפוני, בשרשת איים בשם Svalbard archipelagoהארכיון לא מיועד אך ורק עבור GitHub (למשל, יש מצב שהארכיון עם דגימות זרעים של כמעט כל היבולים בעולם תופס שם מקום קצת יותר משמעותי), אבל עכשיו בין השאר יש שם גם פרויקטים בקוד פתוח שמגיעים לשם ונשמרים עבור הדורות הבאים, מתוך הנחה ששם זה ישמר יותר טוב.קצת מלחיץ שלא סומכים על הגיבויים של Azure, לא?מיועד כנראה עבור החייזרים שיגיעו מתישהו וינסו לקרוא את האימוג’ים.וכיוון שלא דיברנו עדיין על Kubernetes היום - הנה בלוג של מישהו שעובד בגוגל (כן, על Kubernetes) וכתב על מה שהוא חושב שהולך להיות מעניין באיזור של Kubernetes ב-2020אנחנו רק בתחילת השנה, יהיו תחזיות נוספות . . .יש 5-6 תחזיות, מעניינת במיוחד זו של CRD explosion (הכוונה ל Common Resource Definitions)מדובר ב-Data Type שמגדירים ב Kubernetes (כן אלון - ב YAML) - ומאפשר לתאר Entities “שלך” (מה - Business domain שלך) עבור Kubernetes, ואז לעשות איתם כל מיני דברים מעניינים.למשל - אפשר להגדיר Services מיוחדים, כך שעבור כל Service כזה צריך לפחות שלושה Pods וה-Monitoring עם Prometheus, או משהו בסגנון.אז גם אפשר לקחת את ה-CRD שלך ולתרגם אותו באמצעות כלי נוסף (Operator)ה-CRD זו ההגדרה (Syntax), וה-Operator זה מה שמתגרם אותו למשהו שהוא יותר Actionable - ולשניהם יחד יש כוח מאוד גדול.כותב הבלוג צופה CRD explosion - שזה הולך להיות מאוד פופלארי ונראה הרבה כאלה, עד כדי “CRD Hubs” שיכילו את הנפוצים והשימושיים יותר (רוצים להתקין Redis? או Kafka? כאלה)נכון, יש גם פתרונות אחרים ב - Kubernetes (החל מהגדרה “בידיים” דרך מנהלי חבילות למיניהם), אבל הוא צופה שכולם בסוף “יתנקזו” לכיוון של CRD.(אלון) זה מחבר אותי למשהו מהתקופה האחרונה - תהיות בטוויטר לגבי ההייפ סביב Kubernetes: הרי בסוף אפשר לקבל הכל ב-Cloud, גם אם קצת (?) יותר קשה לניהול לבד עם ה-APIs של כל ספק.כאן מדובר על אפליקציות שהן לא Kubernetes אבל עם הקונפיגורציה של Kubernetes, וזו נקודה מאוד מעניינתנשמע הגיוני שניהול של ה-Cloud יהיה ניהול של AWS או GCP או Azure וכו’, עם ממשק אחיד, כך שתוכל לייתר את Kubernetes בעוד כמה שנים, כי יהיה אפשר לעשות הכל ישירות על ה-Cloudאולי לא ב-2020, אבל אם התחזית היא שנראה אפליקציות על בסיס אותה הקונפיגורציה השנה אז כנראה שבסוף נגיע לשם - ו-Kubernetes ישאר נקודת מעבר לעולם אבסטרקציה אחר.(רן) אגב - CRDs כאלה קיימים לא מעט כבר היום - יש CRD שמנהל עבורך S3 (ליצור Bucket או לקבוע הרשאות למשל) - מפעיל אופרטור שמבצע את הפעולה, קצת כמו שכלים כמו Chef או Puppet עובדים.ובהמשך למה שאלון אמר - ברגע שהחלפנו את ה-API הזה, אפשר להחליף את Kubernetes בכלי אחר מלמטה, עם אותו API רק במימוש אחר.אלון - אז נמשיך עם Kubernetes . . . כלי שפותח ב-Google בשם SKAFFOLD - ומאפשר Local K8s developmentעושה Init ,מכין את כל ה-YAML, כותב Dokcer, עושה את ה-Deploy . . .נראה חמוד, לא יצא לי (אלון) לעבוד איתו עדיין, אבל נראה מבטיח, גם אם עדיין שונא YAML.(דותן) מרגיש בנוח עם זה שיש עוד מישהו בסירה…שאלה למי שכן אוהב Kubernetes - כמה פעמים אתם מעדכנים Kubernetes בגלל בעיות Security? (רן) קשה להגיד . . . לא בהכרח כמי שאוהב ולא כמי שמריץ ב-Production. (אלון) אוהב, לא סגור על קצב העדכון, רץ יפה, יש דברים שאני אוהב ודברים שלא. עד רמה מסויימת של Scale זה מאוד נוח, אחר כך צריך ממש להתעסק עם הקונפיגורציות וצריך “להרים את מכסה המנוע” וזה מתחיל להיות מעצבן.(דותן) יש אתגר במקרה למשל בו יש לך לקוח ואתה מחוייב מולו חוזית לתקן בעיה תוך למשל שבועיים - בסביבה עם כל כך הרבה חלקים נעים, איך אפשר להגיע למצב שבו אתה משדרג כל הזמן? זו שאלה קשה, ולא קיבלתי בינתיים תשובה טובה.(אלון) אנחנו רצים על GCP עם ה-Managed Kubernetes שלהם, אז דווקא בנושא של העדכונים זה יותר קל וזה קורה (לפחות בתיאוריה) בלי Down-time.(דותן) יש SLA?כן, לא זוכר מה בדיוקוזה מעניין - כי אתה מבטיח SLA ללקוח שלך - ואתה תלוי בתגובה שלהם ואין לך ממש מה לעשות עם זהזה נכון גם עבור למשל VM שרץ על AWS ויש בו בעיית אבטחה.השאלה מה הסבירות שזה יקרה …אני (אלון) מאמין שדווקא בהקשר של בעיות אבטחה של Kubernetes הענן של Google יהיה מהיר יותר, אבל זו רק הנחה.(דותן) יש מסמך על Penetration tests שהזכרנו בעבר - ויש דברים כאלה (אולי לא קריטיים, אבל יש), כך שכבר עכשיו אם יש לך לקוחות עם דרישות גבוהות עלול להיות לך ניגוד אינטרסים (או לפחות אי התאמה)(אלון) יש להם מסמך על נושא ה-Security, שמדבר על ה-zones ומאיפה הם מתחילים בכל יום, מניח שעבור רמת Critical הם עושים את זה מהר, אבל צריך לקרוא יותר לעומק כדי להבין.קשה לי להאמין שכאן תיהיה הבעיה שלך, כי אפשר להגיד את זה על המון דברים - מוצאים בעיות אבטחה כל יום, כמו לדוגמא מה שהיה עם המעבדים של אינטל (ולוקח זמן להחליף את כל המעבדים…).פה מדובר במטרה נעה . . . בכל מקרה, בשתי חברות שעבדתי בהן הריצו בדיקה על Kubernetes, ופעמיים זה נפל על ענייני Security.אלון יחזור עם יותר פרטים . . .ועוד אתר (שלפעמים לא עובד, תמחקו cookies וזה עוזר) -  Graphviz.it - שמאפשר ליצור גרפים בsyntax פשוט וחמודשפה טקסטואלית שמאפשרת לתאר גרף - ואז זה יוצר את הגרף המתוארצורות שונות, קשתות בצבעים שוניםאפשר ליצור עצים וכל מיני צורות שונות ומשונות - וזה מאוד קל ופשוט לייצג עם

פרק מספר 382 של רברס עם פלטפורמה - קרבורטור מספר 27: אורי ורן מארחים בכרכור לפרק מיוחד של הקרבורטור את נתי שלום (היזם של חברת Cloudify) ואת אורית ירון (VP Cloud Platform ב - Outbrain) לשיחה על Kubernetes, בעיקר בהקשר של Multi-Clouds - מתי זה טוב ומתי זה רע ולמי.לפני הכל - אורית:בשש השנים האחרונות מבלה ב - Outbrain - מנהלת את קבוצת התשתיות - תשתיות ה - Cloud וה - On-Premise. לפני כן סטארטאפים, חברות גדולות - בעולם התשתיות.ונתי, למקרה ששכחתם - מגיע מ - Cloudify, לפני כן המקים של GigaSpaces שעוסקת באוטומציה של בסביבות ענן - ומשם הרקע עם Kubernetes.ולעניין - דיברנו כבר על Kubernetes ב - Outbrain (נגיד בשיחה עם שחף ואלכס בפרק 368 על Kubernetes and Dyploma at Outbrain), וגם לנתי יש לא מעט נסיון בנושא.היום אנחנו רוצים להתמקד בזוית המאוד ספציפית של ה  - Multi-cloud - ב - Outbrain משתמשים ב Multi-Cloud (אחרי שלפני כן לא עשו בכלל).אורי מדייק - הקמנו את ה - Cloud הפנימי שלנו - On-Premise. לגבי Multi-Cloud - אפשר להגיד שהייתה לנו “התנסות”, ויש מקום לדבר על זה.לנתי יש המון ניסיון בעולם התשתיות, וחלק משמעותי מזה זה Kubernetes.למה בכלל מעניין לדבר על Kubernetes בהקשר של Multi-Cloud? האם ישנה איזושהי סינרגיה בין הדברים?שאלה טובה . . . הסיבה העיקרית לכך ששני הדברים הללו הולכים יחד היא ש - Multi-Cloud זו חיה מאוד מורכבת ויש הרבה מאוד סוגים של Scenarios - יש את היכולת להעביר Workloads, שזו אוטופיה שלא באמת ממש מתקיימת (במציאות)יש את היכולת לעשות Interoperability - במשמעות של Workload שרץ בסביבה אחת ויכול “לדבר” עם Workload שרץ בסביבה אחרת.יש Data Synchronization . . .הנושא של Multi-Clouds ובכלל ה - Use Cases יכולים להיות מאוד מגוונים, ולאו דווקא בכפיפה אחת.השורה התחתונה - כשהשכבה המשותפת בין הסביבות הללו נמוכה (מעט משותף), הבעיה הופכת להיות מאוד מורכבת - להעביר VM, לצורך העניין, מענן לענן זה כמעט בלתי אפשרי (כל אחד עם הפורמטים שלו והסינרגיה שלו).ההקשר של Kubernetes מאוד פשוט - לייצר סביבת אבסטרקציה ל - Infrastructure במידה כזו או אחרתכתוצאה מכך שהיום כל ספקי הענן הגדולים תומכים ב - Kubernetes, היכולת הפרקטית (מעבר ליכולת הטכנית) להעביר Workloads מאחד לשני הופכת להיות יותר זמינה לעומת העבר, וזה מפשט משמעותית את החזון של היכולת להריץ את אותו ה - Workload בכמה סביבות שונות.אולי רגע ניקח מכאן צעד אחורה - למה בכלל Multi-Cloud? אמרנו שזו בעיה מורכבת . . . השאלה לאורית על מה בכלל גרם לכם (ב - Outbrain) להתפרש החוצה לעוד מקומות, כשברור שרמת הסיבוכיות שם הולכת להיות שונה (וכנראה גדולה יותר)? לצאת מהארון, במובן של לצאת מה - Rack . . .לכל סביבה ולכל ענן יש יתרונות שעומדים בפני עצמם, וברגע שאתה מגביל את עצמך ומחליט שאתה עובד רק On-Premise או רק ב-GCP או רק ב-AWS, אתה למעשה שם על עצמך הגבלות - ומפספס.אני תמיד מקבילה את זה לאהבה המאוד גדולה שלי לגלידה - כשאני הולכת לגלידריה, אני אף פעם לא בוחרת טעם אחד . . . תמיד מחפשת גם וגם (מי אמר קרמל מלוח?) - וזה מה שהביא אותנו לבוא ולהגיד שאנחנו יכולים להינות גם מהיתרונות של זה וגם מיתרונות של זה - מכל העולמות.השאלה היא האם גם לא סובלים מכל העולמות? ידוע בתעשייה שנכון - יש מה להרוויח, אבל יש גם הרבה ממה לסבול, ואולי Kubernetes קצת מקל על הסבל הזה באיזשהו אופן? בכל אופן זה נשמע כמו סיכון משמעותי.המפתח להתמודד עם הסיכון או עם הכאב הוא לבחור את ה - Workloads ואת ה - Scenarios שבאמת מתאימים ליתרונות של הענן.זאת אומרת - לא לבחור רנדומלית אלא לעשות איזושהי אנליזה מקדימה לפני שקופצים למים - מה בדיוק ה - Benefits - ורק אז לבחור.בהינתן התשתית של Outbrain לפני Kubernetes, אם לדמיין כמה שנים אחורה - זה בכלל נראה לכם כמו משהו Feasible באותה תקופה? ללכת ולהתפרש על Vendors נוספים, שונים לגמרי ממה שהיה לכם?(אורי) אני חושב שקודם כל - עבור Workloads שונים עשינו את זה לפני כן, לפעמים גם לא מבחירה - הרבה פעמים אתה קונה סטארטאפ (ככה יצא) עם טכנולוגיה שהיא לפני שלב ה - Scaling, כזו שבנו אותה על איזשהו Cloud - ואתה “יורש” את זה, ולומד לעבוד בסביבה אחרת עם Workloads שונים.(אורית) אנחנו גם הצענו את ה - Scenarios ואת ה - Workloads שהרוויחו מהמעבר לענן בלי קשר ל  Kubernetes, והעברנו אותם עוד לפני שהייתה לנו סביבת Kubernetes מלאה.אני חייבת לציין שאמנם לדחיפה שלנו לכיוון Kubernetes היה Benefit של Multi-Cloud, אבל יש לה גם Benefit מאוד גבוה כשעובדים בסביבה שהיא On-Premise, וזה אפשר לנו לנצל את המשאבים הפנימיים שלנו בצורה הרבה יותר יעילה ואפקטיבית.(אורי) בוא נאמר שב-Scenario שנתי דיבר עליו - ה”אוטופיה” של לקחת את אותו Workload “ולנשום” אותו לתוך Public Cloud - אנחנו עשינו את זה קודם, וקיבלנו את זה כ By-Product של המעבר ל Kubernetes, כך שהמעבר לא היה על מנת לקבל את היכולת הזו.אני יכול להגיד שלפחות מהחווייה שלי - עבדנו עם  Kubernetes ועברנו ל - Kubernetes - ויום אחד באו אלי גיא ואורית ואמרו לי “בעוד שבוע אנחנו פותחים ניסוי של Multi-cloud”שאלתי “מתי הספקתם לעשות את זה”? . . .זה לא היה טריויאלי, ואולי אורית תוכל להרחיב על הדבר הזה.מצד שני - זה גם לא היה “מאוד” מסובך, בהינתן  Kubernetesאני (נתי) רוצה להתייחס לשאלת ה - To Multi-Cloud or not Multi-Cloud - זה משהו שאני היום שוקד עליו, וחד משמעית אני אומר שאם אתה סטארטאפ שמתחיל ולא רוצה לסבך לעצמך את החיים - אין לך שום סיבה לחשוב על Multi-Cloud.כפי שאורי ציין, Multi-Cloud בהרבה מקרים זו לא בחירה אלא מציאות שנכפית עליךקצת דומה למה שקרה עם Linux ו - Windows וכל מיני מערכות אחרות - זה לא שאתה רוצה את השונות בהכרח כמו שהשונות היא מציאותשאתה גדל אליה מתוך אילוצים וצרכים (כמו רכישת חברות ודברים מהסוג הזה) - נוצרת סביבה הטרוגנית, ו - Multi-Cloud זה חלק מהדבר הזה.קצת כמו צ’אק נוריס - אתה לא בוחר Multi-Cloud אלא Multi-Cloud בוחר בך? בדיוק זה.אם יש לך את האפשרות לייצר Workload יותר פשוט וסביבה יותר הומוגנית, כשהכל רץ במקום אחד - go for it. ההמלצה היא לא להתחיל ב - Multi-Cloud ורק לחשוב Multi-Cloud כי זה הדבר הכי טוב עולם - זה בא עם מחיר ומורכבותלא הייתי נכנס לזה אם אני יכול שלא, אני נכנס לזה כי אין לי ברירה, או כשיש לי Workloads מסויימים שעבורם ה - Gain על ה - Complexity מספיק משמעותי וזה באמת כדאי.ההקשר של  Kubernetes הוא בהורדת החסם ששל המורכבות, כך שיש יותר מקרים שבהם זה כדאי ופחות מקרים שבהם זה לא, כשקודם לכן כמעט בכל המקרים ה - Complexity היה גדול מה - Gain.הדבר השני שיצא לי לדבר עליו בהקשר הזה של Multi-Cloud הוא שגם כאשר אתה מסתכל על Cloud בודד - ה - Clouds עצמם הם חיה מאוד מורכבת והטרוגניתיש הרבה סוגים של Databases, הרבה סוגים של Application Platforms - על אמאזון יש לך את הפלטרפורמה של Containers וגם את Managed Kubernetes, ויש את ה - PaaS שלהם - על כל דבר יש בין 2 ל-3 אופציות, כך שהדרישה להתמודד עם סביבה מורכבת קיימת גם סביבת Cloud בודד.אם אתה בונה נכון את ה - Practices של עבודה בסביבות מורכבות - זה חל על Single Cloud וכל Multi-Cloud כמעט באותה צורה.יש עוד Delta של Multi-Cloud שמגדילה את את המורכבות - אבל יש מאחוריה גם את הגמישותיש מקרים בהם הגמישות עולה על המורכבות ויש מקרים בהם המורכבות עולה על הגמישות - וזו נקודה שחשוב לציין.אמרתם שבאיזשהו שלב, עקב רכישה של חברות וכו’, ה - Multi-Cloud “נכפה” עליכם, אבל עדיין באופן מודע הלכתם לזה בשלב יותר מאוחר. מה הייתה המוטיבציה - Cost? ענייני Redundancy? מה הייתה המוטיבציה ללכת לכיוון הזה?(אורית) אנחנו התחלנו בסביבה שהיא “סביבת Research”, שהייתה מאוד גדולה - והיו לה הרבה מאוד דרישות לאלסטיות (Elasticity).לפעמים היה צורך הרבה מאוד משאבים, והיינו מוצאים את עצמנו לא מצליחים להדביק את הקצב, ומצד שני - בהרבה פרקי זמן היא הייתה עומדת Idle.מצד שני - בדומה להרבה סביבות Research, היא קיבלה עדיפות של “2nd Class Citizen”, ומצאנו את עצמנו בנקודה שבה היינו חייבים לעשות Refresh לסביבה, בין אם זה ב - On-Premise ובין עם באמצעות פתרון אחר.האלסטיות, יחד עם העובדה שזו סביבה שהיא Storage-intensive ו - Compute אלסטי - כל זה מאוד התאים ל Benefits המאוד ברורים שיש בענן.זה הביא אותנו לעשות בדיקה ואיזשהו POC של Evaluation, כי זה היה מבחינתנו הצעד האמיתי הראשון בסביבה אמיתית (ב-Scale גדול) של ענן.אחרי ה-POC הזה ראינו עד כמה זה הקל עלינו את החיים גם מבחינת אדמינסטרציה ומבחינת גמישותבכלל - בתור מנהלת קבוצת תשתיות, אחד הדברים שמתפיקדו של מנהל תשתיות זה להיות Enablers עבור הארגון - להיות מסוגל להגיד “למה כן” ולא “למה לא” ו”אי אפשר” ו”זה יקח זמן”.העבודה שהפכנו להיות היברידיים פתחה המון חסמים - אם אתה רוצה לעשות איזשהו POC ולהביא את החומרה “פנימה לתוך הבית” וזה לוקח זמן ויש Lead Time, אז פה אתה יכול להגיד “בואו נתחיל עם ה-POC ונראה מה נעשה עם הסביבה הזו אח”כ”.היכולת הזו להגיד כן ל - Scenario מאוד רחב של מקרים היא מאוד משמעותית - ועוזרת לחברה להיות הרבה יותר דינאמית, לרוץ מהר, לקפוץ על הזדמנויות עסקיות שאחרת אולי היינו צריכים לסרב להן.(נתי) את מתארת בעצם מקרה של חברה שהיה לה סוג של Private Cloud, ואת בעצם מחברת את ה  -Private Cloud גם כדי להגדיל את הגמישות וכדי לנצל את יכולות האלסטיות של ה  -Cloud, ואני חושב שזה טרנד מאוד משמעותי בארגונים גדולים.השאלה היא מה היה קורה אילו הייתם מתחילים ב - Public Cloud - האם הייתם הופכים אותו ל - Multi-Cloud? נניח שהייתם “גדלים ב-AWS”, ו-AWS היה בשל - כשהתחלתם היו פערים מאוד גדולים בין מה שהיה אפשר לעשות ב-Private לעומת Public, והיום הדברים השתכללו.(אורי) כן . . אני אולי נתפס כמטיף או “משיח שקר” או מה שלא תרצה להגיד, אבל הבעיה עם Public Clouds מגיעה בשלב ה - Scaling.הכל נורא קל לך ב - Public Cloud וכו’, אבל החשבונית הולכת והופכת כבדה בשלב ה - Scaling.בסך הכל, סטארטאפים מגיעים ל - Scaling בשלב הצמיחה, ואם לא גייסת מספיק כסף בשביל לקחת אותו ולהעביר אותו לחשבון הבנק של ג’ף בזוס (אחלה מודל עסקי, אגב), אז כל שקל חשוב לך, ומדובר בסופו של דבר על חסכון מאוד משמעותי כשמדובר ב Economy of Scale. חסכון בסוף של מיליוני דולרים, אם לא עשרות מיליוני דולרים, שאתה יכול לחסוך בכל שנה ולהשקיע את זה בלשכור אנשים - זה מאות משרות.(רן) ננסה למקד את השאלה של נתי - הוא אומר: “נשים לרגע את הכסף בצד ואת האידיאולוגיה גם בצד - נניח שהייתם מתחילים כבר ב-AWS או ב-GCP, האם היית הולך על Cloud נוסף?” האם יש איזשהו יתרון בהוספת Vendor נוסף, או שאם אתה כבר במקום שהוא אלסטי אז תשאר רק ב-AWS או רק ב-GCP וכו’?(אורי) אלסטי לאלסטי . . . אני לא יודע . . .(אורית) אני חושבת שנכון להיום, עדיין רואים הבדלים בין העננים, ועדיין אפשר להגיד לצורך העניין ש - Big Query של GCP הוא Ahead of the game . . .(אורי) אלו Workloads שונים . . .(אורית) ולכן אני כן חושבת שגם כ - Startup, יש מקום לבחון, על בסיס ה - Workflow או המקרה הספציפי שבודקים, איפה נכון לשים את הדברים.אני גם חושבת שבאופן כללי - כן, בעולם ה - Vendor Management (ויש פה Vendor Management), עדיף לך לדעת שאתה יכול לשחק בשני סוגי המגרשים (או בשלושתם) - זה עניין גם של כמה באמת יש לך Bandwidth לענייני Vendor Management - לא הייתי הולכת על יותר משניים כנראה, כי המחיר הוא כבר גבוה, אבל בהחלט אני חושבת שיש מקום לבדוק את הדבר הזה - יש עדיין הבדלים טכנולגיים בין שני העננים הגדולים (AWS ו-GCP) - יש הבדלים.(נתי) פעם היו אומרים Azure… מעניין לראות שהיום GCP נכנס לרשימה של השניים הגדולים, זה שינוי מאוד גדול שהם עברו.(אורית) Azure בדר”כ סופרים את שירותי ה-365 כחלק מה - Cloud וזה יוצר תמונה שונה(אורי) יש להם עכשיו ג