יום חמישי, 27 בינואר 2022

432 Carburetor 32: 2022 DevOps Predictions


בפרק מספר 432 של רברס עם פלטפורמה, קרבורטור מספר 32 אנחנו נפגשים עם נתי שלום (כבר 32 כוסות קפה).
הקרבורטור זו סדרה של תשתיות, בעיקר, שאנחנו עושים עם נתי - מדברים על מה שחדש בעולמות התשתית, והפעם - כמיטב המסורת - אנחנו נעשה תחזיות לשנת 2022: בתחילת כל שנה אנחנו עושים “פרק נבואי” [הנה של 2020 - 384 Carburetor 28 - 2020 predictions ושל 2021 - 403 Carburetor 30] שבוא נתי מספר לנו מה אנחנו הולכים לראות בעולם התשתיות במהלך השנה הקרובה.


(רן) נתי מתעסק הרבה מאוד בעולם התשתיות, DevOps וכו’ - וכתב בלוג-פוסט שהייתה לי ההזדמנות לקרוא, אז בוא ותן  לנו איזושהי סקירה של מה שלדעתך אנחנו הולכים לראות בשנה הקרובה.
  • (נתי) אז אני אתחיל מאיזשהו רקע, אני אקריא איזשהו ציטוט מ-Spotify על מה שנקרא “The Speed-Paradox”, ואני אצטט: The faster you  grow, the more fragmented and complex your software ecosystem becomes - and then everything slows down again” . . . 
  • אני חושב שהפרדוקס הזה די מייצג הרבה מאוד מהשיחות שיש לי עם  כל מיני מנהלי פיתוח וצוותי DevOps
    • הם בעצם אומרים: “אנחנו התחלנו את ה-Journey של DevOps כשאנחנו היינו הפתרון לבעיה . . .”
      • באנו ואמרנו שאנחנו מחברים את ה-Dev ל-Ops, שוברים את הקירות . . .
      • “אנחנו הפתרון לאג’יליות בארגון!”
    • פתאום הם באים ואומרים ש”הכדור מתחיל להתהפך עלינו” - 
      • אנשי פיתוח מתחילים לכעוס עלינו נורא, כי אנחנו הופכים ל-Bottleneck בתוך הארגון 
      • ואנחנו לא עומדים בקצב - יש המון דברים שאנחנו צריכים לעשות ואנחנו לא עומדים בקצב
      • אנחנו יותר ויותר מבינים שמשהו פה ניהיה מאוד מתסכל . . . 
(אורי) התשתית עוצרת? או מתחילה לעצור?
  • (נתי) בדיוק.
  • למעשה, צוותי DevOps עכשיו ניהיו מה שהיה פעם ה-Ops, מבחינת רמת-התסכול שיש כלפיהם . . . 
    • אם בעבר אלו היו אנשי ה-Ops שהיו “תוקעים את כל העסק” והם אלו שהיו מואשמים ב”חוסר אג’ליות” כי הם שמרו על . . . Keeps the lights on, ולא היו מוכנים לשום שינוי
    • אז היום זה לא המקרה - היום צוותי DevOps אחראים על האוטומציה, והם מוצאים את עצמם פשוט מתעסקים עם המון אינטגרציות והמון המון משימות, שלא מאפשרות להם בסוף לתת את האג’יליות שצוותי הפיתוח רוצים.
(רן) אז הפקק עבר מגבעת אולגה לנתניה” . . . . הוא רק התקדם, אבל יש עוד פקק.
  • (נתי) אהבתי מאוד את האנלוגיה - וזה ממש ככה.
  • ואני חושב שאם ב-Spotify, שהם בהחלט נחשבים לאיזשהו Rockstar בעולמות האלה של DevOps, פרצה שלהבת - מה יגידו אזובי הקיר?
  • אז כמובן שזה כנראה מייצג הרבה ארגונים - ואלה שזה לא מייצג אותם, אז כנראה שיגיעו לשם עוד מעט, אם לא הגיעו לשם כבר.
  • אבל אני יכול להגיד שמהרבה שיחות, אני כמעט שלא זוכר ארגון אחד שלא בא ואמר לי “איך אני משפר את היעילות של הצוות שלי? אני לא מצליח למצוא מספיק אנשי DevOps, לא הגיוני כבר אני אשים איש DevOps על כל אחת מהבעיות שאני נתקל בהן - זה גם יקר וגם הופך להיות כמויות מאוד גדולות.
    • כי דרישות האוטומציה הולכות וגדלות והמורכבות הולכת וגדלה.
(אורי) אבל היום ה-Bottleneck הוא האוטומציה - אם אתה עושה Infrastructure-as-a-Code, אז מישהו יצטרך לטפל בקוד הזה . . . .
  • (נתי) בדיוק, תיכף ננתח את זה ואז נבין גם, כתוצאה מזה, מה אני חושב שהולך לקרות.
  • אבל באמת - המעבר הזה לאוטומציה התחיל ממקום שבו האתגר היה לעבור מ-monolith ל-microServices, בצד של האפליקציות
    • זה התחיל מממקום שבו אנחנו לוקחים Manual Process והופכים אותו לאוטומטי
    • ואז הבשורה של Ansible ב-Configuration Management פשוט ו-Terraform ב-Infrastructure-as-a-Code הגיעה בדיוק לנקודת הזמן הזאת
    • ואחרי זה Kubernetes, כמשהו שמייצר איזושהי אבסטרקציה לתשתיות של Cloud, הגיע כדי לתת איזשהו פתרון לאיך עוברים מעולם שהוא ללא אוטומציה לעולם שהוא עם אוטומציה, לכל אחת מהקטיגוריות האלה.
  • מה קרה מאז? אנחנו מדברים על בערך, אני חושב, איזור 2015 פחות או יותר, 2016 . . . כשעולם ה-DevOps התחיל ככה לצמוח.
    • הכלים האלה פחות או יותר צמחו בעולם הזה - אנחנו קצת שוכחים את זה
      • והם נשארו לא . . . די דומים למה שהם היו גם אז
  • אם אנחנו מסתכלים, אז הם השתפרו מאוד ביציבות והם השתפרו מאוד בפשטות, השתפרו מאוד בעושר הכלים
    • אבל כתפיסה, הם נשארו עדיין באותו עולם, מבחינת תפיסה.
  • מה שהשתנה זה לא שהכלים האלו ניהיו פחות טובים - וזו פחות או יותר התיזה שאני מנסה להוביל כאן - מה שהשתנה זה בעצם שהעולם השתנה . . . 
(רן) הצפיות השתנו . . .
  • (נתי) כשאני אומר שהעולם השתנה, אז גם פה, שוב פעם אפשר לבדוק מה קרה בעולם ה-Cloud והמעבר ל-Cloud.
  • אז (1) - אנחנו מדברים על מעבר מארכיטקטורות הרבה יותר מורכבות ומבוזרות, 
    • בעבר זה היה המעבר מ-Monolith ל-Applications - היום אנחנו מדברים על microServices ועל Serverless, על דברים שהם כבר יותר Multi-Site גלובאלי, פיזור גלובאלי של אפלקיציות
    • ואחרי זה גם פיזור שהוא לכיוונים של Edge ועוד כהנה וכאלה.
  • אנחנו מדברים על הרבה מאוד AI ו-Machine Learning, שבהגדרה הן מערכות מאוד מבוזרות - ואנחנו מדברים גם על זה שה-Stack עצמו, ה-Pipeline שאנחנו מדברים עליו . . . 
  • דיברתי על הנושא של כלים שיש לנו היום - יש לנו את GitOps ויש לנו את DevSecOps ו-MLOps
    •  ואפשר לקחת עכשיו את כל ה-Ops-ים האלה ולחבר אותם ביחד.
    • וכל זה בעצם ניהיה העולם החדש
  • אז כשמסתכלים על זה ככה, די ברור שמה שנכתב ב-2014 ו-2015 לא יכול להחזיק מים לבעיות של “העולם המודרני”.
    • הוא חייב להיות חלק מהפתרון, אבל הוא כבר לא יכול להיות הדבר העיקרי והיחידי.
  • וה-Complexity רק עלתה וגדלה - ואני חושב שזה מה שהוביל גם את Spotify לכתוב את מה שהם כתבו.
    • הם, אגב, יצאו עם פתרון שנקרא Backstage שהוא סוג של פתרון שלהם לבעיה הזאת, ותיכף ניגע בזה.
  • אבל בגדול - יש כן הכרה בכך שמשהו פה צריך להשתנות.

  • (רן) אז אני חושב שנגעת פה בכמה דברים -
    • קודם כל, Backstage זה איזשהו כלי שהוא פורטל-מפתחים, כלי פנימי שנותן למפתחים של Spotify - במקום לשלוח הודעה ב-Slack לאיש הפלטפורמה או במקום לפתוח Ticket - לעשות את הדברים בעצמם.
      • אז זה סוג-של פלטפורמה ל-Self-Serve למפתחים
    • אבל הזכרת פה כמה דברים - אחד זה שאמרת שההתפתחות של DevOps היא Enabler - אבל ברגע שפתחנו את הפקק, אז פתאום יש דרישות חדשות והארכיטקטורות ניהיות יותר ויותר מורכבות
      • הזכרת microServices ו-Serverless ו . . . לא מעט דברים התפתחו פה, ופתאום יש לא מעט דרישות גבוהות יותר
      • וגם ניהיו תת-התמחויות - DevSecOps ו-FinOps ו-MLOps ו-EdgeOps, שאחר כך אתה תיגע בזה .  . . התפתחו עוד ועוד דיסיפלינות ויש יותר ויותר כלים.
    • אז נכון - הכלים יודעים לעשות יותר ממה שהיה פעם, אבל עכשיו גם צריך לעשות אינטרגרציה ביניהם, והאינטגרציה הזו היא לא פשוטה - 
      • אולי כל אחד מכיר מצוין את הכלי שלו, אבל הם צריכים לעבוד ביחד - והנה עוד ערימה גדולה של עבודה ומורכבות שצריך לפתור פה.
    • (נתי) נכון
(אורי) אני קצת . . . השיחה מתסכלת אותי קצת . . . 
  • (נתי) זה מרגיש שחזרנו אחורה . . . 
(אורי) השיחה מתסכלת אותי כי לא רק שחזרנו אחורה, או שהבעיה “קפצה דרגה” אבל היא עדיין בעיה
    • זה גם ממקום שאני לא מוצא לזה את הפתרון
    • או Moving Forward, נניח תסתכל על Backstage - גם ב-Outbrain יש פורטל-מפתחים, שאולי הוא עדיין לא כמו Backstage - אני חושב שעדיין לא הגענו לצרכים, שלצורך העניין יש ל-Spotify
      • אבל לא נורא, עוד חצי-שעה נגיע . . .. 
    • אני חושב שבסדר, אז יש לך Backstage או פורטל-מפתחים כזה, ואתה מנגיש דרכו פתרונות - זה עוד פעם Infrastructure-as-a-Code, 
      • אבל גם לו יש מגבלות - הוא לא מכסה את כל הבעיות או את כל הצרכים שלך
      • ועכשיו מישהו יצטרך לפתח את הדבר הבא, ויהיה עוד Bottleneck . . .
    • אני חושב שיש משהו מאוד מובנה ב-Value-chain הזה, לצורך העניין, של Business שתלוי באפליקציות או בפיתוחים, והפיתוחים שתלויים בתשתית . . . . וזה תמיד יהיה, וזה לא משנה איזו רמת אבסטרקציה תעשה ביניהם.
    • [ד”ש מד”ר גולדראט - “המטרה” עוד מעט בן 40 . . .]
  • (נתי) אני באמת מסכים ש-Backstage, כפורטל-למפתחים, נוגע בנקודה, הייתי אומר אחת מיני רבות - ולאו דווקא בבעיה הכי גדולה.
  • אם אני מסתכל על הטרנד הזה, של מה שקוראים לו בתעשייה “Shift-Left” - וזו, אני חושב, אחת הבשורות שאנחנו מתחילים לראות - זה בעצם שמה זה כל  “Shift-Left” הזה? 
    • זה בעצם בא ואומר שיש לי, מצד אחד, Workflow של פיתוח - אני יודע לעבור דרך Git, אני יודע לנהל תהליך מאוד מורכב של פיתוח, של Teams, הרבה אנשים שעובדים ביחד על פיתוח של קוד ושיכולים לעבוד במקביל - לעשות שינויים, לנהל שינויים.
    • ויש לי את כל ה-Workflow הזה, שמנוהל ע”י ה-”Source of Truth” הזה שנקרא Git
      • כשאני יכול לעשות Push לקוד, אני יכול לעשות Pull לקוד, אני יכול לתרום, אני יכול לקבל תרומות, אני יכול לנהל את כל ה-Workflow הזה.
    • ולצידו צמחו עוד הרבה מאוד Workflows אחרים, של CI/CD ו-Workflow-אים אחרים של IT - 
      • שזה ServiceNow וכאלה ועוד . . . הרבה Workflow-אים כאלה.
    • והטרנד הזה, למשל, ש-GitOps מוביל אותו, בא ואומר “למה צריך הרבה Workflow-אים?”, למה לא לחבר את הכל לאיזשהו Workflow אחד שהוא מרכזי? 
        • כשבמקרה הזה, אותו Workflow שהמפתחים עובדים איתו הוא גם הכי “בשל”, אני חושב, לתהליכים מורכבים
      • וניישר קו - כל התהליכים עכשיו יתכווצו לתוך ה-Workflow הזה.
    • אז זה שינוי אחד, שאני חושב שיכול מאוד לייצר איזושהי בשורה חדשה על איך שאנחנו עובדים - 
      • במקרה הזה, אם נניח שאנחנו מסתכלים על העולם של GitOps, אז במקום שאני אקרא עכשיו ל-CI/CD ואגיד לו “עכשיו תריץ לי את ה-Pipeline הזה, עכשיו תריץ לי את ה-Pipeline ההוא” - אני בעצם אעשה Push לקוד, וברגע שמישהו יעשה לו Merge אז, אוטומטית, התהליך הרלוונטי יקרה.
      • אם צריך Approval Process אז אוטומטית יקפוץ לי ה . . . . יש לי את ה-Pull-Request וגם אני יכול אוטומטית לצרף לזה מישהו שיעשה את ה-Review.
      • ואז הוא יעשה לי Review לתוך הדבר הזה וככה אני אוכל לוודא שבאמת הקוד הזה לא יכנס ל-Production לפני שהוא עבר איזשהו תהליך של Review.
    • יש שם המון המון “Workflow-אים”, נקרא לזה ככה, שכבר מובנים בתוך תהליך הפיתוח - והמהלך הזה של ה-Shift-Left בעצם בא ואומר “בוא נכווץ את כל שאר התהליכים לתוך התפיסה הזאת”.

(אורי) אז אילו, למשל, עוד תהליכים אתה רואה נכנסים לתוך ה . . .
  • (נתי) למעשה, כמעט כל תהליך שאתה חושב עליו יכול להיכנס לזה.
  • אנחנו נגענו בדוגמא של DevSecOps ושל MLOps ואפילו FinOps - הם כבר שם.
    • זה בעצם בא ואומר: בוא ניקח את עולם ה-Security ונכניס אותו לתוך תהליכי הפיתוח, בוא ניקח את עולם ה-Finance ונכניס אותו לתוך תהליכי הפיתוח, כדי שגם שם נקבל Visibility בשלב הרבה יותר מוקדם.
    • אבל הרעיון הבסיסי הוא שמקום שיהיה CIO שמסתכל על הדוחות הכספיים ואיכשהו, ב-Retrospective, אומר “טעיתי או לא” ובדרך כלל אין לו מושג אם מה שהוא רואה  . . . .
    • (אורי) CFO . . .
    • (נתי) CFO - וגם סוג-של-CIO בחלק מהארגונים, שכן יש להם אחריות על הנושאים האלה . . .
    • (רן) בארגונים שהם פחות טכנולוגיים, אז שם ה-CIO . . . .
    • (נתי) כן, זה לאו דווקא הצד הפיננסי במובן של מכירות והכנסות, אלא יותר בקרה על IT - יותר בצד הזה . . .
      • על ההוצאות של ה-IT.
      • אז CIO, הרבה פעמים כן יש להם איזושהו סוג של אחריות 
      • והיה לנו גם את ה-CISO שאחראי על ה-Security . . . 
  • ואני חושב שהמגמה הזו היא מגמה אחת שאמורה מאוד לייצר איזושהי קונסיסטנטיות (Consistency) בתהליך - ולפשט את ריבוי התהליכים שקיימים היום ואת ריבוי הכלים שקיימים היום.
      • גם אם יש הרבה כלים - יש איזושהי דרך מרכזית אחת לנהל אותם
    • ואני חושב שזה גם ימשיך להיות - אנחנו נראה יותר ויותר את רוב התהליכים האלו, שקשורים לאוטומציה של תהליכי DevOps מנוהלים סביב הדבר הזה שנקרא Git, ובעצם “מתלבשים” עליו כמשהו שדרכו אתה מריץ את שאר התהליכים בארגון.
    • זה עולם מקביל לחלוטין . . . תגיד עכשיו לאיש DevOps עכשיו להתחבר ל-ServiceNow ולפתוח Ticket ב-ServiceNow אז הוא יזרוק אותך מכל המדרגות . . . 
      • ומצד שני, תגיד ל-IT לכתוב Template או מודול של Terraform, אז  . . .
      • (אורי) אז הוא יגיד לך “תביא לי Ticket” . . . 
      • (נתי) בדיוק
  • אז יש עדיין את ה-Silo הזה - שהוא היום אפילו יותר גדול ממה שהיה בעבר - ואני חושב שבגדול, אם מסתכלים על כל ה-Silo-אים האלה, הפתרון של ה-Silos יקרה באמצעות זה שכולם יתרכזו סביב הדבר הזה שנקרא Git
    • כולם יתרכזו סביב ה-Workflow-אים האלה שקיימים, של הפיתוח - ואני חושב שבדרך הזאת הבעיה, לפחות של איך שמנהלים תהליכים של אוטומציה, תיהיה קונסיסטנטית (Consistent)
  • ומילת המפתח היא “קונסיסטינטיות” - כי המורכבות לא תיפתר, אבל היכולת להגיע לאיזושהי רמה של קונסיטנטיות כן יכולה להיפתר
    • וזה, לכשלעצמו, ייצר כבר, אני חושב, קפיצה מאוד גדולה בהורדת הסיבוכיות.

(אורי) אז הנה, אני עכשיו תופס את הכובע האופטימי, בסדר?
  • למה אני אופטימי? כי אני אביא עכשיו סיפור מהחיים, בימים אלה: Outbrain הונפקה, ואנחנו עכשיו בתהליכים של בנייה של SOX ומה שנקרא ITGC - ה - IT General Controls
    • וקודם כל - הרבה מהאנשים, במיוחד כשמדברים על תרבות של DevOps וכו’ שהיא מאוד פלורליסטית ומעניקה Ownership לכולם וכל זה - אז זה נשמע מאוד לא-Control-י . . . 
    • (רן) אנטי-Compliant-י . . . 
    • (אורי) כן - אבל, ברם-אולם, מה שאני חווה זה שדווקא ל-Engineering, למי שמוטמעים אצלו תהליכי DevOps ו-CI/CD כמו שצריך - הכי קל לנו . . . .
      • כי ה-Pipeline כבר נמצא, וכבר היום המהנדס עושה את ה-Commit שלו ולצורך העניין הוא יכתוב שהוא רוצה שזה יהיה Commit & Deploy - אז ירוצו כל הטסטים וכל הבדיקות ובדיקות אינטגרציה וכל ה-Pipeline ירוץ
      • וזה יעשה, בתכל’ס, Deployment . . . .
  • (נתי) נכון, ואני אומר שזה בסופו של דבר באמת workflow מאוד מורכב, שכבר חלק יחסית משמעותי בתוך הארגון התרגל לעבוד איתו
    • יודע מה זה Approval Process ויודע גם לעבוד עם . . . .
  • (אורי) וזה בכלל בא מהצד של האיכות, לא מהצד של Compliance ו-Audit ומקומות כאלו.
  • (נתי) נכון - ועכשיו מה שיפה הוא שגם פיצחו את הנוסחא לאיך עושים את הבקרה הזאת בלי לפגוע באג’יליות - כי אתה כן מצליח לשחרר קוד עשר פעמים ביום, או שלושים פעמים ביום . . .
    • (אורי) 300 . . . .
    • (נתי) או 300 . . . - וזה למרות שהתהליך הוא מאוד מורכב ולמרות שיש בו הרבה מאוד בקרות ולמרות ששיש בו את כל זה.
  • מה שעשו זה שהרבה מאוד מהבקרות הן אטומטיות - ובדרך הזאת הצליחו לייצר פה תהליך שהוא מאוד Efficient, שלא פוגע באג’יליות.
    • אבל שמצד שני, לא מגיע ל-”Wild West” הזה שהיה בקצה השני של הבעיה הזאת.
  • לכן אני חושב שאימוץ של התפיסה הזאת הוא, כנראה, Best Practice שכדאי לאמץ אותו לשאר התהליכים.
(אורי) מה שאני רואה זה שדווקא המקום הזה, שנחשב להכי פלורליסטי, הוא דווקא הכי קל . . .
  • (נתי) נכון, כי הוא רגיל לחשוב ככה . . .
(אורי) נכון
  • (נתי) . . . ומה שהיה לו קשה זה שכל העולמות האחרים - ובגלל זה היה את ה-Silos - דיברו בשפה אחרת, עבדו עם כלים אחרים, היה להם  . . .
    • הם האטו אותו כל הזמן כתוצאה מזה ולא דיברו באותה השפה.
  • ופה, שוב פעם, אני חוזר למהלך הזה שקורה עם זה - זו נקודה אחת שאני חושב שאנחנו נראה את הדבר הזה קורה בעוד גזרות ולמעשה אין הצדקה כמעט ל-Workflow-אים שהם, לצורך העניין, “ארגוניים”
    • לדעתי זה יגיע גם לעולמות של Marketing וזה יגיע גם לתהליכים אחרים
    • יש גם חברות בארץ שכבר נבנו על הדבר הזה
  • ובעצם לוקחים עוד ועוד תחומים בתוך הארגון ועושה להם את ה-Shift-Left הזה, לתוך התהליכים האלה.

(רן) אז בוא רק לשנייה נעשה סיכום - אני חושב שגם שהשתמשנו פה בלא מעט מושגים שאולי שווה להסביר.
  • אז באת ואמרת “אוקיי, DevOps איפשר הרבה מאוד דברים - וברגע שקיים ‘האיפשור הזה’, ברגע שקיימת האפשרות, אז גם דברים הופכים ליותר מורכבים”.
    • דיברת על ארכיטקטורות מורכבות, דיברת על דיסיפלינות (Discipline) שפעם לא היו קיימות כמו MLOps ו-FinOps וכו’
  • ואמרת שלדעתך הפתרון הוא בלאפשר פורטל כניסה אחד לתוכם
    • הפורטל הזה יכול להיות או Backstage או GitOps - ואולי גם דברים אחרים.
    • אבל אתה אומר שאם פורטל הכניסה יהיה אחד, אז זה מאוד יפשט את כל הדברים.
  • (נתי) נכון.
  • (רן) לא הגדרנו מה זה GitOps, אז בוא נגיד ככה בשתי מילים מה המשמעות של זה - כי בניגוד לכל ה-Ops-ים האחרים, המשמעות שלו פה היא שונה
    • אז GitOps זו בעצם דיסיפלינה שבאה ואומרת שנעשה Commit [טוב!] לקוד - ואז אתה לא צריך לעשות אחר כך Deployment, ה-Deployment קורה בצורה אוטומטית.
    • הקוד הוא ה-Production, ה-Production זה העתק של הקוד
    • זה נכון שגם לפני כן הייתי עושה Review לקוד - זה אומרת, לא היה נכנס לProduction משהו שלא עבר Review - 
      • אבל GitOps אומר יותר מזה: לא קיים ב-Production משהו . . . .זאת אומרת שהם זהים, יש פה הכלה הדדית
      • לא רק שכל דבר עובר Review, אלא שכל מה שעבר Review כבר ב-Production.
      • זאת אומרת שאין לך “מחסן” שבו אתה שומר את השינויים ואחר כך עושה Deploy.
      • אז זה, אני חושב, אחד ה . . .. 
      • (אורי) אלא אם כן לא עבר Testing . . . .
      • (רן) כן, אם זה לא עבר . . . אז או שזה עבר Merge מוצלח וזה נמצא ב-Master - ואז זה גם אוטומטית עובר ל-Production, אתה לא צריך ללחוץ על אף כפתור נוסף כדי שזה יעבור לשם - או שזה לא עבר, ואז זה לא עבר Merge.
    • (אורי) אבל יש גם Integration tests וכו’ שקורים אחרי ה-Merge, אז . . . כל אחד וה-Pipeline שלו
    • (רן) “עד כדי קבוע” . . . כן.
  • אז אתה אומר שזה פתרון למורכבות הזאת, פתרון אחד, אולי, למורכבות הזאת.
    • (נתי) נכון.

  • (נתי) נקודה שנייה שאני חושב ששווה התייחסות זה כל הנושא של ה-Infrastructure-as-a-Code - לאן הוא הולך, לאילו מקומות הוא הולך?
  • ונגעתי ב-Debate שעדיין קיים, אבל אני חושב שיש לי דעה יותר מוצקה היום לגבי לאן אני חושב שזה ילך
    • בין הגישה ה-HashiCorp-ית שבעצם לייצר DSL, או HCL זה נקרא.
      • שפה שהיא Domain-specific לעולמות של Infrastructure-as-a-Code
    • לבין Pulumi, שעשו קצת הרבה רעש בשנים האחרונות - של להגיד ש-Developers רוצים שה-Infrastrucutre ינוהל
      • אם אני כותב ב-Java אז שזה ירוץ לי ב-Java, אם אני כותב ב-Groovy אז שירוץ ב-Groovy וכו’
(רן) זאת אומרת ש-HCL מייצג את הגישה של “זו שפה דיסקריפטיבית (Descriptive), זו קונפיגורציה - תתאר אותה”
    • אתה לא יכול לתכנת - אתה יכול לעשות “+ 1 / 5 if else then”  . . . אי אפשר לעשות שם.
    • ו-Pulumi זו שפה . . .
  • (נתי) הם בעצם מתרגמים, מאחורי הקלעים, בעצם מחוללים סוג של Terraform code באמצעות API . . . .
  • (רן) אבל Pulumi נותן לך כלים, סט של כלים של מתכנת - שאתה יכול לעשות . . . 
  • (נתי) שזו, בעצם, האטרקטיביות של זה למתכנת - אתה יכול לעשות Loop-ים, אתה יכול לעשות Conditionals, אתה יכול למעשה לייצר Complex Business Logic מאחורי זה.
  • (רן) כן - כמו, למי שזוכר, Chef לעומת Puppet - כש-Chef זה היה שפת תכנות ו
  • (נתי) כן, ראיתי את ההערה שלך שם והיא באמת העלתה לי חיוך כשקראתי את זה . . . אני זוכר את ה-Debate-ים, אפילו אז . . .
  • אבל בגדול, אם אני אחזור חזרה ל-Debate הזה, אז כשאתה מסתכל על זה כמפתח אתה אומר “וואלה, מגניב - אני יכול לכתוב את זה בקוד ה-Native שלי, יש גם את כל העושר של הקוד הזה”
    • אני יכול לעשות על זה באמת דברים יותר מורכבים - מגניב, נראה לי מאוד הגיוני.
  • אבל מה שקורה - ואפילו כשקוראים הערות של אותו יזם, של Pulumi, שכחתי את שמו כרגע . . . 
    • (רן) משהו אירופאי אני זוכר . . . 
    • (נתי) תיכף אני אזכר [Joe Duffy]
  • גם הוא מודה בזה שבסוף בסוף, אם אתה תכתוב עכשיו Java, לצורך העניין קוד כדי להרים Infrastructure - השפה לא בנויה להתמודד עם זה שזה הרבה מאוד פעולות א-סינכרוניות, הרבה מאוד פעולות מבוזרות.
    • במקרה של Partial failures וניהול State, לצורך העניין - מאוד מובנה בתוך הבעיה עצמה.
  • יש הרבה מאוד לוגיקה שהיא Domain-Specific שלא נמצאת בשפה.
    • כל הנושא של Exception handling הוא לא רלוונטי בכלל לעולמות האלה - וגם מאוד מאוד קל ללכת לאיבוד בקוד עצמו, 
      • כי אתה תראה שם פתאום קוד שעושה מיליון דברים אחרים שלא קשורים - וגם את החלק הזה של ה-Infrastructure.
    • ואפילו בכל מיני בעיות נורא פשוטות - כשאתה רוצה להרים מכונה ואחרי זה לקבל את ה-IP שלה:
      • אז בגלל שזו פעולה א-סינכרונית, והשפה בסופו של דבר כשאתה כותב קוד היא מאודSequence-אלית בצורת עבודה שלה - אז אתה לא יכול ממש לכתוב את זה כקוד ולצפות שעכשיו יש לך את ה-IP של המכונה, כי זה איזשהו תהליך א-סינכרוני שמתישהו חוזר
      • ועכשיו לך תעשה את זה עם Future או עם כל מיני דברים כאלה, שלכאורה קוד נותן את זה.
  • אז הדעה שלי היא מאוד חד-משמעית לגבי הדבר הזה - שבאמת, עד כמה שזה נראה לכאורה מפתה, זה מאוד לא נכון וזה מאוד לא הגיוני
    • ולדעתי, במיוחד לאחר שקראתי את ההערות של אותו יזם, גם הם מבינים שזה לא המקום
    • ועכשיו השאלה היא האם תיהיה שפה אחרת שהיא Domain-Specific - או HCL
  • ופה אני חושב שזה כבר לא שאלה של “מה השפה הי טובה” - אני חושב ש-Python זו דוגמא מצויינת לזה - אלא באמת של איפה נמצא ה-Adoption
    • אני חושב שכולם מכירים את זה ש-Terraform הצליחו מאוד, הגיעו היום להרבה מאוד Deployment-ים
    • השפה כבר מוטמעת בהרבה מאוד מקומות - אני לא רואה את זה משתנה בעתיד הקרוב
    • ולכן אני שה-Gravity שהם יצרו וה-Stickiness שהם יצרו זה משהו שישאר לעוד הרבה זמן.
  • ומה שאני כן חושב שנכון שיקרה זה יותר Ecosystem שנבנה סביב ה-HashiCorp הזה, שהוא לא רק סביב HashiCorp, אלא Ecosystem שלם של פתרונות וכלים שנבנה מסביב לשפה.
    • בדומה למה שראינו בעולמות של Kubernetes ודברים אחרים.
  • וזה, לדעתי, בעולם שלInfrastructure-as-a-Code, המגמה שאנחנו נראה.
  • עכשיו - מה יתפתח . . . אני אעצור פה שנייה . . .

(אורי) אני רוצה באמת להתייחס לדבר הזה - אתה יכול להגיד שיש לי עולם שאנחנו רגילים אליו - “קוד זה קוד, אפליקציה זו אפליקציה ותשתית זה תשתית” . . . ו”הנה התשתית ובבקשה - אפליקציה,, תרוצי על התשתית הזאת ואל תיגעי לי בתשתית”.
מהצד השני, אנחנו כבר יודעים ומכירים כבר כמה שנים את העולמות של Serverless, שאומרים “חביבי - אין תשתית . . . הקוד שלך הוא קוד, תריץ אותו, הוא ירוץ לך איפה שהוא יעשה את העבודה הזאת ונגמר, לא מעניין אותך איפה זה רץ” - זה הקיצון השני.
ועכשיו, תוך כדי שאתה מדבר, אני אומר רגע - למה אני, כמפתח, אני יכול לעשות Instantiation של איזשהו אובייקט מתוך Class שיש לי, מגניב לי - אני מרים אובייקט, מוריד משתמש בו, הכל סבבה - למה אני לא יכול להרים Server? למה אני לא יכול להרים לי Database מתוך הקוד? למה לא? למה אני חייב לעצור ויש לי איזשהו מחסום איפה שזה נוגע בתשתית?
  • (נתי) אז התחלתי לגעת בכמה מהבעיות . . . . יש הרבה מאוד בעיות שהן Domain-Specific, כששפה עצמה לא בנויה אליהן.
  • נתתי דוגמא אחת שהיא מאוד שכיחה - הרמת VM וזו פעולה א-סינכרונית
    • אז בקוד שלך אתה צריך עכשיו כאילו לחכות ל-VM הזה, עד שתקבל את ה-IP ורק אז אתה יכול להמשיך לעבוד . . .
  • (אורי) אבל זה רק כי אתה רגיל לעבוד על זה סינכרונית, וואלה, די - גמרנו ב-2015 לעבוד סינכרונית . . .
  • (נתי) אז אני אומר שאתה תראה שזה . . . אתה תראה שתהליכים כאלה הופכים להיות מאוד מורכבים בשפות הקיימות.
    • זה לא כזה פשוט לכתוב קוד כזה, עדיין - גם אם יש לך את הפתרונות של Future ועוד כל מיני דברים אחרים אתה יכול לנהל את זה.
  • ו-2 - צריך להבין שכל הנושא של Partial Failures, ובכלל Failures, הוא מאוד שכיח בתוך העולמות האלה של מערכות מבוזרות
    • כל הנושא של Exception Handling וטיפול בדברים האלה, של  . . .
(אורי) מה זה שונה מטרנזקציה ב-Database? היא גם יכולה להיכשל . . .
  • (נתי) זו שאלה מצויינת - ואני אקח עכשיו ואגיד לך . . . קח מערכת שאתה מרים עכשיו, Datacenter - תריץ אותו בקוד ותנסה לעשות Troubleshooting . . . קרתה שם תקלה, ואתה צריך לנסות לעשות Troubleshooting לאיפה התקלה שם.
    • אתה תראה עכשיו Stack trace מאוד מורכב, שנוגע בהרבה מאוד דברים שלא רלוונטיים לבעיה הזו, משהו שיכול להיות רלוונטי לדבר הזה.
    • ובתוך זה מוחבאית הבעיה שבגללה הבעיה ב-Infrastructure קרתה.
  • ואני אמשיך - לזה יש את זה שאתה רוצה לעשות Governance, אתה רוצה לוודא שעכשיו מי שמרים Server ל-Production לא בטעות מוחק את ה-Database
    • אז אתה רוצה לבדוק שהוא הכניס את הערכים הנכונים, אתה רוצה לבדוק שהוא הריץ את זה ב-Region הנכון . . . 
    •  אתה רוצה לבדוק עוד הרבה מאוד דברים בהקשר הזה.
  • עכשיו, כשהשפה היא שפה שלא בנויה לזה, שוב פעם - אז הכלים שיש לך כדי לעשות Governance לדבר הזה ולעשות Static Code Analysis ועוד כל מיני דברים אחרים - הם לא יודעים להכיר את הדבר הזה
    • כי עכשיו הם צריכים לנתח קוד שעושה מיליון דברים אחרים, וגם את זה.
    • ואיפשהו הם צריכים להבין איזה חלק  של הקוד הוא כן Infrastructure ואיזה חלק של הקוד הוא לא Infrastructure- ועל הקוד הזה להכיל חוקים מסויימים ועל חוק אחר להכיל חוקים אחרים . . .
(אורי) אני לא יודע  אם . . . 
  • (נתי) אז ב-Scale קטן זה עוד יכול לעבוד, אבל ב-Scale גדול זה כבר אובדן שליטה מוחלט, לחלוטין.
  • לכן אני חושב שגם בהערות שקראתי, אפילו ב-Announcement של Pulumi, שב-Discussion Group של המפתחים שלהם עצמם, כולם באו ואמרו “אוקיי, מגניב, אחלה, מאוד פשוט - אבל ב-Scale זה נשבר לי, אני לא מצליח לעשות עם זה” . . . 

(אורי) יש הרבה דברים שנשברים ב-Scale . . . אבל כמו הרבה דברים שאנחנו יודעים ב-Scale אתה הולך לאופטימיזציות אחרות ולמקומות שהם יותר Bare-Bones, אם אתה רוצה באמת לאפטם (Optimize) ל-Scale.
אבל במקומות שאתה רוצה אג’יליות - וואלה, יכול להיות מגניב . . .
  • (נתי) אז נתתי את הדוגמא של ה-Database ואני אמשיך איתה - למה אתה לא כותב ל-Database באמת בקוד? אתה כותב עדיין, הרבה פעמים, ב-SQL-ים, ואתה עדיין כותב  בשפה שהיא, הייתי אומר, אפילו API מאוד ספציפי של העולמות האלה - ולא ב-Java, כמו שהיית כותב ב-Java או לצורך העניין ב-Go או . . .?
(אורי) יש פה אנשים, סביב השולחן, שכתבו Java Connector ל-Cassandra . . . .
  • (נתי) . . . אז אני אומר שאני גדלתי גם בעולמות האלה אבל אני אומר שזה בסוף לא מחזיק מים
  • כי רוב האנשים - היכולת שלהם לבטא, נניח, אם נכנסנו לעולמות של דאטה - כדי לבטא שאילתה, למשל, בקוד, אז אתב כותב אובייקט.אובייקט.אובייקט . . . 
    • מאוד לא אינטואיטיבי, וזה נראה פתאום כמו איזה קוד שהוא Nested, יצור-כלאיים כזה.
    • עכשיו, גם אם אתה מסתכלים על Scala, אז הם הלכו למקומות האלה וזה נראה נורא ואיום.
  • אז אני אומר שיש מקום  . . . Infrastructure זה Domain - זה Domain ספציפי, כמו ש-Database זה Domain, כמו ש-Analytics זה Domain - ול-Domain הזה יש התנהגות משלו.
  • ואני חושב שאנחנו בכלל, כתעשייה, מבינים את זה שלא צריך שפה אחת שעונה על כל הבעיות, כי אין כזאת חיה.
    • לכל Domain יש את הצורך ב-Domain-specific Language שלו ובהתנהגויות שלו - וזו הגישה הנכונה.
  • והגישה הנכונה היא לבדוק Stack מהרבה Domain-specific Languages ולא מ-Language אחד שמנסה להיות השפה של הכל.

(רן) בוא אני אעזור לך לטעון את הטיעון שלך, נתי: לרנדר (Render) דף HTML - אתה יכול לעשות את זה ב-++C, נכון? אתה יכול להרכיב את האלמנטים, לייצר את הפונטים והכל . . . זה אפשרי - אבל אתה עושה את זה ב-HTML, כי זה הרבה יותר פשוט, כי זו שפה שהיא בטוחה, זו שפה שהיא דסקרפטיבית (Descriptive).
באותה מידה, אתה טוען שגם עם Infrastructure - נכון, אפשר לעשות את זה ב-++C או ב-Java או ב-JavaScript ואפשר Pulumi שמאפשר לך את זה - אבל לא כדאי, כי אם אתה תמשיך לעשות את זה במשך הרבה זמן והצוות שלך יגדל, אז אתה תתחיל להסתבך . . . 
(אורי) השאלה היא האם השפות לא צריכות ללכת לשם? . . . C התחיל כ-C, אבל כשנהייתה לו דרישה ל-Object-Oriented אז זה התפתח ל-++C . . . 
(רן) נכון. אני חושב שבעצם, אם אני יושב בצד ומקשיב, אני חושב שמה שנתי מנסה להגיד שכן - זה אפשרי, אבל לא כדאי, כי השפה לא נבנתה לזה. השפה היא General-Purpose Language, היא טובה להרבה מאוד דברים ויכולה לעשות הרבה מאוד דברים - אבל כשאתה רוצה לעבוד עם Infrastructure, אז המורכבות שם היא כל כך שונה, שכדאי שתשתמש בשפה שהיא Domain-Specific.
וספציפית, נתי מזכיר את HCL, אבל זו לא האופציה היחידה . . .
  • (נתי) נכון
(רן) בגדול, אתה אומר שהשפות שהן Domain-Specific הן אלו שתשלוטנה, ולא אלו שהן וריאציות כמו Pulumi ו . . .
  • (נתי) אני חושב שגם Pulumi מודים בזה . . . .
  • אני אוסיף, אגב, לגבי הדוגמא של ה-HTML - כשאנחנו מסתכלים על דף Web רגיל, אז יש לנו גם שם יותר משפה אחת של HTML - יש שם JavaScript ו-CSS
    • אפילו בדף HTML פשוט, אנחנו כבר מדברים על שלוש שפות - שכל אחת מהן היא Domain-Specific
    • וגם כשאנחנו פותחים דף בודד אנחנו נתקלים בזה.
  • אז הדוגמא הזאת, של שפות ל-Domain-ים, תמשיך להיות.

(רן) אבל יש עוד כיוון אחד שלא נגענו בו, שהייתי רוצה שנדבר עליו לפני שאנחנו מסיימים עם האייטם הזה - היה לנו איזה ראיון קצר עם Martin Casado לפני כמה חודשים, והקלטנו כמה פרקים על נושא של עלויות של מחשוב ענן ועלויות באופן כללי, ועל זה שלפעמים חברות בוגרות יותר מחליטות “לרדת מהענן” מתוך שיקולים של מחיר.
אחד המושגים שעלה שם זה מושג של Repatriation - בעצם לקחת אליך בחזרה את ה-Workloads: אם, לצורך העניין, עשית Deployment ב-AWS, ובאיזשהו שלב גילית שה-Deployment - או אולי חלק ממנו או אולי רכיב ממנו - הוא יקר לך מדי, ואתה רוצה לקחת אותו אליך ולעשות אותו בצורה יותר זולה . . .
(אורי) . . . יקר לי 750 שקל” . . . .
(רן)  . . . עכשיו, יש כאלה שמראש הם Off the Cloud, כמו שאמר מכובדי סביב השולחן הזה, יש כאלה - אבל בוא, רגע, נדבר על כל המגמה הזאת של Repatriation, כמו שקרה לזה Casado - מה אתה חושב שהולך לקרות ב-2022?
  • אז קודם כל, נדבר על זה שלמה בכלל אנחנו מדברים על זה? . . . 
  • אז כמובן שהבעיה הזו, אגב, היא לא חדשה - היא קיימת פחות או יותר מהיום שה-Cloud נוצר, ולא טיפלו  בה כי זו בעיה מאוד מורכבת.
    • ולכן, כדי לעשות Repatriation, להתחיל לייצר פתרונות ב-Private Cloud, אני חושב שבסגנון של Outbrain - זה דורש צוות Operations מאוד חזק, ידע מאוד עמוק של Infrastructure Management
    • והרבה ארגונים לא יודעים ולא מסוגלים לעשות את זה - ולפעמים, כתוצאה מזה, זה גם לא הדבר הנכון עבורם.
  • קרו פה כמה דברים, אני חושב, שפתחו את השאלה הזאת - 
    • אחד זה שאני חושב שהעלויות של ה-Business הגיעו למצבים שב-Scale-ים שאנחנו מדברים עליהם, שהם כאלה גדולים - אז פתאום העלויות, כשמסתכלים על זה במונחים של Supply Chain אז פתאום אתה רואה איזשהו רכיב שעולה מעל 50%, שזה מה ש-Martin Casado דיבר עליו, אז אתה מבין שמשהו פה לא הגיוני ואתה חייב לטפל בו.
    • הדבר השני שאני חושב שקרה זה Kubernetes ועוד כל מיני רכיבים שמאפשרים לעשות אבסטרקציה
      • זאת אומרת שהיכולת שלי להרים עכשיו סביבה  ב-Private Cloud וב-Public Cloud ולנייד משאבים ולהרים  Infrastructure - זה ניהיה הרבה יותר קל היום, וזו כבר לא “ויה דולורוזה” כמו שזה היה פעם.
      • זה לא שזה קל לגמרי וזה לא פשוט לגמרי - אבל הרבה יותר קל לראות את זה, ויש גם Ecosystem מאוד גדול של כלים ושל חברות שנותנות פתרונות לבעיה הזאת.
    • ועכשיו, כשאתה נדרש לשאלה הזאת, ואתה אומר: “אני רוצה להרים עכשיו משהו ב-Private Cloud”, אז פתאום אני רואה ארגונים, אפילו בצוותים קטנים וסטארטאפים, שהולכים ועושים דברים כאלה.
      • וגם אם מריצים משהו בענן - אז הם לא יקחו תמיד את ה-Managed Service, כי איתו בה הרבה מאוד “Baggage”
      • או לחילופין, הם יבנו Stack-ים שהם לרוב לאו דווקא ה-Managed Services של ה-Cloud - אני חושב ש-Datadog זו דוגמא מצויינת - הם ינסו לקחת Workload או שירותים, גם אם מנוהלים אז לא הכל של AWS או לא הכל של Azure ולא הכל של GCP, כדי שתיהיה להם את היכולת שליטה וגמישות הזאת, וגם כדי שיוכלו להריץ את זה במקום אחר אם הם ירצו.
    • אז אני חושב שהמגמה הזאת, ככל שהבשלות של הכלים האלה תגדל - אז אנחנו נראה שהמוטיבציה להגיע למקומות שבהם את ה-Business העיקרי שלי - אני רוצה שליטה עליו, על ה-Supply Chain, כי ה-Supply Chain שלי, ואני חושב שנגעת בזה בשיחה הקודמת שדיברנו עליה - השליטה על ה-Supply chain היא יתרון תחרותי - ולא רק אופטימיזציה של Cost.
      • היא יכולה גם לייצר יתרון תחרותי במובן הזה שאני יודעים - ואנחנו רואים את זה בדוגמא של הסינים: מי ששולט ב-Supply Chain בסוף יכול להיות השליט של התחום שלו, לצורך העניין.
      • אז זה הופך כבר להיות משהו מאוד אסטרטגי, לא איזושהי אופטימיזציה  של Cost ואיך אני חוסך פה או חוסך שם עלות.
      • זה ממש הופך להיות משהו אסטרטגי - והכלים היום כן מאפשרים לחשוב יותר . . . מאפשרים ליותר ארגונים לחשוב על צורת העבודה הזו.
(אורי) אני חושב ש-Martin גם בא לזה מהמקום של וליואציות (Valuations) - הרבה מאוד מהמכפילים שאתה מקבל הם מכפילים על EBITA, ושם בוא - תתחיל להסתכל על ה-P&L שלך, ואיפה שיש “L” גדול מדי אז תתחיל להוריד אותו. והוא אומר שיש, כנראה . .. הוא קרה לזה “The Trillion Dollar Paradox - טריליון דולר, בשווי חברות, שיושב היום על הדלתא הזאת של המכפילים, ש . . .
  • (נתי) וזה אפילו מספר שהוא קונסרבטיבי, אגב . . . אם מסתכלים על זה, אז זה אמור להיות אפילו יותר.
  • כן, אני חושב שזה נוגע לזה - וכשהוא נגע בזה, אז הוא בעצם בא ותיאר, כשהוא חושב מאוד כמו אנליסט, אז הוא הסתכל על ה-”Cloud Wars 1.0” לעומת “Cloud Wars 2.0” - 
    • אז Cloud Wars 1.0 קרו בין שחקני ה-Cloud שהיום כולנו מכירים אותם בתוצאה שקיימת כיום - לעומת יצרני המחשוב, שזה HP ו-Dell וכו’
      • וגם אז הסתכלו על זה ואמרו, כמו שהיום אומרים על Repatriation - אומרים “מה, השתגעתם? אתם הולכים להיות יצרן של Server-ים? אתם הולכים לייצר חומרה? “יש פה חברות שזה ה-Domain שלהן” . . .
      • אפילו הייתה הרבה מאוד ביקורת על זה - והיום אני לא חושב שמישהו בכלל שואל את השאלה הזאת, זה די ברור . . .
    • (רן) את זה אמרו ל-Amazon ול-Google - “למה לכם לייצר חומרה אם HP מייצרים את החומרה בשבילכם?”
      • אבל לא - Amazon הלכו וקנו חברות חומרה, והיום הם מייצרים לעצמם.
    • (נתי) בזמנו, כשהרמת Datacenter, לא חשבת על לבנות חומרה, אף אחד לא חשב על זה - אבל פתאום הגיעה . . .
    • (אורי) חוץ מ-Facebook . . . .
    • (נתי) בדיוק - כשזה הגיע ל-Scale-ים גבוהים . . . ולמה הם הגיעו למסקנה הזאת? כי הם עשו את ה-Supply Chain Management ואמרו שיש פה Bucket שלוקח יותר מ-50% מה-Cost שלנו וזה לא הגיוני - אנחנו יכולים לעשות את זה פשוט יותר וטוב יותר ולשלוט ב-Supply Chain הזה.
    • אז אותו הדבר קורה היום לחברות ב-Scale בענן - הוא בא ואומר שאוקיי, קוראית עכשיו מגמה, כמעט 1 ל-1 למה שקרה אז, בין ה-Cloud לספקי המחשוב - זה קורה היום בין ספקי התוכנה לספקי הענן . . .
      • אז ספקי התוכנה הגיעו לנקודה - כל חברות ה-SaaS ב-Scale - הגיעו לנקודה שבה פתאום ה-Infrastructure Costs עולה להם מעל ל-50% - וגם הם מתחילים לשאול את עצמם את השאלה הזאת.
      • עכשיו - יש להם את כוח האדם להרים את ה-Infrastructure, אם הם רוצים - הם פשוט צריכים להחליט.
      • אין להם את הבעיה של ה-Barrier הטכנולוגי לעשות את זה  - וזה כבר באמת עניין של החלטה.
    • עכשיו - כן יש פה קושי אם אתה לא עושה את זה נכון ואם אתה עושה את זה מאוחר מדי ואם אתה לא חושב על זה קודם ועוד כל מיני שיקולים אחרים - אבל אני חושב שה-Barrier הזה ירד מאוד, ולכן אנחנו נראה את המגמה הזו הולכת וגדלה.
(אורי) אז בהורדה של ה-Barrier הזה נכנסים כלים טובים יותר - Kubernetes זו דוגמא - אבל עדיין יש Barrier של פחד, שנובע מחוסר-ידע.
  • (נתי) זה נכון, אבל אני אומר שפה באמת ה . . . הייתי אומר “המוצלחים יותר” מבינים שיש פה יתרון תחרותי
    • זו לא שאלה טכנית-פנימית של אופטימיזציה לאיזשהו תהליך - זה כמו שאתה חושב על “איך אני בונה חברה?” פחות או יותר, ו”איך אני גורם לה להצליח ביחס לתחרות?”
  • אז כשזה מגיע למשוואה הזאת, המטיבציות הופכות להיות מאוד גדולות - זה כמו שהיום פתאום מסתכלים על ייצור צ’יפים ועל איפה נמצא ייצור צ’יפים.
    • פעם ברור היה שזה באינטל, אבל היום אפל יוצאים עם M1 ו-Amazon יוצאים עם ה . . שכחתי איך קוראים לצ’יפ שלהם וכולם עם הצ’יפ שלהם - כי הם הבינו שצ’יפ זה דבר יקר ווהוא גם “מתנהג לא נכון” ל-Workload  שהם רוצים ואפשר לעשות לו אופטימיזציה
    • והנה באה ARM ופתחה את השוק הזה באמת, וכל אחד יכול לייצר לעצמו את הצ’יפ האופטימלי שלו [לתכנן - לייצר זה עדיין עניין אחר].
    • והאמת שאני חייב לציין שה-M1 הוא דבר מדהים - הוא כמעט, ביחס לכמות ה-Zoom-ים שאני יכול להריץ היום עליו בלי לטעון את ה-Mac שלי שהיא פנומנלית
      • לפני כן לא הייתי עובד סשן אחד עם ה-Intel-based Mac  - הייתי צריך לטעון אותו כל הזמן.
    • אז גם בצ’יפים זה . . .
    • (רן) והיית יכול להכין עליו טוסט . . . . טוסט-מועך כזה.
    • (נתי) לגמרי . . .
  • אז אנחנו רואים את זה כמעט בכל דבר - כשאנחנו עוברים ל-Scale-ים כאלה, אז מה שמכתיב זה ה-Supply Chain וכשמסתכלים על Supply Chain, המספרים מדברים - והמספרים מכתיבים אסטרטגיות ומוצאים את הדרך להגיע לזה.
  • רואים את זה ביצרני רכב, רואים את זה ביצרני צ’יפים, רואים את זה עכשיו בבטריות [טסלה זה שלושתם . . .] - ויראו את זה בכל מיני מקומות שבהן היה כזה “ברור שאני הולך לספק X שיעשה לי את הקוד” ו”ברור שאני הולך לסין כדי לייצר בטריות” ו”ברור שאני הולך לטייוואן כדי לייצר צ’יפים” - כל הפרדיגמות האלה נשברות.

(רן) אז אני מנסה להבין מה אתה אומר - אתה אומר שעכשיו כל סטארטאפ יתחיל לבנות את הכל בבית? או שאתה אומר שיקומו Vendor-ים, יקומו מתחרים ל-Amazon בתחום, לצורך העניין, ב-Messaging, יקומו מתחרים ל-Amazon, בתחום ה-Storage יקומו אלטרנטיבות לספקי העננים הגדולים - ואז אתה, כמשתמש, בוחר את הפתרון שמתאים לך: אם אתה צריך Storage מהיר וזול אז אוקיי, אתה לא חייב לקנות אותו מה-Amazon, אתה יכול לקנות אותו ממישהו אחר . . . 
  • (נתי) מ-Snowflake למשל . . . . ו-Snowflake זו דוגמא מעולה, כי לכאורה לא היית מצפה שבכלל תיהיה זכות קיום לחברה כזאת, בעולמות  של ענן - כי למה ש-Amazon לא יצליחו לעשות Snowflake יותר טוב מ-Snowflake . . . . [חוץ מזה שהשם כבר תפוס אצלם על מוצר אחר . . .]
    • ועובדה שהם מצליחים כן לייצר את ה-Margin וזה בגלל שהם מייצרים אופטימיזציה ורקטיקלית.
  • אני חושב שמה שיקרה זה הכל מהכל - זה לא הקצוות.
  • כן, יהיו מי שישתמשו בענן וזה כן יהיה עדיין המקום המרכזי שבו תריץ את רוב ה-Workload שלך - אבל יהיה לך Workload שהוא “ה-80% שלך”, שהוא גם עיקר העלות שלך - ועליו אתה תעשה את האופטימיזציות האלה.
  • אבל סביבות פיתוח, Testing וגם סביבות Production שהן לא ב-Scale מאוד גבוה - אין טעם לעשות על זה אופטימיזציה.
  • אז זה יהיה משהו מאוד היברידי וכן - יהיו חלק מזה שזה פתיחה לשחקנים נוספים שהם לא שייכים ל-Cloud - נתנו את הדוגמא של Snowflake
    • אבל אפילו אם תסתכל על Datadog אז זו דוגמא מצויינת - לכאורה יש לכל ה-Cloud-ים פתרונות ל-Monitoring והם גדלים במספרים של 60% לשנה עדיין, שבמספרים שהם מוכרים בהם זה פנומנלי.
  • אז הרף לחברות האלה הולך ועולה - הן צריכות להיות מאוד מוצלחות, מאוד אופטימליות, מאוד Efficient
    • וחלק מהיכולת שלהן להיות Efficient זה לשלוט ב-Infrastructure 
  • דיברתי, אגב, עם חברת Security, תיכף אני אזכר בשם - אז גם הם מריצים את רוב ה-Datacenter-ים שלהם - והוא אמר לי “תקשיב, במספרים שלנו, אם אני הייתי מריץ את זה ב-AWS, הייתי פושט את הרגל”.
    • זה נורא פשוט - זה Business שאם אתה לא מצליח לשלוט ב-Stack הזה וב-Margins אז אתה פשוט לא תשרוד.
    • (נתי) ScaleOps  . . . [זו החברה שהתכוונתי]

(אורי) אני חושב ש . . . אתה זוכר שדיברנו - רן - עם בחור מ . . . Zadara? נכון?
(רן) כן - ז’ באדר א’ . . .  [372 Zadara]
(אורי) אז הוא אמר שהם נותנים שירות לענן - אבל ה-Infrastructure שלהם הוא מבחוץ . . . . אני חושב שאחד הדברים שנורא כואבים לחברות שרוצות לתת שירותים בענן זה שמהר מאוד, “ספק-הענן-שלא-נקרא-לו-בשמו” מחקה אותם ומתחרה בהם - כשהם בעצם נותנים Business על הענן שלו.
(רן) וגם על זה היה לנו פרק, אם אני לא טועה . . . [365 הקוסמי - Carburetor 26 - open source politics] - על כמה מקרים כאלה.
(אורי) ומי שיכול להוציא את התשתית שלו החוצה ולהוזיל אותה מאוד, מצליח ויש לו Edge תחרותי אפילו על ספק הענן . . . .
  • (נתי) לגמרי . . . . נתנו פה כמה דוגמאות - zScaler ו-Snowflake ומן הסתם החברה שלך - Outbrain
  • כל אחד מהדברים האלה הם דוגמא לזה שזה . . .
(אורי) Outbrain זה . . הלקוחות שלה הם לא בתוך הענן, אנחנו לא נותנים שירות למישהו בענן . . .
  • (נתי) נכון, אבל זה כן משפיע בסוף על ה-Cost של השירות ואני מעריך שאולי אצלכם פחות, אבל בטוח ב-zScaler ו-Snowflake זה ממש משפיע.
(אורי) זה משפיע משמעותית על  . . .
  • (נתי) זה מה שהלקוח רואה בסוף
(אורי) העניין הוא שכשאתה נותן שירות SaaS, אז זה לרוב חותך ב-Margin שלך . . .
  • (נתי) בדיוק - ולכן ה-Cost של ה-Infrastructure הופך להיות משהו שהוא הרבה יותר מהותי ב-Supply chain הזה.

  • נתי) אני רוצה אולי לגעת, אולי לעשות איזושהי קפיצה, שדרכה אולי אפילו נוכל לסכם - כי אפשר לדבר הרבה על זה עוד, יש עוד מלא דברים שקורים בעולם הזה . . .
  • (רן) עד סוף השנה . . .
  • (נתי) עד סוף השנה, כן . . . . נדע ב-Retrospect . . .
  • אני חושב שנגעת בשאלה של התסכול, של ה”אוקיי, יקרה פה את זה ויקרה פה את זה ויקרה ה-Transition . . . “ - ועדיין אנחנו מרגישים שאנחנו זזים באותו, פחות או יותר באותה ה-Enchilada . . .
  • (רן) “מעבירים את הפקק קדימה” . . . . אבל עדיין יש פקק.
  • (נתי) מעבירים את הפקק קדימה, כן - אבל עדיין אנחנו נשארים בפקק, ובאמת אין פה איזו תחושה של איזושהי בשורה.
  • וכשאני מנסה, ככה, באמת להגיד מה יכול להיות Game Changer ואיך אנחנו יכולים באמת להוריד ולעשות קפיצת מדרגה בפשטות, לצורך העניין - אז אני חושב שיש שני דברים -
    • אני אגע בראשון, שאני חושב שהוא אותי הכי מלהיב, במחשבה - אני קורא לזה Fiverr ל-Infrastructure-as-a-Code “ . . . .
    • בעצם, מה שקורה פה, בנוסף לזה שיש Infrastructure-as-a-Code, זה שהרבה שירותים הופכים להיות “Pre-Templatized” כבר מה-Vendor-ים עצמם, ויש הרבה מאוד Template-ים כאלה - אבל מאוד קשה לצרוך אותם
      • מאוד קשה למצוא אותם, מאוד קשה לצרוך אותם, מאוד קשה לדעת מה האיכות שלהם, מאוד קשה למצוא את אנשי ה-DevOps האלה שיכולים אחרי זה לתת לך שירותים  ולדעת מי ומה טוב וגם העלות שלהם מאוד יקרה.
      • ובעצם, אפשר לייצר פה סוג של Crowdsourcing - עולם של Crowdsourcing, שבו היכולת לצרוך דברים שהם כבר “Pre-Templatized”
      • כי לרוב אנחנו “ממציאים מחדש את הגלגל” לאחוז גדול של הדברים - אז דברים שהם Pre-Templatized, עכשיו יש פה מטבע שעובר לסוחר, עכשיו אני כן יכול  להעביר לך Template או מודול של Terraform, והוא ירוץ אצלך ב-AWS כמו שהוא ירוץ אצלי ב-AWS, והוא ירוץ בכל אחד מה-Cloud-ים האחרים אותו הדבר.
      • עכשיו יש לנו את המטבע הזה, שפתאום אפשר לסחור בו - ולכן אני חושב שלייצר איזה Ecosystem כזה, של Crowdsourcing שבאמת אנחנו לא נחפש בכל פעם את האיש DevOps שיפתור לנו את הבעיה שפתרו גם, לצורך העניין, ל-Wix או לכל אחת מהחברות האחרות - ועכשיו אצלי
      • אלא נוכל לייצר באמת איזשהו Marketplace שיכול בעצם להוזיל מאוד ולפשט מאוד את איך שאנחנו חושבים בכלל על הבעיה ואת איך שאנחנו צורכים אותה
      • פשוט “תביא לי כלי Templatized ל-Kubernetes ל-Testing” או סביבה שכבר מוכנה מראש לדבר הזה 
      • זה לאו דווקא חייב להיות שירות SaaS - זה יכול להיות מישהו שמבטיח שהדבר הזה - האוטומציה הזאת - עבודת עבורי, והוא מתחזק לי את האוטומציה ואני מקבל את זה ויכול להריץ את זה בשירות שלי.
      • ואפשר בהחלט לעשות פה מהפכה באיך שאנחנו חושבים על הבעיה הזאת.
(אורי) אני חושב שזה יהיה משהו שהוא . . . אתה אומר שמאחורי זה יהיה גם בנאדם, כנראה?
  • (נתי) או בנאדם או חברה.
  • קח שוב פעם את הדוגמא של Crowdsourcing ב-Fiverr - בעצם לקחו את כל הצד הזה של יועצים ושל Freelancer-ים ובאו שאמרו שברגע שאני אאגד אותם תחת איזו מטריה אחת, ההנגשה של הדבר הזה גם מורידה את העלויות וגם מאפשרת לי לייצר הרבה יותר קשרים שהם Ad-Hoc-ים, אני לא חייב לעשות תהליך מאוד מורכב כדי למצוא את ה-Freelancer הרלוונטי
    • אם אני רוצה עכשיו להרים אתר, לצורך העניין WordPress, אז אני מוצא את הבנאדם הרלוונטי שעושה את זה - אני יכול למצוא אותו בהודו ואני יכול למצוא אותו בפיליפינים ואני יכול למצוא אותו בארץ.
  • ויהיו הרבה מאוד סוגים של בעיות כאלה, שאני יכול לפתור בשיטה הזאת, כי יש הרבה מאוד דברים שהם חוזרים על עצמם ויש הרבה מאוד דברים של “להמציא את הגלגל”.
    • ויש אחוז מסוים של דברים שאני חייה לעשות אותם בעצמי - אבל היום את הכל, פחות או יותר, אנחנו עושים בקצה של הבעיה הכי מורכבת שיש, ובכלים הכי יקרים שיש ובכוח אדם הכי יקר שיש ובאנשים הכי מורכבים שיש
    • כי קשה לנו להכניס אותם לתוך הארגון, מאוד קשה לנו לקחת את התוצרים שלהם, מאוד קשה לנו למצוא אותם
    • וזה יכול לייצר, בדיוק כמו ש-Fiverr יצרו מהפכה בעולמות של פרילאנסרים, זה יכול ליצור מהפכה באיך שאנחנו יכולים לפחות לקחת את החלק הזה שהוא Repeatable ולפתור אותו בארגונים שלנו, ולפשט מאוד את הבעיה בזה שאני יכול לעשות Outsourcing לאחוז גדול ממנה.
  • הדבר השני זה באמת ה-No-Code, שהוא קשור לזה כמובן - כל האיזורים האלה שאיך אני גם מאפשר לאנשים שהם לא מפתחים לכתוב אוטומציה ל-Infrastructure.
    • שזה כאילו סתירה ל-As-Code - יש לנו No-Code ו-As-Code והדוגמאות של זה, אם אנחנו מסתכלים על Monday ואנחנו מסתכלים על כל כלי האוטומציה של Marketing - הרבה מאוד מכלי האוטומציה האלה נבנו על ההבטחה הזאת - שאני יכול לתת ממשק משתמש מאוד מאוד פשוט  . . .
    • (רן) כמו Zephyr או IFTTT  . . . 
    • (נתי) כן - אני יכול לתת הרבה מאוד Templatize, הרבה מאוד אינטגרציות מוכנות מראש - ותעשה Drag & Drop ואתה לא צריך למצוא מפתח ואני גם אתן לך אוטומציה.
  • (רן) יש כאלה גם ל-Machine Learning עכשיו, לא מעט.
  • (נתי) בדיוק . . . אז אני חושב שמתבקש שיהיה גם משהו כזה לעולמות של Infrastructure, כי יש גם הרבה מאוד דברים ב-Infrastructure שהם כאלה, של “תרים לי Kubernetes, תחבר לו איזה elm chart ו . . . “
    • (רן) “ . . .אתה צריך Load balancer, אתה צריך שלושה Server-ים מאחוריו, אתה צריך Database, תזרוק . .. “
  • (נתי) כן . . . אז היו לנו, בעבר, את “הטראומות PaaS” אני קורא לזה . . . מה שניסה כאילו לפתור את הבעיה הזאת אבל יצר “גן סגור” ואת ה-Classic Jailbreaker
    • אבל היום, ברגע שלצורך העניין ה-PaaS הזה הופך להיות פתוח ו-Custom ויש לי שליטה על כל אלמנט ב-Stack, אז אני כן יכול לדבר במושגים.
  • די ברור לי שזה לא יהיה ה-”Monday-Style” - זה חייב להיות משהו שאני כן יכול לכתוב ב-No-Code אבל יהיו מודולים מסויימים שאני צריך לכתוב אותם בקוד וצריכה להיות פה אינטראביליות בין הפרדיגמות האלה.

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

(רן) טוב, נתי - היה תענוג, היה מעניין . . .
(נתי) כרגיל, לא גמרתי את הקפה אפילו . . .
(רן) אז תודה רבה - אנחנו היינו אנחנו וזו הייתה 2022, ובואו נקווה שהכל יצליח לנו.
(אורי) אנחנו לא עושים Retrospect, אז אתה יכול להגיד מה שאתה רוצה . . .  [הכל מוקלט, כן?]
(נתי) אבל שימו לב שלא הזכרנו את המילה “Covid” ולא הזכרנו את המילה “אומיקרון”, שזה כבר בשורה לכשלעצמה . . . היו סיבות להזכיר את זה גם בהקשר הזה אבל הצלחתי להימנע מזה - וזה ההישג הכי גדול של הפודקאסט.
(רן) אמרת שזה איזשהו קטליזטור כלשהו, אני לא אנקוב בשמו . . . אבל בקטנה.
(אורי) לוריאנט הבא יקראו “קובנרנטיס” . . . 
(נתי) בדיוק . . .
(רן) תודה רבה ולהתראות

 האזנה נעימה ותודה רבה לעופר פורר על התמלול!