יום ראשון, 7 בנובמבר 2021

425 Centralized policy management for K8s


שלום וברוכים הבאים לפודקאסט מספר 425 [?To Early] של רברס עם פלטפורמה! היום ה-1 בנובמבר 2021, השעה היא פחות או יותר 2100 בערב ואנחנו נמצאים באולפן הביתי שלנו אשר בכרכור - אהלן אורי! הקדמה ארוכה . . .
היום אנחנו מתכבדים לארח את שמעון - אהלן שמעון! - (שמעון) אהלן, כיף להיות פה, תודה רבה - (רן) איזה יופי שבאת וברוך הבא . . . - (שמעון) עשיתי את המסע מתל אביב, אני בטח לא היחיד פה שעולה לרגל . . .  - (רן) בסוף עוד תקנה פה בית . . . (אורי) . . . והצטרפת ל-425 הרגלים . . .


(רן) אז שמעון - ברוך הבא! שמעון מחברת Datree, והיום אנחנו הולכים לדבר בעיקר על Kubernetes ועל איך עושים רגולציה למפתחים, אבל תיכף נדבר על זה בצורה קצת יותר . . .
  • (שמעון) זו מילה נוראית . . . 
(רן) בקטע טוב!  . . .  איך בעצם שומרים על Policy שפוי, ככה שה-Production שלנו לא יפול ויתרסק - כשאנחנו מדברים ספציפית על Kubernetes, אבל אולי גם נכליל את זה.

ולפני שנצלול לנושא - נושא עמוק וטכני ומעניין - ספר לנו קצת עליך, שמעון:
  • (שמעון) נעים מאוד, קוראים לי שמעון, אני בן 33 מתל אביב
    • מה שנקרא “התקנתי את הלינוקס הראשון שלי” בגיל 12, ומאז התאהבתי ב-Open Source - אני זוכר, זה היה אז Red Hat 6 . . . 
    • לאחר מכן, פתחתי את החברה הראשונה שלי בגיל 15 - בתחום של Web Hosting ושרתי משחק [Game Servers]
      • זה בתקופה שלפני ה-Cloud . . . .
    • ו-Fast Forward: 
    • ולפני שפתחנו את Datree, הייתי ה-General Manager של חטיבת פיתוח התשתיות של Iron Source - היה מאוד מעניין לעשות Scale לחברה מ-30 עובדים ל-1,000 עובדים, עם תשתיות פיתוח ל-400 מתכנתים.
      • ושם הרגשתי הרבה מאוד מה-Challeng-ים שאנחנו פותרים היום ב-Datree.
(רן) אוקיי, אז אתה אומר שגדלתם מ-30 ל-400, פחות או יותר?
  • (שמעון) מ-30 ל-1,000 - זה בכללי, עובדים; [מבחינת] מתכנתים הגענו ל-400, אני חושב.

(רן) בסדר, אז 400 מפתחים עובדים כנראה על Cluster די גדול - ומישהו צריך לנהל את ה-Cluster הזה ולדאוג לזה שהוא יהיה “בריא” - וכנראה שיש כמה Cluster-ים כאלה. אולי לצערך או לשמחתך - זה היה התפקיד שלך, בין השאר . . . או שאתה ניהלת את הכוח שעשה את זה.
  • (שמעון) כן . . . .שמע, אתה יודע - בחברה, לצורך העניין, כמו Iron Source, יש לך הכל: ECS ו-Fargate ו-Kubernetes ו-EC2 רגיל ו-Bare Metal באיזה Co-location . . . . יש הכל 
    • אז באמת מהבחינה הזאת, יצא לי לעבוד עם הרבה מאוד סוגים של תשתיות.
  • אגב - גם AWS וגם GCP וגם Azure, כי אתה בסוף  . . . 
    • היה לנו גם GitHub, גם GitLab וגם Bitbucket - לא כי רצינו, אלא כי אתה רוכש חברות ודברים נכנסים . . .
    • (אורי) Iron Source גדלה הרבה מרכישות, ו . . .
    • (שמעון) נכון - ואגב, זה היה אחד מה-Challenge-ים, שאין אחידות - הכל  . . . אני לא אגיד “ג’ונגל”, אבל “רב-גוני” . . . .
    • (אורי) אהה . . . 
    • (רן) ג’ונגל . . . ג’ונגל.
  • (אורי) Iron Source, יאמר לזכותם, ואולי זה גם חלק מהיופי של לעשות רכישות ולתת לכולם להמשיך לרוץ קדימה . . . 
    • (שמעון) חד משמעית, זה היה מקום מדהים - מאוד מאוד שמחתי לעבוד שם והיו Challenge-ים מאוד מאוד מעניינים.
  • ובאמת ככה יום אחד התעוררתי - ובלילה, אחד המתכנתים עשה טעות והכניס Misconfiguration שהגיעה ל-Production . . . 
    • זה קרה פה לכל המאזינים, כנראה - מ-Secrets שדלפו לאיזשהו GitHub Repo או Misconfiguration, בין אם זה Kubernetes או -EC2 או לא משנה במה אתם משתמשים - וזה הגיע ל-Production.
    • וזה בסדר - אני כל הזמן עושה טעויות, אנשים טועים, אבל אחד ה-Challenge-ים הכי גדולים היה “אוקיי, סבבה - Fool me Once זה בסדר, Full me twice זה בעיה שלי . . .”
      • איך אני אגרום עכשיו ל-400 מתכנתים לא לעשות את אותה הטעות שוב.
(רן) אה, אין שום בעיה - שולחים אימייל! : “חבר’ה - בבקשה לא לעשות Misconfiguration!”
  • (שמעון) אתה צוחק, אבל אני ראיתי הרבה ארגונים ששולחים מייל . . . “חברים, מעכשיו משתמשים בגירסא הזאת, מעכשיו משתמשים ב-Container-ים האלה”.
    • מן הסתם, זה די מגוחך וזה לא עובד.
  • ניסיתי כל מיני דברים . . . ניסיתי את ה-Email . . . 
    • אני מאוד פעיל בקהילות
    • אני אחד מה-Co-Organizers של CNCF Tel Aviv
    • אני AWS Community Hero, אז אני מוביל את ה-Meetup הכי גדול בעולם של Amazon . . .
      • יש לנו 8,000 אנשים
  • אמרתי בואו נעשה Meetup! 
    • עשינו Meetup, הסברתי על Secure Development ומה לעשות ואיך ולמה - אבל ברור שזה לא עובד
    • זה חייב להיות in-flow ב-Development Process של המפתחים . . .
(אורי) דרך אגב - יש מצב שאתה Community Hero בגלל שמישהו עשה טעות בקונפיגורציה, ודרך זה AWS נותנת לך את התארים . . .
  • (שמעון) יכול להיות . . .
(רן) הייתה פעם סדרה, אני לא יודע אם אתם זוכרים, בשם “גיבורים בעל כורחם” . . . אז הנה - דוגמא.
(אורי) זה בהמשך ל-Darwin Awards . . . 
(רן) לא, “גיבורים בעל כורחם” הייתה סדרה אמיתית, בדרך כלל על חיילים שהגיעו לכל מיני מצבים מאוד קשים ואז נאלצו להראות את הגבורה שלהם - אז כמו שהם לא בחרו להיכנס לשם, גם אתה לא בחרת להיכנס לשם אבל יצאת בגבורה . . .

(רן) אוקיי, אז Kubernetes - למי שלא היה באיזור הזה בשנים האחרונות - Kubernetes זה Cluster Management, או Orchestrator יותר נכון. 
בעצם, אם יש לכן תוכנה שרצה בתוך Container - נניח Docker, לא ניהיה ספציפיים - ויש לכם אלפים כאלה, אז צריך משהו שינהל את אותם - שירים אותם, שיעשה להם Healing, שיפרוש אותם, שישים את הגרסאות הנכונות וכו’ - ו-Kubernetes הוא זה שעושה את זה.
עכשיו, למי שעדיין מכיר Kubernetes - כדאי שתכירו YAML או JSON - בעצם, Kubernetes פועל ע”י קבצים, קבצי-ענק לפעמים, של JSON-ים או YAML-ים שבאמצעותם אתם מקנפגים (Configure) - אתם אומרים “את ה-Product הזה תשים פה”, “את ה-Service הזה תשים שם” וכו’. 
ואז נשאלת השאלה- ?What could go wrong
  • (שמעון) אז אני חושב שאולי באמת נדבר על המהפיכה שקרתה פה, כי אני חושב שזה משהו שהוא בקנה מידה של המצאת ה-VM, לטעמי.
  • כי אנחנו חיינו גם - אז באנו ופתאום הגיעו ה-Cloud-ים ואז היה את ה-API של AWS ואת ה-API של GCP ואת ה-API של איזשהו Bare-Metal שאתה משתמש - וניהיה פה מגדל בבל.
  • ואז קמו והקימו את ה-Cloud Native Foundation, את ה-CNCF, ואמרו: “חברים, בואו נעשה שכבה אחידה, שנוכל לדבר בינינו” - ותריץ את זה על Bare-Metal או AWS או GCP או Azure או איפה שתרצה
    • אבל שתיהיה לנו שפה אחידה - כי זה לא הגיוני שאנחנו, בשביל לפתח מוצר, צריכים לתמוך בכל כך הרבה דברים.
  • עכשיו, כשעשו את זה - זה כבר היה בתקופה שהיא יחסית מאוחרת, ויכלו לבוא ולהכיל את ה-Modern Practices בתוך זה
    • אז למשל, בתוך Kubernetes אין UI שאתה יכול לעשות לו Launch Instance, פשוט אין דבר כזה
    • אין שום כפתור שאפשר ללחוץ - יש רק קבצים, לצורך העניין YAML-ים, שלוקחים ועושים להם Apply - ובעצם שולחים אותם לשרת ואומרים “היי! הנה ה-Instructions set של מה שאני רוצה שיקרה!”.
    • ואני חושב שזו מהפכה - כי זה מביא אותך לעולמות של GitOps, זה מביא אותך לעולמות שהכל מתועד, על כל שינוי שקורה אתה יכול לדעת מי שינה אותו ולמה שינה אותו ואיך להחליף אותו
    • וזה באמת שם לנו Even Playing Field מסויים - שלטעמי זה ממש הדור הבא . . . . לא רק לטעמי - ניתן לראות מה קורה בעולם.

(רן) זה למעשה כלי  שנותן לך לתאר את סביבת ה-Production שלך בצורה . . . כקונפיגורציה (Configuration), בצורה שהיא דיסקרפטיבית (Descriptive) - אתה לא צריך להריץ Script-ים כדי שיעבירו אותך למצב הזה, אלא אתה פשוט אומר “הנה, זה המצב - תעשה Apply, תכיל את זה” - וזה נשמע כמו פתרון מצויין, אבל עדיין יש לי תחושה שיש פה כמה צרות שמתחבאות פה בפנים . . .
(אורי) יש תמיד את המתח הזה, בין האם אני עושה UI ומאחורי ה-UI אני יכול לשמור על . . . אני יכול להפעיל חוקים או למנוע אפשרויות מסויימות ב-UI - ואז זה שומר עלי; או שאני נותן לעשות את ה-Description באמת בקובץ ועל הקובץ הזה יש לי בעצם Audit של מי עשה ומה עשה ואני יכול לתחקר אחורה - אבל זה הכל שאלה של  . . .
  • (שמעון) Flexibility? . . .
(אורי)  . . . האם זה מניעה או האפשרות אחר כך לתעד . . . או Full Flexibility והיכולת לתחקר אחורה.
  • (שמעון) Simplicity vs. Flexibility, אני קורא לזה . . .
  • ובאמת, חד-משמעית, הלכו All-in על Flexibility - מה שמוריד את ה-Simplicity פשוט לאפס . . . 
    • ובדיוק מה שדיברנו פה - זה מביא להמון המון בעיות.
  • אבל לפני שניכנס לבעיות ספציפיות ב-Kubernetes, אני חושב שגם מאוד חשוב לדבר על עוד Transition אחד שקרה - וזה שבהרבה ארגונים התחילו לשבור את החומה . . . 
    • אם לפני כמה שנים שברנו את החומה של של ה-QA ושל ה-Dev, אז היום שוברים את החומה של ה-Ops ושל ה-Dev
    • יש לנו את העולם של לפתח בצורה אג’יילית (Agile) ו-DevOps-ית - ובהרבה ארגונים הולכים או עשו “You built it - You run it - and you operate it”  . . .
      • “אני, ה-DevOps, לא אקום בארבע בבוקר כי אתם כתבם באגים - אתם תקומו בארבע בבוקר ואתם תסדרו את זה”
    • עכשיו, מן הסתם יש לזה יתרונות, כי זה נותן לנו Speed of Delivery, אתה לא צריך לחכות לאף איש DevOps, אתה לא צריך להיות תלוי באף אחד, יש לך Full Ownership
      • מצד שני . . . 
(רן) זה נותן Accountability, שזה דבר מאוד חשוב . . . אתה אחראי: אתה עשית פאשלה, אז אתה גם אחראי לתקן אותה.
  • (שמעון) חד-משמעית - אבל מצד שני . . . .
(אורי) וואי, אתם מדברים מה-זה-2015 . . . 
(רן) כן, אנחנו רק משחזרים את ההיסטוריה . . .
(רן) . . . תיכף נגיע ל-2021 . . . 
  •  (שמעון) . . . ומנגד, מן הסתם, וואלה - אולי אני ה- Java Payment Engineer  הכי טוב שיש, אבל מה לי ול-Docker-ים? מה לי ול-Kubernetes? אני לא מומחה בדבר הזה, ופתאום אני נאלץ לבוא ולגעת בדברים האלה, שאני לא כל כך מבין בהם הרבה.
  • וגם לא הגיוני לצפות עכשיו מכל מפתח Java - או לא יודע, כל מפתח בכלל - שיהיה Expert תשתיות של Kubernetes, זה פשוט לא  . . .
(אורי) או שלפחות יהיה מודע לתשתית . . . 
  • (שמעון) נכון.

(רן) אוקיי, אז פה אנחנו מתחילים לראות את הבעיה, זה קצה הקרחון . . . בואו נצלול פנימה, נראה כמה קירות בקרחון  הזה.
  • (שמעון) אז בוא ניכנס יותר עמוק לעולם הבעיה ב-Kubernetes ואז נדבר על עולמות הפתרונות השונים.
  • אז באמת קראנו מאות פוסט-מורטמים (Post-Mortem) של Outages ב-Kubernetes - ואני חייב להגיד שרוב הטעויות . . .
    • ואגב גם ניתן לקרוא היום - למשל State of Security Report של Red Hat 2021, מראה שבאמת בכל הארגונים ה-Number 1 Concern זה Misconfigurations . . . .
    • זה לא Security incidents ולא שיפרצו לי - זה שאנחנו נדפוק את עצמנו . . . 
    • בגדול, זה ה-Number 1 Challenge עכשיו . . .
  • ומה שקורה זה קצת מה שדיברנו - בגלל ש-Kubernetes בנוי ל-Flexibility, אז אני יכול לעשות הכל - 
    • אבל אז אני אומר “טוב, אני אביא Container ואני אקח איזה Copy & Paste של איזה Template פשוט - ואני אריץ שם, לא יודע - RabbitMQ, וביחד עם ה-Service שלי ועוד איזשהו Redis ויריץ אותו . . .
    • אמממה? שכחתי ש-RabbitMQ, ב-Default שלו, עושה Consume לכל ה-Memory שהוא יכול, כי הוא עושה לזה Queueing  . . .
      • ולא שמתי Memory-Limit בתוך ה-Kubernetes YAML שלי ל-Workload הזה.
      • ועכשיו אני בבעיה, כי יש לי “Pod סורר”, שלקח עכשיו את כל ה-Memory של כל ה-Node - ועכשיו אני יכול לחוות Outage . . .
    • עכשיו, אתה - כ”מפתח קלאסי”, נקרא לזה - אולי אתה לא חשוף לזה
      • אולי אתה גם רגיל לעבוד בעולמות הוירטואליזציה (Virtualization) או ה-EC2, כשאתה יודע שכל דבר רץ על Instance ולכל דבר יש את ה-Boundaries שלו
      • אבל מה לעשות - פה לא . . . פה אתה יכול להריץ Kubernetes על ה-Bare-Metal אפילו, ופה ה-Docker יכול לרוץ Native . . .
      • וזו רק דוגמא אחת - יכול להיות שלא שמתי Liveness Probe או Readiness Probe . . . והדוגמאות הן עוד מאוד ארוכות . . . 
(רן) עכשיו, בעיקרון הייתי יכול גם לפני זה לקחת RabbitMQ ולהתקין אותו בצורה לא נכונה . . . אבל זה היה קשה יותר. עכשיו זה ממש קל - זה להעתיק YAML ולשים אותו בפנים - וזה עובד. לפני זה הייתי צריך לעבוד קשה, ורוב הסיכויים שאם הייתי עובד קשה, אז גם הייתי מבין איך נכון לעשות את זה, ועולה מראש על הטעויות שלי.
פה זה כל כך קל, שזה פשוט להעתיק YAML מ-Stack Overflow והנה - לכאורה זה עובד . . . עד אשר מגיעה השעה 3 בלילה - ואז זה מפסיק לעבוד . . . 
  • (שמעון) נכון . . . שמע, יש דברים כמו . . . דברים שקרו נגיד ל-Target
    • שמו CronJob וה-Restart Policy שלו, אופס . . . עשו טעות וראו שזה כל הזמן עושה Restart
    • אממה - ה-Pod הזה, היה בו איזה Error - אז הופ! עשו Spin ל-4,500 Pod-ים עם ה-Cron הזה, שדפק להם את כל ה-Cluster.
  • עכשיו, זו טעות קטנה, של “האם אני עושה Restart Always או Never או Kill” - אלו דברים מאוד מאוד פשוטים, לכאורה . . . .
    • ופתאום אין לנו את ה-Guard Rails, שאולי היו לנו פעם עם ה-Ops - פתאום כל Developer שולח את  זה ל-Cluster ו-טאק! אללה-באב-אללה, לך תדע מה יהיה . . .

(רן) אז למעשה Kubernetes מצד אחד נתן . . . ייצר הזדמנות. עכשיו מאוד קל לפרוש דברים, מאוד קל לשבור את החומות בין Ops לבין Dev - אורי, עכשיו עברנו את 2015 אז אני מתנצל, אבל בנוסף . . . 
(אורי) התעוררתי . . .
(רן) . . . אבל בנוסף, הוא גם נותן לנו, אולי, הזדמנות עכשיו גם לייצר רגולציה - מילה שאתה לא אוהב - או לייצר Safety, אוקיי? אבל בעצם, אם לפני זה כל אחד היה צריך לייצר את ה-Safety הזה בעצמו, ע”י Whatever-כל-מיני-כלבי-שמירה מסוגים שונים או כל  מיני Script-ים כאלה שהיית כותב לעצמך, אז היום יש לך אפשרות לייצר את זה בצורה שמתאימה לכולם - זה קצת אולי מדבר עם ה-CNCF שעליו דיברת מקודם.
אז מה עשה העולם, כשהוא ראה את הדברים האלה?
  • (שמעון) שאלה מעולה . . . אז בעצם מה קרה? ניתן לראות שני סוגים של Approaches שנלקחו ע”י חברות - 
    • ה-Approach הראשון היה “טוב, זה קורה חברים, אין מה לעשות - מעכשיו כל שינוי ב-Kubernetes ב-YAML, ב-Helm Charts - מעכשיו ה-DevOps צריך לחתום על זה”, לעבור על זה . . .
      • ואז במקום שה-DevOps יתעסקו ב-Customization, ב-Performance, בדברים שהם רוצים - הם נהיים מעיין “Human Debugger” ל-YAML, והם צריכים עכשיו - מסכנים, 20 DevOps-ים על 500 מפתחים - צריכים לעבור בראש, לעשות ביד Debugging ל-YAML-ים של מתכנתים . . .
      • (רן) “ועדת DevOps” - הכי אוקסימורון שיש . . . “לך תעבור את הועדה” . . . 
(אורי) השאלה היא גם אם שליחה כזאת של קונפיגורצית Kubernetes קוראית כל הזמן? זה לא כמו כשמפתח שולח קוד . . . האם זה באמת קורה כל הזמן או שזה קורה לעיתים רחוקות ואז אולי זו לא בעיה . . . .
(רן) למה שזה לא יקרה כל הזמן? אתה רוצה לשנות כמות זיכרון, אתה רוצה לשנות מספר Pod-ים, אתה כל הזמן . . .
  • (שמעון) . . . אתה רוצה להריץ Service חדש, אולי מספר Service-ים  . . .
(אורי) בסדר, זה  . . . כמה זה קורה עם המפתח? רוב העבודה שלו זה לפתח . . . אם פעם בכמה זמן הוא צריך לשנות את הקונפיגורציה (Configuration) של ה-Pod שלו אז בסדר . . . 
  • (שמעון) פה אני אקח אותך בחזרה ל-2015 . . . 
(אורי) אני רק אגיד - זה ברור שזה פחות . . . יש לו פחות עצמאות, אוקיי? אבל השאלה היא האם זה באמת קורה כל כך הרבה . . . 
  • (שמעון) שאלה טובה . . . האם זה קורה פחות מקוד רגיל? חד משמעית, אני בטוח.
  • אבל אני אקח אותך שוב למסע בזמן ל-2015, נושא לעוס מכל כיוון - microServices vs. Monolith וכו’ - אז כנראה שהאמת היא איפשהו באמצע.
    • אבל בסוף אנחנו רואים, בארגונים שמשתמשים במערכות שלנו שאני יכול לדבר עליהם - עשרות ומאות של Service-ים . . .
    • וגם אוהבים לעשות את ה-Separation of Concern - אומרים “אוקיי, יש לי משהו, אז במקום לדחוף אותו עכשיו לתוך אותו ה-Service ולהעמיס עליו עוד יותר - בוא נעשה Service נפרד!”
      • אממה - בכל פעם שאתה עושה Service נפרד, יש לו קונפיגורציות משלו, דאטה משלו, אולי Databases משלו, אולי Cache-ים משלו
      • ואז ניהית לך פה “ערימה של Infrastructure” [על הדשא?], שאם פעם ב-Monolith היה לנו Monolith ענק עם שכבה דקה של Infrastructure - עכשיו יש לנו אפליקציה עם שכבה דקה של אפליקציה ומלא מלא Infrastructure מסביבה - כפול 500 כאלה . . .

(רן) אני אעשה . . . דרך אגב, אורי - אני יכול לענות לך על השאלה של “עד כמה זה קורה?”: תקרא את ה-Post-Mortem-ים ותראה כמה זה קורה . . . קורה הרבה.
(אורי) זה בסדר, אבל אתה יודע - תקרא את ה-Post-Mortem-ים של טעויות קוד . . . 
(רן) כן, אבל אתה יודע - אנחנו מנסים למצוא את היחס הנכון . . .אבל אנחנו רואים שזה קורה, זאת אומרת - זה קורה.
(אורי) אני לא מתווכח עם זה שזה קורה - זה קורה, ויש תמיד את הצורך הזה בעצמאות, אבל חשוב לשים את ה . . .
  • (שמעון) אני חושב שהשאלה, אורי, היא גם מה ה-Cost? - אם אני עשיתי עכשיו טעות והשתמשתי ב-Type הלא נכון או אני לא יודע מה יש בתוך הקוד שלי, לעומת אם אני עכשיו לא שמתי את ה-Memory Limit או את ה-Liveness Probe לא נכון, וזה יכול להשפיע לי על כל ה-Workload שלי ב-Cluster
  • ואולי זו הנקודה - להגיד מה ה-Blast Radius של טעות בקונפיגורציה של Kubernetes.

(רן) אז פתרון אחד היה “וועדת ה-DevOps” הזו, שכולנו פסלנו . . . אוקיי, אילו עוד פתרונות?
  • (שמעון) פתרון אחר זה הצד השני לחלוטין - זה “טוב, יאללה, אין מה לעשות, זה מה שיקרה” . . .
  • (רן) “אכלתם אותה, חבר’ה . . . יש לכם Kubernetes, יש לכם YAML - תסתדרו”.
  • (שמעון) נכון  . . .
  • (אורי) השאלה היא רק מי משלם את השיק . . .
  • (שמעון) נכון - ואגב, אפרופו אתה אומר שיק, זה אחד ה-Use Case-ים באופן מעניין, כשאנחנו עוד מעט נגיע לדבר על הנושא של פוליסות, אבל לשים מעיין Cost Center - 
    • יש אנשים שמרימים מיליון דברים . . . וואלה, של מי זה? מה זה? מה זה עושה פה? מי ה-Owner? איזה צוות זה? מה קורה פה כאילו? [מי נתן את ההוראה?!]
(אורי) אני יכול להגיד שב-Outbrain, ברגע שנכנסנו ל-Kubernetes, הבנו שיש כמובן את העניין הזה של ה-Cost ופשוט פיתחנו Visibility לכל Cost - כל צוות יודע מה ה-Cost של ה-Service-ים שלו, כמה עולה לו כל Service, והם יכולים . . . פעם (Once) שאתה מודד את זה, את יכול לקחת Action.
  • (שמעון) אבל השאלה היא איך אתה יודע שהמתכנת שהעלה את ה-Service הבא לא שכח לשים Label? . . .
    • ואז המערכת שאוספת פשוט לא תצליח “לאסוף את ה-Owner” . . . .
(אורי) אז במקום הזה, אנחנו בעצם בודדנו את המפתח מהתשתית ויש לו Pipeline שלם, והוא מבחינתו רואה “Service” . . .
(רן) אז יש פה בעצם את פתרון מספר שלוש . . . דיברנו על שני פתרונות: אחד זה היה “וועדת DevOps” , שתיים זה “קחו אולר שוויצרי ותתחרעו עליו” - ושלוש זה לייצר אבסטרקציה: לא לחשוף להם את Kubernetes As-is, אלא ליצור שכבה שמפשטת את זה. [368 Kubernetes and Dyploma at outbrain]
  • (שמעון) בדיוק - ואגב, אני מאמין שבמובן מסויים, Datree איפשהו משחקת שם על ה-Abstraction Layer הזו
    • מילה שאני דווקא אוהב זה דווקא סוג של Guard Rails מסויימים - שוב פעם, במשחק שבין Flexibility ל-Simplicity.
  • יש ארגונים שפשוט המפתח, בסופו של דבר, לא רואה שמאחורה זה Kubernetes YAML - הם עושים את ה”שמעון-YAML”, ויש להם שם ערכים מסויימים שחשופים אליהם
    • זה Memory ו-CPU ו-Whatever-מה-שאני-רוצה
  • אגב, יש כאלה שגם אם לא נתת את ה-YAML הפנימי שלנו - ה-Outbrain.yaml או ה-AppsFlyer.yaml - אז אתה לא יכול לעשות את ה-Deployment.
    • ואז זה בעצם לקחו ופשוט . . . כי הרי יש אינסוף של פרמוטציות בקונפיגורציות (Permutations, Configurations) ב-Kubernetes, אז הלכו ועשו איזושהי Abstraction Layer על זה.
(רן) אז במשרעת הזאת, שבין Flexibility ל-Simplicity, אז לקחו את זה לכיוון של Simplicity.
  • (שמעון) נכון.
(רן) וזה יכול לעבוד לחלק מהחברות, אבל כמו שאמרת יש לזה את החסרון של “אוקיי, לפעמים אתה רוצה לעשות משהו קצת אחר”.
  • (שמעון) נכון

(אורי) עכשיו, יש בעניין הזה שתי אפשרויות - אתה יכול לשים ממש אפליקציית ניהול מעל זה ולשים בפנים את כל ה”בדיקות נכונות” על ה-Input-ים שמגיעים מהאפליקציה, ויש פתרון של לבנות Compiler, אוקיי? . . . אתה עדיין יכול לשים Kubernetes YAML, אבל אני אריץ לך עליו  . . . Debugger או . . .
  • (שמעון) Linter אולי . . . 
(אורי)  . . .שמפעיל את ה-Rules ש . . .
  • (שמעון) יפה,  בדיוק
(רן) איזשהו מנוע  . . . תיכף נגיע לזה, אני רואה שזה על קצה הלשון שלך - איזשהו מנוע-חוקים שאומר “זה בסדר - אבל זה לא בסדר”, אוקיי . . .  
  • “מותר לך להרים 50 Pod-ים, אסור לך להרים 51”
  • “מותר לך להקצות 250Mb זכרון - אסור לך להקצות מילימטר יותר”
אז איך עושים את זה?
  • (שמעון) אז זה לוקח אותנו קדימה - דיברנו קצת על ה-Cloud Native Foundation, ויש שם הרבה פרויקטים, אני מאוד ממליץ.
    • לאחד הפרויקטים קוראים  Open Policy Agent (OPA) - הופה-היי . . . 
    • זה בעצם פרויקט שהוא, בבסיסו, ב-Core, זה Policy Agent, שאגב משתמשים בו להרבה Use-Case-ים
      • יש חברות שמשתמשות בו בכלל ל-Authorization, כש-microService מדבר עם איזשהו microService אחר
      • וכיש שם איזשהו User שרוצה לבצע פעולה, אז הוא פונה ל-Service ושואל אותו “האם שמעון יכול לעשות פעולת Delete - כן או לא?”
      • ובעצם מפרידים את ה-Logic Layer של ה-Decision Making מהבחינה הזאת, לבין האפליקציה עצמה.
    • (רן) וה-Scenario הזה לא קשור ל-Kubernetes?
    • (שמעון) לא . . . אני נותן דוגמא אחת כדי שנבין את הזה . . .
  • בגדול, ל-Open Policy Agent יש שתי צורות של הרצה שלו - 
    • או כ-HTTP Server שאתה פונה אליו
    • או שאתה יכול להביא אותו כ-Library, שאתה פשוט מדבר איתו.
  • עכשיו, ה-Interface של הדבר הזה הוא שפה דקלרטיבית (Declarative) שקוראים לה Rego, שהיא Inspired ע”י שפה בשם Datalog
    • וה-Emphasis בשפה הזו הוא What you see is what you get
    • זאת אומרת שאין שם איזה-שהם אובייקטים מטורפים או לולאות מטורפות או דברים דינאמיים . . .
    • הפוך - מנסים כמה שיותר שיהיה דיסקריפטיבי (Descriptive) 
    • ו-Fair, אני אגיד שזו שפה לא-הכי-קלה שיש . . .  היא מצד אחד . . . נכון, היא דיסקריפטיבית, אבל מצד שני זה קצת “מקשה על העין”.
  • (רן) כן - ועכשיו צריך מישהו שישמור עליך מפני השפה הזאת, כי גם שם אתה יכול לעשות שגיאות . . .
  • (שמעון) נכון . . . . אז בעצם זה לוקח אותנו למקום שאתה יכול לתת פוליסות - ולפוליסות האלה אפשר לפנות ולשאול האם אני יכול לבצע פעולה או לא לבצע
    • הוא פשוט שואל אותי - “מה אתה אומר?”
    • נותן לך Input של Data, נותן לך Input של Rule-ים - תבדוק לי ותגיד לי האם זה בסדר או לא בסדר.
  • ואז, כדי להיכנס טיפה יותר עמוק, יש את Conftest ו-Gatekeeper
    • כש-Conftest - כשמו כן הוא: Configuration Test שמבוסס על  Open Policy Agent
      • והוא כבר נבנה ב-Use Case של לעשות בדיקות על Configuration Files
      • כשאחד ה-Configuration Files, מן הסתם, זה Kubernetes YAMLs
      • ואתה ממש יכול לרשום שם “תבדוק לי האם קיימים Label-ים, והאם יש Label מסוג Cost או Team? ואם לא - אז תיכשל!”
      • ואז בעצם מה שעושים זה שבתהליך ה-CI/CD או כ-pre-commit Hook או מה שזה לא יהיה, אנחנו מריצים את הטסטים האלה.
      • אז זה צד אחד, זה Conftest
    • הצד השני זה Gatekeeper - 
(רן) רגע, שנייה, בוא - אני אעצור אותך . . . יש פה הרבה מושגים ואני רוצה לפרוט אותם.
  • אז קודם כל, ה-Conftest - זה משהו שאם אני מבין נכון ירוץ ב-CI או באיזשהו Pipeline שבו אתה . . .
    • אוקיי - שינית קוד של Kubernetes, נגיד ששינית YAML או . . . אפילו אם יש לך איזשהו כלי, נגיד כמו מה שיש ב-Outbrain - אבל בסופו של דבר הוא שינה את הקונפיגורציה של Kubernetes
      • קודם כל תריץ על זה Conftest - ואם הוא יגיד שזה בסדר אז תמשיך הלאה
      • לצורך העניין - “תמיד חייב להיות Label של Cost”, שתדע לאיזו קבוצה זה שייך.
  • ו-Admissions זה כבר סיפור אחר - זו חיה שכבר חיה בתוך Cluster של Kubernetes . . . [עמק החיות המוזרות?]
  • (שמעון)  . . . כי אתה יכול לשאול אותי “שמעון - אבל מה אם יש לי בנדיטים? מה אם הם עושים kubectl - Apply בום-טראח לתוך ה-Cluster, ולא עובדים עם GitOps ולא עוברים בתוך ה-Pipeline?”
  • אז לשם זה יש באמת את Gatekeeper, שאני לא יודע עד כמה אנחנו רוצים לחפור עמוק אבל זה שוב פעם כמו במערכות הפעלה, כשיש לך System Calls - 
    • אז זה לצורך העניין ככה ה-Antivirus עובד - יש איזשהו Executable שרוצה לרוץ, המערכת הפעלה קוראת ל-Antivirus ואומרת “אתה שומע, חביבי - זה בסדר? זה לא בסדר?”
      • והוא הולך ומריץ בדיקה ואומר לו “בסדר” או “לא, תעשה לזה Block”.
    • בדיוק אותו הדבר - רק על Kubernetes
(רן) אוקיי, אז אפשר לחשוב על זה כמו על ה-Bouncer בכניסה למועדון לילה, שבא ומסתכל הטיפוסים - “אתה בסדר, אתה נכנס” או “אתה לא בסדר, אתה לא נכנס” - וגם זה על בסיס איזושהי Policy [יותר Profiling . . .]. 
גם זה, דרך אגב, OPA?
  • (שמעון) כן, גם זה מבוסס OPA וגם זה מבוסס על פוליסות ב-Rego
(רן) אוקיי, אז ההבדל המשמעותי זה ש-Conftest רץ בזמן, נקרא לזה “על יבש” - הוא רץ על הקונפיגורציה, אבל Gatekeeper רץ בזמן ה-Execution, ככה שגם אם ניסית לעקוף איכשהו את ה-Conftest אז הוא יעצור אותך בכניסה.
  • (שמעון) מדויק

(רן) אוקיי, ובאופן טיפוסי אתה רואה חברות משתמשות בשניהם, באיזשהו אופן? עם קונפיגורציה משותפת? אולי איזשהו שילוב של מה שאורי הזכיר מקודם, של אבסטרקציה מעל? מה קורה בשטח?
  • (שמעון) אז מה שקורה בשטח זה דה-פאקטו היום ניהייה סטנדרט Across the board ה-Open Policy Agent ואני רואה הרבה חברות שמשתמשות ב-Conftest ו-Gatekeeper
    • אבל איפה ה-Challenge?
  • אז אתה אומר לי “שמעון, שכנעת אותי! שמעתי ברברסים, נשמע מדהים!”
    • יאללה - הולך, נכנס, מוריד Conftest - אבל אז אתה מוצא את עצמך בוהה, מול מסך ריק - ואתה אומר : רגע, אבל אילו פוליסות אני אשים?” . . . .
    • מה - אני אחכה ל-Outage הבא כדי לדעת אילו Policies לשים? זה אחד . . . 
  • ושתיים - אתה אומר “יש לי Git Repositories 500,  אז מה - עכשיו אני אעשה 500 Commit-ים ל-Conftest הזה?”
    • “ועכשיו אני רוצה לשנות Policy - אז מה, אני אעשה 500 Pull-Request-ים?”
    • אז פתאום אתה אומר “רגע - אני צריך איזושהי דרך Central-יסטית לנהל את זה”
  • ואז מה שקורה זה שהיום, בעיקר ארגונים, הולכים ובונים את ה-Layer הזה, של
    • (א) להבין איזה חוקים לשים
    • ו-(ב) של צורה לשלוט בזה . . . בצורה מבוזרת - ובונים את זה בעצמם.
  • שזה גם מביא איזשהו Dashboard שמראה אילו Locations יש, מה בעצם קרה, מה רץ איפה ולמה . . .
    • שאגב - זה בדיוק Datree . . . בנינו בדיוק את מה שהרבה חברות בונות - פשוט אנחנו נותנים את כ-Service.

(רן) אז Datree . . . דרך אגב - מאיפה השם? עוד לא דיברנו על זה . . . אבל Datree זה ”כלי שבא ועוזר לך לנהל את ה-OPA שלך” [אחד ה-One-liners אם לא ה-] - זאת אומרת, יש לך פוליסה, אתה מבין בגדול מה אתה רוצה לעשות - אבל עכשיו לך תכיל את זה על 500 Repositories וכו’ - וזה מה ש-Datree עושה.
אז מאיפה השם?
  • (שמעון) אז זה כמו Data-Tree . . . למפות, אתה יודע . . .
  • בגדול, אנחנו Abstraction Layer מעל הדבר הזה - אתה עושה brew install datree ויש לך Datree
    • אתה לא צריך להתעסק עם שום “OPA-ות שמופות” . . .אין לך כלום מאחורה.
  • ודבר ראשון מגיע לך, Built-in, שלושים חוקים, שהם, נקרא לזה “נכתבו בדם”
  • לאחר מכן, אתה יכול להיכנס ל-Dashboard שלנו ולהפעיל או לכבות כל Policy - ולהתחיל ליצור פוליסות שונות.
    • כי אתה יכול לשאול אותי “שמעון! אז הדלקתי פה, שמתי Memory Limit 4Gb - ועכשיו באו אלי הצוות של ה-AI ואמרו לי ‘מה זה 4Gb? אני לא מתעורר ב-4Gb! תן לי 50Gb!  . . . “
      • רגע - צוות כזה צריך ככה וצוות כזה צריך ככה . . . אתה פתאום צריך הרבה חוקים והרבה פרמוטציות של הרבה Policies . . .
      • זה פתאום מתחיל להסתעף . . .
    • ואתה אומר “מה עם ה-Global Policies, שאני מכיל אותן לכל הארגון? אולי אני חייב Liveness ו-Readiness פה בכל Workload?”
      • אבל עכשיו, הדברים שהם קונפיגורביליים (Configurable) ספציפית פר-Service - הם צריכים לדעת את ה-Context של ה-Service הספציפי.
  • ובעצם, כאן אנחנו נכנסים - אנחנו נותנים לך, במקום אחד, לבוא ולהגדיר את הדברים האלה
    • כמובן שאנחנו גם תומכים בלכתוב Custom Rules
    • אגב, אנחנו תומכים בלכתוב Custom Rules גם לא ב-OPA - כי דיברנו עם הרבה מהלקוחות שלנו והם אמרו “שמע, זה פשוט מסובך . . .כאילו, תן לי, אתה יודע, תן לי לעשות איזה YAML פשוט  . . .”
    • אז לקחנו את JSON Schema - זה RFC Specification, שיש לו מימושים ב-JSON-ים וב-YAML-ים שונים, ובעצם אתה יכול להגדיר חוקים בצורה פשוטה וקלה, ואנחנו מורידים ממך את כל העול הזה.

(רן) איפה, לתפיסתך צריך לעבור הגבול - אם צריך לעבור גבול, לצורך העניין - בין ה-Operations לבין הפיתוח? ואני מצטער שאני חוזר ל-2015, אבל בואו נעשה את השאלה הזו רלוונטית . . .
נגיד, לדוגמא - האם ה-Operations הם אלו שצריכים להיות אחראים על ה-Policies והפיתוח הם אלה שלוקחים את זה משם? האם ה-Operations הם אלו שצריכים להיות אחראים לא רק על ה-Policies אלה גם על ה-Cluster עצמו ועל כל מיני . . . ועל הגדרות גנריות, ולתת למפתחים רק כמה Call-Back-ים מסויימים, לצורך העניין “את מספר הפורט אתה תקבע, אני אקבע את כל השאר” או “את כמות הזכרון אתה תקבע, את כל השאר אני אקבע” . . . 
זאת אומרת - איפה לדעתך צריך באמת להיות הגבול בין תחום האחריות של צוות ה-Operations לבין צוות הפיתוח?
  • (שמעון) שאלה מעולה - אני חושב שאני אתחיל בתשובה של “כמובן שזה תלוי . . .”, אני לא כזה מבוגר אבל אני קצת פחות ילד ויודע שהתשובה היא תמיד, מה שנקרא “זה תלוי” . . .
  • אני יכול להגיד מה אני רואה בארגונים - אז דבר ראשון, אני רואה בבירור מובהק שכל ארגון, יש בו את ה-DevOps, יש בו סט אחד של פוליסות שהוא כאילו Company-wide Policies
    • שאומר “תשמע, בלי Health Checks ב-Container, בלי Liveness Probe, בלי Readiness Probe - חברים, אי אפשר”.
      • “בלי Cost Center Label אני לא יכול” . . .
    • “אני לא יכול” - וזה ברמות של, כאילו . . . ב-Iron Source היה לנו את “ה-Iron Hunter” שהיה הולך ומוצא כל Resource שלא היה מתוייג ופשוט הורג אותו . . . .
      • אמרנו “חברים, הולך להיות פה Hunter - אנחנו מודיעים על זה מראש, יש לכם שלושה חודשים  . . .”
      • (רן) “אל תתפשו בלי  . . . “
      • (שמעון) לא, אמיתי - זה היה הורג Resource-ים  . . . תקשיב, זה משוגע לחלוטין, אבל כאילו הגענו למצב שזה פשוט לא היה  . . . לא הייתה ברירה.
      • אז זה דבר ראשון.
  • דבר שני - עכשיו אני מתחיל להיכנס פנימה, ואני חושב שזה גם דיבור שהוא מאוד כזה Cultural - האם יש לך צוות Cental-יסטי אחד וכל השאר מתכנתים? האם יש לך DevOps Ambassadors בתוך כל צוות, שיכולים לקחת את ה-Ownership הזה בשביל הצוות ולעבוד עם ה-DevOps?
    • זה מתחיל להיות כאילו . . . זה מאוד נוגע ב-Culture של הארגון, וזה לא גרידא-טכנולוגי.
  • (רן) מעולה, אוקיי . . .

(אורי) אני רואה את זה . . . בכל דבר אתה יכול להגיד “בוא נעביר למפתח גם אחריות על KPI כזה ו-KPI אחר”, אתה יודע . . . מפתחים מאוד אוהבים את ה-Craftsmanship שיש להם, אוהבים את היעילות. אתה יכול להגיד . . . ויש כאלה שמניעים את ה-Business KPIs והם אוהבים את זה וסבבה.
זו הרבה שאלה של איפה את שם Cost, אוקיי? ו-Cost אל מול Revenue - לפעמים שווה לי שמשהו יהיה יקר אבל הוא מזיז קדימה Business KPIs בצורה הרבה יותר גדולה.
לפעמים צריך איזו “יד כללית” כזאת, שתסתכל על הכל ברמה קצת יותר . . . “אוקיי, יש לנו סוג של מומחיות בתשתית,  יש לנו מומחיות של Cost Optimization בתשתית - תנו לנו לעזור לכם”.
  • (שמעון) חד-משמעית . . . אני יודע גם שאתה נותן כאן הרבה את הדוגמאות של Cost, אני עבדתי גם בחברה שהיא Ad-Tech, אני מבין מאוד את העולם של ה-Cost.
  • אני חושב שה-Ownership על ה-Cluster צריך להיות על ה-Bare-Metal של ה-Cluster, או נקרא לזה על הקונפיגורציות שלו - כן צריך להיות על ידי צוות מרכזי.
  • והנושא הכמה-שיותר-אפליקטיבי צריך להיות בצד של המפתחים - ואז יש איזשהו “את האמת באמצע”.
    • להגדיר בכמה אחוז CPU Memory זה עושה Scale-up לעוד Pod-ים? וואלה, זו גם שאלה אפליקטיבית . . .
    • זו שאלה מאוד מאוד אפליקטבית, ולא משנה כמה תשתיות יגידו “לא, אתם מבזבזים פה Resource-ים!”
      • יכול להיות שאם אני מרים אותו ב-90% CPU אז הוא “נחנק” ולא מצליח לעשות Serving ולא - אני צריך להרים עוד ב-70%.
    • אז צריך להבין פה את ה-Balance משני הצדדים
  • אני כן מסכים, במובן מסויים, עם “היד הכללית המכוונת” - זה כמו שאולי לא צריך ללכת overboard על “You  Own it, You Run it-  ולכו תסתדרו לבד”, ואולי מהצד השני לא צריך לנעול הכל, ואתה עכשיו פה “Code Monkey”, מחליף מכפתור אדום לירוק.
    • אבל אם  . . . אני כן מאמין וכן חושב שזה היה שינוי ממש טוב שיש Ownership לצוותים אפליקטיביים - שהם קמים בלילה, שהם חושבים על “איך אני עושה לזה Scale, איך אני עושה לזה Load Balancing”, והם לא תקועים רק בחלל האפליקטיבי הזה שלהם.
  • מה שאני שומע ממתכנתים זה שהם אומרים “תשמע, ה-Guard Rails האלה ממש עוזרים לי”
    • כי אני יודע, תחשוב על זה משני הצדדים - ה-DevOps משקשקים כי הם אומרים “מכניסים פה שינויים לתשתית שהם לא יודעים מה הם עושים!” וה-Developers משקשקים כי הם אומרים “אני עושה פה שינויים וגם אני לא יודע בדיוק מה אני עושה” - ושני הצדדים כאילו רועדים בשתי הפינות
    • ודווקא לבוא ולתת כלים שאומרים “רגע, חברים - בואו, נעשה את הבדיקות, נעזור לכם, ניתן לכם איזשהם Guard Rails שיחזיקו לכם את היד משני הצדדים” יכולים להעלות את ה-Trust משני הכיוונים.

(אורי) ואתה יודע - בדרך כלל, ה-Guard Rails השאלה מכסים 90-95% מהצרכים של ה-Developers, שנמצאים בתוך ה-Guard Rails.
ויקרה, כן - פעם בכמה זמן, כשמישהו צריך זה . . . אז הוא ידבר עם איש DevOps שיפתח לו את מה שצריך - ולא קרה כלום.
  • (שמעון) נכון . . .
(רן) מה - הם מדברים?!
(אורי) לפעמים . . . ב-Guard Rails.

(רן) טוב, שמעון - היה מרתק. יש עוד נושאים שלא כיסינו שהיית רוצה לכסות לפני שאנחנו מסיימים?
  • (שמעון) לא . . . אני חושב שעשינו כיסוי טוב.
(רן) מעולה! מגייסים?
  • (שמעון) כמובן! אנחנו מגייסים, גם למשרות טכניות בכל התפקידים וגם למשרות Go-to-Market.
(רן) איך נראה ה-Stack הטכנולוגי שלכם? זאת אומרת, חוץ מ-Kubernetes שהזכרת, מה עוד קורה שם?
  • (שמעון) אז ה-CLI ב-Go, ה-Backend שלנו זה TypeScript ו-Next.js, 
  • הכל על AWS בעיקר, יש גם קצת Azure
  • יש Container-ים, הכל CI/CD ו-Deployment ל-Production אוטומטי.
  • מאוד כיף! Building by Developers, for Developers - אבל For Real . . .
    • כאילו - אנשים אשכרה באים להתראיין אצלנו וזה “אחי - לך ל-GitHub, לך תתקין את זה” . . . מבחינתי זה אחד הדברים שאותי, כאילו, מדליקים.
  • (שמעון) כן . . .
(אורי) לא נורא . . .

(רן) שיהיה בהצלחה, תודה שבאת.
(שמעון) איזה כיף - תודה רבה!
(רן) להתראות

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

אין תגובות:

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

הירשם ל- תגובות לפרסום (Atom)