יום שבת, 27 ביוני 2020

391 Carburetor 29 - 3rd generation automation

פרק מספר 391 של רברס עם פלטפורמה - קרבורטור מספר 29 (16?): הסדרה בה אורי ורן מארחים בכרכור את נתי שלום (Cloudify), והפעם ב-17 ליוני 2020 אחרי נצח של קורונה (הקרבורטור נפל לרדיאטור . . . ) ולפני (?) שהגל השני מגיע (?!)
  • נתי הוא איש תשתיות וזהו הנושא העיקרי גם להיום, וספציפית - 3rd Genration Automation (אוטומציה - הגל השלישי! שמעתם את זה כאן לראשונה).

רגע לפני - כמה מילים על נתי, למקרה שמישהו עדיין לא שמע
  • נתי שלום, CTO ו - Founder של Cloudify (ולפני כן GigaSpaces), מתעסק הרבה בטכנולוגיות Open-source, היום הרבה בתחום של אוטומציה של תשתיות ענן, Networking, עכשיו זה כבר מתחיל גם להיות בטכנולוגיות של AI וכו’ - זה ממש בקצרה.
  • (רן) לא מזמן Facebook פרסמו שהם בנו מכונה שמתרגמת משפת תכנות אחת לאחרת, כך שאתה יכול למשל לכתוב ב-C וזה יתורגם לך ל-Python וכו’
  • (נתי) אפרופו Job Security - כששמעתי את אנשי ה-AI מדברים על זה ומהו “החלום הרטוב” שאליו אפשר להגיע, הם דיברו על ייצור של רובוט שיודע לתכנת, ולכתוב את התוכנה לעצמו.
    • (רן) סופסוף נוכל להחליף אותך ב-Script . . .
    • (אורי) אבל Facebook ידועים בכך שהם כותבים ב-PHP וזה מתרגם ל-++C  . . .
    • (רן) אז עכשיו AI עושה את זה . . . כל דבר צריך קצת AI.

אז התכנסנו כאן היום כדי לדבר על “אוטומציה” - ואוטומציה זו מילה מאוד טעונה, מסורתית.
למעשה, “אוטומציה” הייתה מעיין מילה נרדפת ל-QA אוטומטי - אבל זה לא המקרה כאן.
אז מה זה בעצם “אוטומציה דור שלישי”? על מה אנחנו מדברים - מהן המטרות? מה הם שני הדורות הקודמים, והכי חשוב: מהו הדור השלישי? המון שאלות, ננסה אחת-אחת . . .
  • (נתי) אז נתחיל באמת ממה הם בעצם הדורות האלה ולמה אני מכנה את זה “דור שלישי” - אני חושב שמה שנתן את ה-”Boost” לאוטומציה זה כל נושא הענן, מהסיבה הפשוטה שהענן הוא חיה יחסית מורכבת, והיכולת להתנהל בסביבה הזו בלי אוטומציה הפכה לכמעט בלתי אפשרית, בשונה מ-Data Center שבדר”כ היה סטטי וכו’.
  • הדור הראשון היה מאופיין בזה שחילקנו ל-Layers המפורסמים של IaaS ו-PaaS ו-SaaS, כשלכל שכבה היה את ה”איזור אוטומציה” שלה . . .
    • (רן) רק נתרגם - IaaS זה קיצור של Infrastructure as a Service, שירותים כמו EC2 ו-S3 וכו’; PaaS זה Platform as a Service - שירותים כמו Heroku או Google App Engine; ו-SaaS זה Software as a Service, כמו Google Docs וכו’.
    • (נתי) למעשה, יש לך שכבה (IaaS) שמאפשרת לך לנהל את ה-Virtual Machines ואת ה-Network ואת כל החלק הזה; PaaS זה מודל שמגדיר או מניח מראש איך התשתית האפליקטיבית ואיך שהאפליקציה שלך נראית - בעצם “מחביא” לך את ה-Infrastructure ומאפשר לך להתרכז רק בכתיבת הקוד
      • האוטומציה הייתה משהו שהוא גם מאוד Opinionated - מעיין “Black-box שעושה לך קסמים”, כשאתה לא באמת חשוף או יודע איך הוא מנהל את הדברים
    • ואז SaaS זה גם סוג של Black-box - אבל ברמת השירות: את מקבל Service (המפורסם ביותר בזמנו היה CRM) כשאין לך באמת מושג איך זה מנוהל, וזה גם לא מעניין אותך - מי שאחראי עליו, אז אותו זה מעניין אבל  אותך זה לא.
  • הדורות של האוטומציה בעולמות האלה אופיינו באמת לפי השכבות הללו, וכל אחד נתן את המענה שלו - שבעולם ה-IaaS מדובר בעיקר ב-Scripts עם “קצת חוכמה”, אני חושב ששם זה פחות או יותר התחיל להתפתח.
  • זה תהחיל להיות מעניין ברגע שהעולם של ה-PaaS התחיל לאבד קצת רלוונטיות, ואז המרחק בין IaaS ל-PaaS הפך להיות משהו קצת מטושטש ולא כל כך מוגדר, כי ה-Workloads והאפליקציות הפכו להיות חיה מאוד מורכבת, יותר ממה שיכול להיכנס לאיזשהו Template שמישהו חשב עליו קודם.
    • זה יצר את הגל של האוטומציה של הדור השני . . .
    • (רן) זה מדגדג לי קצת ללכת לשיחה צדדית, אבל לא נתפתה (חזקים!) - אמרת ש-PaaS איבד את המרכזיות שלו ורציתי לשאול למה . . . אבל ננסה להתמקד באיפה שאנחנו.
    • (נתי) יש הרבה סיבות לדעתי, כן.
(רן) אז נתמקד חזרה בסיפור שלנו - אנחנו מדברים על אוטומציה לא בהקשר של QA אלא בהקשר של עולמות ה-DevOps או Operations של Data Centers וכו’ - ודיברנו על הדור הראשון.
  • (נתי) הדור השני זה בעצם הכניסה של Cloud Native ומה שהיום נקרא Infrastructure as a Code - השכבות של ה-IaaS וה- PaaS מתאחדות, ואנשים בונים את ה - Platform as a Service “שלהם” on-the-fly, בעצמם - ולהרבה מאוד Use cases משלהם.
    • בהרבה מקרים Kubernetes זה הכי קרוב ל - Platform as a Service במופע הזה, אבל הרבה יותר פתוח - כשמן הסתם ה-Containers נותנים לנו כבר Building Blocks שאני יכול יותר לקסטם (Customize) ולשלוט בהם, החל מרמת מערכת ההפעלה ועד רמת הקוד,
      •  זו יחידת עבודה הרבה יותר גנרית מאשר Platform as a Service בדור ה-IT הראשון שהיה מאוד Opinionated על השפה ו-Framework וה-Stack הטכנולוגי ואיך כל Stack ירוץ וכו’.
  • (אורי) ה-Containers לא המציאו את זה - ה-Images של ה-Virtual Machines לפני זה היו אותו הדבר . . .
  • (נתי) זה נכון ולא נכון . . . נכון ברמה הטכנית של המילה, אבל לא נכון כי לפעמים “היכולת של האריזה להיות קלה”, משהו שאתה מייצר בקלות ומעלה בקלות, אורז אותו - ויכול לעשות הרבה כאלה ב-VM אחד - זה משנה את הפרדיגמה (Paradigm).
    • בגלל ש-VM הוא “חיה יחסית כבדה”, לא היית מייצר VM בתדירות כזו גבוהה אלה מייצר אותו “פעם ב…”, ולכן היה מאוד שכיח לנהל דברים על ה-VM אחרי שהוא נוצר.
    • (אורי) וגם ה-Boot-strapping שלו היה כבד…
    • (נתי) בגלל הכבדות הזו שלו, רוב התהליכים היו עם Configuration Management כמו Chef או Puppet על ה-VM אחרי שהוא נוצר - לא היית מייצר את ה-Image כשהוא Pre-baked ומעלה אותו.
    • ה-Container ייצר יחידת עבודה שהיא הרבה יותר Granular - מספיק גנרית אבל גם כזו שאתה יכול לבנות ביחידות קטנות.
    • זה יצר Building block שלא תלוי בשפה ולא תלוי במערכת הפעלה, וזה פישט מאוד את בעיית הניהול - 
      • קודם לכן, במיוחד כשמדברים על Multi-Cloud - לעשות Multi-Cloud היה כמעט בלתי אפשרי כיוון שלכל ספק Cloud יש את ה-VM שלו והאריזה שונה והאופרציה כתוצאה מזה היא מאוד שונה
      • אנשים פשוט לא עשו את זה, ה - Effort vs. Value לא התכנס.
    • (אורי) אני יכול להגיד שלנו (Outbrain) זה פתח את האפשרות לעשות Multi-Cloud.
    • (נתי) ולא רק לכם - אתמול הייתה לי שיחה עם דור אטיאס, שפעם היה ב-BlazeMeter והיום עם סטארטאפ אחר (Cycode) ודיברנו על זה קצת - ופתאום אני שומע על סטארטאפים שמדברים על Multi-Cloud, כשלפני שנה זה היה כמעט בגדר קללה לסטארטאפים (“למה בכלל צריך Multi-Cloud?”, “האם צריך Multi-Cloud?”)
    • אתה רואה עקומה מאוד יפה - ברגע שהסיבוכיות יורדת, פתאום נפתחות אופציות שלפני כן, בגלל רמת הסיבוכיות, אז זה לא שטכנית אי אפשר היה לעשות אותן אבל הכדאיות לא הייתה שם.
    • זה בדיוק כמו בעקומות של תמחור - יש מוצרים שלא היו קיימים, אפרופו Cloud וסטארטאפים, אם העלות לא הייתה מגיעה לרמה מסויימת.
    • יש איזשהו Threshold מסויים שה-Containers ייצרו, שפישט את רמת הסיבוכיות של האופרציה ואיפשר לכלים גנריים לפתור בעיה יחסית רחבה של אוטומציה על פני הרבה פלטפורמות, מה שלא היה קודם לכן
      • קודם האוטומציה הייתה מאוד תלויה בשפה
      • שוב אנחנו מגיעים לדוגמא של Configuration Management עם Chef ו-Puppet - כולם זוכרים כמה זה היה מסובך לעשות Configuration Management, היית משקיע המון ועד שהיית מגיע למשהו, ואז בשנייה שהיית משנה אותו כל האוטומציה שלך הייתה נשברת . . .
      • עם Containers הרבה יותר קל להגיע ליציבות שהיא אינקרמנטלית (Incremental) - אתה יכול לייצר Building Blocks כך שאתה בונה בכל פעם עוד שכבה של אוטומציה יחסית בקלות.
  • אז הייתי אומר שדור 2 התאפיין במעבר הזה ל - Containers ול- Cloud Native ול - Infrastructure as a Code, שלכאורה התחיל לפני - אבל בעצם תפס תאוצה אחרי.
    • למה תפס תאוצה אחרי? כמו בכל טכנולוגיה חדשה, יש את המשפט הידוע ש”if all you have is a hammer, everything looks like a nail”, אז הרעיון היה כשהגיע Kubernetes וכולם אמרו שהכל יהיה Kubernetes וזה יפתור לי את כל בעיות העולם . . .

(רן) אז מה שבעצם אפיין את הדור הראשון זה Virtual Machines וכלים כמו Chef ו-Puppet ואולי Terraform ל-Infrastructure
  • (נתי) ו-PaaS, אם אתה רוצה “להחביא” את כל הבלגן . . .
  • (רן) ודור שני, שבו אנחנו למעשה נמצאים - ודרך אגב, המון חברות עדיין נמצאות בדור ראשון, זה לא קרה כל כך מזמן אלא רק בשנים האחרונות, 
  • כנראה שהרבה מהמאזינים שלנו נמצאים בדור ראשון וזה בסדר גמור - גם אנחנו (רן), אני חייב להגיד
  • הדור השני מתאפיין ב-Docker ו - Kubernetes וגם Cloudify באותו דומיין, ובעוד מוצרים דומים.
  • הזכרת (נתי) גם גם Multi-Cloud או לפחות איזשהו Enablement עבור Multi-Cloud
  • (נתי) וגם Infrastructure as a Code שזה, למי שלא מכיר, מושג שאני חושב ש -Terraform הובילו והפך מאז למושג בתעשייה
    • כשמו כן הוא - במקום שאני אנהל את האוטומציה דרך IT ועם GUI (מעלה מכונה, מוריד מכונה, מעיין חצי אוטומציה) - ב-Infrastructure as a Code המפתח הוא זה שאחראי על זה, והשפה הטבעית עבור המפתח היא קוד - ולקוד כבר יש הרבה מאוד תשתיות לאיך עושים Collaboration ו-Version control והרבה מאוד תהליכים
    • ניתן לעשות הפרדה מלאכותית בין איך שה-IT מתנהל לבין איך שה-Infrastructure מתנהל, ולכן אפשר להתייחס גם לאוטומציה של ה-Infrastructure כאל אוטומציה של Build של אפליקציה.
(אורי) זו לא בעצם חזרה ל Chef ו-Puppet?
  • (נתי) לא - השוני הגדול הוא ש Chef ו-Puppet עדיין היו “חיה של IT” . . . גם אם השתמשו ב-Ruby כשפה, זו עדיין הייתה “חיית אמצע” כזו, לא חיה שאתה שם ב-Git ו . . .
  • (אורי) זה לגמרי כן…  זה היה תלוי בך ובאיך שאתה מנהל את זה, אבל אצלנו לפחות זה היה ברור, ועדיין ברור, ואנחנו משתמשים לא מעט ב-Chef - היה ברור שזה קוד, וזה צריך Versioning וכל Cookbook הוא בסוף אפליקציה והוא צריך ניהול קוד
  • (רן) אני חושב, אורי, שלשמחתך Outbrain זו לא דוגמא מייצגת - אתם עשיתם (ואני גם הייתי בזמנו) מ-Chef מטעמים שרוב החברות לא הצליחו לעשות, וגם משאר התשתיות.
  • (אורי) זה Chef - הוא עושה מטעמים . . . 
  • (רן) האמת היא שעם יד על הלב - הרבה חברות נתקלות במחסומים כשהן מגיעות לעבוד עם Chef או עם Puppet או עם כלים אחרים - 
    • יש כאן איזשהו barrier to entry שהוא יחסית גבוה, לא כל המפתחים מצליחים להגיע לשם - ואז זה נשאר באיזור ה-Ops או IT או DevOps או איך שלא נקרא לזה - וזה לא נגיש לכל המפתחים כמו שזה נגיש אצלכם.
    • אני מתחבר במובן הזה למה שנתי אומר - כן, זה היה “שלהם”, Chef זה כלי “שלהם” . . . 
  • (אורי) Chef זה עדיין כלי שמשתמשים בו אנשי האופרציה וכו’, אבל זה כן מנוהל כאילו זה קוד.
  • (נתי) אני חושב שהשוני הוא לא האם אתה יכול לשים את ה Cookbook או ה-Templates במקרה של Terraform ב-Git, כי אפשר לשים כל סקריפט ב-Git ולנהל אותו לכאורה משם
    • אני חושב שיש הבדל מאוד גדול בין התפיסה, הייתי אומר, ה-Imperative (קריטי), זה שאם אתה מגדיר את כל ה-workflow וכל ה-API ומנהל את זה בצורה הזו - שזה יותר Configuration Management (דוגמת Ansible), לבין מודל יותר Declarative (הצהרתי), שבו אתה מגדיר את ה-Desired state והפלטרפורמה יודעת לעשות את האבסטרקציה כדי להגיע לאותו Desired state.
    • לכאורה, זו אותה הבטחה של Chef - אבל כשאתה מטפל ב-Infrastructure ואתה מאוד Infrastructure-centric ברמה של Cloud Resource Management, אז אתה מטפל בזה אחרת.
    • ניתן דוגמא - למשל, כשאתה רוצה להרים מכונה, למשל ב-Ansible במקרה הכי פשוט, אתה צריך להרים את הסקריפט של איך להרים את המכונה וגם את הסקריפט לאיך להוריד את המכונה:
      • במודלים דקלרטיביים (Declarative) אתה מגדיר “אני רוצה מכונה” - ואז בעצם ה-flow של איך אתה מייצר מכונה הוא נגזרת אוטומטית וה-flow של איך אתה מוריד מכונה הוא אוטומטית הreverse-code של הדבר הזה, אתה לא צריך לקרוא או להגדיר שום דבר שעושה את התהליכים האלה.
    • (אורי) אנחנו מתחילים לפזול לדור שלישי?
    • (נתי) אנחנו מתחילים לפזול לדור שלישי, כן . . .  אני אגיד עוד מילה על דור 2: עדיין בדור 2 צורת העבודה היא שאני רוצה לעשות אוטומציה אז אני כותב Templates: לכל Resource שאני רוצה לנהל יש APIs ויש איזשהו קובץ YAML שמייצג את ה-API בצורה יותר אבסטרקטית
      • אני צריך לכתוב סקריפטים בשפה אחרת שיתארו את מה שאני רוצה להגיע אליו, והייתי צריך לכתוב את זה.
    • (רן) דרך אגב - אם כבר מדברים על Kubernetes, אז Operators של Kubernetes זה משהו שהוא בעינך עדיין דור 2?
      • (נתי) הם כבר חוצים את הקו . . . הם נוגעים בדיוק במה שאני מאפיין כבר את דור 3
  • (נתי) דור 3 בא לעולם שבו יש כבר הרבה אוטומציה מובנית - אתה בנית Data center, וזה כבר לא מעבר ממודל של “אין אוטומציה” ל”יש אוטומציה”, או מחצי אוטומטי לאוטומטי, אלא מעבר לזה שיש הרבה מאוד אוטומציה עם הרבה מאוד כלים שונים
  • אני קורא לעולם הזה Multi-domain - יש לך אוטומציה של AWS שזה Cloud Formation, ויש לך את האוטומציה של Azure שזה ARM - Azure Resource Management, כשל-Google יש את האוטומציה שלהם (Cloud Deployment Manager)
    • ל-RDS יש כבר לפעמים Templates מוכנים מראש, ל-Kubernetes יש את ה-Operators . . . 
    • ב-Terraform עושים חלק מהעבודה אבל יש הרבה מאוד מקרים שבהם תגיד “יש לי כבר את Cloud Formation, למה אני צריך עכשיו לכתוב סקריפט מחדש ולהמציא את הגלגל?”
    • זה עולם שפתאום יש לך בו הרבה מאוד אוטומציות שכבר נכתבו, מוכנות ונמצאות כחלק Built-in מהפלטרפורמה
    • ויש הרבה Domains של אוטומציה, שכל אחד מהם קצת שונה - אבל הוא קיים ואתה לא יכול להתעלם ממנו, אתה לא יכול להגיד “אוקיי, אז תיהיה לי איזושהי שפה אחת שתמדל לי את הכל ואני אקרא לה עם Template או קובץ YAML וזה יעשה את הכל”.
    • אז פתאום את מוצא את עצמך בכל פעם “ממציא את הגלגל”, כי מה לוקח הכי הרבה זמן באוטומציה? לכתוב את ה-Script הזה . . . עד שאתה מגיע למצב שבו האוטומציה יציבה ועובדת לוקח המון זמן.
    • אם מישהו כבר כתב את התהליך הזה, במיוחד אם קוראים לו AWS או שקוראים לו Azure, והוא כבר עשה לזה את ה - Hardening וזה רץ והוא נותן לך את הכל מוכן מראש, כשאתה רק צריך להגדיר את הפרמטרים - תשתמש בזה.
    • מן הסתם ב-Kubernetes, כשיש כבר כלים מובנים - למה להמציא משהו מעל שיעשה את אותו הדבר ש-Kubernetes כבר נותנים?
  • דור שלישי מאופיין ב”מולטי-דומייניות“ (Multi-Domain) הזו, בהכרה בזה שאין שפה אחת שתנרמל את הכל ואין כלי אחד שיפתור את הכל
    • יש הרבה כלים והרבה מאוד שפות והרבה מאוד Domains של אוטומציה והרבה מאוד סביבות שעשו להן כבר אוטומציה, בין עם זה בדור 1 או דור 2
    • אני עכשיו צריך להתנהל בתוך הסביבה הזו.
  • (רן) אתה מתאר פה קודם כל סיוט . . . אתה מתאר פרגמנטציה (Fragmentation)  . . .
    • (נתי) זו מציאות , לא סיוט - מציאות שצריך לדעת לחיות איתה . . 
    • (אורי) שזה סיוט . . .
    • (נתי) מה זה סיוט? אם האלטרנטיבה שלך היא להגיד “אני אפשט את זה ע”י כך שאכתוב את הכל בכלי אחד”, נגיד Kubernetes או Terraform - זה גם סיוט, כי אתה בעצם הולך “להמציא עכשיו את הגלגל” הרבה מאוד פעמים על דברים שכבר נפתרו, לכאורה.
      • “סיוט” זו הגדרה יחסית לנקודת המוצא שלך - ולאן שאתה רוצה להגיע.

(רן) רגע, אבל יש סיפא טובה למשפט שלי . . . נבנה מחדש: אתה מתאר כאן איזשהו סיוט לאופרטור, לצורך העניין - האופרטור יכול להיות איזשהו מפתח, לא בהכרח איש IT.
  • יש הרבה מאוד Domains, כשלכל Domain יש את השפות שלו והקונספטים שלו - ועכשיו אני צריך להבין את כולם, ואם אני רוצה לממש איזשהו שרת Email אני צריך לטפל בשלוש פלטפורמות שונות . . . האם מתוך כל הפרגמנטציה הזו יש בדור השלישי גם איזושהי אגרגציה (Aggregation), איזשהו “אב גדול” שישלוט בכולם?
  • (נתי) הרמת לי להנחתה . . . עם “אב גדול” באה גם הרבה מאוד אחריות, ומצאתי שכשאני אומר את המשפט הזה אני חייב מיד גם לסתור אותו - אז אני משתמש באיזושהי אנלוגיה שאני חושב שהיא מאוד ישראלית, אבל מצאתי שהיא עובדת לא רק בישראל: הצבא!
    • איך פותרים בעיה של מערכת גדולה? נסתכל על המבנה הארגוני של הצבא, כשיש לך הרבה מאוד יחידות “אוטונומיות” - יש לך את השייטת, יש לך שיריון, צנחנים וכו’ (“טייס בשייטת מטכ”ל”)
    • כל יחידה היא אוטונומית מאוד - יש לך את התרבות שלה ואת המבנה שלה וכו’
    • אבל - כשיש לך משימה, נניח לעצור את Karine A, אז יודעים שמביאים את השייטת ואת חיל הים ועוד, מרכיבים ביחד Task Force ויוצאים למשימה.
    • הרעיון הוא בעצם להתייחס לבעיות מורכבות בצורה הזו - כשאתה עולה בגראנולאריות (Granularity), אתה בעצם אומר שאתה לא מנסה לנהל כל יחידה עד הביט הכי נמוך שלה, אלא מנסה לעבוד עם כל יחידה כיחידה אוטונומית על מה שהיא טובה בו
      • עכשיו האתגר שלי הוא לדעת להרכיב אותן Ad-hoc בדיוק למשימה שאני צריך כרגע - אני צריך עכשיו להרים סביבת טסטים לאיזשהו מערך של בדיקות, אז אני קודם כל קורא ל-RDS ול-Load Balancer, ואם זו סביבה שאני רוצה שתיהיה למפתח בודד אז יכול להיות שזה יהיה Local Load Balancer, ו-Containers של Database שמייצג לי, לכאורה, את אותו API - ואני אעשה הרכבות מהרמות האלה ולא עכשיו אתחיל נהל את כל הביטים של ה-Infrastructure בכל פעם מחדש.
      • אני אחפש בכל אחת מהסביבות את ה-Building Blocks המוכנים
    • אנחנו עשינו את המהלך הזה בשנה האחרונה, של אינטגרציה עם Azure ועם Terraform ועם Kubernetes - ופתאום הרגשנו איך זה לאט לאט פותח תפיסה אחרת לאיך שאתה חושב על בעיית האוטומציה.
    • פתאום אני מרכיב את האוטומציה מתוך זה שאני עכשיו למשל לא צריך איטגרציה עם ה-API: יש לי Templates של Azure שתומכים בכל האיטגרציה של Azure, או את Cloud Formation שכבר תומך בכל ה-API - אני יכול לבנות כלי הרבה יותר גנרי שלא דורש אינטגרציה ספציפית.
      • פתאום זה פותח לי את זה שאני יכול לנהל כל Cloud Resource באשר הוא - בלי צורך באינטגרציה: רק לקרוא ל-Template הנכון במקום הנכון ופחות או יותר סגרת את העניין.
    • יש בזה הרבה אתגרים - אתה לא יכול להתייחס לזה כאל Black-box לחלוטין כי אתה צריך בסוף להעביר לזה פרמטרים ולהוציא מזה פרמטרים, אתה צריך להבין האם זה הצליח או לא הצליח - ואם זה לא הצליח אז איפה.
      • יש כאן רמת אינטימיות מסויימת שנדרשת, אבל היא הרבה יותר Loosely-coupled מהדור השני לצורך העניין.
  • (רן) אתה מדבר בעצם על סוג של “App-Store” כזה, כשאם לצורך ה-Operations אתה צריך איזשהו Service אז אתה הולך ל-AWS שיקראו לו בשם כזה או ל-Google שיקראו לו בשם אחר, אבל בגדול זה אותו ה-Service, כמו שיש אפליקציות לאנדרואיד ול-IOS
    • (נתי) קפצת כמעט לדור הרביעי, אבל בגדול לשם זה הולך, זה הרעיון.
    • (רן) כמו שיש לי אפליקציה שאני יכול להוריד אותה לאנדרואיד ואני יכול להוריד אותה ל-iPhone . . . יש אולי משהו שונה אבל בגדול שתיהן יכולות לתת לי פחות או יותר את אותו הדבר - אז גם פה: אני הולך ל-Cloud הרלוונטי, מדבר בשפה שלו ומקבל את הכלי הזה, כשאני לא צריך להכיר את הפרטים
      •  כמו שהורדתי אפליקציה לטלפון, ככה אני אני יכול להשתמש ב-Database …
    • (נתי) בדיוק, ואני ארחיב ואומר - הדוגמא של אנדרואיד ו-Apple שהיא דוגמא טובה מהבחינה הזו
      • בסוף אם אני מנסה לפתור בעיה של Multi-Cloud אז אני רוצה Kubernetes על AWS או רוצה Kubernetes על Azure, בסוף בשניהם אני אקבל Kubernetes - האם אני צריך שזה גם יהיה אותו הכלי שמריץ את ה-Kubernetes, או שאני יכול שב-Azure זה יעלה עם ה-Template שלו וב-AWS עם Cloud Formation - כמשתמש אני מקבל Instance של Kubernetes, ולא כל כך מעניין אותי עם איזה סקריפט הרמת אותו . . . מעניין אותי איך הקונפיגורציה (Configuration) של ה-Cluster הזה נראית והאם היא מתאימה לי, כן או לא - אבל איך הרמת אותו? זה הופך להיות אבסטרקטי מבחינתי.
    • (רן) גם יכול להיות אגב שלא מעניין אותך איך זה ממומש מאחורה . . . כל עוד הם חושפים לך את ה-API.
    • (נתי) נכון - יש היום יותר ויותר Building blocks כאלה, שאפשר להתייחס אליהם - לכמעט כל מי שמתעסק היום ב-Cloud יש סדרה של Building blocks שחוזרים על עצמם - RDS, כל סוגי ה-Databases as a Service הפופולאריים, מן הסתם Kubernetes  . . .  עוד כמה יחידות, אבל מספר בסופו של דבר סופי, זה לא אינסופי.
      • יש כמובן את כל ה-Long Tail שיכול להיות כמעט אינסופי, אבל ה-80% די חוזר על עצמו בקונפיגורציות שונות, ואתה יכול באמת להגיע למודלים . . .
      • הייתה לי את אותה השיחה שהזכרנו עם דור אטיאס, שבה הוא נתן דוגמא של “אם הייתי יכול להריץ עכשיו להרים ידנית את ה-Kubernetes, ואז בקליק להריץ את האוטומציה”.
      • כשאתה עובד עם AWS למשל, אתה יכול לעשות לזה “Reverse engineering”, לדעת מהם ה-Building blocks ומהם ה - Templates מאחוריהם, אז מה שנשאר בסוף זה רק הפרמוטציה הספציפית - מהם הפרמטרים הספציפיים שהגדרתי.
      • אני יכול גם לעשות את האוטומציה הרבה יותר פשוטה, כי היא תיהיה סוג-של-Auto-Generated.
      • ברגע שעולים לשכבה הזו, אני יכול פתאום לחשוב במושגים של אוטומציה הרבה יותר אבסטרקטית
    • אם אני ממשיך בקו הזה, אז זה כנראה כבר נכנס לשאלה הבאה -  לאיזה סוג של Workload זה מתאים ומתי אני צריך את זה? 
      • זה כן פתאום שינה את השיח לאיך אני חושב על אוטומציה ואיך אני חושב על מודל של אופרציה שלכזה דבר, באיזה Layer אני צריך להישאר.
      • זה פתאום שם במקום קצת אחר את הנושא של איפה ה - Infrastructure as a Code נמצא ואיפה ה - Cloud Native נמצא
      • זה הופך להיות עוד Building Block - כבר לא מרכז היקום אלא אחד מה-Building Blocks שאני חייב להתייחס אליהן.

(רן) לפני כמה שבועות אירחנו כאן את רועי אושרוב, ודיברנו על מספר נושאים - בין השאר על הנושא של Contentious Deployment (או Continuous Delivery) ואיפה זה נמצא היום (מוזמנים לחזור לפרק הזה, שני פרקים אחורה).
רציתי לשאול איך הסיפור הזה הולך להשפיע על Continuous Delivery? האם יש איזשהו ממשק ביניהם?
  • (נתי) קודם כל, Continuous Delivery הוא גם סוג של אוטומציה וסוג של Orchestrator, כשההבדל הוא שהוא מתמחה באוטומציה של של Build Processes - וגם פה, שוב אפשר לראות את ההתמחויות האלה . . .
    • (אורי) Build ו-Deploy
  • (נתי) בדיוק - בדור השני באמת חשבנו ככה, שכל מה שקרה באוטומציה נחשב כ”מתחרה” אחד של השני, וכל אחד ניסה להגיד למה Terraform יותר טוב מ - Ansible או להיפך, למה Terraform יותר טוב מ-Kubernetes ולמה Nomad יותר טוב ממשהו אחר - והיה המון בלבול.
  • אני חושב שאנשים מתחילים להבין שלכל דבר יש איזור שהוא מאוד טוב בו ואיזור שהוא פחות טוב בו - וזה ה-Multi-Domains, שזו איזושהי בשלות, או שלב של בשלות.
  • בחזרה ל-CI/CD, אני חושב שלפטרפורמות האלו של CI/CD יש התמחות ב- Build Processes, ואעפ”י שאתה יכול לכאורה “לתפור את זה” עם כלים אחרים, הם יעשו עבודה יותר טוב והם הרבה יותר מותאמים  לסוג הזה של העבודה.
  • מה שכן מעניין שקרה עכשיו לאחרונה, בעיקר בגלל החצייה הזו שהזכרתי של קו של Cloud native ו - Infrastructure as a Code, פלטפורמה שהייתה כמעט בלעדית המון זמן שנקראת Jenkins ל - Build Processes, לפחות בגרסא הראשונה של Jenkins, התחילו לראות שהיא לא מותאמת כל כך לעולם הזה של ה-Infrastructure as a Code ו - Cloud Native, כי היא מאוד Imperative, מאוד Task-oriented ופחות יודעת לטפל בגרנולאריות (Granularity) יותר מורכבת.
    • שוב - אני מדבר על הדור הראשון של זה, הם עשו איזשהו Jenkins 2 שכבר יותר מותאם לזה אבל עדיין בתפיסה הזו.
  • זה פתאום איזשהו גל שבו הרבה CI/CD-ים שלכאורה מתחרים על הנתח הזה של Jenkins, כשהמכנה המשותף לכולם הוא שכולם נמצאים באיזשהו שלב ב - Source Code או ב - Ecosystem שלך.
    • אז יש את Git עם Git actions שתופס עכשיו כמו אש בשדה קוצים (עוד שנייה כבר קיץ ,למה ככה?), כי הוא יושב בעצם ישר על ה-Repo וזה הכי קל.
    • יש את CircleCI שלכאורה הוא שלב אחד לפני Git actions, עשו את מה ש-Git actions עושה - הם בעצם לקחו את המודל הזה טיפה לפני, עושים את אותו הדבר אבל דור אחד קודם לכן.
      • התפיסה גם הייתה ש”אני נותן לך SaaS - אתה לא צריך להתקין Jenkins, אתה מקבל Service” ובכך בעצם מפשט לך את התהליך בזה שאני יודע לעבוד עם Containers כיחידת עבודה ולא דורש עכשיו שתכתוב לי סקריפטים ב-Groovy וכל מיני דברים כאלה שאנשים לא אוהבים ב-Jenkins.
    • אחרי זה נוצרו GitLab ו - Git Ops, שמשלבים גם Infrastructure as a Code עם Git, ויצרו איזושהי תפיסה . . . למי שמכיר קצת Dependency injection ב-Spring אז זה קצת מזכיר את התפיסה הזו ולמי שמכיר את Chris Richardson שהוא אחד היזמים שם אז יכול להבין גם מאיפה הרעיונות הגיעו.
    • ההסבר הוא שהיה פה “פתאום” איזשהו ואקום באיזושהי נקודת זמן, וזה ייצר “פתאום” הרבה מאוד פתרונות - 
      • והסתכלנו על זה לאחרונה כדי לנסות להגיד מה בעצם שונה פה בין כל הפתרונות, ואתה רואה שהשונות היא כבר מאוד קטנה
    • היה סקר ב-2019 על אילו הן הפלטפרומות הן הפופולאריות ועדיין Jenkins על 38% ואחרי זה CircleCI ואז GitLab - פחות או יותר שלושת אלה היו המובילים.
      • היום יש את CodeFresh ועוד הרבה כאלה שמנסים להתחרות בתחום.
    • כשהסתכלתי על זה אמרתי “אוקיי, אני עכשיו ארגון, מה אני עושה עם הדבר הזה? יש לי עכשיו עוד כאב ראש להתעסק איתו”
      • מה שהפתיע אותי לרעה היה שבהרבה מאוד ארגונים יש יותר מ-CI/CD אחד . . . אז התחלתי לחקור את זה כדי להבין איך הגענו למצב הזה.
      • למה? האם ההבדלים  הההדלים הם כאלה משמעותיים?
    • ואז אתה מגלה שהכלי בכלל היה נחשב ככלי Development . . . 
  • (רן) אצלכם (Cloudify) יש שניים כרגע?
  • (רן) אצלנו (Appsflyer) גם יש שניים ,אגב.
    • (נתי) זה לא מפתיע בכלל . . .
  • (רן) אורי - מה אצלכם (Outbrain)? אתם עם אחד?
    • (אורי) אנחנו ב - 1.5 . . . יש TeamCity וקצת Jenkins
    • (רן) אני גם רואה את זה בהרבה חברות
  • (נתי) עכשיו, כשאתה הולך לספקי Cloud, הרבה מאוד יש איזשהו Affinity (העדפה) ל-Cloud, אז הוא “ידחוף” אותך לאיזשהו כיוון
  • המציאות הזו גם ייצרה איזושהי מורכבת מעניינת, ועולה השאלה איך לפתור את הבעיה הזו? האם אני באמת צריך לכל אחד כלי נוסף ונפרד
  • אחת הסיבות, אני אומר עוד פעם, היא שזה היה נחשב ככלי Development - וזה גם מה שמשתנה בדור השלישי.
    • פתאום התובנה שזה כלי הרבה יותר מרכזי בארגון ושהוא צריך להיות מנוהל היא תובנה מאוחרת - בהרבה ארגונים היא עדיין לא קרתה.
    • זה היה כלי כמו IDE - משהו שמישהו מתקין, משחק איתו ועושה מה שהוא רוצה - ופתאום זה משהו שנוגע לך ב - Production ובהרבה מאוד מערכות בארגון.
    • היום יש את המשפט הזה ש”אם זה לא ב-CI/CD אז זה לא קיים”, או “אין לך אוטומציה אם זה לא ב-CI/CD” - כל מיני משפטים כאלה שאני שומע היום בארגונים שמתחילים להבין את המשמעות של זה
      • זה הופך להיות תשתית סופר-מרכזית - אבל היא לא מנוהלת
      • אז יש כאן איזשהי אנומליה, ורק עכשיו מתחילים לשאול את השאלות האלה, אני ממש רואה את זה ב - Enterprises במיוחד, שעכשיו מתחילים להבין את המרכזיות של זה ואיפה זה צריך להיות
      • ואז הם מתחילים לשאול את השאלה של “למה יש לנו כל כך הרבה כלי CI/CD?” ו”למה, אפילו אם יש לי Jenkins - למה יש לי כל הרבה Instances של Jenkins?”
  • (רן) אני לגמרי יכול להתחבר עם הנקודה הזו . . . נתת למשל את הדוגמא של IDE וזו הדוגמא הכי טובה - בדרך כלל אומרים למפתח “תכתוב במה שנוח לך - אתה אוהב VI או Emacs או IntelliJ או Eclipse? תעבוד במה שנוח לך”.
    • לאף אחד לא אכפת - מה שחשוב זה שתעשה Commit לקוד מפורמט . . .
    • אותו הדבר היה גם עם ה-CI: “אתה צריך להריץ אז תריץ איפה שבא לך, למי אכפת איפה זה רץ?”  - אם אתה רוצה אז Jenkins או אם אתה רוצה TeamCity או משהו אחר . . .
    • ויום אחרי זה אתה מתעורר - וכל הארגון תלוי בזה.
    • (נתי) זה הופך לקו ייצור . . .
    • (רן) ברגע שיש תקלה ב - Jenkins, או ב-CI שלך, החברה מושבתת - אתה לא יכול יותר לעשות Deployment, אתה לא יכול לתקן בעיות
    • זה הופך למשהו שהוא סופר-סופר-קריטי - ואז אתה מגלה שאתה בברוך . . .
  • (אורי) אבל בסוף אתה מסתנכרן לאיזשהו Pipeline מרכזי . . . אני אומר את זה “on the verge”, על באג שעכשיו פגע בנו . . .
    • כשהוא לא היה על ה - Pipeline המרכזי, אז ב - Pipeline המרכזי אתה מפתח גם איזושהי “תורת לחימה” של בקרת איכות ושל “Immune system” מעל ה - Pipeline המרכזי
    • פתאום כשיש לך משהו שהוא לא ב-Pipeline המרכזי - שם זה “ינשך אותך”.
  • (נתי) זו בדיוק הנקודה האחרונה לגבי הדור השלישי - זה גם מה שמאפיין אותו: ההבנה שהג’ונגל הזה שהיה שבו כל אחד עושה מה שהוא רוצה, אז כשזה ניהיה קן הייצור של החברה זה כבר לא יכול לקרות.
    • ואז באמת נשאלת השאלה של איך אני מכניס מודלים של Governance ואיך אני מייצר בקרות ומי אחראי על מה ואיזשהו סדר בבלגן.
    • וגם ניסיון להגדיר תפיסה ארכיטקטונית - איך בונים אוטומציה, איזה כלים, מי אחראי על הכלים האלה? באילו שכבות?
    • הכל מאוד צעיר, התפיסה הזו - ברוב הארגונים כל אחד עדיין ממציא לעצמו את התשובות, ואני חושב שאין עדיין “תשובות בית ספר” סדורות לכל הדבר הזה.
    • השאלה של איך אתה עושה Governance בלי לפגוע באג’יליות - בלי לפגוע בזה שעכשיו אנשים יפתחו מהר ויוציאו גרסאות אבל מצד שני כן יש לך בקרה
      • זו תרבות, אבל אם תחשבו על השאלה הזו אז זה קונפליקט שהיום שואלים גם על דמוקרטיה . . . יש לך משטרה, אבל מצד שני אתה רוצה חופש לפרט, אז זה בדיוק המתח הזה.
      • גם לחופש פרט יש גבולות, כי מתישהו החופש פרט שלך יכול לפגוע בפרט אחר ואז אתה צריך חוקים ואתה צריך סדר
      • אנחנו ממש בראשיתו של הגל הזה (חייבים בדיחות קורונה באמצע), לדעתי, של לנסות ולבנות את התפיסות האלה - ואני חושב שזו איזושהי בגרות מסויימת שגם מאפיינת את הדור הזה.
    • (אורי) אגב - פה אוטומציה נותנת הרבה מהסיפור הזה, כי כל התפיסה הזו של “תבנה מערכת חיסונית שלאט לאט משתפרת”, תכל’ס היא שומרת עליך ואתה מתחיל להיות מסוגל לרוץ מהר - לא המצאנו את זה, האבולוציה המציאה את זה . . .
      • לא סתם קוראים לזה “מערכת חיסונית”, כי בסוף אנחנו יודעים שאנחנו יכולים לרוץ וליפול ולחטוף פצע - והפצע הזה הוא משהו שהגוף יטפל בו והכל בסדר, אפשר להמשיך לרוץ.
    • (נתי) כן, אתה אומר את זה בגלל שבאוטומציה, מרגע שטיפלת בפצע אתה יודע שבפעם הבאה הוא לא יקרה לך, ובלי אוטומציה - גם אם טיפלת בפצע, הסיכוי שהוא יקרה שוב בגלל Human error עוד פעם הוא יחסית גבוה, כי זה לא ממודל באיזושהי צורה.
    • (אורי) אני רואה איך במהלך השנים, אני מתחיל להסתכל על סיכומים של Take-Ins - אצלנו Take-In זה Retrospective, או Post-mortem (הגרסא הפולטיקלי קורקט . . .) - אני רואה את הסיכומים של ה - Take-Ins ואני מנסה למצוא אילו Action Items לקוחים שהם Action Items של Process, ולא רק של “בוא נבנה עוד אוטומציה, עוד Alert, עוד Monitoring . . .”
      • מתחילים להסתכל ולהיות מאוד מרוכזים באיך אנחנו פותרים את הבעיות האלה עם טכנולוגיה, כשלפעמים אתה צריך גם להגיד “אוקיי, יכול להיות שיש דברים שאנחנו לא יכולים לפתור רק עם טכנולוגיה”, 
      • לפעמים אנחנו מסתכלים רק על מה שמתחת לפנס ולא על דברים שהם Process, אבל אלו דברים שנבנים ביחד כל הזמן
      • בסוף - הם שומרים עליך, ואם יש Pipeline אחד אז הרבה מתוך האוטומציות האלה יכנסו . . .
      • (נתי) כי אתה בחשיפה מאוד גבוהה מן הסתם, אז יש הרבה יותר מתודולוגיה שאתה מכיל מעצם זה שיש Visibility מאוד גבוה וחשיפה מאוד גבוהה - ומן הסתם אם יש בעיה אז היא עולה מהר באסקלציה (Escalation)
    • (אורי) רציתי לשאול אותך על העניין הזה של איחוד פלטפורמות - שיש פה מצב שבו פתאום כל אחד מפתח לעצמו את השפת אוטומציה שלו: אם יש הרבה מאוד פלטרפורמות, למה . . . למשל, כשאנחנו עשינו Multi-Cloud, עשינו Setup שרץ, אותה אפליקיה רצה גם ב-Data Center וגם ב - Public Cloud - אבל מה שעזר לנו לעשות את זה זה Kubernetes . . .
      • בגלל שכל ה-CI/CD stack שלנו הוא מעל Kubernetes, בסך הכל היינו צריכים שיהיה לנו Kubernetes ב-Public Cloud, וזהו.
      • מבחינת המפתח, זה אותו Deployment - פתחת לו עוד Data Center
    • (נתי) אני אזכיר לך איפה זה לא הצליח, אם אתה זוכר . . .
      • (אורי) ב - Cost . . . 
    • (נתי) ב-Cost, אבל למה ה-Cost לא הצליח? כיוון שבסוף היה לך Services של Data, שלא הכל הוא Stateless ולא הכל רץ Kubernetes, והם היו צריכים להיות קרובים ל-Kubernetes אבל הם היו קבועים ולא משהו שכל כך קל לנייד בהתאם ל-Cost - ואז ה-Cost הפך לפקטור כי צריך להריץ Data בהרבה מקומות ולשחרר Data בהרבה מקומות, אז זה הפך להיות לא-כלכלי (להרחבה - ד”ש לקרבורטור 27)
    • כשאתה מסתכל על פן מסויים, שבאמת אפשר להריץ אותו ב-Kubernetes אז התמונה נראית מאוד ורודה
      • פתאום כשאתה פותח את התמונה ל - End-to-End, אתה מגלה שיש פה בורות שוואלה - הם בסוף מתורגמים לעלות, ובעלות הכוללת הדבר הזה צף מהר מאוד.
  • ניסינו להגיד “אוקיי, אז מה למדנו מזה? מה אפשר ללמוד מזה? איך אפשר לייצר תפיסה של איך בונים מערכות בעולם הזה?”
    • היה כלל אחד, שאני חושב שהוא מחבר אותנו בחזרה לדור הראשון של PaaS - 
    • מה PaaS בעצם עשה? בא ואמר “אני יודע איך הסביבה שלך צריכה להראות” - נניח בעולמות של Web applications צריך להיות Web Container ו-Load balancer, אולי Database עם Availability מסויים, Ruby on Rails כ-Stack מסויים . . .
      • אם זה ככה, וכולם עובדים עם אותו Template, אז זו הסביבה, נעשה לה הקשחה (Hardening) “ובא לציון גואל”.
    • איפה זה נפל? בזה שהרבה ארגונים לא מריצים כבר ככה אפליקציות . . . לכל אחד יש את ה-Stack שלו, ובמיוחד היום כשאנחנו עוברים ל-AI ול-ML ולסביבות כאלו שהן מאוד מבוזרות ומאוד מורכבות ועם הרבה מאוד כלים והרבה מאוד Processes שמשתנים כל הזמן - אין לי ארכיטקטורה אחת שמישהו יכול לחשוב עליה מחוץ לארגון שלי.
      • יש לי הרבה ארכיטקטורות שונות - אבל הן סופיות, וזו נקודת המפתח.
    • כל ארגון יכול להגיד איזה סוג של Environments יש לנו: יש Environment ל-Analytics, יש ל-ML ול-AI, יש ל-Testing ויש ל-Development . . . יש מספר סופי של סביבות שהמפתחים בסוף “זורקים” את הקוד אליהן.
    • אם היית יכול לבנות סוג של Platform as a Service לכל הסביבות האלה בקלות, אז היית יכול לייצר Relationship הרבה יותר נכון בין ה-Pipeline של ה-Developer לבין ה-Environment עצמו.
    • זה הרעיון באופן עקרוני - להפוך את היכולת להפריד בין ה-CI/CD לבין ה-Infrastructure, כי מה שראינו זה ש”הספגטי” הכי גדול זה שבאותו Pipeline כל אחד קורא ל-Infrastructure בצורה שלו, רק בגלל שיש לו איזה פרמטר אחד שבו הוא רוצה לעבוד עם Spot instances ולא עם VM ב-Development
      • ואז פתאום נוצר לך Fork . . . ואז גיליתי שיש לי איזשהו חור ב-Security, אז אני רוצה להחליט של-Database אני פותח רק את ה-Port הזה ולא Port אחר
      • ועכשיו יש לך עשרה מקומות לגעת ולהבין איפה מישהו הגדיר את ה-Security Group הזה וזה הולך . . .
    • אם אני הולך ובונה איזושהי פלטפורמה, שבה יש לי את הכל מרוכז במקום אחד, ויש לה פרמוטציות אחרות, ויש קבוצה שמתמחה באיך עושים אופטימיזציה ל-Cost לפלטפורמה הזו, נניח לדוגמא של AI או Hadoop או מה שאתם לא משתמשים בו היום ל-Analytics, אז אני יכול להגיע למצב שבו - 
      1. יצרתי פשטות למפתח - הוא יכול להרים סביבה כזו יחסית בקלות ולא צריך לדאוג לכל ה-Infrastructure הזה
      2. אני לא צריך לרוץ לעשרה מקומות כדי לבדוק איפה בדיוק נוגעים במקום הזה.
  • זה הרעיון, in a nutshell . . . בלי להיכנס לכל הפרטים
    • אנחנו קוראים לזה Environment as a Service, והרעיון הוא בעצם לקחת עקרונות של Platform as a Service, אבל להפוך אותם להרבה יותר גמישים ופתוחים, כדי שיהיה אפשר לייצר הרבה סוגים של Platform as a Service ארגוני
    • כל ארגון הוא עדיין יהיה שונה וקשה לייצר Platform as a Service לרוחב כל הארגון
    • אז אנחנו מגיעים ליחסים יותר הגיוניים בין, לצורך העניין, המפתח שרוצה Agility לבין הארגון שרוצה Control.
  • (רן) אני רואה את זה כסוג של דרך ביניים , בין PaaS ל-IaaS . . . מעיין “Build your own PaaS”.
  • (נתי) קראנו לזה Environment as a Service לא סתם - זה בדיוק ה-Layer הזה באמצע, בין ה-IaaS ל-PaaS.

(רן) נתי- שוב החכמת אותנו slightly smiling face תודה שבאת עד לצפון הרחוק (כרכור-סיטי), שיהיה לכולנו גל שני שמח . . .


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