Artwork

תוכן מסופק על ידי רברס עם פלטפורמה. כל תוכן הפודקאסטים כולל פרקים, גרפיקה ותיאורי פודקאסטים מועלים ומסופקים ישירות על ידי רברס עם פלטפורמה או שותף פלטפורמת הפודקאסט שלו. אם אתה מאמין שמישהו משתמש ביצירה שלך המוגנת בזכויות יוצרים ללא רשותך, אתה יכול לעקוב אחר התהליך המתואר כאן https://he.player.fm/legal.
Player FM - אפליקציית פודקאסט
התחל במצב לא מקוון עם האפליקציה Player FM !

445 Carburetor 33 - platform engineering

 
שתפו
 

Manage episode 338786303 series 2497397
תוכן מסופק על ידי רברס עם פלטפורמה. כל תוכן הפודקאסטים כולל פרקים, גרפיקה ותיאורי פודקאסטים מועלים ומסופקים ישירות על ידי רברס עם פלטפורמה או שותף פלטפורמת הפודקאסט שלו. אם אתה מאמין שמישהו משתמש ביצירה שלך המוגנת בזכויות יוצרים ללא רשותך, אתה יכול לעקוב אחר התהליך המתואר כאן https://he.player.fm/legal.

פודקאסט מספר 445 של רברס עם פלטפורמה - קרבורטור מספר 33. אורי ורן מארחים את נתי שלום אחרי כמה חודשים טובים [32 היה בינואר], כדי לדבר על נושאים תשתיתיים מעניינים.
(רן) היום אנחנו רוצים לדבר על נושא שנקרא Platform Engineering - את שתי המילים אנחנו מכירים [בכל זאת - רברס עם פלטפורמה], אז Platform ו-Engineering - אבל מה זה “Platform Engineering”? אז בוא נצלול פנימה . . .
(אורי) בטח יש גם Platform-Reverse-Engineering . . . [נסו ב-DALL·E הקרוב למקום מגוריכם]
  • (נתי) Platform אתה יודע ו-Engineering אני לא צריך להסביר לך . . . . אבל אני אחזיר אותך לשיחות שהיו לנו, אני חושב שבאיזור 2012, איפשהו באיזור הזה.
    • אני זוכר שהיית Advocate של Heroku ושל כל מה שנקרא “Platform-as-a-Service”
    • זה היה ממש בימים שבהם חילקו את ה-Cloud - אני לא יודע אם יש עוד אנשים שעדיין זוכרים את זה - ל . . .
(אורי) SaaS ו-IaaS . . . .
  • (נתי) . . . ל-IaaS ו-SaaS ו-PaaS - שלושת השכבות . . . .
(רן) Infrastructure-as-a-Service ו-Software-as-a-Service ו-Platform-as-a-Service . . . .
  • (נתי) בדיוק - Infra ו-Platform ואז Service - בסדר הזה.
  • ואז הייתה איזושהי תקופת-עדנה ל-Platform-as-a-Service - כשהרעיון מאחורי זה היה ש”ה-Infrastructure-as-a-Service הוא מסובך”
    • ו-Platform-as-a-Service נועד לתת ממשק למפתחים, “שיחביא” את המורכבות הזאת ע”י זה שבעצם כמעט כל האפליקציות יהיו סוג של . . . .
    • היה בזמנו Node.JS, היה Rails - היו כל מיני Stack-ים כאלה
    • ואמרו - “בואו נייצר . . “ - ממילא האפליקציה בנויה מאיזשהו Stack די ידוע מראש ורוב העבודה זה Boilerplate - “ . . . בואו נעטוף את זה, ותיהיה פלטפורמה ששתיתן לך את הכל”
      • וזה יהיה פרודוקטיבי מאוד למפתחים.
    • ואני חושב ש . . .
(אורי) “תבוא - תכתוב Business Logic . . . .”
  • (נתי) בדיוק . . . . וכל עוד האפליקציות באמת נראו ככה, אז הייתה עדנה לתפיסה הזאת
  • היה את AWS שיצאו אחרי - שכחתי איך קראו לשירות שלהם [AWS Elastic Beanstalk?] . . . והיה את Google App Engine . . .
(רן) כן . . . אז Google App Engine ו-Heroku - כנראה Heroku הייתה . . .
  • (נתי) Salesforce קנו אותם בסוף . . . .
  • ול-AWS היה את הפתרון שלהם - ה-Beanstalk! זה היה הפתרון שלהם.
    • וכל Cloud יצא עם ה-Platform-as-a-Service שלו . . .
  • והייתה תקופה של אני-חושב-2014-כזה, איפשהו באיזורים האלה, שהיתה לזה איזושהי “תקופת עדנה”, נקרא לזה ככה.
    • ופתאום זה נעלם . . .
    • היה את Cloud Foundry - ופתאום זה די התחיל-כזה-לדעוך - ומהר.
  • תיכף נחזור לנקודה הזאת, אבל אני חושב שקרו . . .
(רן) אני אזכיר לך - נתי - ש-Correlation is not a Causation . . . . באותו תקופה בדיוק ייצור החסה בשטחים גם עלה . . . .
  • (נתי) אז לא - יש קשר . . . יש הרבה קשר, אגב.
  • למעשה, זה הולך לצומת שאני חושב שכל תעשיית התוכנה מסתובבת סביבה משנות-הפחות-או-יותר-60 ואולי אפילו לפני - זה ה-Tradeoff הידוע שבין גמישות לפשטות.
    • מה שמשתנה זה לא ה-Tradeoff הזה והמתח המובנה שיש בתוכו, אלא הכלים שכל פעם נוצרים והיכולת לעשות את ה-Tradeoff הזה פעם אחת יותר בכיון הגמישות ופעם אחרת יותר לכיוון הפשטות
    • המטוטלת הזאת מלווה אותנו המון המון זמן - ותמשיך ללוות אותנו גם בהמשך.
  • אז במטוטלת ההיא - אני מזכיר, בימים הראשונים כש-EC2 היה רק Storage-Network-Compute - היה מאוד מאוד מורכב.
    • היה מאוד מסובך לאנשים להבין איך עושים אוטומציה ב-APIs ו-Script-ים וכל מיני דברים שאתה לא תמיד היית רגיל לעשות ב-Data-center.
(רן) CloudFormation . . . . למי שזוכר, זה היה מזעזע . . . .
  • (נתי) ו-CloudFormation, שומו שמיים - איזה JSON שהופך להיות API-Call . . . .
  • ואז, בתקופה הזאת, באמת להרבה ארגונים היה מאוד קשה לעבוד עם התשתית הזאת
    • ולכן הצורך בפשטות היה מאוד מובן וחזק.
  • ופה נכנס ה-Tradeoff הזה לגמישות - כי בעצם קרו כמה דברים -
    • אחד זה השירותים בענן - יש לי פה איזה גרף מעניין שאני אחלוק איתך אחרי זה, שמראה באיזה קצב AWS התחילו להוסיף עוד שירותים [הנה פה למטה]
      • הם כבר מזמן לא רק Storage-Network-Compute . . . .
      • והפלטפורמות לא הדביקו את הקצב . . . פשוט נוצר מצב שכשאתה עובד עם הפלטפורמה, אתה מקבל פחות ופחות שירותים בענן, ואז אתה אומר “רגע - אני משלם ל-AWS אבל בסוף אני מקבל ‘’שליש-AWS‘’ או ‘רבע-AWS או ‘עשירית-AWS . . . .” - זה לא הגיוני. [ובכן . . . ]
    • דבר שני שקרה בתוך הדבר הזה זה שהארכיטקטורה של האפקליציות הפכה להיות שונה, בטח אם אנחנו מדברים על Machine Learning . . .
      • הן נהיו יותר מבוזרות, והקוביות האלה של Rails וה-Stack-ים של J2EE וה-Stack-ים של Python במקרה הזה, לא זוכר כבר את השם של . . .
      • (רן) Django!
      • (נתי) Django! בדיוק . . . . אז הם נהיו פחות ופחות פופולאריים, והמערכות הפכו באמת להיות הרבה יותר מורכבות ומבוזרות, ככה שגם התפיסה הארכיטקטונית כבר לא התאימה.
    • שני הדברים האלה לבד כבר די הכניסו את הפתרון הזה לסטרס - ובמקביל, בצד של “הגמישות”, התחילו להתפתח פלטרפורמות שעשו את האבסטרקציה . . . . פישטו בצורה מסויימת את התשתית לענן
      • זה Terraform - ו-Kubernetes בשלב יותר מאוחר - לעולמות של Container-ים.
    • וזה נתן איזשהו Tradeoff יותר סביר לתקופה-אפילו-ארוכה, בין פשטות לגמישות - יותר לכיוון הגמישות, על חשבון פשטות.
    • באותו זמן, אני חושב שזה היה מספיק כדי באמת להיות מסוגל לעשות את האפליקציות היותר מורכבות על הענן
  • והגענו לאיזור 2020-2021, ופתאום חברות שהן לא Legacy - לא הבנקים הגדולים, Morgan Stanley וכאלה ו-Enterprises - כמו Spotify . . .
    • (רן) גילו שזה נורא מסובך . . . .
  • (נתי) בדיוק . . . Spotify - “ה-Rockstar של ה-DevOps” [חייב להיות meme לזה . . .] . . . באמת ה-Poster-child של ה-DevOps, שכולם בעצם קוראים את המניפסטים שלהם ומאמצים אותם מיד, שזה די מדהים לכשלעצמו.
    • והם באים ואומרים “תקשיבו - ה-Cloud הזה וה-Terraform הזה ו-Kubernetes הזה - זה מסובך . . . .”
    • וואלה מסובך . . . ואז פתאום אתה תופס את עצמך - שנה לפני כן, השיחה הייתה נראית אחרת לגמרי . . .
  • לי היו בשנה הזאת הרבה מאוד שיחות עם לא מעט חברות בתחום הזה, שבאמת הן לא “חברות Legacy”
    • אני מדבר על Wix ועל AppsFlyer לצורך העניין - חברות שהן חברות תוכנה, שפשוט גדלו בקצב גבוה
      • ולכולן יש את כאבי הגדילה . . . .
    • והן הבינו דבר מאוד פשוט - אין הגיון בזה שכל מפתח יכתוב קוד ב-Terraform ואין הגיון שכל מפתח יכיר Kubernetes
      • ולכן צריך “משהו באמצע”, שיעזור למפתחים להשתמש בזה - כי יש לזה המון יתרונות - אבל בצורה יותר מופשטת, יותר אבסטרקטית.
(רן) אתה, למעשה, בא ומתאר עכשיו פלטפורמה של מפתחים - פנימית? לעובדים שלי?
  • (נתי) בדיוק . . . עכשיו, מה ההבדל בין ה-Platform-as-a-Service של Heroku וזה?
    • העקרונות הם אותם עקרונות - אני שם אבסטרקציה כדי שתחביא את המורכבות, וככה בעצם היעילות של המפתח נהיית יותר גבוהה.
      • החלק הזה נשאר זהה
    • ה”איך” ניהייה שונה - כי בעצם מה הייתה הבעיה של הפלטרפורמות האלה? הזכרנו חלק מהבעיות, אבל הבעיה העיקרית הייתה שגם כארגון, אני פתאום מאמץ משהו שמכתיב לי איך אני צריך לעבוד, ואני לא יכול כמעט להזיז בו כלום . . .
      • אני תלוי באיזה מישהו אחר - וזה לא מתאים לי.
    • ואמר - ברח לי השם שלו עכשיו, היה . . . הבחור הזה מ-Google . . .
      • (אורי) יבגני?
      • (נתי) לא יבגני . . . רגע, תיכף אזכר ונכניס אותו במקום הנכון . . .
    • הוא אמר שבעצם, בסוף בסוף - כל אחד היה רוצה שיהיה לו Platform-as-a-Service - As long as you build it yourself . . . .
      • זאת אומרת - כל עוד אני יכול לתפור אותה למידות שלי, זה רעיון מצויין . . . .
(אורי) סליחה, אבל אתה מרים לי להנחתה - אני יכול להגיד לך “ברוך הבא ל-Outbrain” . . . . [ד”ש - 368 Kubernetes and Dyploma at outbrain]
  • (נתי) או . . . אז אני בטוח שהדברים האלה כבר יושמו ואתה מכיר את הכל ו-Outbrain כבר עשתה את זה בשנות ה- . . . מה שנקרא “ב-47” . . . .
(אורי) שלושים שנה, לך תזכור”, כן . . . אבל זה גם מתאים את עצמו, כמו שאתה יודע . . .
  • (נתי) כן . . . הרעיונות - אין בהם שום דבר חדש . . . . כמו שאמרתי, אלו דברים שכבר מהימים הראשונים של התוכנה אני חושב שאנחנו מסתובבים סביב ה-Tradeoff הזה
    • שום דבר - מהבחינה הזאת, של המתח הפנימי הזה שבין הפשטות לגמישות - הוא תמיד היה ויהיה.
    • מה שמשתנה זה הכלים וסוג המורכבות שאנחנו רוצים להגיע אליה
    • ואנחנו כל הזמן משנים את ה-Tradeoff הזה בהתאם למציאות שאנחנו נמצאים בה.
  • אז גם פה המציאות עכשיו היא כזאת: השכבה היא כבר לא ענן - הייתי אומר “כמו שהכרנו בעבר” -
    • יש לנו באמת שכבות כמו Terraform, שזה Infrastructure-as-a-Code ו-Kubernetes שזה ניהול של Container-ים
    • שנתנו לנו איזושהי אבסטרקציה שמאפשרת לנו לחשוב על הדבר הבא.
  • ועכשיו, בעצם, היכולת של ארגון לבנות פלטפורמה שהיא “תפורה למידותיו” - נהייתה עם חסמים הרבה יותר נמוכים ממה שהיו קודם
    • אם קודם הייתי אומר לך “תבנה, על בסיס של VM-ים לצורך העניין, ’פלטפורמה למפתחים’, שתיתן פתרון-as-a-Service לכולם” - רמת המורכבות הייתה מאוד מאוד גבוהה ולא היית ניגש לזה בכלל.
(רן) אני חושב שיש לזה . . . לפיתוח של פלטפורמה פנימית, מעבר לצורך לפשט - זה גם מונע צרכים אחרים, כגון Enforcement ו-Security וסטנדרטיזציה . . . .
  • (נתי) נכון . . . קראתי לזה Efficiency ו-Consistency
    • בגדול זה איך אני מבטיח - בין צוותים - שהצורה שמשתמשים במשאבים תיהיה קונסיסטנטית (Consistent) בין הצוותים ובין מפתחים
    • וגם Efficiency - במובן הזה שבסוף כשאני רוצה Database ואני רוצה . . . אני לא צריך להכיר את איך שמקנפגים (Configure) ואיך מרימים אותו
      • מישהו צריך להכיר את זה - אבל לא כולם.
      • בדרך כל זה מתבטא ביחס מאוד ברור - מעטים צריכים להכיר, הרבה צורכים, מעט צריכים לבנות . . .

(אורי) זה, כאילו . . . אני חושב שלפעמים, אין ממש מושג עד כמה זה הופך את החיים להרבה יותר פשוטים כשיש לך Pipeline אחד והוא מותאם לצרכיך - זאת אומרת, הוא גם נותן לך את הגמישויות שאתה צריך ומקשיח את מה שאתה לא צריך לדעת או לא צריך להתעסק איתו . . .
  • (נתי) זהו, שעכשיו מה אמרת? בדיוק את הנקודה שבה המטוטלת הזו כל הזמן זזה - ותמיד היא תזוז.
  • ה-Tradeoff שאתה לוקח בעצם, במודע, זה שאתה נהייה “Opinionated” -
    • אתה אומר, נניח כשלקחנו Terraform ו-Kubernetes - הם מאוד Un-opinionated: יש לך . . פחות או יותר “אני חושף לך את כל המתגים האפשריים - תבחר!”
    • אני אתן לך את כל המתגים בעולם, פחות או יותר - של ה-Network, של ה-Storage, של ה-Compute, של ה-Load Balancer - הכל! . . .
(אורי) . . . ואז תגלה ש-80% מהמתגים האלה לא רלוונטיים בכלל - הבעיה היא שלכל אחד, ה-80% שלו הם אחרים . . . .
(אורי) . . . אתה רואה שבתכל’ס, החברות הגדולות - “הבהמות הגדולות” - ככה הן עובדות: הן לא חושפות למפתח את ה-Infrastructure-as-a-Code . . .
  • (נתי) נכון . . . הרבה פעמים זה לא מתחיל ככה - אבל זה מגיע לשם.
  • יש איזשהו Maturity Cycle - שבהתחלה, גם כשהרמת VM-ים לצורך העניין, או כשהרמת Compute במקרה שלך . . . .
(אורי) . . . לא היה VM-ים . . .
  • (נתי) . . . לא היה VM-ים . . . את זה האמת לא ידעתי, אבל כשהתעסקת עם Bare Metal, אז זה היה מאוד . . .
  • אני זוכר את הימים של להתעסק באיך שנראה הכרטיס ואיזה סוג ואיך עושים אופטימיזציה לכל ה-Compute כדי שהוא יהיה יעיל . . . .
(אורי) . . . . אבל זה אף פעם לא היה ב-Domain של המפתח - זה היה ב-Domain של . . . פשוט, חלק מהעניין זה לעשות “Platform Engineering”.
  • (נתי) נכון, אבל אז היה . . . אני זוכר, היה מאוד חשוב איזה סוג Compute אני מקבל, איזה סוג מעבד יש בו, איזה סוג . . . . כמה זכרון . . .
    • דברים כאלה שהיום בענן אתה מקבל Extra-Large - Medium - Whatever . . .
      • ואתה פחות או יותר יודע שזה מה שאתה מקבל - אין לך מושג, כמעט, איך ה-”Extra-Large” מורכב ואיזה מעבד עומד מאחורי זה וכמה Cycle-ים יש ל-CPU . . . .
      • המון דברים שהיום אתה באמת כבר לא חושב עליהם במובן הזה.
  • אז אני אומר - זה כל הזמן קורה, והיום אנחנו נמצאים בנקודה שבה זה קורה סביב Platform Engineering על גבי פלטפורמות של Terraform ו-Kubernetes וענן
    • וזו הנקודה שהרבה ארגונים שעברו את שלב ה-Scale הגיעו אליה - כזו שאני חושב שגם אתה תיארת, של התהליך שעברתם ב-Outbrain - כשאתה מתחיל לשאול את עצמך איפה באמת ה-Tradeoff?
    • ואתה מגיע למסקנה שה-Tradeoff לא עובר בזה שאני נותן את כל דרגות החופש למתפחים ועושה אופטימיזציה להכל, אלא שאני צריך להיות מאוד Opinionated -
      • יש דברים שאני נותן דרגות חופש, יש דברים שאני לא נותן דרגות חופש - וזה משתנה מארגון לארגון.
    • לכן חשוב לי שהפלטפורמה תיהיה בשליטה, ולא משהו שמוכתב ע”י איזה Vendor או על ידי איזושהי תשתית חיצונית.

(אורי) אני חושב שהרבה מאוד מהפחד להבין את התשתית הזאת - זו תשתית בסוף, אוקיי? זו תשתית שהיא Opinionated והיא אומרת לך “פה - ככה עובדים”. ואתה מכניס מפתח חדש - נגיד שב-Outbrain אנחנו מכניסים מפתח חדש ותוך שבועיים-שלושה הוא אפקטיבי, כי יש לו את הכל בשביל להיות אפקטיבי, הוא לא צריך פתאום להתחיל “לגלח את היאק” בשביל להתחיל עם Kubernetes או משהו אחר.
אבל ההחלטה הזאת לשים Platform Engineering ו”פתאום” שיהיה לך Deployment Pipeline וכל מה ששומר עליך, ו”פתאום” ה-Infrastructures “מוחבא” לך - היום מהנדס ב-Outbrain עושה Deploy והוא לא יודע, או שהוא יודע אבל זה לא ממש משנה לו, אם הקוד שלו Deployed On-Perm או על ענן, זה לא משנה לו . . .
  • (נתי) וזה עכשיו אפשרי בזכות Kubernetes, נכון?
(אורי) זה אפשרי בזכות Kubernetes, אבל לא רק בזכות Kubernetes . . .
  • (נתי) זאת אומרת שאם היית עושה את זה בלי Kubernetes, היה לך פי-מיליון יותר מסובך . . .
(אורי) אבל לא רק בזכות Kubernetes - אלא בזכות זה שיש עוד שכבה, שמבודדת אותו גם מה-Kubernetes, כי האימפלמנטציה (Implementation) של Kubernetes ב . . .
  • (נתי) נכון, ב-AWS היא טיפה שונה . . .
(אורי) . . . . והיא שונה ב-Azure מאיך שהיא . . . . זה לא מעניין אותו.
  • (נתי) כן, אני יודע, ברור - אבל זה . . . נוצרה לך איזושהי שכבה מעל ההתשתית של הענן, שמאפשרת לך עכשיו לבנות את השכבה הנוספת הזאת.
    • לפני כן - אם היית מוריד אותה - היה לך לא משתלם להתעסק בלבנות תשתית כזאת.
(אורי) כן . . . יכול להיות שבמקום שאתה עובר מלהיות Un-opinionated ל-Opinionated, אז פתאום לאנשים חסרים כמה דברים . . . בסדר, אז אתה דואג להם שלא יהיו חסרים להם כמה דברים - זה לוקח חודש או חודשיים או אולי שלושה, המערכת מקבלת את ה-Maturity שלה, ובשלב מסויים אתה כבר . . . התדירות שבה אתה צריך להתאים את ה-Infrastructure, את הפלטפורמה לגמישויות, היא נהיית כל כך לא-שכיחה . . . .
  • (נתי) אני מסכים איתך - אני חושב שצריך לקרות, עוד פעם, “שינוי טקטוני” כזה, כמו המעבר לענן, משהו בסדר גודל הזה - כדי שזה עוד פעם יעצר.

(רן) אני רוצה להצביע פה על איזושהי בעיה . . . בעצם מה שאתה אומר, נתי, זה שעכשיו כל חברה צריכה להקים “צוות פלטפורמה”, שיכתוב לעצמה את הפלטפורמה - בגלל זה אנחנו קוראים לזה ככה, “Platform Engineering” - והפלטפורמה הזאת היא לא טריויאלית, כן? . . . אתה מדבר על לייצר Heroku-כזה-פנימי” . . .
  • (נתי) נכון . . .
(רן) . . . מה הפתרון לזה? עכשיו, כמייסד בחברה, אני צריך קודם כל לגייס צוות-פלטפורמה ענק?
  • (נתי) לא . . . אז (א) זו שאלה - השאלה - והרמת לי להנחתה מן הסתם, אבל אני אגיד מה המציאות ומה רוצים להגיע אליו.
  • אז באמת, אנחנו רוצים להגיע לפלטפורמה, שזה סוג של “לבנות Heroku
    • בהתחלה זה מתחיל ממשהו מאוד נאיבי, מגניב - “אני אגייס אנשים, אני אבנה משהו מאוד מעניין, אני אעשה משהו שהוא לא רק-Script-ים סוף סוף, אני אבנה משהו שהוא מוצר, אני אתייחס לזה כמוצר . . . .”
    • (רן) “אני אכתוב JSON!” . . .
  • (נתי) כן . . . ובסוף, מה שאתה רואה זה שהם מתעסקים עדיין הרבה מאוד ב-GitOps ואולי קצת מסביב ל-GitOps, ב-Flux וטוב . . . שזה GitOps . . . ובעוד כמה דברים מסביב לזה.
    • עדיין, נשארים ב-Layer המאוד-מאוד-נמוך הזה, שהוא עוד לא יכול לתת את החוייה ואת הקפיצת-מדרגה בפשטות.
      • אני קורא לזה שיש לך חלום לבנות גורד שחקים - ואתה עדיין תקוע בלבנים ובמלט . . .
      • ומלבנים ומלט כנראה שלא תבנה גורד-שחקים בזמן הקרוב . . . .
  • ולכן - וזה מביא אותי לאיזשהו פוסט שדווקא פרסמתי היום, של Spotify - שמדבר על משהו שנקרא C4
    • ו-C4 זה בעצם . . . הבעיה שהם באים ואומרים זה שכל עוד אני תקוע ב”לבנים וחצץ” או “לבנים ומלט” - מאוד קשה לי לבנות מערכות גדולות
      • מאוד קשה להסתכל על המערכת כמערכת - כי אין לי את השפה הזאת בכלל
      • איך אני יכול לבנות מערכת כשאני . . . כשהכל הוא ב-Assembly? . . .
    • ואז הם הגיעו לנקודה שבה באמת צריך את השפה הזאת, שמגדירה דברים שנקראים Domains, Systems, Components . . .
(רן) אז C4 זו למעשה שפת-Modeling?
  • (נתי) C4 זה זה סוג-של-שפת-Modeling, שלמעשה היה איזשהו פוסט ב-InfoQ שהם אימצו אותו ובנו מאחוריו “תפיסה מוצרית”, נקרא לזה ככה
    • שבאמת באה ואומרת איך אני עכשיו לוקח מערכות מורכבות וממדל אותן לתוך סביבה.
  • וברגע שאני אוכל - אז אני יכול להתחיל לייצר כל מיני סביבות Dev-Production מסוגים שונים
    • אבל בלי לדעת עכשיו שזה . . . איזה Terraform מעורב בכל Module כזה
    • אני אוכל לתת ממש פרמטרים שאומרים “תעשה את ל-Development” תעשה לי את זה ל-Production” -
      • ומתחת אני אדע כבר לעשות לזה את ההתאמה
      • זה יהיה Optimized ל-Cost”; זה יהיה Optimized ל-Availability”; זה יהיה Optimized ל-Security”; זה On-Demand” - ועוד כל מיני דברים מהסוג הזה.
  • אבל אני מדבר פתאום בשפה . . . השפה שאני אדבר בה עם הפלטפורמה היא הרבה יותר אבסטרקטית - אני מדבר בשפת-System, לצורך העניין, ולא בשפת microService.
  • אז ה-C4 הוא איזושהי תפיסה שנועדה קודם כל לייצר את השפה הזאת ולייצר את ההבנה הזאת ולייצר את היכולת להתסכל על מערכת בכלל . . .
    • היום, אם אתה תשאל מישהו “תראה לי, תעשה לי Whiteboard וצייר לי את המערכת” - אין שפה נורמאלית לצייר מערכת, כי המורכבות היא מאוד גדולה
    • ואין גם את הטרמינולוגיה . . . . כלומר, היום אם אתה תנסה, אפילו ברמת הטרמינולוגיה, לדבר ולהראות שפה, אז הם ידעו לדבר על מודולים והם ידעו לדבר על microServices - אבל לא מעבר לזה.
    • אנחנו די נתקענו באיזורים האלה כבר הרבה זמן . . .
  • אז התובנה הזאת היא גם חלק מהנקודה הזאת - ותיכף אני אגיע ל-Build vs. Buy ואיך הופכים את זה לפרקטיקה . . .
(רן) הרמתי לך להנחתה . . .
  • (נתי) כן . . . אז קודם כל, אמרתי שישנה איזושהי הבנה שכדי להגיע למשהו, שבכלל אפשר לדבר על Build vs. Buy - צריך להיות משהו שהוא Repetitive
  • ו”ההרמה להנחתה” היא באמת שאי אפשר לבנות את הפלטפורמה הזאת . . .
    • למרות Kubernetes ולמרות Terraform - זו עדיין הרבה מאוד עבודה.
    • ובאמת, אם אתה תנסה לבנות את זה לבד, זה גם יהיה לך מאוד יקר, גם יקח לך הרבה מאוד זמן, גם לא תגיע לגורד-שחקים אלא תשאר בפחות או יותר . . . אולי תבנה עוד קומה, אבל לא יותר מזה.
      • אבל לא תעשה את הקפיצה, לא תעשה את ה-Leap הזה.
  • ועכשיו מתחילות להיבנות תשתיות, שהן בעצם עוזרות לארגונים לבנות את הפלטפורמה הזאת - כשבעצם הם חוסכים הרבה מאוד עבודה שהיא Repetitive.
    • ו-Backstage זה אחד מהדברים האלה - בא מבית היוצר של Spotify [רפרנס לינואר 2022 -432 Carburetor 32: 2022 DevOps Predictions]
    • אני מסתכל על ברטרוספקט (Retrospective), כי הרבה פעמים שואלים איך Spotify ומה ל-Spotify ול-Open Source ול-Backstage ולכל הדברים האלה
      • ואני מזכיר לכולם - Amazon היא חנות ספרים . . . .
      • באותו זמן, כש-Amazon התחילו את ה-Journey שלהם, היה להם eCommerce ואחרי זה, כדי למכור את ה-eCommerce, הם התחילו מזה שהם באו ואמרו - “הנה, בנינו חנות ספרים, אנחנו יודעים למכור טוב באינטרנט - כנראה שעשינו משהו נכון, אז בואו אולי נשכפל אותו”.
      • ולאט לאט זה ניהיה מה שזה ניהיה היום - אבל זה התחיל מאבולוציה מהסוג הזה.
    • ולכן אני חושב שלא הייתי פוסל - אמנם הם עוד לא חושבים ככה - אבל לא הייתי פוסל את זה ש-Spotify . . .
(רן) Spotify עוד לא יודעים שהם . . . .
  • (נתי) ל-Spotify יש אספירציות (Aspirations) . . .
  • מעבר לזה, למשל, הם מתייחסים ל-Backstage כאל מוצר מסחרי - יש להם Business Model והם בונים לו Marketplace
    • הם לא עושים את מה ש-Netflix עשו, שזה רק Open Source ו”שלח לחמך” . . . .

(אורי) אני חושב שאתה נוגע בנקודה, שלא משנה אם המוצר הוא מסחרי או לא - קבוצת פלטפורמה צריכה להתייחס למוצרים שלה כאל “מוצרים” . . . .
  • (נתי) בדיוק . . .
(אורי) . . . זה שיש להם לקוחות פנימיים - זה לא אומר שזה לא מוצר.
  • (נתי) זה משפט מאוד חזק ואני משתמש בו הרבה . . .
(אורי) . . . . ברגע שעשינו את ה-Shift הזה - הרבה מאוד דברים פתאום התחילו לזוז.
  • (נתי) אני חושב שזה משפט ששווה להתעכב עליו, כי הוא מאוד מאוד חשוב - כמה שהוא נשמע טריוויאלי כשאומרים אותו . . .
  • כי יש פער בין זה שאתה אומר אותו וזה נשמע טריוויאלי . . . אתה מכיר את המשפטים האלה שאתה אומר “אה, ברור!”, אבל איפשהו ביומיום אתה לא מגיע אליהם וזה לא בדיוק מתנהל ככה? . . . .
(רן) אז הנה “נייר לקמוס” - כמה מנהלי מוצר יש לכם בקבוצת הפלטפורמה?
(אורי) שניים . . . אחד-שניים . . . .
(רן) אז אם התשובה היא “אפס” אז כנראה ש . . . .
  • (נתי) זה אומר שגם אם הביאו . . . כשאני שואל “אוקיי - מה השתנה?” אומרים לי “הבאנו Product Manager!”
    • אז אומר “אוקיי - ומה הוא עושה?”
    • ואז אתה רואה פתאום שהם נתקעים . . . .
  • איך אני מגדיל את ההנחייה הזאת למוצר?
(אורי) ה-Leap לא קרה ב”להביא Product Manager” . . .
(רן) לא, זה רק Proxy לזה . . .
(אורי) . . . לזה שמסתכלים על זה . . .
  • (נתי) זה אומר שב-Management נוצרה איזושהי הבנה שיש פה איזה משהו שצריך להתייחס אליו אחרת . . . .
(רן) אם ה-Product Manager עסוק כל היום בתיאומים של מה הפלטפורמה נותנת וזה - אז הוא לא באמת עושה את עבודת ה-Product. אם הוא מייצר Spec-ים ואוסף דרישות, אז הוא כנראה כן עושה את עבודת המוצר.
  • (נתי) והשורה התחתונה היא שזה מוצר מאוד מורכב . . . .
    • יש לו (א) לקוחות מאוד מורכבים
    • והוא מוצר מורכב כי שוב פעם - הוא מתעסק ב-Tradeoff הכי מורכב בעולם התוכנה . . .
    • שכחתי איך קראו לבחור שתיאר את זה - Lamp-משהו? [Butler Lampson] - המשפט הזה, שכל בעיה בתוכנה אפשר לפתור עם עוד אבסטרקציה . . . [We can solve any problem by introducing an extra level of indirection]
    • אז בגדול, הבעיה הזאת היא באמת מורכבת - ולכן זה לא מפתיע שארגונים שמייצרים מוצרים מופלאים שנמכרים במיליונים ומיליארדים ומצליחים מאוד, מביאים Product Manager לבעיה מהסוג הזה ופתאום נתקעים . . . .
      • פתאום זה לא . . . . כי הצד של הלקוח פה נראה אחרת וכל התהליך הזה הוא מאוד שונה מאיך שהם רגילים לעבוד ומאיך שהם רגילים לחשוב.
      • וזה לא מספיק - זה כן מראה על זה שיש Buy-In ארגוני וזה כן מראה על זה שיש “מישהו בהנהלה” שמתחיל להבין שזה חשוב ושכל הארגון מתחיל להיתקע על הציר הזה של ה-DevOps
      • ושזה לא הגיוני, העלויות האלה של ה-DevOps לעומת הקצב שבו הם מסוגלים לייצר סביבות - ואת הכל הם “מחווטים ביד” . . . .
    • אז זה כן מראה על איזושהי בשלות ארגונית, זה כן מראה על תרבות ארגונית שמתחילה להתפתח לכיוון הזה - אבל זה שלב מאוד “בראשיתי” של התהליך הזה.
    • ובאמת . . .
(אורי) הכי אני אוהב את ההמשפט שאומר ש”ה-Ops - או ה-DevOps - יעלם” . . . . הדברים האלה רק ניהיים יותר יקרים.
  • (נתי) וההמשך של המשפט הזה הוא “You write it - You run it” . . . .
    • ואני חושב שגם פה יש הבנה שה-”Run it” הזה, או היכולת של מפתח לנהל את זה - יש הרבה מפתחים שלא יודעים לעשות את זה, ולא לכולם יש את ה-Skill הזה . . . .
(אורי) אני חושב שב-”You built it - You run it” - לפחות בשבילנו, המשמעות של זה היא אחרת . . . היא כאילו “You built it - אז אתה אחראי על זה”. כאילו, זה “בסדר - התשתית תריץ לך את זה, אבל אם זה נשבר אז אתה קם בלילה” . . .
  • (נתי) השאלה היא עד כמה רחוק אתה הולך עם זה? . . . זאת אומרת, הוא זה שהולך לכתוב את ה-Monitoring של זה? וכל ה-Data Source, לצורך העניין? ו . . .
(אורי) לא - הוא מקבל את התשתית ל-Monitoring - אבל הוא צריך להגיד “אוקיי, את המטריקה (Metric) הזאת אני רוצה למדוד, ועל זה - על ה-Threshold הזה - תביא לי התראה, או על ה-Trend הזה . . . .”
  • (נתי) אז הרחבת לו את הגבול-גזרה של הסמכות שלו - אתה אומר לא רק “אתה כותב קוד”, וכמו ב-QA ו-Development או אני לא יודע מה . . .
  • הרחבת את הסמכויות שלו בדבר הזה - אבל עדיין השארת שכבה מספיק גדולה ומשמעותית של הפלטפורמה - שהיא גנרית.
(אורי) היא פשוט מורידה לו את ה-Yak Shaving - את ה . . .
  • (נתי) ואני זוכר גם את השיחות שהיו בינינו - שאמרנו “זה לא DevOps אם אנחנו עושים את זה ככה . . . .”
    • אם אנחנו שמים מתווך באמצע - בין הפלטפורמה לבין המפתח - זה לא DevOps . . . .
  • אין סיבה שלא כולם יהיו אחראים על הדבר הזה - והיו לנו המון שיחות כאלה . . .
(אורי) צריך להבין מה ה-Essence פה, ומה לא ה-Essence . . .
  • (נתי) אבל זה Maturity, אני חושב, של התעשייה - להבין איפה לשים את הקו הזה
  • אבל אני זוכר ממש את השיחות הראשונות האלה, כשהתחלנו - אני זוכר גם איתך, רן, ואיתך [אורי] בטוח
      • “מה זה DevOps?”
      • “איך באמת שוברים?”
    • והיה את ה-Phoenix Project [!] שדיבר על זה הרבה ועל איך שוברים את הגבולות ועל זה שבאמת . . . .
    • ו-Netflix דיברו על זה הרבה . . .
    • וכולם דיברו על כמה “היום, כל מפתח יכול לעשות הכל!” ובעצם “תן להם את כל דרגות החופש - והם יפתרו את כל בעיות העולם!”, ולא צריך . . . והיה את את ה-No-Ops, אם אתה זוכר . . . דיברו הרבה על ה-No-Ops באותו זמן.
  • אני חושב שאנחנו היום באיזשהו Maturity אחר - פתאום אנשים שואלים “אוקיי - הגענו ל-Scale, הגענו וסבבה ו-DevOps אחלה - אבל צריך להסתכל על זה באיזשהו . . . באיזושהי בגרות ובאיזושהי רמת-בשלות מסויימת.
    • ואני חושב שזה מה שקורה עכשיו.
  • ולשאלה שלך, עוד פעם - האם כל ארגון צריך לבנות לעצמו פלטפורמה? כל ארגון רוצה לבנות את הפלטפורמה לצרכים שלו - זה לא אומר שהוא צריך לבנות אותה מאפס או שהוא צריך לבנות אותה אפילו . . . את הכל בעצמו.
(אורי) בסדר, גם את Kubernetes הוא לא בונה, נכון?
  • (נתי) בדיוק - אבל זה לוקח זמן . . . . אני יכול להגיד לך שהיו גם Enterprises שבנו Kubernetes לעצמם לפני שהיה Kubernetes - לקחו Container-ים וניסו לפתור את הבעיה הזאת . . .

(רן) אבל אילו כלים - ברמה הזאת, של Platform-as-a-Service - קיימים בשוק? הזכרת את Backstage - מי עוד קיים שם?
  • (נתי) אז Backstage הוא פרויקט Open Source של CNCF - הוא מן הסתם מקבל היום Adoption יחסית מאוד גבוה.
  • יש חברה שנקראית Humanitec, שהתחילה לסמן את עצמה - חברת סטארטאפ, יחסית קטנה.
  • יש כלים שהם עצם “רוכבים” על השכבה של Terraform - יש את env0 הישראלית . . .
  • אנחנו, כמובן - ב-Cloudify - מתעסקים עם זה הרבה עכשיו
    • גם בחיבור עם Backstage כאינטגרציה וגם, אגב, בחיבור עם ServiceNow.
  • אז מתחילות להיווצר חברות שהן בעצם . . . הייתי קורא להן “הדור הבא של ה-DevOps” -
    • הן השכבה למעלה - מתחברים ל-Terraform ו-Kubernetes ומתחילים לתת את הערך הזה “שלמעלה”.
  • ובאמת זה מתחיל להיות בשאלה של ה-Build vs. Buy - כבר יש אופציות
    • אם קודם לא הייתה ברירה אלא לבנות את זה בעצמך, היום כבר מתחילות להיווצר אופציות.
  • ואז יש כל מיני עניינים של Tradeoff-ים בין כל אחד . . .
  • אגב - היה גם פוסט מעניין של בחור בשם אליוט, שעשה השוואה בין כמה כלים בתחום הזה, והראה שאפילו Terraform בעצמה ו-Terraform Enterprise הוא נחות לעומת הכלים שהיום מנהלים Terraform - וגם זה פתאום קורה עכשיו . . .
  • אז אני חושב שיש היום יותר אופציות ממה שהיו לפני שנה או שנתיים - ואני חושב שהטרנד הזה מתחיל ומן הסתם מואץ באמצעות ה-Backstage ובאמצעות ה-Ecosystem של ה-CNCF.

(רן) בתחילת השיחה שלנו, דיברת על סיטואציה שבה היה PaaS - לצורך העניין Heroku - והיו את שירותי ה-Infrastructure-as-a-Service כמו AWS ו-GCP - ואז הם התחילו לסגור את הפער. כלומר - פתחו עוד ועוד שירותים, ובסוף יצרו “PaaS-ים פנימיים” כמו Beanstalk ו-Google App Engine, שהיום הם כבר לא כל כך רלוונטיים, לא יודע אם הם עדיין קיימים - אבל הם עשו את זה בזמנו.
אתה רואה את אותם שירותי ענן מייצרים כלים כמו Backstage? כלים בתחום הזה, של . . .
  • (נתי) אני חושב שבתחום הזה, נסתכל שנייה ברטרוספקט על כל מיני טרנדים שקורים בענן - כי בכל פעם השאלה הזאת עולה . . .
    • “מתי הענן יסגור את הפער והאם יש מקום לעוד חברות בתעשייה הזאת?”
  • אז (א) - אנחנו רואים שיש הרבה חברות שחיות, למרות שיש את AWS ו-GCP ו-Azure - והסיבה היא שהם “כל-בו” ויש תמיד את ה-Vertical Focus, ויש שוני בין הדברים.
    • הם כן מעלים את הרף, זאת אומרת - כדי להצליח היום בעולמות האלה לא מספיק לבנות מוצר טוב - הוא צריך להיות מאוד מאוד טוב.
    • כי כדי להתחרות ב-AWS וכאלה אתה גם ממש צריך לתת . . . בדרך כלל, ההבדלים יהיו ב-Ecosystem ובאינטגרציות - בערך המוסף שאתה נותן מעל הפלטפורמה.
    • אפשר לראות את הדבר הזה ב-Snowflake, שמי האמין שהדבר הזה יצליח ויתחרה ב-RDS ובכל ה-Data Services של ה-Cloud? . . . . והם מצליחים מאוד.
    • ו-Datadog זו עוד דוגמא מטורפת - הם גדלים בקצב מטורף . . . .
    • ויכולתי להגיד את אותו הדבר גם על Elastic, אפילו שאתה יכול להגיד לי ש-AWS לקחו את הקוד שלהם והתחרו בהם . . . [למיטבי שמע - 365 Carburetor 26 - open source politics]
    • ויש עוד המון דוגמאות של חברות שמצליחות למרות שהענן נותן פתרון - על הציר של שני דברים . . .
(רן) פוקוס . . .
  • (נתי) אחד זה מה שאני קורא לו “פוקוס מוצרי” ו-(2) זה יכולות של אינטגרציה.
  • וכמובן - חוסר-תלות בספק-הענן, כי יש הרבה אנשים שחוששים מחיבוק-הדב הזה . . .
  • וזה ימשיך להיות - ולכן אנחנו נראה את העננים יותר ויותר מייצרים פלטפורמה-פנימית - ולצידם חברות שמייצרות את ה-Vertical Focus הזה.
    • והחברות שישרדו ויצליחו אלו החברות שבאמת תצלחנה לעשות את זה הרבה יותר טוב ממה שהענן נותן
    • וזה יהפוך את זה לבאמת אתגר הרבה יותר קשה - בעבר היו הרבה יותר חברות שמתחרות על האחוזים הקטנים והיום תיהיינה הרבה פחות
      • כי חייבים ממש להיות חברה טובה כדי להצליח לשרוד את התחרות הזאת.

(אורי) אני חושב שזה היה בשיחה הקודמת שלנו, לפני בערך 200 יום, דיברת על ה-GitOps, שהוא מן-כזה-שם-כללי לכל “ה-Ops-ים האחרים” - ה-MLOps וה-FinOps ו . . .
  • (נתי) אני רואה שאתה זוכר ומקשיב . . . . התרשמתי.
(אורי) כן, אנחנו בגיל שלנו . . . . Anyway, האם בעצם השכבה הזאת שאתה היום קורא לה “Platform Engineering” היא בעצם המימושים של אותו GitOps ואותם Pipline-ים מסודרים ש . . . .
  • (נתי) שאלה מצויינת - ואני חושב שהתשובה היא “לא” . . . .
  • ואני אסביר - מה הם מנסים בעצם כרגע? אני לוקח את הדוגמא של Backstage כי זו הדוגמא שהכי קל לי להתייחס אליה - מה Backstage מנסה לעשות?
    • היא לא באה ומנסה להגיד “אני עכשיו עוד -Tool-chain ב-Stack שלך”.
      • ההיפך - יש לך יותר מדי Tool-chains . . . .
    • “אני מנסה לתת לך - כ-Developer - . . . .” - מה אתה, כ-Developer - איך העולם שלך נראה? יש לך מטריקות (Metrics) שאתה לוקח מ-Datadog וכל מיני דברים כאלה, ומביאים לך מטריקות של פיתוח ומטריקות של Production . . .
(אורי) “Business” . . . .
  • (נתי) בדיוק . . .
    • ויש לך APIs - כמו Flux וכל הדברים באלה
    • ויש לך את האפליקציות שרצות ב-Kubernetes
    • ויש לך את Git ואת הRepository שלו
    • ויש לי את ההרשאות שיש לי בענן ואת ה-Account הספציפי שיש לי בענן
    • זה העולם שלי - כמפתח.
  • עכשיו - תשאל כמה, היום - איך המידע הזה מונגש למפתח?
    • אז יש לו Jira פה ו-Git פה ועוד Dashboard-ים מכל כיוון שהוא
    • אבל אין משהו שמרכז לו את זה ב-Context פרוייקטלי, ב-Context אפליקטיבי
      • בצורה שהוא פותח חלון והכל נמצא לו מסודר
  • זה בגדול מה שנניח Backstage מנסה לעשות - בסוף זה איזשהו UI Framework עם הרבה מאוד Plug-Ins, שיודע לרכז את המידע ב-Dashboard אחד - ומשם הוא מתחיל
    • אחרי זה זה מתרחב, כי כל Plug-In נותן עוד דברים נוספים - אבל פונקצית המטרה הראשונית שלו היא “ארגון הבאלגן”, יצירת “סדר בבאלגן”.
(רן) זאת אומרת - יצירת איזשהו “פורטל למפתחים” - מקום שבו מפתחים פותחים את היום . . . .
  • (נתי) נכון - וזה מאוד שונה ממה שהיכרנו ב-Heroku וכאלה - פחות הצד של ה-Provisioning ויותר הצד . . . הייתי אומר “האינטגרציה”
    • והכלים והיכולת לייצר Dashboard אחד שבאמת ייתן את ה-View ה-Service-oriented או ה . . . . שהוא מרכז את המידע למפתח ופחות Operation-oriented ו-Security-oriented ופחות כל הדברים שהיום יש להם פתרונות משל עצמם.
    • ואיפשהו - המפתח קצת הוזנח בתוך האוסף כלים הזה . . . .

(אורי) האמת שמתוך השראה מ-Backstage, ב-Outbrain פיתחנו משהו שהוא יותר “מנוע חיפוש” - כדי להתמצא בכל הדברים האלה, והוא פשוט מביא . . . קוראים לו “Devel” - כי זה הכלי של ה-Developers . . . - הוא מביא למפתח את כל ה-Resource-ים שהוא צריך למצוא, מביא אותם “קדימה” - בין אם זה מה שכתוב ב-Confluence ו-Alert-ים ומטריקות (Metrics) . . . ו-Jira מאונדקס בפנים, והמבנה הארגוני מאונדקס (Indexed) - איזה צוות? מי On-call בצוות? כל הדברים האלה אתה מקבל במילת חיפוש . . .
  • (נתי) אז תחשוב שנניח . . . לכתוב Plug-In ב-Backstage זה TypeScript, זה נורא פשוט . . . React ו-TypeScript ואתה פחות או יותר בנית לך את ה-Widget שלך.
  • תחשוב שעכשיו אתה יכול לשים את זה במקום שבו הוא מונגש מאוד - ושאתה יכול סביבו גם לתת הרבה מאוד Widget-ים אחרים
    • והחוזקה העיקרית היא שיש Ecosystem של הרבה אינטגרציות כאלה, שאתה לא צריך להתעסק איתן..
    • הרבה פעמים, החברות-עצמן מייצרות את ה-Widget-ים האלה - וזו העוצמה הגדולה של זה, של ה-Ecosystem וה-Comunity שנוצר סביב זה.
    • מתחיל להיות גם Community Play מאוד משמעותי - זה Open Source כמובן
  • אז עם זה קשה להתחרות - וגם אין סיבה כי שוב, זה Open Source וזה מאוד קל, יחסית, להטמעה - בעיני.
    • במיוחד כשמסתכלים על זה מהזוית - ושוב פעם, זה מאוד שונה מאיך שפלטפורמות נבנו בעבר - מהזווית של “ארגון הבלגאן” ופחות מהזווית של “בוא, אני - מעכשיו הכל עובר דרכי! מעכשיו אתה מריץ את הכל דרכי!”
      • ואז זה שינוי ארגוני וזה שינוי סדרי עולם
    • אלא יותר “בוא - תמשיך לעבוד כמו שאתה עובד ואני רק אארגן לך את הדבר הזה”
      • ולאט-לאט - ופה אנחנו מדברים כבר על איך מטמיעים כזה דבר - לאט-לאט אני אתחיל להכניס לך את הדברים האלה.
    • אגב - גם כשדיברתי עם רועי מ-AppsFlyer . . .
(אורי) !The Umbrella Maneuver . . . . [זה לא Trademark של אמדוקס?]
    • (נתי) . . . עכשיו אתה גורם לי לחשוב על זה . . .
  • . . . אז אני חושב שאחד הלקחים, כששאלתי אותו “מה היית עושה אחרת?” - אז הוא גם נגע בנקודה הזאת, שיכול להיות שהנקודת-כניסה הזאת, של GitOps ו-Kubernetes וכל אלו, היא קצת יותר קשה
    • כי היא מחייבת באמת . . .
(אורי) . . . Enforcement . . .
    • (נתי) היא מחייבת Enforcement הרבה יותר אגרסיבי ושינוי הרבה יותר גדול לצוותים
      • לעומת - כשאתה בא מהזווית הזאת של ה”ארגון בלגאן” ואתה נותן ערך מאוד מהיר
      • אתה משנה מעט - ולאט לאט אתה מייצר איזשהו Path ל-Transition שהוא יותר “רך”, נקרא לזה ככה.

(רן) דרך אגב - זה מעניין שהזכרת את ה”מנוע חיפוש”, אורי - כי אני זוכר שככה, כשקראתי קצת פוסטים מעניינים מהימים הראשונים של Google, שבהם הם רצו לארגן את הידע העולמי - והיו שם שתי גישות מנוגדות: אחת זה “בואו פשוט ‘נארגן את האינטרנט’”, ומי שזוכר את ה-Buzz של Semantic Web” וכו’ - “בואו נייצר Entities באינטרנט, בואו נייצר דפים שהם ‘כתובים היטב’ וכל מנוע חיפוש יכול בסופו של דבר לאנדקס אותם לתוך איזשהו Database עם Entities של ממש”, לבין הגישה ההפוכה של “אוקיי, הכל בלגאן - בוא נבנה מנוע חיפוש מעל כל זה ואיכשהו נצליח להכניס חוכמה לתוך מנוע החיפוש” - ואנחנו יודעים היום איזו גישה בסופו של דבר ניצחה, לפחות בעולם האינטרנט . . .
מה שכן - בעולם הפלטפורמה, אתה יודע - גם פה זה Tradeoff: אם אתה מרשה את הבלגאן אז אתה תמשיך “לאכול חצץ” אחר כך . . ..
  • (נתי) אז זהו - שאני לא חושב שהכוונה היא להשאיר את הבלגאן.
  • הכוונה היא היא לייצר באמת איזה . . .
(רן) . . . כנקודת פתיחה . . .
  • (נתי) בדיוק - זאת אומרת, אתה אומר: להתחיל עכשיו לחנך את כל הצוותים -
    • ואתה מכיר את זה טוב - לעבוד בשיטה שונה כשיש להם משהו עובד ואף אחד לא עושה להם הנחה על הלוחות זמנים ל-Delivery ואומר “אה, אתם צריכים לעשות איזה שינוי בפלטפורמה? - אז בוא נדחה את ה-Delivery שלנו בשנה כדי שתתארגנו על עצמכם - ואז נדבר. . . .” - אין חיה כזאת.
    • ולכן מאוד קשה לעשות שינוי כזה ברכבת שנוסעת ב-200 קמ”ש או אולי אפילו יותר . . .
  • וזה תמיד יהיה חסם - ולכן אתה חייב למצוא את המדרגות האלה, שיכולות לעזור
  • ומכל השיחות שאני מדבר עם אנשים בעולמות האלה, יש תסכול מאוד מאוד גדול בין ההבנה של הצורך לבין היכולת ליישם אותו - זה איזור תסכול ענק.
(אורי) אני יכול להגיד מה עבד לנו, כי כן - אנחנו עובדים ב-Pipeline-ים עם פלטפורמה-שהיא-מוצר - וחלק מההבנה הזאת זה כאילו גם “האם בניתי את המוצר נכון?” . . . .החשש מה-Engagement של המפתחים לתוך המוצר הזה זה גם “האם בנינו או הבאנו את המוצר הנכון?” - ואין דרך אחרת מאשר לנסות את זה.
אז מה שעבד לנו זה לקחת צוות אחד, שהם Early Adopters, ולהגיד “יאללה - בואו תנסו” . . . . בוא תנסה ותיהיה הנסיין שלנו, ותן לנו את הפידבקים - ומהצוות האחד הזה מקבלים פידבקים ומשתפרים עד שרואים שהוא מבסוט ואז אומרים “יאללה - עוד צוות: בואו תנסו” . . . וזה מאחד לשניים לארבעה ולשמונה צוותים, ותוך כדי זה המוצר משתפר עוד ועוד.
למשל, ה-Dyploma אצלנו, שהיא זה - היא בעצם מוצר שמאפשר לך . . . שחושף בפניך את כל ה-Infrastructure, הוא מאפשר לך לזוז מהר וה-Infrastrucure “מטפל בעצמו”. אז החסם המאוד גדול שלנו - כי לפני זה עבדנו עם Glue ו-Fiddler וכאלה - אז החסם המאוד גדול היה ה-UI, לא היה UI . . . . כל הצוותים הראשונים עבדו עם APIs, עם API שהיה ב-Command Line - והם היו מבסוטים, היה להם בסדר עם ה-Command Line וזה, אבל בשלב מסויים הגענו לשלב שהצוותים הבאים שרצו את זה אמרו “בלי UI אנחנו לא זזים . . . .” - אז היינו צריכים לבנות UI, אז בנינו UI לכל הדבר הזה.
ואז היה UI, היה Engagement, אוקיי - עברנו מסה קריטית, ואחרי שאתה עובר את המסה הקריטית אתה אומר “אוקיי - יאללה: הנה תאריך וכל השאר עוברים”.
  • (נתי) אני חושב שיש שני דברים שהם מאוד מיוחדים במקרה של Outbrain -
    • אחד זה שהיה לכם צוות פלטפורמה כמעט מ-Day-1 - בגלל שאתם מריצים את התשתית בעצמכם
      • וגם צוות פלטפורמה מאוד חזק, אם אני יכול להתרשם.
    • הרבה ארגונים - ואני חושב שאתה מכיר חלק מהם - לא נבנים ככה . . . הם נבנים לגידול מאוד מהיר, ובדרך כלל כדי להגיע לגידול מהיר אתה בהרבה פעמים מאוד לא ריכוזי, עד כדי דמוקרטיזציית-יתר . . .
      • ואז הם נכנסים לנקודה שבה הם מתחילים להיכנס לאיזורי הפלטפורמה בשלב שבו כבר יש להם מה שנקרא “הרבה מאוד עצים ביער שהתפזרו להם”
      • ועכשיו לך תארגן אותם לתוך איזה “שדה גידול מסודר כזה”, שיהיה מסודר בשורות . . . .
    • וזה הרבה יותר קשה מחברה שבאמת נבנתה מ-Day-0 ונמצאת בפלטפורמה ושיש שם חשיבה של פלטפורמה ושל יעילות ו-Efficiency של Infrastructure ו-Cost
      • וכל מיני דברים - שכל הזמן זה ב-DNA
    • ולכן אני חושב שלהרבה מאוד חברות אין את הפריבילגיה שאתה מתאר
      • ולכן הרבה מאוד מהתהליכים שאתה תיארת - אני יכול לראות איך הם מצליחים ב-Outbrain
      • אבל אני רואה את הקושי של חברות אחרות להצליח בשיטה כזאת . . .
(אורי) רן ואני החלפנו - מה שנקרא “השוואנו גדלים” לפני השיחה . . .
  • (נתי) זה לא עניין של גודל - הגודל לא קובע . . . .
(רן) זה לא הגיל - זה התרגיל . . .
(אורי) לא . . . כבר מישהו עשה את החשיבה וכבר יש צוות פלטפורמה . . .
  • (נתי) ועדיין זה מאוד קשה - הרבה יותר ממה שאתה מתאר . . .
  • מה שאתה תיארת זה . . . החיים שלך דבש” מה שנקרא . . .
    • אם אתה הצלחת לעשות את ה-Adoption הזה - שהוא, אגב, Adoption קלאסי, כמו שהיית מוכר עכשיו מוצר לכל לקוח.
(אורי) כן, כמו מוצר לכל לקוח . . .
  • (נתי) אז למה זה קשה? זה עדיין מאוד קשה . . . אצל אחרים יותר מאשר אצלך.
    • זה לא קל, אתה צודק - אני רק אומר ש . . .
(אורי) אני חושב שפשוט צריך להבין שצריך לעשות את זה - אי אפשר To enforce it - צריך Buy-In.
ואתה יודע מה? כשיש לך צוות אחד שמבסוט ואומר “וואו - החיים שלי קלים עכשיו! החיים שלי יפים עכשיו!” . . .
  • (נתי) זה ברור . . .
(אורי) . . . “ואני רץ הרבה יותר מהר!” - אז זה יותר קל גם בצוות השני וזה מדבק וזה . . .
(רן) זה כמו תהליך של “חינוך שוק” - צריך גם לייצר Trust בקבוצת הפלטפורמה - וכן, יש מקומות שבהם המכירה הזאת הרבה יותר קלה ויש מקומות שבהם המכירה הזאת קצת יותר מאתגרת . . .
(אורי) במקום שהמכירה הזאת מאתגרת - תשאיר אותם לסוף . . . תשאיר אותם לסוף.
  • (נתי) אני שואל באמת - כי אפילו בינינו לבין עצמנו: נניח Spotify - מה גרם להם להצליח? אני חושב שזה מכנה משותף מאוד דומה לשלכם . . .
    • אני חושב שהיה להם צוות פלטפורמה משלב יחסית מוקדם, והם חשבו הרבה מאוד על הבעיה הזאת של ה-Scale ועל הבעיה של ארגון צוותים
    • ומן הסתם הם יצאו גם עם הרבה מאוד מניפסטים של איך . . .
    • ממש אתה רואה שיש שם חשיבה, משלב מאוד מאוד מוקדם - כחלק מהתרבות הארגונית שלהם.
    • ואני חושב שארגונים כאלה, בהגדרה - אני יכול לראות איך הם עושים תהליכים כאלה, עם הקושי שבדבר - ומתגברים עליו.
      • כי יש את התרבות ויש את התשתית ויש התהליכים - ויש משהו לבנות עליו, שזה עוד איזשהו Increment . . .
    • חברות שלא נבנו ככה - ויש עדיין הרבה כאלה - יהיה להן מאוד מאוד קשה . . .
  • אני חושב שזו השורה התחתונה, אבל אני חושב שזה גם נוגע בהרבה דברים שדברנו עליהם בהקשר הזה.
  • ואז, אני חושב שה-Tradeoff הנוסף שנוסף פה, דרך ה-Backstage, זה “בוא נמצא Wins יותר ‘רכים’, שלא מחייבים אותי עכשיו לבנות על תשתית כזאת” - ובואו נכיר בבעיה הזאת ונתחיל משם.
  • וזה, אני חושב, המשחק הזה שאני חושב ש-Backstage יצר פה - שהוא שונה מאוד מאיך שהכרנו את הדוגמאות האלה, של Heroku ואחרים.

(רן) בסדר - אז אנחנו יכולים לדבר על זה עוד ימים שלמים, אבל נראה לי שכל מי שמאזין לנו [וקורא!] כבר הגיע למשרד, אם נסעתם . . .
(אורי) . . . שיהיה להם על מה לדבר במשרד [לגמרי . . . ]
(רן) אז זו הייתה השיחה שלנו על Platform Engineering - ותזכרו איפה שמעתם את זה קודם! אולי לא אצלנו, אבל בכל אופן . . .
תודה רבה, נתי!
(נתי) א- להתראות ו-ב - אני אוסיף כמה References מעניינים, למי שרוצה להעמיק בנושא, שמדברים גם על Terragrunt והמסע של Yevgeniy Brikman ועוד אחרים [הנה - Cloud Adoption Fails] - אנחנו נשתף את זה בפוסט [הנה, כאן - ויש גם את Software Visualization — Challenge, Accepted].
(רן) לגמרי, נושאים שלא הספקנו להגיע אליהם . . . בהחלט.
תודה - ולהתראות.

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

  continue reading

151 פרקים

Artwork
iconשתפו
 
Manage episode 338786303 series 2497397
תוכן מסופק על ידי רברס עם פלטפורמה. כל תוכן הפודקאסטים כולל פרקים, גרפיקה ותיאורי פודקאסטים מועלים ומסופקים ישירות על ידי רברס עם פלטפורמה או שותף פלטפורמת הפודקאסט שלו. אם אתה מאמין שמישהו משתמש ביצירה שלך המוגנת בזכויות יוצרים ללא רשותך, אתה יכול לעקוב אחר התהליך המתואר כאן https://he.player.fm/legal.

פודקאסט מספר 445 של רברס עם פלטפורמה - קרבורטור מספר 33. אורי ורן מארחים את נתי שלום אחרי כמה חודשים טובים [32 היה בינואר], כדי לדבר על נושאים תשתיתיים מעניינים.
(רן) היום אנחנו רוצים לדבר על נושא שנקרא Platform Engineering - את שתי המילים אנחנו מכירים [בכל זאת - רברס עם פלטפורמה], אז Platform ו-Engineering - אבל מה זה “Platform Engineering”? אז בוא נצלול פנימה . . .
(אורי) בטח יש גם Platform-Reverse-Engineering . . . [נסו ב-DALL·E הקרוב למקום מגוריכם]
  • (נתי) Platform אתה יודע ו-Engineering אני לא צריך להסביר לך . . . . אבל אני אחזיר אותך לשיחות שהיו לנו, אני חושב שבאיזור 2012, איפשהו באיזור הזה.
    • אני זוכר שהיית Advocate של Heroku ושל כל מה שנקרא “Platform-as-a-Service”
    • זה היה ממש בימים שבהם חילקו את ה-Cloud - אני לא יודע אם יש עוד אנשים שעדיין זוכרים את זה - ל . . .
(אורי) SaaS ו-IaaS . . . .
  • (נתי) . . . ל-IaaS ו-SaaS ו-PaaS - שלושת השכבות . . . .
(רן) Infrastructure-as-a-Service ו-Software-as-a-Service ו-Platform-as-a-Service . . . .
  • (נתי) בדיוק - Infra ו-Platform ואז Service - בסדר הזה.
  • ואז הייתה איזושהי תקופת-עדנה ל-Platform-as-a-Service - כשהרעיון מאחורי זה היה ש”ה-Infrastructure-as-a-Service הוא מסובך”
    • ו-Platform-as-a-Service נועד לתת ממשק למפתחים, “שיחביא” את המורכבות הזאת ע”י זה שבעצם כמעט כל האפליקציות יהיו סוג של . . . .
    • היה בזמנו Node.JS, היה Rails - היו כל מיני Stack-ים כאלה
    • ואמרו - “בואו נייצר . . “ - ממילא האפליקציה בנויה מאיזשהו Stack די ידוע מראש ורוב העבודה זה Boilerplate - “ . . . בואו נעטוף את זה, ותיהיה פלטפורמה ששתיתן לך את הכל”
      • וזה יהיה פרודוקטיבי מאוד למפתחים.
    • ואני חושב ש . . .
(אורי) “תבוא - תכתוב Business Logic . . . .”
  • (נתי) בדיוק . . . . וכל עוד האפליקציות באמת נראו ככה, אז הייתה עדנה לתפיסה הזאת
  • היה את AWS שיצאו אחרי - שכחתי איך קראו לשירות שלהם [AWS Elastic Beanstalk?] . . . והיה את Google App Engine . . .
(רן) כן . . . אז Google App Engine ו-Heroku - כנראה Heroku הייתה . . .
  • (נתי) Salesforce קנו אותם בסוף . . . .
  • ול-AWS היה את הפתרון שלהם - ה-Beanstalk! זה היה הפתרון שלהם.
    • וכל Cloud יצא עם ה-Platform-as-a-Service שלו . . .
  • והייתה תקופה של אני-חושב-2014-כזה, איפשהו באיזורים האלה, שהיתה לזה איזושהי “תקופת עדנה”, נקרא לזה ככה.
    • ופתאום זה נעלם . . .
    • היה את Cloud Foundry - ופתאום זה די התחיל-כזה-לדעוך - ומהר.
  • תיכף נחזור לנקודה הזאת, אבל אני חושב שקרו . . .
(רן) אני אזכיר לך - נתי - ש-Correlation is not a Causation . . . . באותו תקופה בדיוק ייצור החסה בשטחים גם עלה . . . .
  • (נתי) אז לא - יש קשר . . . יש הרבה קשר, אגב.
  • למעשה, זה הולך לצומת שאני חושב שכל תעשיית התוכנה מסתובבת סביבה משנות-הפחות-או-יותר-60 ואולי אפילו לפני - זה ה-Tradeoff הידוע שבין גמישות לפשטות.
    • מה שמשתנה זה לא ה-Tradeoff הזה והמתח המובנה שיש בתוכו, אלא הכלים שכל פעם נוצרים והיכולת לעשות את ה-Tradeoff הזה פעם אחת יותר בכיון הגמישות ופעם אחרת יותר לכיוון הפשטות
    • המטוטלת הזאת מלווה אותנו המון המון זמן - ותמשיך ללוות אותנו גם בהמשך.
  • אז במטוטלת ההיא - אני מזכיר, בימים הראשונים כש-EC2 היה רק Storage-Network-Compute - היה מאוד מאוד מורכב.
    • היה מאוד מסובך לאנשים להבין איך עושים אוטומציה ב-APIs ו-Script-ים וכל מיני דברים שאתה לא תמיד היית רגיל לעשות ב-Data-center.
(רן) CloudFormation . . . . למי שזוכר, זה היה מזעזע . . . .
  • (נתי) ו-CloudFormation, שומו שמיים - איזה JSON שהופך להיות API-Call . . . .
  • ואז, בתקופה הזאת, באמת להרבה ארגונים היה מאוד קשה לעבוד עם התשתית הזאת
    • ולכן הצורך בפשטות היה מאוד מובן וחזק.
  • ופה נכנס ה-Tradeoff הזה לגמישות - כי בעצם קרו כמה דברים -
    • אחד זה השירותים בענן - יש לי פה איזה גרף מעניין שאני אחלוק איתך אחרי זה, שמראה באיזה קצב AWS התחילו להוסיף עוד שירותים [הנה פה למטה]
      • הם כבר מזמן לא רק Storage-Network-Compute . . . .
      • והפלטפורמות לא הדביקו את הקצב . . . פשוט נוצר מצב שכשאתה עובד עם הפלטפורמה, אתה מקבל פחות ופחות שירותים בענן, ואז אתה אומר “רגע - אני משלם ל-AWS אבל בסוף אני מקבל ‘’שליש-AWS‘’ או ‘רבע-AWS או ‘עשירית-AWS . . . .” - זה לא הגיוני. [ובכן . . . ]
    • דבר שני שקרה בתוך הדבר הזה זה שהארכיטקטורה של האפקליציות הפכה להיות שונה, בטח אם אנחנו מדברים על Machine Learning . . .
      • הן נהיו יותר מבוזרות, והקוביות האלה של Rails וה-Stack-ים של J2EE וה-Stack-ים של Python במקרה הזה, לא זוכר כבר את השם של . . .
      • (רן) Django!
      • (נתי) Django! בדיוק . . . . אז הם נהיו פחות ופחות פופולאריים, והמערכות הפכו באמת להיות הרבה יותר מורכבות ומבוזרות, ככה שגם התפיסה הארכיטקטונית כבר לא התאימה.
    • שני הדברים האלה לבד כבר די הכניסו את הפתרון הזה לסטרס - ובמקביל, בצד של “הגמישות”, התחילו להתפתח פלטרפורמות שעשו את האבסטרקציה . . . . פישטו בצורה מסויימת את התשתית לענן
      • זה Terraform - ו-Kubernetes בשלב יותר מאוחר - לעולמות של Container-ים.
    • וזה נתן איזשהו Tradeoff יותר סביר לתקופה-אפילו-ארוכה, בין פשטות לגמישות - יותר לכיוון הגמישות, על חשבון פשטות.
    • באותו זמן, אני חושב שזה היה מספיק כדי באמת להיות מסוגל לעשות את האפליקציות היותר מורכבות על הענן
  • והגענו לאיזור 2020-2021, ופתאום חברות שהן לא Legacy - לא הבנקים הגדולים, Morgan Stanley וכאלה ו-Enterprises - כמו Spotify . . .
    • (רן) גילו שזה נורא מסובך . . . .
  • (נתי) בדיוק . . . Spotify - “ה-Rockstar של ה-DevOps” [חייב להיות meme לזה . . .] . . . באמת ה-Poster-child של ה-DevOps, שכולם בעצם קוראים את המניפסטים שלהם ומאמצים אותם מיד, שזה די מדהים לכשלעצמו.
    • והם באים ואומרים “תקשיבו - ה-Cloud הזה וה-Terraform הזה ו-Kubernetes הזה - זה מסובך . . . .”
    • וואלה מסובך . . . ואז פתאום אתה תופס את עצמך - שנה לפני כן, השיחה הייתה נראית אחרת לגמרי . . .
  • לי היו בשנה הזאת הרבה מאוד שיחות עם לא מעט חברות בתחום הזה, שבאמת הן לא “חברות Legacy”
    • אני מדבר על Wix ועל AppsFlyer לצורך העניין - חברות שהן חברות תוכנה, שפשוט גדלו בקצב גבוה
      • ולכולן יש את כאבי הגדילה . . . .
    • והן הבינו דבר מאוד פשוט - אין הגיון בזה שכל מפתח יכתוב קוד ב-Terraform ואין הגיון שכל מפתח יכיר Kubernetes
      • ולכן צריך “משהו באמצע”, שיעזור למפתחים להשתמש בזה - כי יש לזה המון יתרונות - אבל בצורה יותר מופשטת, יותר אבסטרקטית.
(רן) אתה, למעשה, בא ומתאר עכשיו פלטפורמה של מפתחים - פנימית? לעובדים שלי?
  • (נתי) בדיוק . . . עכשיו, מה ההבדל בין ה-Platform-as-a-Service של Heroku וזה?
    • העקרונות הם אותם עקרונות - אני שם אבסטרקציה כדי שתחביא את המורכבות, וככה בעצם היעילות של המפתח נהיית יותר גבוהה.
      • החלק הזה נשאר זהה
    • ה”איך” ניהייה שונה - כי בעצם מה הייתה הבעיה של הפלטרפורמות האלה? הזכרנו חלק מהבעיות, אבל הבעיה העיקרית הייתה שגם כארגון, אני פתאום מאמץ משהו שמכתיב לי איך אני צריך לעבוד, ואני לא יכול כמעט להזיז בו כלום . . .
      • אני תלוי באיזה מישהו אחר - וזה לא מתאים לי.
    • ואמר - ברח לי השם שלו עכשיו, היה . . . הבחור הזה מ-Google . . .
      • (אורי) יבגני?
      • (נתי) לא יבגני . . . רגע, תיכף אזכר ונכניס אותו במקום הנכון . . .
    • הוא אמר שבעצם, בסוף בסוף - כל אחד היה רוצה שיהיה לו Platform-as-a-Service - As long as you build it yourself . . . .
      • זאת אומרת - כל עוד אני יכול לתפור אותה למידות שלי, זה רעיון מצויין . . . .
(אורי) סליחה, אבל אתה מרים לי להנחתה - אני יכול להגיד לך “ברוך הבא ל-Outbrain” . . . . [ד”ש - 368 Kubernetes and Dyploma at outbrain]
  • (נתי) או . . . אז אני בטוח שהדברים האלה כבר יושמו ואתה מכיר את הכל ו-Outbrain כבר עשתה את זה בשנות ה- . . . מה שנקרא “ב-47” . . . .
(אורי) שלושים שנה, לך תזכור”, כן . . . אבל זה גם מתאים את עצמו, כמו שאתה יודע . . .
  • (נתי) כן . . . הרעיונות - אין בהם שום דבר חדש . . . . כמו שאמרתי, אלו דברים שכבר מהימים הראשונים של התוכנה אני חושב שאנחנו מסתובבים סביב ה-Tradeoff הזה
    • שום דבר - מהבחינה הזאת, של המתח הפנימי הזה שבין הפשטות לגמישות - הוא תמיד היה ויהיה.
    • מה שמשתנה זה הכלים וסוג המורכבות שאנחנו רוצים להגיע אליה
    • ואנחנו כל הזמן משנים את ה-Tradeoff הזה בהתאם למציאות שאנחנו נמצאים בה.
  • אז גם פה המציאות עכשיו היא כזאת: השכבה היא כבר לא ענן - הייתי אומר “כמו שהכרנו בעבר” -
    • יש לנו באמת שכבות כמו Terraform, שזה Infrastructure-as-a-Code ו-Kubernetes שזה ניהול של Container-ים
    • שנתנו לנו איזושהי אבסטרקציה שמאפשרת לנו לחשוב על הדבר הבא.
  • ועכשיו, בעצם, היכולת של ארגון לבנות פלטפורמה שהיא “תפורה למידותיו” - נהייתה עם חסמים הרבה יותר נמוכים ממה שהיו קודם
    • אם קודם הייתי אומר לך “תבנה, על בסיס של VM-ים לצורך העניין, ’פלטפורמה למפתחים’, שתיתן פתרון-as-a-Service לכולם” - רמת המורכבות הייתה מאוד מאוד גבוהה ולא היית ניגש לזה בכלל.
(רן) אני חושב שיש לזה . . . לפיתוח של פלטפורמה פנימית, מעבר לצורך לפשט - זה גם מונע צרכים אחרים, כגון Enforcement ו-Security וסטנדרטיזציה . . . .
  • (נתי) נכון . . . קראתי לזה Efficiency ו-Consistency
    • בגדול זה איך אני מבטיח - בין צוותים - שהצורה שמשתמשים במשאבים תיהיה קונסיסטנטית (Consistent) בין הצוותים ובין מפתחים
    • וגם Efficiency - במובן הזה שבסוף כשאני רוצה Database ואני רוצה . . . אני לא צריך להכיר את איך שמקנפגים (Configure) ואיך מרימים אותו
      • מישהו צריך להכיר את זה - אבל לא כולם.
      • בדרך כל זה מתבטא ביחס מאוד ברור - מעטים צריכים להכיר, הרבה צורכים, מעט צריכים לבנות . . .

(אורי) זה, כאילו . . . אני חושב שלפעמים, אין ממש מושג עד כמה זה הופך את החיים להרבה יותר פשוטים כשיש לך Pipeline אחד והוא מותאם לצרכיך - זאת אומרת, הוא גם נותן לך את הגמישויות שאתה צריך ומקשיח את מה שאתה לא צריך לדעת או לא צריך להתעסק איתו . . .
  • (נתי) זהו, שעכשיו מה אמרת? בדיוק את הנקודה שבה המטוטלת הזו כל הזמן זזה - ותמיד היא תזוז.
  • ה-Tradeoff שאתה לוקח בעצם, במודע, זה שאתה נהייה “Opinionated” -
    • אתה אומר, נניח כשלקחנו Terraform ו-Kubernetes - הם מאוד Un-opinionated: יש לך . . פחות או יותר “אני חושף לך את כל המתגים האפשריים - תבחר!”
    • אני אתן לך את כל המתגים בעולם, פחות או יותר - של ה-Network, של ה-Storage, של ה-Compute, של ה-Load Balancer - הכל! . . .
(אורי) . . . ואז תגלה ש-80% מהמתגים האלה לא רלוונטיים בכלל - הבעיה היא שלכל אחד, ה-80% שלו הם אחרים . . . .
(אורי) . . . אתה רואה שבתכל’ס, החברות הגדולות - “הבהמות הגדולות” - ככה הן עובדות: הן לא חושפות למפתח את ה-Infrastructure-as-a-Code . . .
  • (נתי) נכון . . . הרבה פעמים זה לא מתחיל ככה - אבל זה מגיע לשם.
  • יש איזשהו Maturity Cycle - שבהתחלה, גם כשהרמת VM-ים לצורך העניין, או כשהרמת Compute במקרה שלך . . . .
(אורי) . . . לא היה VM-ים . . .
  • (נתי) . . . לא היה VM-ים . . . את זה האמת לא ידעתי, אבל כשהתעסקת עם Bare Metal, אז זה היה מאוד . . .
  • אני זוכר את הימים של להתעסק באיך שנראה הכרטיס ואיזה סוג ואיך עושים אופטימיזציה לכל ה-Compute כדי שהוא יהיה יעיל . . . .
(אורי) . . . . אבל זה אף פעם לא היה ב-Domain של המפתח - זה היה ב-Domain של . . . פשוט, חלק מהעניין זה לעשות “Platform Engineering”.
  • (נתי) נכון, אבל אז היה . . . אני זוכר, היה מאוד חשוב איזה סוג Compute אני מקבל, איזה סוג מעבד יש בו, איזה סוג . . . . כמה זכרון . . .
    • דברים כאלה שהיום בענן אתה מקבל Extra-Large - Medium - Whatever . . .
      • ואתה פחות או יותר יודע שזה מה שאתה מקבל - אין לך מושג, כמעט, איך ה-”Extra-Large” מורכב ואיזה מעבד עומד מאחורי זה וכמה Cycle-ים יש ל-CPU . . . .
      • המון דברים שהיום אתה באמת כבר לא חושב עליהם במובן הזה.
  • אז אני אומר - זה כל הזמן קורה, והיום אנחנו נמצאים בנקודה שבה זה קורה סביב Platform Engineering על גבי פלטפורמות של Terraform ו-Kubernetes וענן
    • וזו הנקודה שהרבה ארגונים שעברו את שלב ה-Scale הגיעו אליה - כזו שאני חושב שגם אתה תיארת, של התהליך שעברתם ב-Outbrain - כשאתה מתחיל לשאול את עצמך איפה באמת ה-Tradeoff?
    • ואתה מגיע למסקנה שה-Tradeoff לא עובר בזה שאני נותן את כל דרגות החופש למתפחים ועושה אופטימיזציה להכל, אלא שאני צריך להיות מאוד Opinionated -
      • יש דברים שאני נותן דרגות חופש, יש דברים שאני לא נותן דרגות חופש - וזה משתנה מארגון לארגון.
    • לכן חשוב לי שהפלטפורמה תיהיה בשליטה, ולא משהו שמוכתב ע”י איזה Vendor או על ידי איזושהי תשתית חיצונית.

(אורי) אני חושב שהרבה מאוד מהפחד להבין את התשתית הזאת - זו תשתית בסוף, אוקיי? זו תשתית שהיא Opinionated והיא אומרת לך “פה - ככה עובדים”. ואתה מכניס מפתח חדש - נגיד שב-Outbrain אנחנו מכניסים מפתח חדש ותוך שבועיים-שלושה הוא אפקטיבי, כי יש לו את הכל בשביל להיות אפקטיבי, הוא לא צריך פתאום להתחיל “לגלח את היאק” בשביל להתחיל עם Kubernetes או משהו אחר.
אבל ההחלטה הזאת לשים Platform Engineering ו”פתאום” שיהיה לך Deployment Pipeline וכל מה ששומר עליך, ו”פתאום” ה-Infrastructures “מוחבא” לך - היום מהנדס ב-Outbrain עושה Deploy והוא לא יודע, או שהוא יודע אבל זה לא ממש משנה לו, אם הקוד שלו Deployed On-Perm או על ענן, זה לא משנה לו . . .
  • (נתי) וזה עכשיו אפשרי בזכות Kubernetes, נכון?
(אורי) זה אפשרי בזכות Kubernetes, אבל לא רק בזכות Kubernetes . . .
  • (נתי) זאת אומרת שאם היית עושה את זה בלי Kubernetes, היה לך פי-מיליון יותר מסובך . . .
(אורי) אבל לא רק בזכות Kubernetes - אלא בזכות זה שיש עוד שכבה, שמבודדת אותו גם מה-Kubernetes, כי האימפלמנטציה (Implementation) של Kubernetes ב . . .
  • (נתי) נכון, ב-AWS היא טיפה שונה . . .
(אורי) . . . . והיא שונה ב-Azure מאיך שהיא . . . . זה לא מעניין אותו.
  • (נתי) כן, אני יודע, ברור - אבל זה . . . נוצרה לך איזושהי שכבה מעל ההתשתית של הענן, שמאפשרת לך עכשיו לבנות את השכבה הנוספת הזאת.
    • לפני כן - אם היית מוריד אותה - היה לך לא משתלם להתעסק בלבנות תשתית כזאת.
(אורי) כן . . . יכול להיות שבמקום שאתה עובר מלהיות Un-opinionated ל-Opinionated, אז פתאום לאנשים חסרים כמה דברים . . . בסדר, אז אתה דואג להם שלא יהיו חסרים להם כמה דברים - זה לוקח חודש או חודשיים או אולי שלושה, המערכת מקבלת את ה-Maturity שלה, ובשלב מסויים אתה כבר . . . התדירות שבה אתה צריך להתאים את ה-Infrastructure, את הפלטפורמה לגמישויות, היא נהיית כל כך לא-שכיחה . . . .
  • (נתי) אני מסכים איתך - אני חושב שצריך לקרות, עוד פעם, “שינוי טקטוני” כזה, כמו המעבר לענן, משהו בסדר גודל הזה - כדי שזה עוד פעם יעצר.

(רן) אני רוצה להצביע פה על איזושהי בעיה . . . בעצם מה שאתה אומר, נתי, זה שעכשיו כל חברה צריכה להקים “צוות פלטפורמה”, שיכתוב לעצמה את הפלטפורמה - בגלל זה אנחנו קוראים לזה ככה, “Platform Engineering” - והפלטפורמה הזאת היא לא טריויאלית, כן? . . . אתה מדבר על לייצר Heroku-כזה-פנימי” . . .
  • (נתי) נכון . . .
(רן) . . . מה הפתרון לזה? עכשיו, כמייסד בחברה, אני צריך קודם כל לגייס צוות-פלטפורמה ענק?
  • (נתי) לא . . . אז (א) זו שאלה - השאלה - והרמת לי להנחתה מן הסתם, אבל אני אגיד מה המציאות ומה רוצים להגיע אליו.
  • אז באמת, אנחנו רוצים להגיע לפלטפורמה, שזה סוג של “לבנות Heroku
    • בהתחלה זה מתחיל ממשהו מאוד נאיבי, מגניב - “אני אגייס אנשים, אני אבנה משהו מאוד מעניין, אני אעשה משהו שהוא לא רק-Script-ים סוף סוף, אני אבנה משהו שהוא מוצר, אני אתייחס לזה כמוצר . . . .”
    • (רן) “אני אכתוב JSON!” . . .
  • (נתי) כן . . . ובסוף, מה שאתה רואה זה שהם מתעסקים עדיין הרבה מאוד ב-GitOps ואולי קצת מסביב ל-GitOps, ב-Flux וטוב . . . שזה GitOps . . . ובעוד כמה דברים מסביב לזה.
    • עדיין, נשארים ב-Layer המאוד-מאוד-נמוך הזה, שהוא עוד לא יכול לתת את החוייה ואת הקפיצת-מדרגה בפשטות.
      • אני קורא לזה שיש לך חלום לבנות גורד שחקים - ואתה עדיין תקוע בלבנים ובמלט . . .
      • ומלבנים ומלט כנראה שלא תבנה גורד-שחקים בזמן הקרוב . . . .
  • ולכן - וזה מביא אותי לאיזשהו פוסט שדווקא פרסמתי היום, של Spotify - שמדבר על משהו שנקרא C4
    • ו-C4 זה בעצם . . . הבעיה שהם באים ואומרים זה שכל עוד אני תקוע ב”לבנים וחצץ” או “לבנים ומלט” - מאוד קשה לי לבנות מערכות גדולות
      • מאוד קשה להסתכל על המערכת כמערכת - כי אין לי את השפה הזאת בכלל
      • איך אני יכול לבנות מערכת כשאני . . . כשהכל הוא ב-Assembly? . . .
    • ואז הם הגיעו לנקודה שבה באמת צריך את השפה הזאת, שמגדירה דברים שנקראים Domains, Systems, Components . . .
(רן) אז C4 זו למעשה שפת-Modeling?
  • (נתי) C4 זה זה סוג-של-שפת-Modeling, שלמעשה היה איזשהו פוסט ב-InfoQ שהם אימצו אותו ובנו מאחוריו “תפיסה מוצרית”, נקרא לזה ככה
    • שבאמת באה ואומרת איך אני עכשיו לוקח מערכות מורכבות וממדל אותן לתוך סביבה.
  • וברגע שאני אוכל - אז אני יכול להתחיל לייצר כל מיני סביבות Dev-Production מסוגים שונים
    • אבל בלי לדעת עכשיו שזה . . . איזה Terraform מעורב בכל Module כזה
    • אני אוכל לתת ממש פרמטרים שאומרים “תעשה את ל-Development” תעשה לי את זה ל-Production” -
      • ומתחת אני אדע כבר לעשות לזה את ההתאמה
      • זה יהיה Optimized ל-Cost”; זה יהיה Optimized ל-Availability”; זה יהיה Optimized ל-Security”; זה On-Demand” - ועוד כל מיני דברים מהסוג הזה.
  • אבל אני מדבר פתאום בשפה . . . השפה שאני אדבר בה עם הפלטפורמה היא הרבה יותר אבסטרקטית - אני מדבר בשפת-System, לצורך העניין, ולא בשפת microService.
  • אז ה-C4 הוא איזושהי תפיסה שנועדה קודם כל לייצר את השפה הזאת ולייצר את ההבנה הזאת ולייצר את היכולת להתסכל על מערכת בכלל . . .
    • היום, אם אתה תשאל מישהו “תראה לי, תעשה לי Whiteboard וצייר לי את המערכת” - אין שפה נורמאלית לצייר מערכת, כי המורכבות היא מאוד גדולה
    • ואין גם את הטרמינולוגיה . . . . כלומר, היום אם אתה תנסה, אפילו ברמת הטרמינולוגיה, לדבר ולהראות שפה, אז הם ידעו לדבר על מודולים והם ידעו לדבר על microServices - אבל לא מעבר לזה.
    • אנחנו די נתקענו באיזורים האלה כבר הרבה זמן . . .
  • אז התובנה הזאת היא גם חלק מהנקודה הזאת - ותיכף אני אגיע ל-Build vs. Buy ואיך הופכים את זה לפרקטיקה . . .
(רן) הרמתי לך להנחתה . . .
  • (נתי) כן . . . אז קודם כל, אמרתי שישנה איזושהי הבנה שכדי להגיע למשהו, שבכלל אפשר לדבר על Build vs. Buy - צריך להיות משהו שהוא Repetitive
  • ו”ההרמה להנחתה” היא באמת שאי אפשר לבנות את הפלטפורמה הזאת . . .
    • למרות Kubernetes ולמרות Terraform - זו עדיין הרבה מאוד עבודה.
    • ובאמת, אם אתה תנסה לבנות את זה לבד, זה גם יהיה לך מאוד יקר, גם יקח לך הרבה מאוד זמן, גם לא תגיע לגורד-שחקים אלא תשאר בפחות או יותר . . . אולי תבנה עוד קומה, אבל לא יותר מזה.
      • אבל לא תעשה את הקפיצה, לא תעשה את ה-Leap הזה.
  • ועכשיו מתחילות להיבנות תשתיות, שהן בעצם עוזרות לארגונים לבנות את הפלטפורמה הזאת - כשבעצם הם חוסכים הרבה מאוד עבודה שהיא Repetitive.
    • ו-Backstage זה אחד מהדברים האלה - בא מבית היוצר של Spotify [רפרנס לינואר 2022 -432 Carburetor 32: 2022 DevOps Predictions]
    • אני מסתכל על ברטרוספקט (Retrospective), כי הרבה פעמים שואלים איך Spotify ומה ל-Spotify ול-Open Source ול-Backstage ולכל הדברים האלה
      • ואני מזכיר לכולם - Amazon היא חנות ספרים . . . .
      • באותו זמן, כש-Amazon התחילו את ה-Journey שלהם, היה להם eCommerce ואחרי זה, כדי למכור את ה-eCommerce, הם התחילו מזה שהם באו ואמרו - “הנה, בנינו חנות ספרים, אנחנו יודעים למכור טוב באינטרנט - כנראה שעשינו משהו נכון, אז בואו אולי נשכפל אותו”.
      • ולאט לאט זה ניהיה מה שזה ניהיה היום - אבל זה התחיל מאבולוציה מהסוג הזה.
    • ולכן אני חושב שלא הייתי פוסל - אמנם הם עוד לא חושבים ככה - אבל לא הייתי פוסל את זה ש-Spotify . . .
(רן) Spotify עוד לא יודעים שהם . . . .
  • (נתי) ל-Spotify יש אספירציות (Aspirations) . . .
  • מעבר לזה, למשל, הם מתייחסים ל-Backstage כאל מוצר מסחרי - יש להם Business Model והם בונים לו Marketplace
    • הם לא עושים את מה ש-Netflix עשו, שזה רק Open Source ו”שלח לחמך” . . . .

(אורי) אני חושב שאתה נוגע בנקודה, שלא משנה אם המוצר הוא מסחרי או לא - קבוצת פלטפורמה צריכה להתייחס למוצרים שלה כאל “מוצרים” . . . .
  • (נתי) בדיוק . . .
(אורי) . . . זה שיש להם לקוחות פנימיים - זה לא אומר שזה לא מוצר.
  • (נתי) זה משפט מאוד חזק ואני משתמש בו הרבה . . .
(אורי) . . . . ברגע שעשינו את ה-Shift הזה - הרבה מאוד דברים פתאום התחילו לזוז.
  • (נתי) אני חושב שזה משפט ששווה להתעכב עליו, כי הוא מאוד מאוד חשוב - כמה שהוא נשמע טריוויאלי כשאומרים אותו . . .
  • כי יש פער בין זה שאתה אומר אותו וזה נשמע טריוויאלי . . . אתה מכיר את המשפטים האלה שאתה אומר “אה, ברור!”, אבל איפשהו ביומיום אתה לא מגיע אליהם וזה לא בדיוק מתנהל ככה? . . . .
(רן) אז הנה “נייר לקמוס” - כמה מנהלי מוצר יש לכם בקבוצת הפלטפורמה?
(אורי) שניים . . . אחד-שניים . . . .
(רן) אז אם התשובה היא “אפס” אז כנראה ש . . . .
  • (נתי) זה אומר שגם אם הביאו . . . כשאני שואל “אוקיי - מה השתנה?” אומרים לי “הבאנו Product Manager!”
    • אז אומר “אוקיי - ומה הוא עושה?”
    • ואז אתה רואה פתאום שהם נתקעים . . . .
  • איך אני מגדיל את ההנחייה הזאת למוצר?
(אורי) ה-Leap לא קרה ב”להביא Product Manager” . . .
(רן) לא, זה רק Proxy לזה . . .
(אורי) . . . לזה שמסתכלים על זה . . .
  • (נתי) זה אומר שב-Management נוצרה איזושהי הבנה שיש פה איזה משהו שצריך להתייחס אליו אחרת . . . .
(רן) אם ה-Product Manager עסוק כל היום בתיאומים של מה הפלטפורמה נותנת וזה - אז הוא לא באמת עושה את עבודת ה-Product. אם הוא מייצר Spec-ים ואוסף דרישות, אז הוא כנראה כן עושה את עבודת המוצר.
  • (נתי) והשורה התחתונה היא שזה מוצר מאוד מורכב . . . .
    • יש לו (א) לקוחות מאוד מורכבים
    • והוא מוצר מורכב כי שוב פעם - הוא מתעסק ב-Tradeoff הכי מורכב בעולם התוכנה . . .
    • שכחתי איך קראו לבחור שתיאר את זה - Lamp-משהו? [Butler Lampson] - המשפט הזה, שכל בעיה בתוכנה אפשר לפתור עם עוד אבסטרקציה . . . [We can solve any problem by introducing an extra level of indirection]
    • אז בגדול, הבעיה הזאת היא באמת מורכבת - ולכן זה לא מפתיע שארגונים שמייצרים מוצרים מופלאים שנמכרים במיליונים ומיליארדים ומצליחים מאוד, מביאים Product Manager לבעיה מהסוג הזה ופתאום נתקעים . . . .
      • פתאום זה לא . . . . כי הצד של הלקוח פה נראה אחרת וכל התהליך הזה הוא מאוד שונה מאיך שהם רגילים לעבוד ומאיך שהם רגילים לחשוב.
      • וזה לא מספיק - זה כן מראה על זה שיש Buy-In ארגוני וזה כן מראה על זה שיש “מישהו בהנהלה” שמתחיל להבין שזה חשוב ושכל הארגון מתחיל להיתקע על הציר הזה של ה-DevOps
      • ושזה לא הגיוני, העלויות האלה של ה-DevOps לעומת הקצב שבו הם מסוגלים לייצר סביבות - ואת הכל הם “מחווטים ביד” . . . .
    • אז זה כן מראה על איזושהי בשלות ארגונית, זה כן מראה על תרבות ארגונית שמתחילה להתפתח לכיוון הזה - אבל זה שלב מאוד “בראשיתי” של התהליך הזה.
    • ובאמת . . .
(אורי) הכי אני אוהב את ההמשפט שאומר ש”ה-Ops - או ה-DevOps - יעלם” . . . . הדברים האלה רק ניהיים יותר יקרים.
  • (נתי) וההמשך של המשפט הזה הוא “You write it - You run it” . . . .
    • ואני חושב שגם פה יש הבנה שה-”Run it” הזה, או היכולת של מפתח לנהל את זה - יש הרבה מפתחים שלא יודעים לעשות את זה, ולא לכולם יש את ה-Skill הזה . . . .
(אורי) אני חושב שב-”You built it - You run it” - לפחות בשבילנו, המשמעות של זה היא אחרת . . . היא כאילו “You built it - אז אתה אחראי על זה”. כאילו, זה “בסדר - התשתית תריץ לך את זה, אבל אם זה נשבר אז אתה קם בלילה” . . .
  • (נתי) השאלה היא עד כמה רחוק אתה הולך עם זה? . . . זאת אומרת, הוא זה שהולך לכתוב את ה-Monitoring של זה? וכל ה-Data Source, לצורך העניין? ו . . .
(אורי) לא - הוא מקבל את התשתית ל-Monitoring - אבל הוא צריך להגיד “אוקיי, את המטריקה (Metric) הזאת אני רוצה למדוד, ועל זה - על ה-Threshold הזה - תביא לי התראה, או על ה-Trend הזה . . . .”
  • (נתי) אז הרחבת לו את הגבול-גזרה של הסמכות שלו - אתה אומר לא רק “אתה כותב קוד”, וכמו ב-QA ו-Development או אני לא יודע מה . . .
  • הרחבת את הסמכויות שלו בדבר הזה - אבל עדיין השארת שכבה מספיק גדולה ומשמעותית של הפלטפורמה - שהיא גנרית.
(אורי) היא פשוט מורידה לו את ה-Yak Shaving - את ה . . .
  • (נתי) ואני זוכר גם את השיחות שהיו בינינו - שאמרנו “זה לא DevOps אם אנחנו עושים את זה ככה . . . .”
    • אם אנחנו שמים מתווך באמצע - בין הפלטפורמה לבין המפתח - זה לא DevOps . . . .
  • אין סיבה שלא כולם יהיו אחראים על הדבר הזה - והיו לנו המון שיחות כאלה . . .
(אורי) צריך להבין מה ה-Essence פה, ומה לא ה-Essence . . .
  • (נתי) אבל זה Maturity, אני חושב, של התעשייה - להבין איפה לשים את הקו הזה
  • אבל אני זוכר ממש את השיחות הראשונות האלה, כשהתחלנו - אני זוכר גם איתך, רן, ואיתך [אורי] בטוח
      • “מה זה DevOps?”
      • “איך באמת שוברים?”
    • והיה את ה-Phoenix Project [!] שדיבר על זה הרבה ועל איך שוברים את הגבולות ועל זה שבאמת . . . .
    • ו-Netflix דיברו על זה הרבה . . .
    • וכולם דיברו על כמה “היום, כל מפתח יכול לעשות הכל!” ובעצם “תן להם את כל דרגות החופש - והם יפתרו את כל בעיות העולם!”, ולא צריך . . . והיה את את ה-No-Ops, אם אתה זוכר . . . דיברו הרבה על ה-No-Ops באותו זמן.
  • אני חושב שאנחנו היום באיזשהו Maturity אחר - פתאום אנשים שואלים “אוקיי - הגענו ל-Scale, הגענו וסבבה ו-DevOps אחלה - אבל צריך להסתכל על זה באיזשהו . . . באיזושהי בגרות ובאיזושהי רמת-בשלות מסויימת.
    • ואני חושב שזה מה שקורה עכשיו.
  • ולשאלה שלך, עוד פעם - האם כל ארגון צריך לבנות לעצמו פלטפורמה? כל ארגון רוצה לבנות את הפלטפורמה לצרכים שלו - זה לא אומר שהוא צריך לבנות אותה מאפס או שהוא צריך לבנות אותה אפילו . . . את הכל בעצמו.
(אורי) בסדר, גם את Kubernetes הוא לא בונה, נכון?
  • (נתי) בדיוק - אבל זה לוקח זמן . . . . אני יכול להגיד לך שהיו גם Enterprises שבנו Kubernetes לעצמם לפני שהיה Kubernetes - לקחו Container-ים וניסו לפתור את הבעיה הזאת . . .

(רן) אבל אילו כלים - ברמה הזאת, של Platform-as-a-Service - קיימים בשוק? הזכרת את Backstage - מי עוד קיים שם?
  • (נתי) אז Backstage הוא פרויקט Open Source של CNCF - הוא מן הסתם מקבל היום Adoption יחסית מאוד גבוה.
  • יש חברה שנקראית Humanitec, שהתחילה לסמן את עצמה - חברת סטארטאפ, יחסית קטנה.
  • יש כלים שהם עצם “רוכבים” על השכבה של Terraform - יש את env0 הישראלית . . .
  • אנחנו, כמובן - ב-Cloudify - מתעסקים עם זה הרבה עכשיו
    • גם בחיבור עם Backstage כאינטגרציה וגם, אגב, בחיבור עם ServiceNow.
  • אז מתחילות להיווצר חברות שהן בעצם . . . הייתי קורא להן “הדור הבא של ה-DevOps” -
    • הן השכבה למעלה - מתחברים ל-Terraform ו-Kubernetes ומתחילים לתת את הערך הזה “שלמעלה”.
  • ובאמת זה מתחיל להיות בשאלה של ה-Build vs. Buy - כבר יש אופציות
    • אם קודם לא הייתה ברירה אלא לבנות את זה בעצמך, היום כבר מתחילות להיווצר אופציות.
  • ואז יש כל מיני עניינים של Tradeoff-ים בין כל אחד . . .
  • אגב - היה גם פוסט מעניין של בחור בשם אליוט, שעשה השוואה בין כמה כלים בתחום הזה, והראה שאפילו Terraform בעצמה ו-Terraform Enterprise הוא נחות לעומת הכלים שהיום מנהלים Terraform - וגם זה פתאום קורה עכשיו . . .
  • אז אני חושב שיש היום יותר אופציות ממה שהיו לפני שנה או שנתיים - ואני חושב שהטרנד הזה מתחיל ומן הסתם מואץ באמצעות ה-Backstage ובאמצעות ה-Ecosystem של ה-CNCF.

(רן) בתחילת השיחה שלנו, דיברת על סיטואציה שבה היה PaaS - לצורך העניין Heroku - והיו את שירותי ה-Infrastructure-as-a-Service כמו AWS ו-GCP - ואז הם התחילו לסגור את הפער. כלומר - פתחו עוד ועוד שירותים, ובסוף יצרו “PaaS-ים פנימיים” כמו Beanstalk ו-Google App Engine, שהיום הם כבר לא כל כך רלוונטיים, לא יודע אם הם עדיין קיימים - אבל הם עשו את זה בזמנו.
אתה רואה את אותם שירותי ענן מייצרים כלים כמו Backstage? כלים בתחום הזה, של . . .
  • (נתי) אני חושב שבתחום הזה, נסתכל שנייה ברטרוספקט על כל מיני טרנדים שקורים בענן - כי בכל פעם השאלה הזאת עולה . . .
    • “מתי הענן יסגור את הפער והאם יש מקום לעוד חברות בתעשייה הזאת?”
  • אז (א) - אנחנו רואים שיש הרבה חברות שחיות, למרות שיש את AWS ו-GCP ו-Azure - והסיבה היא שהם “כל-בו” ויש תמיד את ה-Vertical Focus, ויש שוני בין הדברים.
    • הם כן מעלים את הרף, זאת אומרת - כדי להצליח היום בעולמות האלה לא מספיק לבנות מוצר טוב - הוא צריך להיות מאוד מאוד טוב.
    • כי כדי להתחרות ב-AWS וכאלה אתה גם ממש צריך לתת . . . בדרך כלל, ההבדלים יהיו ב-Ecosystem ובאינטגרציות - בערך המוסף שאתה נותן מעל הפלטפורמה.
    • אפשר לראות את הדבר הזה ב-Snowflake, שמי האמין שהדבר הזה יצליח ויתחרה ב-RDS ובכל ה-Data Services של ה-Cloud? . . . . והם מצליחים מאוד.
    • ו-Datadog זו עוד דוגמא מטורפת - הם גדלים בקצב מטורף . . . .
    • ויכולתי להגיד את אותו הדבר גם על Elastic, אפילו שאתה יכול להגיד לי ש-AWS לקחו את הקוד שלהם והתחרו בהם . . . [למיטבי שמע - 365 Carburetor 26 - open source politics]
    • ויש עוד המון דוגמאות של חברות שמצליחות למרות שהענן נותן פתרון - על הציר של שני דברים . . .
(רן) פוקוס . . .
  • (נתי) אחד זה מה שאני קורא לו “פוקוס מוצרי” ו-(2) זה יכולות של אינטגרציה.
  • וכמובן - חוסר-תלות בספק-הענן, כי יש הרבה אנשים שחוששים מחיבוק-הדב הזה . . .
  • וזה ימשיך להיות - ולכן אנחנו נראה את העננים יותר ויותר מייצרים פלטפורמה-פנימית - ולצידם חברות שמייצרות את ה-Vertical Focus הזה.
    • והחברות שישרדו ויצליחו אלו החברות שבאמת תצלחנה לעשות את זה הרבה יותר טוב ממה שהענן נותן
    • וזה יהפוך את זה לבאמת אתגר הרבה יותר קשה - בעבר היו הרבה יותר חברות שמתחרות על האחוזים הקטנים והיום תיהיינה הרבה פחות
      • כי חייבים ממש להיות חברה טובה כדי להצליח לשרוד את התחרות הזאת.

(אורי) אני חושב שזה היה בשיחה הקודמת שלנו, לפני בערך 200 יום, דיברת על ה-GitOps, שהוא מן-כזה-שם-כללי לכל “ה-Ops-ים האחרים” - ה-MLOps וה-FinOps ו . . .
  • (נתי) אני רואה שאתה זוכר ומקשיב . . . . התרשמתי.
(אורי) כן, אנחנו בגיל שלנו . . . . Anyway, האם בעצם השכבה הזאת שאתה היום קורא לה “Platform Engineering” היא בעצם המימושים של אותו GitOps ואותם Pipline-ים מסודרים ש . . . .
  • (נתי) שאלה מצויינת - ואני חושב שהתשובה היא “לא” . . . .
  • ואני אסביר - מה הם מנסים בעצם כרגע? אני לוקח את הדוגמא של Backstage כי זו הדוגמא שהכי קל לי להתייחס אליה - מה Backstage מנסה לעשות?
    • היא לא באה ומנסה להגיד “אני עכשיו עוד -Tool-chain ב-Stack שלך”.
      • ההיפך - יש לך יותר מדי Tool-chains . . . .
    • “אני מנסה לתת לך - כ-Developer - . . . .” - מה אתה, כ-Developer - איך העולם שלך נראה? יש לך מטריקות (Metrics) שאתה לוקח מ-Datadog וכל מיני דברים כאלה, ומביאים לך מטריקות של פיתוח ומטריקות של Production . . .
(אורי) “Business” . . . .
  • (נתי) בדיוק . . .
    • ויש לך APIs - כמו Flux וכל הדברים באלה
    • ויש לך את האפליקציות שרצות ב-Kubernetes
    • ויש לך את Git ואת הRepository שלו
    • ויש לי את ההרשאות שיש לי בענן ואת ה-Account הספציפי שיש לי בענן
    • זה העולם שלי - כמפתח.
  • עכשיו - תשאל כמה, היום - איך המידע הזה מונגש למפתח?
    • אז יש לו Jira פה ו-Git פה ועוד Dashboard-ים מכל כיוון שהוא
    • אבל אין משהו שמרכז לו את זה ב-Context פרוייקטלי, ב-Context אפליקטיבי
      • בצורה שהוא פותח חלון והכל נמצא לו מסודר
  • זה בגדול מה שנניח Backstage מנסה לעשות - בסוף זה איזשהו UI Framework עם הרבה מאוד Plug-Ins, שיודע לרכז את המידע ב-Dashboard אחד - ומשם הוא מתחיל
    • אחרי זה זה מתרחב, כי כל Plug-In נותן עוד דברים נוספים - אבל פונקצית המטרה הראשונית שלו היא “ארגון הבאלגן”, יצירת “סדר בבאלגן”.
(רן) זאת אומרת - יצירת איזשהו “פורטל למפתחים” - מקום שבו מפתחים פותחים את היום . . . .
  • (נתי) נכון - וזה מאוד שונה ממה שהיכרנו ב-Heroku וכאלה - פחות הצד של ה-Provisioning ויותר הצד . . . הייתי אומר “האינטגרציה”
    • והכלים והיכולת לייצר Dashboard אחד שבאמת ייתן את ה-View ה-Service-oriented או ה . . . . שהוא מרכז את המידע למפתח ופחות Operation-oriented ו-Security-oriented ופחות כל הדברים שהיום יש להם פתרונות משל עצמם.
    • ואיפשהו - המפתח קצת הוזנח בתוך האוסף כלים הזה . . . .

(אורי) האמת שמתוך השראה מ-Backstage, ב-Outbrain פיתחנו משהו שהוא יותר “מנוע חיפוש” - כדי להתמצא בכל הדברים האלה, והוא פשוט מביא . . . קוראים לו “Devel” - כי זה הכלי של ה-Developers . . . - הוא מביא למפתח את כל ה-Resource-ים שהוא צריך למצוא, מביא אותם “קדימה” - בין אם זה מה שכתוב ב-Confluence ו-Alert-ים ומטריקות (Metrics) . . . ו-Jira מאונדקס בפנים, והמבנה הארגוני מאונדקס (Indexed) - איזה צוות? מי On-call בצוות? כל הדברים האלה אתה מקבל במילת חיפוש . . .
  • (נתי) אז תחשוב שנניח . . . לכתוב Plug-In ב-Backstage זה TypeScript, זה נורא פשוט . . . React ו-TypeScript ואתה פחות או יותר בנית לך את ה-Widget שלך.
  • תחשוב שעכשיו אתה יכול לשים את זה במקום שבו הוא מונגש מאוד - ושאתה יכול סביבו גם לתת הרבה מאוד Widget-ים אחרים
    • והחוזקה העיקרית היא שיש Ecosystem של הרבה אינטגרציות כאלה, שאתה לא צריך להתעסק איתן..
    • הרבה פעמים, החברות-עצמן מייצרות את ה-Widget-ים האלה - וזו העוצמה הגדולה של זה, של ה-Ecosystem וה-Comunity שנוצר סביב זה.
    • מתחיל להיות גם Community Play מאוד משמעותי - זה Open Source כמובן
  • אז עם זה קשה להתחרות - וגם אין סיבה כי שוב, זה Open Source וזה מאוד קל, יחסית, להטמעה - בעיני.
    • במיוחד כשמסתכלים על זה מהזוית - ושוב פעם, זה מאוד שונה מאיך שפלטפורמות נבנו בעבר - מהזווית של “ארגון הבלגאן” ופחות מהזווית של “בוא, אני - מעכשיו הכל עובר דרכי! מעכשיו אתה מריץ את הכל דרכי!”
      • ואז זה שינוי ארגוני וזה שינוי סדרי עולם
    • אלא יותר “בוא - תמשיך לעבוד כמו שאתה עובד ואני רק אארגן לך את הדבר הזה”
      • ולאט-לאט - ופה אנחנו מדברים כבר על איך מטמיעים כזה דבר - לאט-לאט אני אתחיל להכניס לך את הדברים האלה.
    • אגב - גם כשדיברתי עם רועי מ-AppsFlyer . . .
(אורי) !The Umbrella Maneuver . . . . [זה לא Trademark של אמדוקס?]
    • (נתי) . . . עכשיו אתה גורם לי לחשוב על זה . . .
  • . . . אז אני חושב שאחד הלקחים, כששאלתי אותו “מה היית עושה אחרת?” - אז הוא גם נגע בנקודה הזאת, שיכול להיות שהנקודת-כניסה הזאת, של GitOps ו-Kubernetes וכל אלו, היא קצת יותר קשה
    • כי היא מחייבת באמת . . .
(אורי) . . . Enforcement . . .
    • (נתי) היא מחייבת Enforcement הרבה יותר אגרסיבי ושינוי הרבה יותר גדול לצוותים
      • לעומת - כשאתה בא מהזווית הזאת של ה”ארגון בלגאן” ואתה נותן ערך מאוד מהיר
      • אתה משנה מעט - ולאט לאט אתה מייצר איזשהו Path ל-Transition שהוא יותר “רך”, נקרא לזה ככה.

(רן) דרך אגב - זה מעניין שהזכרת את ה”מנוע חיפוש”, אורי - כי אני זוכר שככה, כשקראתי קצת פוסטים מעניינים מהימים הראשונים של Google, שבהם הם רצו לארגן את הידע העולמי - והיו שם שתי גישות מנוגדות: אחת זה “בואו פשוט ‘נארגן את האינטרנט’”, ומי שזוכר את ה-Buzz של Semantic Web” וכו’ - “בואו נייצר Entities באינטרנט, בואו נייצר דפים שהם ‘כתובים היטב’ וכל מנוע חיפוש יכול בסופו של דבר לאנדקס אותם לתוך איזשהו Database עם Entities של ממש”, לבין הגישה ההפוכה של “אוקיי, הכל בלגאן - בוא נבנה מנוע חיפוש מעל כל זה ואיכשהו נצליח להכניס חוכמה לתוך מנוע החיפוש” - ואנחנו יודעים היום איזו גישה בסופו של דבר ניצחה, לפחות בעולם האינטרנט . . .
מה שכן - בעולם הפלטפורמה, אתה יודע - גם פה זה Tradeoff: אם אתה מרשה את הבלגאן אז אתה תמשיך “לאכול חצץ” אחר כך . . ..
  • (נתי) אז זהו - שאני לא חושב שהכוונה היא להשאיר את הבלגאן.
  • הכוונה היא היא לייצר באמת איזה . . .
(רן) . . . כנקודת פתיחה . . .
  • (נתי) בדיוק - זאת אומרת, אתה אומר: להתחיל עכשיו לחנך את כל הצוותים -
    • ואתה מכיר את זה טוב - לעבוד בשיטה שונה כשיש להם משהו עובד ואף אחד לא עושה להם הנחה על הלוחות זמנים ל-Delivery ואומר “אה, אתם צריכים לעשות איזה שינוי בפלטפורמה? - אז בוא נדחה את ה-Delivery שלנו בשנה כדי שתתארגנו על עצמכם - ואז נדבר. . . .” - אין חיה כזאת.
    • ולכן מאוד קשה לעשות שינוי כזה ברכבת שנוסעת ב-200 קמ”ש או אולי אפילו יותר . . .
  • וזה תמיד יהיה חסם - ולכן אתה חייב למצוא את המדרגות האלה, שיכולות לעזור
  • ומכל השיחות שאני מדבר עם אנשים בעולמות האלה, יש תסכול מאוד מאוד גדול בין ההבנה של הצורך לבין היכולת ליישם אותו - זה איזור תסכול ענק.
(אורי) אני יכול להגיד מה עבד לנו, כי כן - אנחנו עובדים ב-Pipeline-ים עם פלטפורמה-שהיא-מוצר - וחלק מההבנה הזאת זה כאילו גם “האם בניתי את המוצר נכון?” . . . .החשש מה-Engagement של המפתחים לתוך המוצר הזה זה גם “האם בנינו או הבאנו את המוצר הנכון?” - ואין דרך אחרת מאשר לנסות את זה.
אז מה שעבד לנו זה לקחת צוות אחד, שהם Early Adopters, ולהגיד “יאללה - בואו תנסו” . . . . בוא תנסה ותיהיה הנסיין שלנו, ותן לנו את הפידבקים - ומהצוות האחד הזה מקבלים פידבקים ומשתפרים עד שרואים שהוא מבסוט ואז אומרים “יאללה - עוד צוות: בואו תנסו” . . . וזה מאחד לשניים לארבעה ולשמונה צוותים, ותוך כדי זה המוצר משתפר עוד ועוד.
למשל, ה-Dyploma אצלנו, שהיא זה - היא בעצם מוצר שמאפשר לך . . . שחושף בפניך את כל ה-Infrastructure, הוא מאפשר לך לזוז מהר וה-Infrastrucure “מטפל בעצמו”. אז החסם המאוד גדול שלנו - כי לפני זה עבדנו עם Glue ו-Fiddler וכאלה - אז החסם המאוד גדול היה ה-UI, לא היה UI . . . . כל הצוותים הראשונים עבדו עם APIs, עם API שהיה ב-Command Line - והם היו מבסוטים, היה להם בסדר עם ה-Command Line וזה, אבל בשלב מסויים הגענו לשלב שהצוותים הבאים שרצו את זה אמרו “בלי UI אנחנו לא זזים . . . .” - אז היינו צריכים לבנות UI, אז בנינו UI לכל הדבר הזה.
ואז היה UI, היה Engagement, אוקיי - עברנו מסה קריטית, ואחרי שאתה עובר את המסה הקריטית אתה אומר “אוקיי - יאללה: הנה תאריך וכל השאר עוברים”.
  • (נתי) אני חושב שיש שני דברים שהם מאוד מיוחדים במקרה של Outbrain -
    • אחד זה שהיה לכם צוות פלטפורמה כמעט מ-Day-1 - בגלל שאתם מריצים את התשתית בעצמכם
      • וגם צוות פלטפורמה מאוד חזק, אם אני יכול להתרשם.
    • הרבה ארגונים - ואני חושב שאתה מכיר חלק מהם - לא נבנים ככה . . . הם נבנים לגידול מאוד מהיר, ובדרך כלל כדי להגיע לגידול מהיר אתה בהרבה פעמים מאוד לא ריכוזי, עד כדי דמוקרטיזציית-יתר . . .
      • ואז הם נכנסים לנקודה שבה הם מתחילים להיכנס לאיזורי הפלטפורמה בשלב שבו כבר יש להם מה שנקרא “הרבה מאוד עצים ביער שהתפזרו להם”
      • ועכשיו לך תארגן אותם לתוך איזה “שדה גידול מסודר כזה”, שיהיה מסודר בשורות . . . .
    • וזה הרבה יותר קשה מחברה שבאמת נבנתה מ-Day-0 ונמצאת בפלטפורמה ושיש שם חשיבה של פלטפורמה ושל יעילות ו-Efficiency של Infrastructure ו-Cost
      • וכל מיני דברים - שכל הזמן זה ב-DNA
    • ולכן אני חושב שלהרבה מאוד חברות אין את הפריבילגיה שאתה מתאר
      • ולכן הרבה מאוד מהתהליכים שאתה תיארת - אני יכול לראות איך הם מצליחים ב-Outbrain
      • אבל אני רואה את הקושי של חברות אחרות להצליח בשיטה כזאת . . .
(אורי) רן ואני החלפנו - מה שנקרא “השוואנו גדלים” לפני השיחה . . .
  • (נתי) זה לא עניין של גודל - הגודל לא קובע . . . .
(רן) זה לא הגיל - זה התרגיל . . .
(אורי) לא . . . כבר מישהו עשה את החשיבה וכבר יש צוות פלטפורמה . . .
  • (נתי) ועדיין זה מאוד קשה - הרבה יותר ממה שאתה מתאר . . .
  • מה שאתה תיארת זה . . . החיים שלך דבש” מה שנקרא . . .
    • אם אתה הצלחת לעשות את ה-Adoption הזה - שהוא, אגב, Adoption קלאסי, כמו שהיית מוכר עכשיו מוצר לכל לקוח.
(אורי) כן, כמו מוצר לכל לקוח . . .
  • (נתי) אז למה זה קשה? זה עדיין מאוד קשה . . . אצל אחרים יותר מאשר אצלך.
    • זה לא קל, אתה צודק - אני רק אומר ש . . .
(אורי) אני חושב שפשוט צריך להבין שצריך לעשות את זה - אי אפשר To enforce it - צריך Buy-In.
ואתה יודע מה? כשיש לך צוות אחד שמבסוט ואומר “וואו - החיים שלי קלים עכשיו! החיים שלי יפים עכשיו!” . . .
  • (נתי) זה ברור . . .
(אורי) . . . “ואני רץ הרבה יותר מהר!” - אז זה יותר קל גם בצוות השני וזה מדבק וזה . . .
(רן) זה כמו תהליך של “חינוך שוק” - צריך גם לייצר Trust בקבוצת הפלטפורמה - וכן, יש מקומות שבהם המכירה הזאת הרבה יותר קלה ויש מקומות שבהם המכירה הזאת קצת יותר מאתגרת . . .
(אורי) במקום שהמכירה הזאת מאתגרת - תשאיר אותם לסוף . . . תשאיר אותם לסוף.
  • (נתי) אני שואל באמת - כי אפילו בינינו לבין עצמנו: נניח Spotify - מה גרם להם להצליח? אני חושב שזה מכנה משותף מאוד דומה לשלכם . . .
    • אני חושב שהיה להם צוות פלטפורמה משלב יחסית מוקדם, והם חשבו הרבה מאוד על הבעיה הזאת של ה-Scale ועל הבעיה של ארגון צוותים
    • ומן הסתם הם יצאו גם עם הרבה מאוד מניפסטים של איך . . .
    • ממש אתה רואה שיש שם חשיבה, משלב מאוד מאוד מוקדם - כחלק מהתרבות הארגונית שלהם.
    • ואני חושב שארגונים כאלה, בהגדרה - אני יכול לראות איך הם עושים תהליכים כאלה, עם הקושי שבדבר - ומתגברים עליו.
      • כי יש את התרבות ויש את התשתית ויש התהליכים - ויש משהו לבנות עליו, שזה עוד איזשהו Increment . . .
    • חברות שלא נבנו ככה - ויש עדיין הרבה כאלה - יהיה להן מאוד מאוד קשה . . .
  • אני חושב שזו השורה התחתונה, אבל אני חושב שזה גם נוגע בהרבה דברים שדברנו עליהם בהקשר הזה.
  • ואז, אני חושב שה-Tradeoff הנוסף שנוסף פה, דרך ה-Backstage, זה “בוא נמצא Wins יותר ‘רכים’, שלא מחייבים אותי עכשיו לבנות על תשתית כזאת” - ובואו נכיר בבעיה הזאת ונתחיל משם.
  • וזה, אני חושב, המשחק הזה שאני חושב ש-Backstage יצר פה - שהוא שונה מאוד מאיך שהכרנו את הדוגמאות האלה, של Heroku ואחרים.

(רן) בסדר - אז אנחנו יכולים לדבר על זה עוד ימים שלמים, אבל נראה לי שכל מי שמאזין לנו [וקורא!] כבר הגיע למשרד, אם נסעתם . . .
(אורי) . . . שיהיה להם על מה לדבר במשרד [לגמרי . . . ]
(רן) אז זו הייתה השיחה שלנו על Platform Engineering - ותזכרו איפה שמעתם את זה קודם! אולי לא אצלנו, אבל בכל אופן . . .
תודה רבה, נתי!
(נתי) א- להתראות ו-ב - אני אוסיף כמה References מעניינים, למי שרוצה להעמיק בנושא, שמדברים גם על Terragrunt והמסע של Yevgeniy Brikman ועוד אחרים [הנה - Cloud Adoption Fails] - אנחנו נשתף את זה בפוסט [הנה, כאן - ויש גם את Software Visualization — Challenge, Accepted].
(רן) לגמרי, נושאים שלא הספקנו להגיע אליהם . . . בהחלט.
תודה - ולהתראות.

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

  continue reading

151 פרקים

כל הפרקים

×
 
Loading …

ברוכים הבאים אל Player FM!

Player FM סורק את האינטרנט עבור פודקאסטים באיכות גבוהה בשבילכם כדי שתהנו מהם כרגע. זה יישום הפודקאסט הטוב ביותר והוא עובד על אנדרואיד, iPhone ואינטרנט. הירשמו לסנכרון מנויים במכשירים שונים.

 

מדריך עזר מהיר