יום ראשון, 8 בדצמבר 2019

382 Carburetor 27 - k8s and multi-cloud

פרק מספר 382 של רברס עם פלטפורמה - קרבורטור מספר 27: אורי ורן מארחים בכרכור לפרק מיוחד של הקרבורטור את נתי שלום (היזם של חברת Cloudify) ואת אורית ירון (VP Cloud Platform ב - Outbrain) לשיחה על Kubernetes, בעיקר בהקשר של Multi-Clouds - מתי זה טוב ומתי זה רע ולמי.

לפני הכל - אורית:
  • בשש השנים האחרונות מבלה ב - Outbrain - מנהלת את קבוצת התשתיות - תשתיות ה - Cloud וה - On-Premise. 
    • לפני כן סטארטאפים, חברות גדולות - בעולם התשתיות.
  • ונתי, למקרה ששכחתם - 
    • מגיע מ - Cloudify, לפני כן המקים של GigaSpaces שעוסקת באוטומציה של בסביבות ענן - ומשם הרקע עם Kubernetes.

ולעניין - דיברנו כבר על Kubernetes ב - Outbrain (נגיד בשיחה עם שחף ואלכס בפרק 368 על Kubernetes and Dyploma at Outbrain), וגם לנתי יש לא מעט נסיון בנושא.
היום אנחנו רוצים להתמקד בזוית המאוד ספציפית של ה  - Multi-cloud - ב - Outbrain משתמשים ב Multi-Cloud (אחרי שלפני כן לא עשו בכלל).
  • אורי מדייק - הקמנו את ה - Cloud הפנימי שלנו - On-Premise. לגבי Multi-Cloud - אפשר להגיד שהייתה לנו “התנסות”, ויש מקום לדבר על זה.
לנתי יש המון ניסיון בעולם התשתיות, וחלק משמעותי מזה זה Kubernetes.

למה בכלל מעניין לדבר על Kubernetes בהקשר של Multi-Cloud? האם ישנה איזושהי סינרגיה בין הדברים?
  • שאלה טובה . . . הסיבה העיקרית לכך ששני הדברים הללו הולכים יחד היא ש - Multi-Cloud זו חיה מאוד מורכבת ויש הרבה מאוד סוגים של Scenarios - 
    • יש את היכולת להעביר Workloads, שזו אוטופיה שלא באמת ממש מתקיימת (במציאות)
    • יש את היכולת לעשות Interoperability - במשמעות של Workload שרץ בסביבה אחת ויכול “לדבר” עם Workload שרץ בסביבה אחרת.
    • יש Data Synchronization . . .
  • הנושא של Multi-Clouds ובכלל ה - Use Cases יכולים להיות מאוד מגוונים, ולאו דווקא בכפיפה אחת.
  • השורה התחתונה - כשהשכבה המשותפת בין הסביבות הללו נמוכה (מעט משותף), הבעיה הופכת להיות מאוד מורכבת - להעביר VM, לצורך העניין, מענן לענן זה כמעט בלתי אפשרי (כל אחד עם הפורמטים שלו והסינרגיה שלו).
  • ההקשר של Kubernetes מאוד פשוט - לייצר סביבת אבסטרקציה ל - Infrastructure במידה כזו או אחרת
    • כתוצאה מכך שהיום כל ספקי הענן הגדולים תומכים ב - Kubernetes, היכולת הפרקטית (מעבר ליכולת הטכנית) להעביר Workloads מאחד לשני הופכת להיות יותר זמינה לעומת העבר, וזה מפשט משמעותית את החזון של היכולת להריץ את אותו ה - Workload בכמה סביבות שונות.

אולי רגע ניקח מכאן צעד אחורה - למה בכלל Multi-Cloud? אמרנו שזו בעיה מורכבת . . . 
השאלה לאורית על מה בכלל גרם לכם - Outbrain) להתפרש החוצה לעוד מקומות, כשברור שרמת הסיבוכיות שם הולכת להיות שונה (וכנראה גדולה יותר)?
  •  לצאת מהארון, במובן של לצאת מה - Rack . . .
  • לכל סביבה ולכל ענן יש יתרונות שעומדים בפני עצמם, וברגע שאתה מגביל את עצמך ומחליט שאתה עובד רק On-Premise או רק ב-GCP או רק ב-AWS, אתה למעשה שם על עצמך הגבלות - ומפספס.
  • אני תמיד מקבילה את זה לאהבה המאוד גדולה שלי לגלידה - כשאני הולכת לגלידריה, אני אף פעם לא בוחרת טעם אחד . . . תמיד מחפשת גם וגם (מי אמר קרמל מלוח?) - וזה מה שהביא אותנו לבוא ולהגיד שאנחנו יכולים להינות גם מהיתרונות של זה וגם מיתרונות של זה - מכל העולמות.

השאלה היא האם גם לא סובלים מכל העולמות? ידוע בתעשייה שנכון - יש מה להרוויח, אבל יש גם הרבה ממה לסבול, ואולי Kubernetes קצת מקל על הסבל הזה באיזשהו אופן? בכל אופן זה נשמע כמו סיכון משמעותי.
  • המפתח להתמודד עם הסיכון או עם הכאב הוא לבחור את ה - Workloads ואת ה - Scenarios שבאמת מתאימים ליתרונות של הענן.
  • זאת אומרת - לא לבחור רנדומלית אלא לעשות איזושהי אנליזה מקדימה לפני שקופצים למים - מה בדיוק ה - Benefits - ורק אז לבחור.

בהינתן התשתית של Outbrain לפני Kubernetes, אם לדמיין כמה שנים אחורה - זה בכלל נראה לכם כמו משהו Feasible באותה תקופה? ללכת ולהתפרש על Vendors נוספים, שונים לגמרי ממה שהיה לכם?
  • (אורי) אני חושב שקודם כל - עבור Workloads שונים עשינו את זה לפני כן, לפעמים גם לא מבחירה - הרבה פעמים אתה קונה סטארטאפ (ככה יצא) עם טכנולוגיה שהיא לפני שלב ה - Scaling, כזו שבנו אותה על איזשהו Cloud - ואתה “יורש” את זה, ולומד לעבוד בסביבה אחרת עם Workloads שונים.
  • (אורית) אנחנו גם הצענו את ה - Scenarios ואת ה - Workloads שהרוויחו מהמעבר לענן בלי קשר ל  Kubernetes, והעברנו אותם עוד לפני שהייתה לנו סביבת Kubernetes מלאה.
  • אני חייבת לציין שאמנם לדחיפה שלנו לכיוון Kubernetes היה Benefit של Multi-Cloud, אבל יש לה גם Benefit מאוד גבוה כשעובדים בסביבה שהיא On-Premise, וזה אפשר לנו לנצל את המשאבים הפנימיים שלנו בצורה הרבה יותר יעילה ואפקטיבית.
  • (אורי) בוא נאמר שב-Scenario שנתי דיבר עליו - ה”אוטופיה” של לקחת את אותו Workload “ולנשום” אותו לתוך Public Cloud - אנחנו עשינו את זה קודם, וקיבלנו את זה כ By-Product של המעבר ל Kubernetes, כך שהמעבר לא היה על מנת לקבל את היכולת הזו.
  • אני יכול להגיד שלפחות מהחווייה שלי - עבדנו עם  Kubernetes ועברנו ל - Kubernetes - ויום אחד באו אלי גיא ואורית ואמרו לי “בעוד שבוע אנחנו פותחים ניסוי של Multi-cloud”
    • שאלתי “מתי הספקתם לעשות את זה”? . . .זה לא היה טריויאלי, ואולי אורית תוכל להרחיב על הדבר הזה.
    • מצד שני - זה גם לא היה “מאוד” מסובך, בהינתן  Kubernetes
  • אני (נתי) רוצה להתייחס לשאלת ה - To Multi-Cloud or not Multi-Cloud - זה משהו שאני היום שוקד עליו, וחד משמעית אני אומר שאם אתה סטארטאפ שמתחיל ולא רוצה לסבך לעצמך את החיים - אין לך שום סיבה לחשוב על Multi-Cloud.
    • כפי שאורי ציין, Multi-Cloud בהרבה מקרים זו לא בחירה אלא מציאות שנכפית עליך
    • קצת דומה למה שקרה עם Linux ו - Windows וכל מיני מערכות אחרות - זה לא שאתה רוצה את השונות בהכרח כמו שהשונות היא מציאותשאתה גדל אליה מתוך אילוצים וצרכים (כמו רכישת חברות ודברים מהסוג הזה) - נוצרת סביבה הטרוגנית, ו - Multi-Cloud זה חלק מהדבר הזה.
  • קצת כמו צ’אק נוריס - אתה לא בוחר Multi-Cloud אלא Multi-Cloud בוחר בך? בדיוק זה.
  • אם יש לך את האפשרות לייצר Workload יותר פשוט וסביבה יותר הומוגנית, כשהכל רץ במקום אחד - go for it. 
  • ההמלצה היא לא להתחיל ב - Multi-Cloud ורק לחשוב Multi-Cloud כי זה הדבר הכי טוב עולם - זה בא עם מחיר ומורכבות
    • לא הייתי נכנס לזה אם אני יכול שלא, אני נכנס לזה כי אין לי ברירה, או כשיש לי Workloads מסויימים שעבורם ה - Gain על ה - Complexity מספיק משמעותי וזה באמת כדאי.
  • ההקשר של  Kubernetes הוא בהורדת החסם ששל המורכבות, כך שיש יותר מקרים שבהם זה כדאי ופחות מקרים שבהם זה לא, כשקודם לכן כמעט בכל המקרים ה - Complexity היה גדול מה - Gain.
  • הדבר השני שיצא לי לדבר עליו בהקשר הזה של Multi-Cloud הוא שגם כאשר אתה מסתכל על Cloud בודד - ה - Clouds עצמם הם חיה מאוד מורכבת והטרוגנית
    • יש הרבה סוגים של Databases, הרבה סוגים של Application Platforms - על אמאזון יש לך את הפלטרפורמה של Containers וגם את Managed Kubernetes, ויש את ה - PaaS שלהם - על כל דבר יש בין 2 ל-3 אופציות, כך שהדרישה להתמודד עם סביבה מורכבת קיימת גם סביבת Cloud בודד.
  • אם אתה בונה נכון את ה - Practices של עבודה בסביבות מורכבות - זה חל על Single Cloud וכל Multi-Cloud כמעט באותה צורה.
    • יש עוד Delta של Multi-Cloud שמגדילה את את המורכבות - אבל יש מאחוריה גם את הגמישות
    • יש מקרים בהם הגמישות עולה על המורכבות ויש מקרים בהם המורכבות עולה על הגמישות - וזו נקודה שחשוב לציין.

אמרתם שבאיזשהו שלב, עקב רכישה של חברות וכו’, ה - Multi-Cloud “נכפה” עליכם, אבל עדיין באופן מודע הלכתם לזה בשלב יותר מאוחר. מה הייתה המוטיבציה - Cost? ענייני Redundancy? מה הייתה המוטיבציה ללכת לכיוון הזה?
  • (אורית) אנחנו התחלנו בסביבה שהיא “סביבת Research”, שהייתה מאוד גדולה - והיו לה הרבה מאוד דרישות לאלסטיות (Elasticity).
    • לפעמים היה צורך הרבה מאוד משאבים, והיינו מוצאים את עצמנו לא מצליחים להדביק את הקצב, ומצד שני - בהרבה פרקי זמן היא הייתה עומדת Idle.
    • מצד שני - בדומה להרבה סביבות Research, היא קיבלה עדיפות של “2nd Class Citizen”, ומצאנו את עצמנו בנקודה שבה היינו חייבים לעשות Refresh לסביבה, בין אם זה ב - On-Premise ובין עם באמצעות פתרון אחר.
    • האלסטיות, יחד עם העובדה שזו סביבה שהיא Storage-intensive ו - Compute אלסטי - כל זה מאוד התאים ל Benefits המאוד ברורים שיש בענן.
    • זה הביא אותנו לעשות בדיקה ואיזשהו POC של Evaluation, כי זה היה מבחינתנו הצעד האמיתי הראשון בסביבה אמיתית (ב-Scale גדול) של ענן.
    • אחרי ה-POC הזה ראינו עד כמה זה הקל עלינו את החיים גם מבחינת אדמינסטרציה ומבחינת גמישות
    • בכלל - בתור מנהלת קבוצת תשתיות, אחד הדברים שמתפיקדו של מנהל תשתיות זה להיות Enablers עבור הארגון - להיות מסוגל להגיד “למה כן” ולא “למה לא” ו”אי אפשר” ו”זה יקח זמן”.
    • העבודה שהפכנו להיות היברידיים פתחה המון חסמים - אם אתה רוצה לעשות איזשהו POC ולהביא את החומרה “פנימה לתוך הבית” וזה לוקח זמן ויש Lead Time, אז פה אתה יכול להגיד “בואו נתחיל עם ה-POC ונראה מה נעשה עם הסביבה הזו אח”כ”.
    • היכולת הזו להגיד כן ל - Scenario מאוד רחב של מקרים היא מאוד משמעותית - ועוזרת לחברה להיות הרבה יותר דינאמית, לרוץ מהר, לקפוץ על הזדמנויות עסקיות שאחרת אולי היינו צריכים לסרב להן.
  • (נתי) את מתארת בעצם מקרה של חברה שהיה לה סוג של Private Cloud, ואת בעצם מחברת את ה  -Private Cloud גם כדי להגדיל את הגמישות וכדי לנצל את יכולות האלסטיות של ה  -Cloud, ואני חושב שזה טרנד מאוד משמעותי בארגונים גדולים.
    • השאלה היא מה היה קורה אילו הייתם מתחילים ב - Public Cloud - האם הייתם הופכים אותו ל - Multi-Cloud? 
      • נניח שהייתם “גדלים ב-AWS”, ו-AWS היה בשל - כשהתחלתם היו פערים מאוד גדולים בין מה שהיה אפשר לעשות ב-Private לעומת Public, והיום הדברים השתכללו.
    • (אורי) כן . . אני אולי נתפס כמטיף או “משיח שקר” או מה שלא תרצה להגיד, אבל הבעיה עם Public Clouds מגיעה בשלב ה - Scaling.
    • הכל נורא קל לך ב - Public Cloud וכו’, אבל החשבונית הולכת והופכת כבדה בשלב ה - Scaling.
    • בסך הכל, סטארטאפים מגיעים ל - Scaling בשלב הצמיחה, ואם לא גייסת מספיק כסף בשביל לקחת אותו ולהעביר אותו לחשבון הבנק של ג’ף בזוס (אחלה מודל עסקי, אגב), אז כל שקל חשוב לך, ומדובר בסופו של דבר על חסכון מאוד משמעותי כשמדובר ב Economy of Scale. 
    • חסכון בסוף של מיליוני דולרים, אם לא עשרות מיליוני דולרים, שאתה יכול לחסוך בכל שנה ולהשקיע את זה בלשכור אנשים - זה מאות משרות.
(רן) ננסה למקד את השאלה של נתי - הוא אומר: “נשים לרגע את הכסף בצד ואת האידיאולוגיה גם בצד - נניח שהייתם מתחילים כבר ב-AWS או ב-GCP, האם היית הולך על Cloud נוסף?” האם יש איזשהו יתרון בהוספת Vendor נוסף, או שאם אתה כבר במקום שהוא אלסטי אז תשאר רק ב-AWS או רק ב-GCP וכו’?
  • (אורי) אלסטי לאלסטי . . . אני לא יודע . . .
  • (אורית) אני חושבת שנכון להיום, עדיין רואים הבדלים בין העננים, ועדיין אפשר להגיד לצורך העניין ש - Big Query של GCP הוא Ahead of the game . . .
  • (אורי) אלו Workloads שונים . . .
  • (אורית) ולכן אני כן חושבת שגם כ - Startup, יש מקום לבחון, על בסיס ה - Workflow או המקרה הספציפי שבודקים, איפה נכון לשים את הדברים.
  • אני גם חושבת שבאופן כללי - כן, בעולם ה - Vendor Management (ויש פה Vendor Management), עדיף לך לדעת שאתה יכול לשחק בשני סוגי המגרשים (או בשלושתם) - 
    • זה עניין גם של כמה באמת יש לך Bandwidth לענייני Vendor Management - לא הייתי הולכת על יותר משניים כנראה, כי המחיר הוא כבר גבוה, אבל בהחלט אני חושבת שיש מקום לבדוק את הדבר הזה - יש עדיין הבדלים טכנולגיים בין שני העננים הגדולים (AWS ו-GCP) - יש הבדלים.
  • (נתי) פעם היו אומרים Azure מעניין לראות שהיום GCP נכנס לרשימה של השניים הגדולים, זה שינוי מאוד גדול שהם עברו.
  • (אורית) Azure בדר”כ סופרים את שירותי ה-365 כחלק מה - Cloud וזה יוצר תמונה שונה
  • (נתי) אם נוסיף גם את נושא ה - Performance, שאלת ה - Multi-Cloud היא שאלה דינמית - זה תלוי ביכולות ובאבולוציה ובמה שקיים בכל Cloud.
    • אם היית שואל את השאלה הזו לפני כמה שנים התשובה שלנו הייתה אחת, אתה שואל אותה היום והתשובה היא קצת אחרת - בעיקר תלוי לאיזה סוג בחירה בדיוק אתה הולך לאיזה סוג של Workload אתה מריץ בכל ענן.
    • יש היום איזשהו affinity לכך ש Data Workload רץ טוב ב - GCP ו - Compute רץ טוב על AWS וכל מיני דברים מהסוג הזה. זה שיש זיקה כזו לא אומר שזה באמת קורה . . .
    • בהמשך לזה - “Windows רץ טוב על Azure” וכו’.
  • אני חושב שזה דומה לשאלות ה - Windows vs. Linux בזמנו - אף פעם לא יהיה מצב שבו תוכל כארגון מ -Scale מסויים להגיד שהכל בסדר.
  • סטארטאפ זה סיפור אחר - שם מבחינתי אין הצדקה ל - Multi-Cloud, או שההצדקה גבולית מאוד.
  • הנקודה שציינת (אורית) לגבי הגמישות בשירותים - של BigQuery למשל והיכולות שלו לעומת מה שיש בעננים אחרים שלא מתקרב לזה למשל - זה סוג מסוים של בחירה.
  • אגב - Google בעצמה עוברת תהפוכות ואבולוציה מאוד משמעותית דרך Kubernetes
    • הייתה לי שיחה עם מישהו מאמאזון, והוא תיאר איזשוהי פאראנויה שהפתיע אותי מאוד לשמוע (כי כולנו הסתכלנו על AWS ושאלנו מי בכלל מתקרב אליהם) - הוא אמר שעכשיו עם המעבר ל - Containers, הנכס המרכזי של AWS שהיה כל האופטימיזציה עבור ה - Compute באמצעות VM וכו’, ו - Google בנתה את הכל על Containers, זה הפך להיות “הדור הבא” ופתאום AWS במעיין Catch-up Mode וצריכים לרדוף. GCP התקדמו הרבה יותר עם ה - Containers, יש להם תשתית הרבה יותר משמעותית לניהול כל ה - Cloud
      • לפי הסטטיסטיקות, 90% מה - Workload של GCP רץ על Containers, הם מגיעים ל - Efficiency מאוד גבוה, וAWS פתאום ב - Catch-up, סיטואציה שאף אחד לא יכול היה לדמיין קודם לכן.
  • (רן) אני רואה ש - AWS כבר כמה שנים בונים את הדור הבא, שזה Lambda Functions
    • (נתי) התשובה שלהם עם Lambda זה בדיוק התשובה לדור הבא של ה  -Containers, 
      • אמרו - בואו נייצר שוב מצב שבו אנחנו אלו שעושים Disruption ומובילים והם יצטרכו לעשות Catch-up איתנו.
    • מבחינת אחוזים של Workloads זה עדיין לא קורה . . .
    • (אורי) זה טרנד שעוד לא תפס, לפחות עדיין
    • (נתי) זה באחוזים שוליים לעומת מה שרץ היום על Containers, מסיבות די מובנות - זה שינוי תפיסה מאוד משמעותי.
    • (אורית) אני חושבת ש-Google עשו מהלך מאוד חשוב בכך שהם הוציאו ל - Open Source את Kubernetes, ולמעשה הבינו שיש הרבה מאוד ארגונים שמחפשים את ה - Hybrid ואת היכולת להיות בכמה סביבות - וכיוונו את זה מאוד לשם
    • אני חושבת שזה מהלך שהם התחילו לפני כמה שנים - התחילו ודחפו את זה - וזה מאוד עזר לצמיחה שלהם.
  • (אורי) אני חושב שיש גם כוח מאוד גדול - וראינו את זה עכשיו עם Kubernetes ועם ה - Containers - ביכולת להיות Hybrid, ולשלב On-Premise עם Cloud.
  • (נתי) ואני אולי רוצה במקום הזה “לקלקל קצת את החגיגה” (כדי שלא כולנו ניהיה חסידים של Kubernetes ו - Multi-Cloud . . . ) - יצאה הכרזה של Docker, שמן הסתם גם גייסו עוד כסף והעבירו חלק מהנכנסים שלהם ל - Mirantis במהלך שקצת הפתיע חלק מהאנשים.
    • (רן) רגע, מה הכוונה ב”חלק מהנכסים”? מדובר במוצר שנקרא Data Enterprise, וזה המוצר העיקרי שלהם (Docker Enterprise, שעבר ל - Mirantis).
    • כן . . . יש שאלה עם הרבה קונספירציות מאחוריה, של מה בדיוק קרה שם.
    • אם מסתכלים על כל ה - PR מאחורי זה הכל נצבע בצבעים מאוד חיוביים, אבל מי שמסתכל קצת מאחורי הקלעים ובין השורות רואה שהיה מהלך שבו, החל מ-2017 ועד היום התרחשו משהו כמו שלוש החלפות ב - Leadership של החברה: היזם שעזב, לאחר מכן מנכ”ל שמונה ועכשיו הוחלף אחרי שנתיים - יש שם איזושהי מצוקה, וכל המהלך הזה נראה שבא יותר על רקע של מצוקה ופחות מרקע של “גילינו את האור ועכשיו נלך הלאה”.
    • (רן) אולי Pivot אמיץ, שנראה שנובע מחוסר ברירה.
    • (נתי) הסיפור של Docker צמח על הרקע של Kubernetes, וקרה שם מהלך מאוד מעניין, שנוגע בזוית אחרת למציאות הזו של הטרוגניות.
      • שוב פעם - לפני כמה שנים אמרו ש”Docker יכבשו את עולם” וזה היה ברור - ובא Kubernetes ואכל את העוגה . . .
    • אני זוכר כשדיברתי על זה, והייתה לי גם שיחה עם אורי כהן על זה - אמרתי שהאסטרטגיה של Docker לא יכולה להחזיק, כי בנו פה פירמידה הפוכה: לא יכול להיות ששחקנים כמו Microsoft ו - Google ואחרים יהיו תלויים בגחמות של Docker לגבי מה שהם יעשו ואילו Features ואילו API הם ישברו, כשיש פלטפורמות שלמות שרצות על זה ועכשיו פתאום נשבר להם ה-API כי החליטו להוציא Feature אחד או להוריד Feature אחר, וזה נעשה בתהליך לא מבוקר שאין להן שום השפעה עליו.
      • היה די ברור שהתעשייה תגיב לזה, ושהשחקנים הגדולים לא יהיו מוכנים לזה.
      • זה הפך לגדול מדי - מהר מדי
      • כך ש - Kubernetes שם לזה תקרת זכוכית מאוד נמוכה, של עד לאן בכלל Docker יכולים לגדול - והם נתקלו בזה Heads-on . . . שם פחות או יותר התחיל ה - Down-turn המשמעותי.
  • (רן) רגע פרשנות - מה שאני מבין זה ש-Docker ניהלו את ה - Containers, אבל רק את ה - Containers
    • אם הם חלמו פעם על Docker Compose, שיעשה את את ה  -Orchestration וכל זה, אז זה כבר לא יקרה - כי Kubernetes עושה את זה פי 10 יותר טוב.
    • אף אחד לא הולך להשתמש ב - Docker Compose או ב - Docker Enterprise, פשוט כיוון שיש מוצרים הרבה יותר טובים.
    • כך ש”תקרת הזכוכית” הזו שאתה (נתי) מדבר עליה אומרת “אתם תשארו ברמת ה - Containers, וזהו”.
      • ובהצלחה אם ה”איך לעשות מזה כסף” . . .
  • (נתי) בדיוק - ומי שמכיר את עולם ה - Open Source יודע שזו בעיה שמאוד לא פשוט לפתור, ולא רבים מצליחים לפתור אותה - זה עולם מורכב לכשלעצמו של איך לבנות מוצר Open Source שגם זוכה ל - Adoption אבל גם אפשר לעשות עליו Monetization. 
    • אנחנו מכירים את הסיפורים המוצלחים - אבל יש גם הרבה שלא מצליחים, וזו משוואה מאוד מורכבת.
  • אני אגיד משהו אחר - מה שאני כן רואה, אם אני צריך לתת איזושהי תחזית ל - 2020 וקדימה - גם Kubernetes לא חף מבעיות . . . גם פה אנחנו מתחילים לראות איזושהי התעוררות מהחלום.
  • אם מתארים חלום רטוב של פלטפורמה שעושה המון דברים וקסמים, אבל היא Overkill עבור לא מעט דברים וצריך גם להודות בזה.
  • ברברסים שמעתי על זה הרבה, ובפודקאסטים שאני שומע הרבה מעולמות הסטארטאפים מדברים זה בציניות, עם שאלות כמו “למה כדי להרים את מה שאני עושה צריך את כל זה?”
  • (נתי) יש את הבדיחה על איש DevOps שנכנס לבאר, לקח את הברמן, שכפל אותו ל-100 - ואז הזמין בירה אחת . . . סוג של אנלוגיה לכך שאנחנו היום עוברים ל -microServices ומוצאים את עצמנו עם הרבה מאוד Services ודברים שבסוף את אומר “זה @$# Web Application - זה פשוט מחזיר HTTP Request ולא צריך להיות מורכב מ-20 Services רק בשביל הדבר הזה, כשכל אחד עושה איזשהו ביט קטן.
  • יש גם את הצד הזה, ואני חושב שמה שחסר פה זה דווקא הסכום של העניין - יש הרבה מאוד מקרים שאני נתקל בהם שבהם יש כמה Containers ואני בסך הכל רוצה לנהל אותם בצורה פשוטה, אז למה אני צריך את כל הדבר הזה שקוראים לו Kubernetes? - הארכיטקטורה וה - Pods וה - Networking וה - Load Balancers. . .
  • (אורי) זה לא משהו שב - Public Clouds, ה - Managed Kubernetes, ייתן לך? 
  • (נתי) אני חושב שגם אם הוא נותן, זה מפשט את האופרציה של ניהול Kubernetes, אבל יש את עניין הארכיטקטורה שאני צריך . . .

(רן) יש שתי “מורכבויות” ב - Kubernetes - הראשונה היא לתפעל את ה - Cluster, שזה משהו שכולכם כבר מכירים כי אתם עושים את זה ביום-יום ואף אחד לא עושה את זה בשבילכם - וזה מורכב, וזו אולי בעיה שה - Cloud Providers יכולים לפתור במידה מסויימת.
המורכבות השנייה זה השימוש - והלימוד של ה - Concepts: מה זה Pod? מה זה Staeful State? וכו’ - וזו מורכבות שלא בהכרח כולם חייבים להתמודד איתה.
אני חושב שיש גם מורכבות נוספת, שהיא מה “נכון” (“מספיק בוגר”) כדי להכניס ל - Kubernetes, ומה לא - לצורך העניין: Workload שהוא Stateful לעומת Workload שהוא Stateless או סוגים שונים של Schedulers  שיכולים לרוץ מעל Kubernetes.
יש פה כמה מורכבויות, ואני חושב שנתי צודק בזה שהוא אומר שלא כולם צריכים Kubernetes.
  • (אורית) החיוך על פנים שלי עכשיו זה בגלל שאנחנו מתכוונים לראות, אחרי שיש לנו Stateless Services שרצים על Kubernetes - לראות האם אנחנו רוצים לגשת ולנעוץ את השיניים בבעיה הבאה - שזה באמת Stateful Services, ואפשר לעשות פודקאסט שלם רק על הדבר הזה . . .
  • אנחנו בכל פעם חוזרים בסופו של דבר לאותו הנקודה, וזו שאלה של Scale - כשאתה רץ ב - scale קטן זה באמת overkill, ולכן אני לא חושבת שיש פה איזשהו Cookie-cutter שמתאים לכולם.
  • זה נורא נחמד, וכולם רוצים את ה - Buzz-words, ואנחנו תמיד רואים בתעשייה את המהנדסים שהולכים לטכנולוגיות רק בגלל שזה מגניב - ולאו דווקא כי יש לזה הצדקה, או use-case או הצדקה של סיבוכיות.
  • מאוד צריך להיזהר מה - Pitfall הזה של “זה מגניב”, כי זה לא בהכרח נותן לך איזשהו Value אם אתה ב - scale קטן.

אמרתם שיצאתם ל-Cloud ב - Scenario של Data Science - האם זה לא Workload שהוא Stateful אצלכם?
  • (אורית) ה - Workload הזה ספציפית לא רץ ב - Kubernetes.
  • אנחנו יצאנו ל - Cloud, אבל עשינו Scenario שבו אנחנו לקחנו את ה Serving Stack שלנו, אחרי שהעברנו אותו לחלוטין ל Kubernetes בסביבת ה - On-Premise שלנו, וכן עשינו את מה שנתי כינה כ”אוטופיה” - לקחנו workload שרץ בכמה Data Centers במקביל, כשאחד ה - Data Centers האלה הוא במקרה “ענני”, על Public Cloud, והעברנו Traffic בצורה שהיא לחלוטין Seamless בין ה - Data Centers השונים ובין הסביבות השונות.
  • (נתי) מסיבות של Latency?
  • (אורית) רצינו לראות (1) האם אנחנו יכולים לשפר Latency לאיזורים מסויימים ו - (2) משמעותי יותר: כשאתה עובד בסביבה שהיא On-Premise, אתה משקיע המון אנרגיה ב - Capacity Planning.
    • אתה מחזיק כל הזמן Buffers . . .
  • (נתי) אז עדיין המרכז היה , נניח, On-Premise, ובעצם השתמשתם ביכולת של ה - Public Cloud לצורך Scale-Out?
  • (אורית) בדיוק - לצרכי Overflow ו-Scale-Out.
  • מה שאורי אמר מאוד נכון - כשאתה מתחיל To Scale-out ב-Scale גדול לתוך הענן, אתה גם נתקל בעלויות מאוד גדולות, וגם ב Scale מאוד גדול יש הרבה Complexity של Scale בענן, זה לא seamless . . .
  • (נתי) את מדברת על Serving, לא ה - Data?
  • (אורית) בתוך ה - Serving שלנו יש גם Data וקסנדרות (Cassandra) . . .
  • (נתי) ואת הקסנדרות לא ניידתם?
  • (אורי, אורי) ניידנו! גם את הקסנדרות . . .
    • (אורית) ודרך אגב - זה עבד במשך סדר גודל של חודשיים בלי בעיות ובלי תקלות - הסיבה שלא המשכנו עם זה היא לחלוטין כספית.
  • (אורי) המטרה שלנו הייתה להוזיל עלויות, לנסות נוכחות קטנה ב - Cloud, שיהיה Active-Active ותיהיה בה את כל הפונקציונאליות, וברגע של Disaster או Spike - להיות מסוגל To scale it out
    • לכאורה זה אמור לאזן. לכאורה . . .
  • (אורית) ה - Traffic של Outbrain מאוד מושפע מאירועים חדשותיים, ומאחר וזה דבר שאי אפשר לצפות אותו . . .
    • אם היינו יכולים אולי היינו עושים דברים יותר משמעותיים לעולם מהמלצות תוכן . . .
  • אבל אי אפשר לצפות אותו - ולכן אנחנו בסביבת On-Premise צריכים כל הזמן לנהל מספיק Buffers ולדאוג שיש לנו מספיק Buffers עבור Spikes שכאלה.
    • ה - Buffers האלה ביום-יום לא נמצאים בשימוש, ועולים הרבה כסף.
  • (נתי) אבל אמרתם שבסוף זה לא הוכיח את עצמו כספית . . . יש כאן סתירה שאני לא מצליח להבין . . .
  • (אורית) לכן הגענו לפרוייקט הזה - אמרנו “ככה וככה עולים לנו ה - Buffers האלה - אם עכשיו נרוץ בענן, כמה יעלה לנו ה - Workload הקטן בענן (המינימלי, ב - Ongoing) ובהערכה גסה, כשנצטרך לגדול - כמה זה יעלה לנו?”
    • אני יכולה להגיד שאחרי ה-POC, כשכבר היה לנו את המספרים האמיתיים של כמה זה עולה - לא הערכות, לא Guess-timations, גם ה- Workload הקטן הזה עלה לנו פי כמה מה-Buffers הגדולים שאנחנו מחזיקים ב-Data Center שלנו On-Premise. 
  • (נתי) כמה מזה היה ה-I/O (הגישה ל-Data)?
    • הגישה ל-Data זה החלק הקטן, ההחזקה של ה-Data... יש כמה אתגרים כשאתה מדבר על Scale גדול  -
      • דבר ראשון - גם בענן, אתה צריך להחזיק את ה-Data  על SSD, אתה צריך את ה-Data “חם”, על High Performance Storage.
      • ה-High Performance Storage הזה הוא מאוד יקר, והסיבה לכך שאתה חייב לעשות זה היא שכשתרצה לגדול, בלי הודעה מראש - הוא צריך להיות זמין, אתה לא יכול להתחיל לנייד אותו מסוג Storage כזה לאחר, וזה אחד המרכיבים של העלות הגדולה.
      • (נתי) זאת אומרת שבעצם - על מנת לנייד את ה - Compute הייתם צריכים להחזיק הרבה Data “חם” באופן קבוע, ואז המיצוע לא באמת עבד.
      • (אורית) האתגר השני הוא שלהחזיק Scale נמוך של Compute בענן זה בסדר - אבל כשאתה צריך בתוך דקות, או בפחות מדקות, לעבור ל-Scale מאוד גבוה, אז בהרבה מקרים אתה לא יכול להישאר בתצורה של Zone בודד (או של Region בודד, כל ענן וההגדרות שלו) . . .
      • (אורי) ואז אתה צריך לשכפל את ה- Setup שלך גם ל-Zones או ל - Regions . . . ועוד פעם להעביר את ה - Data  . . .
      • (אורית) לא בהכרח להעביר את ה-Data אלא מראש לבנות אותו כ-Multi-Region, מה שהופך את ה - Complexity ליותר מורכב - כמו שאמרנו, ברגע שאתה מתחיל להיות גדול בענן, גם שם יש Complexity, וה - Complexity של Multi-Region הוא לא טריויאלי - הוא גם משפיע על עלויות, זה בהחלט נכון.
      • (אורי) אז הניתוח הצליח - והחולה מת  . . .
      • (אורית) מאוד נהנינו מהפרויקט . . .
      • (אורי) טכנית - זה דבר אפשרי, ו - Kubernetes מאפשר את הדבר הזה ביתר קלות - אבל אם ניסינו להשיג הוזלה מבחינת Costs . . .
  • (נתי) אז אני רק אגיד לפחות את ההבנה שלי של למה זה יצא בסוף יותר יקר - כי בסוף מה שהעלה את זה הוא ה - Data
    • הייתם צריכים להחזיק Data “חם” בהרבה מקומות והוא היה צריך לרוץ באופן קבוע ולא באופן אלסטי בדיוק.
    • זה יותר קשה לעשות “אלסטי” ב-Data, ולכן המיצוע של הפניות של ה - Compute, באופן יחסי ל-Cost הקבוע שנוצר כתוצאה מזה שהחזקתם הרבה Data חם בהרבה מאוד מקומות, הביא למצב שבוא העלויות של ה-Data והשכפול של ה-Data כבר היו הרבה יותר גדולות מה-Buffers שלצורך העניין הייתם צריכים להחזיק ב-Private Cloud.
  • (אורית) נכון מאוד - זה העלויות ה - Data והצורך שלך להחזיק אותו ב-Storage שהוא High-Performance.
  • (נתי) זו הסיבה שאמרתי שבהרבה פעמים הניוד הוא אוטופיה - כי בסוף יש גם Data, ומעטים המקרים שבהם אתה מעביר רק Compute ומנייד אותו בכזו קלות.
    • ה-Data מייצר בסוף Affinity מאוד משמעותי.
  • (אורי) אגב - עשינו פה פודקאסט, עם חברה מיוקנעם שעושה Storage (פרק 372 עם Zadara, כן - ז’ באדר א’), שבעצם באים “לתת (פתרון) Storage מבוזר” על פני כמה עננים וכו’.
    • הם, את ה - Storage שלהם, מחזיקים מחוץ לענן.
    • (נתי) ב-Workloads כאלה אתה חייב את זה, אחרת אתה לא עומד ב-Scale.
    • (אורית) אל תשכח שגם אצלנו (Outbrain), הגענו עם איזושהי ארכיטקטורה שהיא Pre-defined - הרבה לפני שבכלל חשבנו על Multi-Cloud - אם אתה יכול מראש, בתחילת הדרך, ליצור ארכיטקטורה שבה ה-Data שלך הוא דבר מרכזי, ויש לך מעיין לוויינים לזה . . . זה משהו שעבור חברה שהיא בתחילת הדרך הייתי ממליצה לחשוב עליו מההתחלה. 
    • גם אם זה קצת יותר מורכב בהתחלה, זהי יהיה שווה לאורך זמן
  • (אורי) יש ארכיטקטורות מעניינות, שבהן אתה בונה On-Premise את ה-Data Center שלך, שמחזיק את ה-Data מאוד קרוב פיזית ל-Data Centers של ענן (ציבורי), ואז אתה”נושם” אליהם ב-Latency מאוד נמוך.
  • (נתי) באופן מעניין, היום גם העננים הציבוריים עצמם מציעים Private Cloud בדיוק בתצורות כאלה - עם Network Pipe מאוד מהיר ל-Private Cloud שהם מציעים, ואז באמת יש את ה-Benefit הזה של האלסטיות הזו שאתה מדבר עליה. יש גם את עניין ה-Performance . . .

(רן) אני חושב שאחת השאלות שתמיד עולה, בהתחלה בהקשר של VM, בהקשר של Containers ושל Orchestration מעל Containers היא - “אוקיי, בהתחלה אני מרוויח את כל הדברים הזוהרים והבוהקים האלה, אבל מה אני מפסיד?”
  • האם אני מפסיד Performance? האם אני מפסיד עלות? דברים כאלה.
נתי - תוכל לספר על ניסוי מעניין שעשית בהקשר של Performance, בעיקר של Data . . .
  • נכון, ב-Network למעשה, אני קורא לזה I/O-Intensive Workloads, שזה למעשה Workload שדורש משאב שהוא או I/O או Storage - שניהם הם למעשה סוג של I/O.
  • בעצם הרעיון היה לבוא ולהגיד שעד היום, כשמסתתכלים על Kubernetes, בדרך כלל תמצאו Stateless Services רצים בסביבה הזו, ופחות Stateful Services, כי גם Kubernetes בעצמו מחליט מתי להוריד ומתי להעלות Instances, ולנייד אותם - זה חלק מתפיסת הארכיטקטורה שלו.
  • כשמדובר על Data, זה לא בדיוק דברים שאתם רוצים או מצפים שיקרו באופן אוטומטי.
  • מעבר לזה - יש כל מיני עניינים של אבסטרקציה של Infrastructure, שבסופו של דבר ברמה של I/O, כל ביט כזה שעכשיו צריך לעבור עוד שכבה - כשיש הרבה ביטים זה מתחיל להיות Overhead משמעותי מאוד, שיכול להגיע ל-20% במקרים מסויימים.
  • התרגיל שעשינו פה היה שיתוף פעולה עם אינטל ועם חברה שקוראים לה F5
    • בעולם ה-VM הבעיה הזו כבר חצי-נפתרה עם כל מיני אקסלרציות של חומרה
    • כיוון שPerformance זה נושא רחב, והתעסקנו בעיקר עם הנושא של ה-Performance שבין ה-Container לבין מערכת ההפעלה ול-Hardware, “החלק התחתון של הגרף”.
      • לא איך מניידים Workloads ולא איך מטפלים בזה ברמת ה-Scheduling.
    • הרעיון היה לבדוק איך אני יכול לתת אופטימיזציה של Performance, אבל בלי לייצר מצב שאתה כמפתח צריך לכתוב את האפליקציה אחרת.
    • ואז בעצם אינטל בנו כל מיני סוגים של Drivers ל-Kubernetes, ויש ב-Kubernetes אפשרות של Feature-Tagging - אתה יכול לסמן Nodes בתוך ה-Cluster שיש להם יכולות מסויימת, ויש את מה שנקרא Feature Discovery - כדי שלא תצטרך לעבור על כל Node ו”לצבוע” אותו, אז כשהוא רץ עם ה-Driver הזה, ה-Driver מוסיף את התיוגים הללו לכל Node, באמצעות זה שהוא” מתחקר את החומרה”.
    • ואז - חושף החוצה ש”ל-Node הזה יש יכולות כאלה וכאלה” - וכשאני מבקש מ-Kubernetes להריץ Workload אני יכול לבקש להריץ את זה על Nodes שיש להם את התכונות האלה.
    • בדרך הזו, אני יכול מצד אחד “לנרמל את האופרציה” ומצד שני - לנייד משאבים למקומות שבהם הם ידעו לנצל את ה-Hardware המיוחד שנועד לזה.
    • אני יכול לבנות Cluster של Kubernetes עם Nodes שהם I/O Intensive, ויש להם יכולות Hardware טובות יותר - ויש Nodes שהם לא I/O Intensive, וזה יכול להיות באותו ה-Cluster, בלי לפצל לשני Clusters, וזו הנקודה שהייתה משמעותית פה.
    • באמצעות ה-Feature-Tagging אנחנו יכולים לנייד את המשאבים האלה - והראנו שאנחנו יכולים להגיע עד כדי x2 על ה-Performance, במקרה הזה עם NGINX (על I/O-Intensive workload), ואני מעריך שניתן ב-Storage, עם SSD וכו’, להגיע אפילו ליותר מזה.
    • גם “רק” פי 2 - תחשבו על זה, זה המון, לא מעט בכלל.
    • במקרה הזה זה היה Workload שהוא SSL - רצינו לחסוך את ה-Overhead שנדרש כדי לעשות הצפנה של SSL על user-space, על מערכת ההפעלה (ובמקום זה נעשה ע”י Chip).
    • יש היום הרבה דברים - בגלל שהכל הופך להיות Software, אנחנו נכנסים לעולם הזה של איך לעשות את ה-Match-making בין Software ל-Hardware, ויש הרבה מאוד דברים מדהימים שמתרחשים בתחום הזה, וזה כנראה נושא לשיחה נפרדת.
    • זה הוכיח את עצמו - וההוכחה הייתה שכן אפשר לאורך זמן להריץ Workloads שלא רצים היום ב-Kubernetes, גם עדיין ב-Kubernetes.
  • (אורי) אינטל בכלל הולכת ומעבירה “שימושים” שהיום האפליקציה או ה- User space ונעשה על ה-CPU - אל כרטיס הרשת.
    • זה נראה טרנד שרץ בכלל, הם לא התחילו את זה.
  • (נתי) אנחנו נכנסים לאזורים שאותי אישית מעניינים כי אני מגיע מרקע של חומרה, אבל יש גם את הנושא של FPGA - למי שמכיר, עד היום על מנת להגיע לביצועים מאוד גבוהים חברות היו בונות צ’יפים משל עצמן
    • צ’יפים ל-Firewall, צ’יפים לראוטרים (כמו סיסקו וכו’) - ומתכננים ממש קופסאות נפרדות לדבר הזה.
    • אז FPGA זה דרך לייצר Programmable-Chip - צ’יפ שבעצמו הוא מתוכנת.
    • דמיינו מצב שבו אתם יכולים ללכת לראוטר שלכם בבית - ולשנות את האלגוריתם של איך הוא מבצע את ה-Routing - פשוט באמצעות Kubernetes לצורך העניין, עד לרמות האלה.
  • אז העולם הזה מתפתח מאוד באיזורים האלה - ואינטל מנסה לייצר הרבה מאוד יכולות שיאפשרו את הדבר הזה.
  • עוד פעם - האתגר Kubernetes - הרתיעה של חברות משימוש בפיצ’רים האלה הוא שאני לא רוצה לבנות פיצ’רים שירוצו רק על אינטל ואז ללהיות נעול על אינטל.
    • הרי יש את ARM ויש את גם את AMD שפתאום חוזרים לחיים ומראים פתאום יכולות יותר טובות - אני לא רוצה להיות נעול אלא רוצה גמישות, והלקוחות שלי דורשים גמישות.
    • אז Kubernetes מאפשר את הגמישות הזו, ואז אני יודע לנצל את התכונות כשהן קיימות - וכשהן לא קיימות אז אולי לנצל לחליפין תכונות אחרות, וזה ההקשר ה-Kubernetes-י של העניין.

אורית - אתם מתעסקים ב-Scheduler? נותנים הנחיות? מתייגים את ה-Nodes שלכם, או שהכל Flat ו”תעשה מה שאתה מבין”?
  • אנחנו עכשיו גם כבר מתייגים דברים, ונותנים Priorities ל-Services שונים, גם בקטע של Scale וגם בקטע של למצוא את המקום המתאים בתוך ה-Cluster,
  • וגם לדוגמא ה-Clusters אצלנו הם על חומרה שהיא הטרוגנית - לא הכל אותו הדבר, וזה הופך להיות משמעותי יותר ויותר.
  • אני חושבת שזה חלק מהאבולוציה - אתה מתחיל עם איזשהו Cluster ולאט-לאט אתה גדל איתו, ומשכלל אותו.

וזה עדיין הכל Workload שהוא Stateless - אני מניח שזה יהפוך להיות Stateful אז בכלל יהיו שם דינוזאורים מסוגים שונים . . .
  • תיהיה חווייה slightly smiling face 

הגענו לסיום. תודה רבה! היה דיון מעניין על Kubernetes וחיות אחרות.

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

אין תגובות:

הוסף רשומת תגובה