Podcasts about agile devops

On the last episode of the Definitely, Maybe Agile podcast, Peter & Dave had a great discussion about 12 year-end suggestions for a more agile 2023. Let's take a look at the four main categories they discussed.This week's takeaways:A. Marketplace and change:   1. Do more with less   2. AI in our work    3. Shorter time horizons (in times of uncertainty)B. Pragmatic stuff to remember   4. Two out one in (manage WIP)   5. High uncertainty means continuous learning and validation    6. Estimates are just guessesC. Don't forget   7. The Agile/DevOps mindset   8. Risks and contingency   9. Don't forget to measureD. End of year   10. Check your progress/direction   11. Take time to review/learn    12. Recognize the people that got you (t)hereWe love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com 

Sairam has been working in the IT industry for the last 26+ years. His industry experience includes manufacturing, government, finance, food, e-commerce, retail, and more. He's a certified Agile/DevOps coach and trainer, and since 2011 he's been helping organizations transform from a traditional to an Agile mindset. Sairam's enthusiasm and energy are contagious in all the best possible ways! We talk about the importance of transitioning from a "command and control" model of leadership to something much more Agile, and all the ways in which that helps modern organizations to grow and thrive. We also touch on his work in both the private and public sectors - how they differ, how they relate, and the ways in which transformation moves through teams and departments. Sairam was truly a joy to speak with, and I could've easily picked any one of a dozen things he said to use as the title for this episode. Give a listen, and get to know this excellent coach a little better.   To learn more about Sairam: https://ajjstech.ca/   To learn more about The Coffee with Coaches podcast, please visit: https://boxer.agency/coffee-with-coaches/  

[קישור לקובץ mp3] שלום וברוכים הבאים לפרק מספר 427 של רברס עם פלטפורמה - התאריך היום הוא ה-25 בנובמבר 2021, והיום אנחנו מקליטים ב-Remote עם ברלין [First we take] - עם יאיר עציוני, שנמצא בברלין - הי יאיר! תודה שאתה פה, כיף שאתה איתנו.יאיר הוא איש DevOps ותיק, והנושא שלנו יהיה מה שנקרא “DevOps Reloaded” או - “בוא נדבר שוב על DevOps ונבין מה זה אומר, וננסה לחזור קצת ל-Basics ונדבר על הנושא כולו” [“DevOps Reloaded” אכן יותר קליט].אז לפני שאנחנו צוללים פנימה - יאיר, מי אתה? מה אתה עושה היום?(יאיר) קוראים לי יאיר עציוני, אני במקור פתח-תקוואי, גרתי בתל אביב 10 שנים.יש לי משהו כמו 20 שנות ניסיון של עבודה בסקטור ה-IT והתוכנה בישראל - עבדתי באמדוקס, כמו רבים וטובים, שם התחלתיעבדתי בסטארטאפים, ב-Qlusters, ב-ECI Telecom, ב-Voltaire, חברת ה-Infiniband . . . התמחיתי בעיקר ב-Linux System ו-Quality Assurance ו-Networking - כל הדברים האלהבאיזשהו שלב, כשהתחיל להגיע הענן, אז בגלל הרקע העבירו אותי הרבה לענןאז AWS, סטארטאפים שוב פעם . . . אחרי זה עבדתי ב-mcAfee - עבדתי בסטארטאפ ישראלי שהתעסק ב-Security, שעבר לידי mcAfeeעבדתי שם גם איזו תקופה . . . Security, Networking, Kernal, דברים כאלהבעיקר כ-QA Engineerואז עברתי לברלין - אחרי שבעצם “פרשתי” מהתחום, אמרתי שאני יותר לא הולך לעבוד בתחום . . . (רן) כן, זה מזכיר לי את “אני עם הסמים גמרתי” . . . . “אני עם ה-DevOps גמרתי” . . . (יאיר) אז זהו, שלא ידעתי שיש בכלל דבר כזה DevOps - אבל הייתי איש QA שעושה Deployments, יודע System, לקנפג (Configure) לעצמו את הסביבות - ואז התחילו להציע לי את הדבר הזה, DevOps . . .אמרתי “מה זה DevOps?” - כי בברלין זה ניהיה פתאום “חם”:מה זה Puppet? מה זה Chef? מה זה הדברים האלה? התחלתי לבדוק . . . ואז עשיתי כמה תפקידים של איש DevOps . . . בכל התפקידים האלה - כמה שקראו לי “איש DevOps”, אני עדיין הרגשתי מעיין שאני System Administrator[“ה-DevOps של המלך”]והשינוי הכי גדול, אני חושב, היה כשפגשתי את מקום העבודה שאני עובד בו עכשיו - שקוראים לו Polar Squadאני יכול להרחיב עליהם טיפה - זו חברה מפינלנד שעושה רק DevOpsובהגדרה של החברה הזאת, אנחנו בעצם יועצים - בעברית אפשר להגיד שאנחנו עושים “ייעוץ תקשוב בענן”אנחנו רואים DevOps בצורה אחרת - אנחנו לא רק עושים “תקשוב בענן”, אנחנו גם עושים משהו שנקרא “ייעוץ ארגוני”, אם אני שוב פעם ניהיה . . . .(רן) נראה לי ש”תקשוב” יש רק בצה”ל . . . אבל אני בטוח שכולם מבינים . . . .בשאר החלקים של התעשייה זה כנראה “תקשורת” או . . . (יאיר) אני אוהב את המילה “תקשוב”, זו אחת המילים האהובות עלי בעברית . . . גם נחמד סוף סוף לדבר קצת עברית . . . המוח שלי צריך עכשיו לעשות המון רי-קליברציה (recalibration) . . .(רן) ביום-יום, דרך אגב, מה אתה - אנגלית? גרמנית?(יאיר) אנגלית - אני התחלתי כבר לחשוב באנגלית . . . אני הייתי לפני כמה חודשים בפתח תקווה [קורה לטובים ביותר], ואני מוצא את עצמי בסופר חושב באנגלית, כשאני צריך לקנות דברים, ואני אומר - “משהו לא בסדר” . . .. המון המון אנגלית כרגע, וברלין היא מאוד International, אז אנגלית זו השפה הרשמית של ה . . . Silicon Allee, מה שנקרא - סצנת הסטארטאפים הלא-ברורה שיש פה.ומה שמעניין, וזה אולי גם משהו שיחבר אותנו להמשך השיחה, זה שבפינלנד הם לוקחים את הדברים בצורה . . . .הם בהרבה מאוד דברים שונים מהישראלים ומאוד דומים לישראלים, אבל הם לוקחים דברים בצורה מאוד רציונלית - והם לא יודעים לעשות חצי עבודה . . . ובפינלנד עשו מחקרים מאוד גדולים על הנפילה של Nokia - זה משהו שבעצם פגע בהם באיזושהי צורה, כי זה משהו שהם מאוד אהבו, זו הייתה גאווה כזאת שם.וכשהם עשו מחקר, הם גילו שמה שבעצם היה חסר זה שהאנשים המקצוענים בתחום שלהם - אנשי ה-System, ה-Product - לא הצליחו להעביר את המסרים ל-C-Levels - וה-C-Levels היו מנותקים ממה שקורה.[זמן טוב לעצור ולצפות שוב ב- Riot On Documentary (2002), שימו לב רק להחזיק חזק לפני]ומה שהתפתח שם זה בעצם זו סצנה שלמה של . . . הם קוראים לזה Flat Hierarchies - בברלין, מיליון חברות יגידו לך שיש להן “Flat Hierarchies”, אבל אין.הן תמיד No Flat בכלל - רק כתוב “Flat Hierarchies” . . .ואני עובד בחברה שאין בה CEO בכלל . . . . אנשים יכולים להגדיר את עצמם . . .בחרנו אפילו את Teal בתור . . . אם אתה מכיר, ייעוץ . . . .לבנות ארגון בצורה של Teal? זה בעצם לבנות אותו מלמטה למעלה . . . .(רן) Teal, לא “טיל” בעברית . . .. אני אעיר, ככה בהערת אגב - דיברת על Nokia ועל פינלנד - אז לי יש משפחה ויש לי גם חבר שגר בפינלנד - והוא גם גר “בעיר של Nokia”, או שלפחות פעם נקראה - קוראים לזה Tampere, איפה שהמפעל הראשי . . . (יאיר) הייתי ב-Tampere!(רן) כן, אז זו עיר מאוד מאוד יפה - אבל Nokia כמעט ולא קיימת שם.אני חושב שהיא עוד קיימת, אבל בטח לא מה שהיה פעם . . . [עדיין כאן . . .](יאיר) כן . . . דרך אגב, תגיד לו שאתה רוצה שהוא יביא לך Mustamakkaraשזה מצחיק - Makkara זה “נקניקיה” בפינית . . . Ma-kara - הם שמעו אותי מדבר עם אשתי והם התפוצצו מצחוק . . . מה שקורה זה שבעצם אנחנו חלק מ-Ecosystem מאוד גדול של חברות מאוד “אידיאליסטיות” וגם העניין הוא שהחברה שלנו יודעת לעשות רק דבר אחד - ואותו דוחפים את האנשים לבנות לבד.זאת אומרת - אין לי HR, אני מנהל את הסניף בברלין ואין לי HR, אני עושה את ה-HR ואני גם עושה את ה-Process-ים.לכן יש מקום מאוד גדול להתפתח בתור בנאדם, וללמוד על התחום שלך - ועל תחומים שאתה לא מכיר בכלל.וזה מאוד מחובר גם ל-DevOps, אנחנו תיכף נגיע לזה - שבעצם אתה לא רק מהנדס בדיקות, אתה יכול להיות הרבה יותר מזה, אז למה ש”נקטין אותך” לזה.אנחנו עובדים עם הרבה מאוד לקוחות - הרבה מהייעוץ הוא ייעוץ ארגוני.הרבה אנשים אומרים לזה משהו כמו “אבל תראה, עשיתי את הכל אוטומטי - ה-כ-ל אוטומטי - יש לי Pipeline-ים, Infrastructure-as-a-Code, הכל מתוקתק - ואני עדיין לא רואה שום דבר משתפר. למה?”(רן) זה באמת ככה . . . מפה אנחנו כבר ממש צוללים לנושא. בטח אתה, שיש לך את הניסיון הזה, לדבר ככה עם לא מעט לקוחות ולהטמיע פרקטיקות - כנראה שאחת התגובות הראשונות שאתה שומע, כמו שכבר התחלת להגיד, ואני מניח שהרבה מהמאזינים שלנו גם שמעו את זה, זה “אוקיי, ניסיתי DevOps, נסיתי טרנספורמציה - למה זה לא עובד? מה חסר? למה לאחרים זה עובד ולי זה לא עובד?” . . .(יאיר) אוקיי . . . אני אתן דוגמא, ואחרי זה מהדוגמא אני אבנה את זה.אני יכול לתת כדוגמא שני לקוחות שלנו - שתי חברות שבעצם הן נכנסו לעניין ה-Kubernetes ולעניין ה-DevOps.דרך אגב - Kubernetes לא בהכרח אומר DevOps, אבל במקרה הזה אפשר להגיד שכן.חברה אחת . . . (רן) כן, נגיד רק באותה הזדמנות שפרויקט לא אומר בהכרח Big Data . . . . אבל ניתן לך את הקונטרה הזו.(יאיר) העניין הוא כזה - לקוח אחד היה, נקרא לזה סטארטאפ-מאוד-חדשני או היפסטרי-כזהאתה יודע - הם כולם עשו את הקפה שלהם Brewed והיו חברה מאוד Green Field-יתה-Frontend, ה-Backend, ה-SRE - הם כולם היו Developers by definion, אנשים שבאים מ-Coding.והם עבדו ביחד - ראיתי איך הם עובדים, זאת אומרת - איך דבר כזה ש . . . זה Cross-Functional teams, עם אחריות מסויימת לכל בנאדם - אבל הם עבדו ביחד, הם . . . היה חסר להם המון ידע בעולם ה-Kubernetes - ב-Pipelines שלהם, באיך לשפר את זה מ-5 דקות Deployment ל-10 שניות Deployment, או 7 שניות או . . . הם לא ידעו כל כך את הטכנולוגיה שמאחורי Kubernetes - אבל הם ידעו לעבוד ממש ממש יפה ביחד.הם - פוף! הם חברה שטסה . . . הם עושים Sprint-ים והם מתקתקים את ה-Sprint-ים והם עובדים כצוותהם נהנים לעבוד ביחד - כל החבר'ה שם, גם היה להם את אותו . . . הייתי אומר שהם התאימו לעבוד אחד עם השני, אם אתה מבין למה אני מתכווןאולי לא המתכנתים הכי מבריקים בעולם - אבל אנשים ברמה גבוהה.החברה השנייה הייתה מעיין ארגון יותר קלאסי - היו להם Sprint-ים, אבל לא היו להם Release-ים בסוף ה-Sprint-ים בהכרחהם היו מאוד מאוד מנותקים אחד מהשני, זאת אומרת - הייתה קבוצת ה-Ops שהייתה מתפרקת כל הזמן, אנשים לא רצו להיות בה, כי כשיש לך 50 הודעות Errors בלילה, אז אתה לא בנאדם שמח . . . .היו Frontend ו-Backend וקבוצת Full-stack - אף אחד לא מדבר עם השני . . . שם גם עשינו ייעוץ ארגוני - אתה ממש רואה את זה, אתה יושב “בתוך הלקוח” ואתה רואה שלושה אנשים רצים כמו מטורפים, מזיעים - ואחרים שרואים YouTube . . . אני לא נגד לראות YouTube בעבודה, אבל כשמישהו אחד מזיע ומישהו אחר רק רואה YouTube . . . .אמרתי לו, ל-CTO - “אני לא אומר שאתה צריך להעביד את כולם בפרך, אבל את שם לב שאתה ועוד שניים עושים הכל - והאחרים מסתכלים עליכם?” . . .. וכמובן כשהיינו צריכים להעביר להם את הידע על ה-HELM charts שבנינו להם - על ה-Repos, על ה-TerraForm, איך כל העסק הזה עובד - אף אחד לא רצה לדעת . . . מה שקרה להם בעצם היה שהם בעצם הם שמרו על המבנה הקודם - אף אחד לא נהנה מה-APIs החדשים של Kubernetes שיכולים לשדרג אותך - ובעצם ה-Ops קיבלו עוד ועוד ועוד ועוד עבודה . . . (רן) אז מה שאתה אומר זה, אם אני אנסה להסיק את המשל ממה שאתה אומר - יש כלים בעולם, לדוגמא Kubernetesאם אנשי ה-Ops פעם השתמשו בכלי אחד והיום משתמשים בכלי אחר - לא עשית בזה כלום . . . מה שהכלים מאפשרים לך זה לחלק את הנטל בין אנשי ה-Ops לאנשי הפיתוח - ושכל אחד ינצל את החלק הרלוונטי אליו בתוך הכלי.לצורך העניין, Kubernetes עושה נקרא-לזה-דמוקרטיזציה של ה-Infrastructure - לא יודע אם זו מילה שהמצאתי עכשיו או לא, אבל בכל אופן זה מאפשר לחלק את הנטל.אם חלק מהחברה הוא גם ככה Idle, שום Kubernetes לא יעזור, כי יש פה איזשהו עניין תרבותי . . . אתה אומר שמי שבא ואומר “טרנספורמצית ה-DevOps שעשינו לא עבדה לי” - אתה אומר שלפחות אחד מהמקרים, או אחת מהסיטואציות שיצא לך לראות, זה שהבעיה היא בתרבות הארגונית ברוב המקרים, ולא מן הסתם בטכנולוגיה או בהטמעהיתכן שיש גם שם בעיה, אבל זה לא מה שאתה מתאר . . .(יאיר) בדיוק - אני הייתי אומר כזה דבר: ההגדרה של DevOps, לפחות אצלנו ב-Polar Squad, היא הגדרה כפולהאנחנו אומרים שזה . . . חייב לבוא שינוי תרבותי ב-DevOps, והשינוי התרבותי הוא כלל-חברתיזה גם Pattern שאני רואה כל הזמן - יש לך צוות DevOps, אבל זה צוות שכל אחד יודע רק משהו מאוד ספציפי בצוות . . . כבר זה לא DevOps, ב-By definion - כי הם . . . אני רואה הרבה אנשים, ואתה לא מאמין כמה מהם אתה . . . הוא יודע רק חתיכה מאוד מאוד קטנה ממה שהוא עושה, הוא לא רואה את התמונה [הכוללת], הוא לא יודע כלום על התמונהואחרי זה, יש לך מלא צוותים בחברה - כל אחד רואה את הפינה שלו, הם לא עובדים ביחד.(רן) האם קיים בכלל “צוות DevOps”, לדעתך? האם זה נכון שיהיה בחברה צוות שקוראים לו “DevOps”?(יאיר) אנחנו נכנסים פה עכשיו לדלת מאוד . . . אני, אישית, מאמין בזה, מהסיבה . . .באמת שהתעמקתי בנושא - למדתי היסטוריה ופילוסופיה באוניברסיטת תל אביב, התחום שלי זה היסטוריה גרמנית של הרעיונות . . . . ואני הייתי מאוד לא מרוצה מהעניין . . . הרגשתי שאין דבר כזה “DevOps Engineer”, זאת אומרת - מבחינתי התפקיד הזה . . . אני מקבל את זה שיש Platform Engineer, אני מקבל את זה שיש Cloud Expert או Cloud Architect, אני אפילו מקבל את ה-SRE, כי ה-SRE - אני מבין את העבודה שלו, גם אם אני לא בטוח שצריך SRE אבל ניחא, “בסדר”, כמו שאמא שלי אומרת . . . אתה צריך מישהו שיעשה לה Reliability בחברה? אני מבין את זהאבל אני לא כל כך מבין את ה-”DevOps Engineer” . . . .אני מבין “DevOps Consultant” - זו הייתה בחירה מודעת ללכת על ה-DevOps Consultant - אני בא, מלמד אותך לעשות את המתודולוגיה הזאת ואני משתחרר, אני הולך, כאילו . . . אני יכול לקבל אפילו DevOps Avdocat, או DevOps Coach - וזה תפקיד שאנחנו חושבים עליו הרבה, על איך עושים אותו בחברה.אני לא חושב ש-DevOps Coach יכול להיות Agile Coach - כי Agile Coach הרבה פעמים לא יודעים איך תוכנה עובדת . . . .אני לא חושב שאתה יכול לייעץ בתוך ארגון או לעזור לארגון לעשות טרנספורמציה, אם אתה לא מבין איך AWS ו-Linux ו-CI/CD Pipelines עובדים.כי אתה לא יכול לדבר באוויר - אתה צריך להראות . . . .נגיד, יש פרויקט שאני יכול לספר, בקצרה, עליו - עשו אותו בבנק בפינלנד, מאוד-מאוד גדולהם פשוט בנו איזושהי Framework של Pipelines ואת כל ה-Deployments והאיך עושים את ה-Enviromentsואז הם שנה עברו, צוות-צוות - לימדו את האנשים, החזיקו להם את הידייםתחשוב - זה בנק, זה מתכנתים Old School by definition - החזיקו להם את הידיים, שמרו עליהם, “תעשה - זה Dokcer, תעשה . . .”אז זה חשוב מאוד . . .(רן) וזה עבד?(יאיר) כן - הבנק עבר אוטומציה מטורפת . . . תראה, אני חייב לשים שוב פעם את הכל בסוגריים - בפינלנד, כשהייתי ברשות השידור בפינלד, אז הם עובדים ב-Scrum וזה קצת לא מה שאנחנו חושבים . . . זה לא רשות השידור בישראל, זה אתר מטורף שכאילו כולו על Infrastructure-as-a-Code והכל שם אוטומטי לחלוטיןאני הייתי שם, ראיתי מה הם עושים - זה קצת . . . מאוד היפסטרי כזה, לא יודע אם זה Applicable לגרמניה וישראל, אבל עדיין . . . . [רגע, אתר רשות השידור כמקום היפסטרי - תן לזה לשקוע . . .]אבל עדיין - הבנק הזה עבר . . . בנק מאושר, הם עשו את זה.בטוח שיש להם מלא בעיות, אני בטוח שזה לא . . . צריך גם להגדיר את זה - מבחינתי, DevOps זו אוטופיה וזה משהו שאנחנו כל הזמן עובדים עליואין Endless loop of measurments . . . .(רן) כן, אז זה בעצם לבוא - אם אני מתרגם את מה שאתה אומר - זה לבוא ולהגיד ש”יש איש DevOps” או ש”יש צוות DevOps” זה אולי שקול ללהגיד “יש איש חדשנות!” או “יש צוות חדשנות!” - אז מה, זה אומר שכל השאר לא חדשניים? זה אומר שכל השאר לא עושים את זה? . . . . אז לבוא ולהגיד ש”יש איש DevOps” זה לבוא ולהגיד שכל השאר לא עושים את זה - וזה בדיוק האנטי-תזה למה ש-DevOps בא ואומר: DevOps בא ואומר שזה של כולם, זה לא רק של מישהו אחד.(יאיר) בדיוק - זה גם של ה-Salesman וזה גם של ה . . . .אני אגיד לך דבר כזה - אם ה-DevOps נשאר בתוך קבוצה מאוד קטנה של שלושה אנשים, אז לא עשינו כלום . . .אם DevOps נשאר קבוצה של שבעה אנשים - לא עשינו כלום . . . .אני לא יכול להגיד לך אם אני יודע . . . עכשיו קוראים לזה “BizOps” ו-”DesignOps” ו-”GitOps” וכל מיני . . . ה-”PeopleOps” . . . אני חושב שכל הדברים האלה מגיעים מאנשים שלא כל כך הבינו . . . .(רן) כן, אז יש את הצד התרבותי - ועכשיו אתה יודע, זה באמת . . . אני חושב שכולם יודעים שהוא קיים, אבל עד שאתה לא באמת חווה את זה, אתה לא באמת מבין מה המשמעות של זה - ולפעמים אני חייב להגיד שגם אני עושה את הטעויות, ורק כשאני מסתכל על זה מהצד - אז אני קולט שעשיתי שם טעויות.אז זה עניין שלוקח הרבה מאוד זמן להבין אותו - ובהקשר הזה, אנשים כמוך, שראו הרבה מאוד חברות ויש להם את הניסיון הזה, יכולים לבוא ולתת את הפרספקטיבה הנכונה.אבל יש גם את העניין הטכנולוגי, שקצת נגענו בו - וחשוב להגיד ש-DevOps זה שילוב של שניהם, ואני חושב שזה נאמר כבר אלפי פעמים, אז פה אנחנו לא חדשים - אבל בוא רגע נדבר על הצד הטכנולוגי, ואולי ככה נעשה איזושהי סקירה קצרה של אילו דברים מעניינים, בצד הטכנולוגי, קרו בזמן האחרון, שבעצם נותנים לנו ומאפשרים לנו לקחת את ה-DevOps צעד אחד קדימה.(יאיר) אוקיי, אז אני חושב שהדבר הכי חשוב שאנחנו רואים לאחרונה זה כניסה של APIs לעולם ה-Infrastructure.בעצם, מה שאנחנו רואים זה שנכנסים כלים של פיתוח לעולם ה-Infrastructure.אני אתן לך דוגמא - כשאני הייתי SysAdmin, היו לי כמה Batch-scripts, ואני לא חושב ש-Git היה אז - וגם אם היה, לא הייתי חולם לשים את זה ב-Git . . . הייתה לי ספרייה כזו של Script - Install - Install Apache . . . . עכשיו זה עולם אחר - אתה לא יכול יותר לעשות את זה בצורה כזאת, כי המערכות כל כך מורכבות - אתה רוצה שכולם יחלקו את המידע ושזה יהיה דקלרטיבי (Declarative) ככל האפשראז בעצם תחשוב על זה - כלי כמו Kubernetes, כלי כמו TerraForm, כלי כמו CDK - משתמשים בעצם ביכולת שענקי התקשוב בענן ו-Google נתנו לנו בעצםבעצם, המפתח וה-Operator מתחילים לעשות קונסולידציה (Consolidation) - הם שניהם עושים הרבה Merge Requests ו-Pull Requests ו-Git ניהיה ה-Source of Truthזה Hopefully, זה לא תמיד קורה . . . אבל אם תחשוב על זה, אתה בעצם משוחרר פתאום - ה-AWS שאני התחלתי לעבוד עליו היה Datacrnter קלאסי . . . הווה אומר - אתה עושה Provisioning למכונות, אחרי זה הם התחילו להוסיף Service-ים - ה-S3 וכל הבניינים האלה.עכשיו - זו מפלצת של Service-ים . . . .מה שאני מנסה להגיד זה שיש את הדבר הזה שאומרים “No Vendor locking” - אבל אם אתה סטארטאפ צעיר, עני יחסית, אין לכם הרבה כסף, אז נכון - זה יעלה לך כסף, אני מסכים, אבל כשאני חושב על העבר ואני חושב על ההווה - אתה יכול, יחסית בזול, אם אתה תחשוב על זה טוב, לבנות לעצמך מערכות ממש טובות - ואחרים עושים לך Lift & Shift.לדעתי, אם האתוס, כשאני הייתי צעיר, היה “בוא נבנה לבד הכל, בוא נעשה הכל לבד” - עכשיו, מי שעושה את זה הוא מתאבד . . .אתה לעולם לא תסיים . . .(רן) אני מסכים לגבי המורכבות - אני חייב להגיד שכל יום, כשאני נכנס ל-Dashoboard של AWS, אני מגלה שם שירותים חדשים שאני לא מבין, אני אפילו לא יודע איך קוראים את השם שלהם, שלא לדבר על מה הם עושים . . . בחלק קטן מאוד שלהם אני משתמש.עכשיו, דיברנו על הדמוקרטיזציה של ה-Infrastrucure - אני אגיד את זה, עד שזה יקלט - אחד האתגרים שלי באופן אישי יצא לראות כשבאים ומכנסים פרקטיקות של DevOps, זה שלאנשי הפיתוח לפעמים קשה לעכל את זה - והדילמה היא . . . כי עכשיו לא צריכים לדעת רק את שפת התכנות - לא רק צריכים לדעת Java ואת כל הספריות שלה או Python או Whatever - הם גם צריכים להבין Infrastructure, משהו שלפני זה מישהו אחר עשה להם, אז עכשיו גם הם צריכים להבין בזה . . .ונשאלת השאלה - מצד אחד זה טוב, אבל מצד שני גם נשאלת השאלה - מהי רמת האבסטרקציה (Abstraction) הנכונה? זאת אומרת - איזו אבסטרקציה צריך לחשוף למפתחים, כדי שיהיו פרודוקטיביים? כדי שבאמת נוכל . . . כדי שהם יהיו איתנו onboard בכל הסיפור הזה של ה-DevOps - וזה די מתקשר לכל הסיפור הזה של Developer Platform, שאני יודע שאתה רוצה להזכיר . . . .אז בוא רגע נדבר על זה - מניסיונך, איזו רמת אבסטרקציה נכונה יכולה לעבוד, כדי שמפתחים יהיו לגמרי Onboard ופרודוקטיביים?(יאיר) תראה, זה מאוד מאוד תלוי . . . אני חושב שקשה לי לתת לזה תשובה אחת.אני חושב שזה גם משתפר עם הזמן, וזה גם מאוד תלוי מי המפתחים - יש מפתחים שמתים לדעת את הדברים האלה ויש מפתחים שלעולם לא יגעו בזה גם . . . (רן) אז אם אתה מגיע עכשיו לחברה, נניח - או אולי אתה יכול להיזכר באחד המקרים האחרונים, שהגעתם לחברה ואני מתאר לעצמי שבאיזשהו שלב גם השאלה הזו עלתה: האם אנחנו רוצים לייצר פלטפורמה למפתחים, ואם כן - אז מה אנחנו רוצים לחשוף להם? האם לחשוף להם Barebone Kubernetes? האם לחשוף להם איזשהו ממשק מעל? האם לחשוף להם שלושה ממשקים מעל? זאת אומרת - איך? מה אנחנו חושפים למפתחים פה?[רפרנס - 368 Kubernetes and Dyploma at outbrain](יאיר) תראה, הייתי אומר שמקרה קלאסי . . . הרבה פעמים, אפשר להמליץ לאנשים להשתמש . . . או שאתה בונה את הפלטפורמה להם . . . הכי טוב למפתחים זה לעבוד עם API - ל-Kubernetes יש API, ויחסית נוח לייצר מולו דברים.אם נגיד . . . כלים כמו TerraForm וזה, אם הם פחות אוהבים, ובכל מקרה עדיף שה-TerraForm שלך יהיה בתוך ה-CI/CD Pipelines, עדיף שכמה שפחות אתה “תעשה עם המקלדת” TerraForm . . .באופן כללי - כמה שפחות מקלדת זה יותר טוב.אני חושב שאם הם בעניין, אז אפשר גם לפתוח קצת, לתת להם קצת kubectl, קצת . . . אבל API - זה הדבר.ולתת להם את זה לאט - כי יש כאן גם Context change - הבנאדם כותב Java, או איזושהי שפה, המון שנים - ונוח לו.הוא מבין שמשהו משתנה, והוא לא רוצה שתפחיד אותו . . . זה ה-Level של האבסטרקציה.או שאפשר להשתמש בכלים כמו humanitec, למשל, שבעצם נותנים לך עוד שכבה, נותנים לך UI יפה כזה מעל ה-Kubernetes - ומחברים לך את כל ה-Dots . . . ואז בעצם יש לך מעיין משהו מאוד נוח לשימוש, שאני חושב שאחרי הסבר מאוד קל אז כל מפתח ישמח לעבוד איתו.ושוב פעם, זה חוזר לעניין הזה שאני מאוד מאוד מאמין בו - אל תבנה לבד כלים, תשתמש בדברים מוכניםאתה חוסך המון זמן וכסף.(רן) כן . . . דרך אגב, אני לא הכרתי את humanitec, אז תודה על הרפרנס . . . אני מסתכל עכשיו באתר וכתוב שזה “Enable developer self-service” - אז מה זה “Self Service”? זה אומר לתת למפתחים להקצות לעצמם משאבים, בזמן שהם צריכים, בלי פגישה ובלי טפסים, לצורך העניין? לייצר API, שהם יכולים דרכו לעשות Provisioning ל-Workloads שלהם?(יאיר) בדיוק . . . (רן) . . . כשעל פניו, זה גם משהו ש-Kubernetes נותן, אבל יכול להיות שהם עושים את זה בצורה יותר “הומנית”, בצורה יותר נוחה . . .(יאיר) מה שהם עושים זה שהם בעצם נותנים עוד שכבה של אבסטרקציה - ובעצם הם עוזרים לך, אתה לא צריך לעשות את ה-Glue, הם עשו בשבילך את כל ה-Glue . . . אני לא יודע אם אתה מכיר או חי את ה-Kubernetes, אבל Kubernetes [זה משהו ש]צריך לדעת לתפעל אותו.אם אתה פשוט זורק Kubernetes בענן איפשהו [רעיון לספורט אולימפי חדש?] וחושב שהדברים יהיו שמחים - אז זה לא, אתה תיהיה מאוד מסכן.הם פשוט מקלים עליך בהרבה הרבה דברים - הם עשו המון עבודה, הם הוסיפו המון APIs, הם הוסיפו המון ממשקיםהם צוות מאוד מאוד חזק - המון אנשים שבאים ממקומות מאוד טובים . . .(רן) . . . דרך אגב - מקלים עליך מהצד של לתפעל את ה-Cluster עצמו, או בצד של להתממשק אליו ולהשתמש בו?(יאיר) יותר בצד של להתממשק ולהשתמש בו, אבל הם גם יכולים לספק לך לפעמים את ה-Cluster, אם אתה רוצה.ואז אתה על ה-Cluster שלהם . . . כל מיני דברים כאלה, בהחלט.(רן) אז יצא לנו לדבר ספציפית על Kubernetes, אבל מן הסתם זו רק דוגמא - יש גם כלים אחרים בעולם, ותהיתי האם פה יש לך אילו-שהן תובנות, לגבי איך יראה ה-Stack הטכנולוגי של עוד X שנים? . . . לא יודע, תבחר X . . . נגיד 5 שנים? 10 שנים? האם תיהיה איזושהי קונסולידציה (Consolidation) לכיוון איזשהו Stack מיוחד, או שאנחנו נמשיך לראות ככה הסתעפויות - ואני יודע שיש פה מן הסתם גם שאלות עסקיות וכלכליות, זה לא רק שאלה טכנולוגית, ברור לגמרי . . . אבל, זאת אומרת, מהדברים שאתה רואה היום - האם אתה רואה ניצנים של התפתחויות חדשות בנושא של הפלטפורמות ענן?(יאיר) אני חושב שהפלטפורמות ענן - החלום שלהן זה . . . הן עובדות בשיטה של סוחר סמים - הן רוצות שתיכנס בחינם, כשאתה חלש וקטן זה נראה לך זול, אתה קונה כמה שיותר שירותים, ואחרי איזה כמה זמן “הו, לא! אני מכור ל-Lambda!” או “אני מכור ל-ALB” . . . אתה לא יכול לצאת מזה.אז הם ישפרו וישדרגו את השירותים שלהםאם, נגיד, Azure ו-AWS נכנסו חזק ל-Kubernetes, הם יעשו “humanitec משל עצמם”, איכשהוהם יעלו על הגל הזה.אני חושב שהרצון של האנשים הוא פשוט לעבוד מהר יותר - והרצון של האנשים לעבוד מהר הולך בניגוד גמור לרמה של ה-Complexity שאנחנו מתעסקים איתה כי microServices זה נחמד, אבל זה קשה לתפעול - צריך המון המון Context, המון המון דבריםוה-Context משתנה המון, אתה . . . . יש איזשהו כלי שאתה חושב שהוא מגניב, ופתאום הוא נעלם לגמרי, ואתה לא יודע מה יהיה הכלי הבא.אבל אני חושב שזה ילך לעוד ועוד אבסטרקציות - עוד ועוד אבסטרקציות.אנשים, אפילו אנשי Ops - מעט מאוד אנשים התחילו “להיכנס מתחת לברזל”, ועוד ועוד אנשים יעלו מעל . . .אני אתן לך דוגמא, ברמת עבודה: אני והבחור השני, שהוא יחסית “ענתיקה” אצלי בצוות - אנחנו, יש לנו תמיד את השאלה הקלאסית שקשורה ל-TCP ול-HTTP - אתה לא מבין כמה אנשים עם ניסיון לא יודעים, לא יכולים להסביר לי את הדבר הזה . . .ותמיד אומר לי הבחור היותר צעיר בצוות - “אבל אתם עתיקים, אתם . . . .”אבל איך אתה יכול לפתור? עדיין ה-ALB שלך . . . מצטער, איך אתה יכול לפתור תקלה, אם אתה לא מבין ואתה לא יודע מה זה Three-way handshake? אני לא יכול, אני מצטער - זה מעצבן אותי . . . (רן) אני כאילו מתפתה לבוא ולהגיד “בוא תשאל אותי רגע את השאלת ראיון בשידור”, ונראה אם אני מצליח לבזות את עצמי, אבל אני אחסוך את זה לעצמי . . . . אתה יודע מצד אחד, יצא לי לחשוב על זה כמה פעמים: תראה, אני יודע איך עובד TCP ו-Three-way handshake, סבבה - אבל יש עוד הרבה דברים שאני לא יודע, אוקיי? אני לא יודע איך עובד הה-CPU ואני גם לא יודע איך עובד ה-GPU ואני לא יודע איך עובד הזכרון של ה-GPU - ויש עוד המון דברים שאני לא יודע.באיזשהו שלב, אתה יודע - זה איזשהו צורך השרדותי: אם אתה תדע את הכל, אתה לא תדע להבחין בין מה שרלוונטי לך לבין מה שלא רלוונטי, מעבר לזה שזה לא פרקטי לדעת את הכל.אז אני אומר שבאיזשהו מובן, זה כאילו מעצבן אותך שהם לא יודעים TCPו-Three-way handshake - ומצד שני, הם “מפנים מקום ב-RAM שלהם” לדברים אחרים, שאולי הם יותר רלוונטיים . . . אז יכול להיות שבראייה השרדותית, הם אולי עשו את הבחירה הנכונה, אפילו שהם לא עשו את זה במודע - אבל הם עשו את הבחירה הנכונה של “בוא לא נלמד את זה, כי זו בעיה פתורה - ואני אשקיע את הזמן בללמוד HELM או Whatever, דברים אחרים שיש להם מקום בזכרון . . . .(יאיר) קודם כל, קיבלתי לעבודה אחד כזה, אז . . . אני נשמע נוקשה אבל אני ממש לא נוקשה.(2) אני חושב - וב-Context של השאלה זה נאמר גם - אני אומר לו “השאלה היא לא… אני לא רוצה שאתה תגיד לי . . .” - כי היה מישהו שלא היה כל כך מומחה לרשתות, שנתן לי מרמת ה-ARP, ה-MAC, והוא נכנס שם ממש לפאקטות (Packets) - ואמרתי “בסדר, זה לא מעניין אותי גם . . . “אבל מה שכן, ב-Context של Infrastructure Engineer, רק תן לי את ה . . . . אני לא מצפה ממך עכשיו להיות אלוף העולם ברשתות, אבל אני רוצה שלפחות תדע שיש שכבות וזה באמת לא הרבה לבקש את זה, לא מדובר פה באיזה Pinpointing, כן . . . מדובר ב . . .אתה יודע - יש שכבות ואתה לא יכול לפתור את ה . . . זה אומר - מבחינתי זה אומר, וסליחה שאני לא מסכים . . . אבל שוב פעם - קיבלתי מישהו גם כשהוא לא ידע את זה, כי הוא ידע מלא דברים אחרים . . . .אז זה לא 100%, כן? אבל . . . (רן) כן - הוא הראה יכולת להעמיק, אתה אומר . . . ודרך אגב, אנחנו מן הסתם סוטים פה לנושא של “איך מראיינים בנושא של DevOps” . . . אבל זה גם נושא מעניין, אולי גם על זה צריך להקליט פעם משהו...אתה אומר, אבל, שהוא העמיק במשהו, אוקיי? הוא הוכיח שהוא יודע להעמיק, ספציפית . . . (יאיר) אני אגיד לך את האמת - באמת באמת - אני מחפש את ה-State of Mind.טכנולוגיה אפשר ללמודהשאלות האלה הן רק יותר כדי לדעת . . . תשמע, אחרת אני אקח אנשים עם State of Mind “מהרחוב” ואני אלמד אותם - ואני לא יכול.השאלות האלה הן איזשהו “בזיק” שאני זורק באוויר כדי לראות איך הם מגיבים - אבל בעיקר חשוב לי איך הוא הוא חושב? האם הוא בא עם סקרנות? האם הוא בא עם יכולת לעשות אבסטרקציה מהדברים שהוא מתעסק בהם? או שהוא מפציץ, או שהוא רובוט . . . (רן) בוא נחזור רגע לנושא שלנו - ואנחנו כבר ככה לקראת הסוף, אז נבחר עוד נושא אחד.רציתי אולי קצת לדבר על Cloud Native - מן הסתם זה Term ששומעים לא מעט . . . מה זה? למי זה טוב? מתי אני צריך את זה?אתה יודע - כולם מדברים על זה, אולי כדאי שגם אני אדע מה זה . . . .(יאיר) אוקיי, קודם כל - Cloud Native זה דבר שכל ברנש או ברנשית שעובדים בפיתוח כרגע כדאי שידעו.זה בעצם גם . . . זה גם סוג-של Non-profit organiztion שמונהול בעצם ע”י כל הענקיות - זה CNCF - ה-Cloud Native Foundationאני מצטער, אבל לפעמים אני שוכח מילים בעברית . . .ובעצם זה גם מביא איזושהי גישה לאיך בעצם אתה אמור לפתח תוכנה - בענן.עכשיו - אני יודע, ואני גם אומר את זה: “ענן התקשוב” הוא לא איזו המצאה כל כך מדהימה וחדשה, אני חושב שמי שעבד אפילו עם Mainframe יודע שבעצם זה היה סוג של ענן תקשובמלא מחשבי-על מחוברים ברשת.אבל כן - אנחנו עכשיו נמצאים בסיטואציה שבה העולם משתנהזאת אומרת, אפילו חברות ענק מתחילות - וזה בגרמניה, המדינה שהיא, נגיד, מאוד מאוד איטית ביכולת שלה לחבק ולקבל טכנולוגיות - מתחילה עכשיו לצאת מהעולם הזה של ה-On-Premise מעולם הזה של “אני צריך את ה-Server-ים שלי אצלי כי הם Secure” . . .ומתחילה לחשוב על הענן בתור “צביר של שירותים”.וצביר השירותים הזה יכול לקדם אותך לעבוד מאוד-מאוד-מאוד מהר.אם אתה מוסיף לזה את הקונספטים של Agile ו-DevOps, אתה יכול בעצם לייצר לעצמך סביבות אלסטיות בטירוףאתה בעצם יכול להשתמש במלא כלים.אני רק אוסיף עוד דבר אחד - זה [אלו] קהילות מאוד מ אוד Vibrant - כל ענקיות התוכנה משלמות מלא-מלא כסף . . .למשל - HELM נשלטת לחלוטין ע”י Microsoft - כל אנשי Microsoft שעובדים על HELM מקבלים משכורות מ-Microsoft . . . (רן) כן, ראיתי את זה ב-GitHub, אני חושב שמי שיצר את זה עובד שם וככה זה התגלגל, אבל אפשר לדבר על זה כמה מילים . . .[מעניין -Matt Butcher, ונראה שבדיוק החודש הוא עבר הלאה . . . .] רק רציתי להעיר, להיות קצת יותר קונקרטי: אמרת “צביר של שירותים”, אז בוא נסתכל רגע על דוגמא קונקרטיתלמשל Storage - אם בעבר ה-Storgae היה היכולת לעשות Mount לאיזשהו דיסק פיזי בתוך המחשב שלך, אז היום Storage, בהרבה מקרים, זה משהו שנמצא רחוק - S3 זו דוגמא קלאסית.עכשיו - אתה לא יודע כמה מחשבים יש מאחורי זה, אתה לא יודע איפה מאחסנים את זה, אין לך שום מושג . . . אבל יש לך API - ואתה יודע שזה אלסטי: כשתצטרך, יהיה לך את זה - ואתה תשלם רק על מה שאתה משתמש.זו דוגמא, דרך אגב - השירות, ספציפית S3, היה קיים הרבה לפני שהמציאו את המונח Cloud Native - וכמו בהרבה מקרים, כמו ב-Design Patterns, קודם כל מסתכלים על מה קורה ורק אחר כך נותנים לזה שם . . . אז למעשה אתה אומר - Cloud Native זה בעצם שנתנו שם להרבה מאוד התנהגויות שמצאו בשטח, שמה שמשותף לכל ההתנהגויות האלה זה שמשתמשים בשירותי ענן שונים . . .ודרך אגב - אנחנו אומרים “ענן”, אבל זה לא חייב להיות ענן, זה גם . . . אני מכיר אימפלמנטציות (Implementations) של Cloud Native, נקרא לזה - שהן בכלל לא ב-Cloud, שהן On-Premise . . . .(יאיר) נכון . . . (רן) . . . כי הם משתמשים בקונספטים של Cloud Native - אז אולי המילה “Cloud” היא קצת אולי מבלבלת . . . (יאיר) . . . יש כלי Native וכל ה . . . כל הדברים האלה, בהחלט.שוב פעם - אל תשכח שמתחת לכל הדברים האלה, זה Marketing Tools, אוקיי? . . . אז ברור שחברות הענן רוצות שאתה תחשוב שהן - יש להן בעלות על הענן, כי אתה משלם להן כסף . . .יש סיבה לזה ש-Kubernetes שיחררה, או ש-Kubernetes שוחרר מ-Google - אבל Borg לא שוחרר מ-Google . . .כי Kubernetes היא גירסת הOpen Source של Borgאתה גם רואה את ה-Distruption ש-Kubernetes עושה ואיך הוא תפס את AWS ואיך ש-AWS רצה אחרי זה - ואתה מבין למה.יש פה עניינים - יש פה סכומי-עתק, כן? כי AWS - זה המנוע של Amazon, ו-Microsoft שמה את כל הביצים שלה בריצה מטורפת על Azureו-Google קצת עובדים אחרת - אני אף פעם לא מצליח להבין את הפילוסופיה של מה שהם מנסים לעשות, אבל יש להם את האימפלמנטצית (Implementation) Kubernetes הכי טובה, אז אתה תמיד צריך לזכור - אפילו שאני מדבר במשפטים אורכים עם הרבה פסיקים [1+] - בסיכומו של הם רוצים למכור לך משהו . . . אתה יכול לעשות את כל הדברים האלה אצלך ב-On-Prem, אתה יכול להריץ איזו אימפלמנטציה שאתה רוצה, זה לא רק מהם - ואתה יכול לקבל את אותם Service-ים - אצלך.ההבדל היחיד שהייתי מוסיף זה ששם מישהו עושה לך את ה-SRE, את ה-Lift & Shift - הוא דואג . . .מישהו דואג שה-S3 שלך תמיד יהיה שם - ואם הוא לא שם, אז הוא יחזיר לך את הכסףוזו נקודה שהיא מאוד מאוד חשובה להבהרה - כי בעצם כל העניין הזה שאתה משלם למישהו אחר קצת מוריד מעצמך את העומסואתה יכול לבחור במה אתה רוצה להתעסקזאת אומרת - אני בכלל “לא רוצה לראות” את ה-Infrastructure, אני לא רוצה לשמוע מ-VMsאני רוצה X מקומות שאני עובד איתם - כמו שאמרנו, נגיד ארבעה-חמישה Services - ושחרר אותי מהכל, אני לא רוצה לראות את זה - ואתה יכול להגיע למקום הזה עכשיו, או להתקרב אליו מאוד-מאוד-מאוד.(רן) אז אם ננסה לסכם רגע את ה-Take-away מהסעיף הזה של ה-Cloud Native, אז(1) זה אוסף של קונספטים שכדאי להכיר(2) צריך לזכור שיש מאחורי זה Marketing, אז לא הכל שם “חקוק בסלע” [מועמד לפרס ה-understatmenet של השנה?]אבל כן יש שם לא מעט Best Practices שכדאי להכיר ולאמץ את מה שרלוונטי אליכם.וה-Term עצמו - “Cloud” - יכול להיות אולי קצת מבלבל, כי תכל'ס אני חושב שכמעט כל ה-Best Practices שקיימים שם, גם יכולים להיות מחוץ ל-Cloudאני יודע שיש הרבה מאוד כלים שהם כלים מצויינים, בלי שום קשר ל-Cloud - כמו Grafana ואחרים - שהם חלק מתוך Cloud Native, ואין שום תלות בינהם לבין היכולת לרוץ על VM ב-Cloudאבל בכל אופן - יש שם לא מעט Resource-ים טובים, וכל הענקים למעשה מובילים את זה - כי אף אחד לא רוצה להישאר בחוץ, כי זו פלטפורמת Marketing מאוד טובה . . . (יאיר) לגמרי . . . .(רן) בסדר, אננחו מגיעים, ככה, לסיום - האם יש משהו שתרצה עוד להוסיף?(יאיר) אני חושב ש . . . הדבר שהייתי רוצה להגיד לאנשים זה שאם אתם יוצאים למסע הזה, של DevOps ו-Cloud Native, ואתם רוצים לעבוד עם הכלים האלה - תחשבו טוב למה . . . מה הכלים האלה יתנו לי? כי כלים-לשם-כלים זה Idle . . .תמיד תחשבו - וזה אולי מביא אותנו בסוף גם להתחלה, ל-Culture ול-DevOps - תחשבו איך הכלים האלה ישפרו את מה שאנחנו עושים ביחד.ומה שאנחנו עושים זה שאנחנו רוצים שה-Business יעבוד . . . איך זה יעשה את ה-Business יותר טוב?מה ה-Added value שאני מקבל על זה - על כל צעד שאני עושה:האם יש לי את האנשים לזה? האם יש לי את הארכיטקטורה המתאימה לזה?למשל, תשים Monolith ב-Kubernetes - סתם, אתה לא מרוויח מזה הרבה, אתה “קונה סבל”, מה שנקרא . . .(רן) . . . צריך גם את המוכנות הטכנולוגית - אבל גם את המוכנות התרבותיתשגם האחרים בחברה ירצו להיות חלק מזה, ואתה לא סתם זורק עליהם סט של טכנולוגיות שהם יחליטו להתעלם מהן ביום שאחרי . . .(יאיר) וגם הייתי אומר שתראה אם זה מתאים . . . הרבה פעמים אני הייתי חלק מצוותים - אני חייב להיות כנה עם זה - בחרנו כלים כי הם נראו לנו מגניביםבחרנו כלים כי הכרנו אותםבחרנו כלים כי זה מה שהחלטנו באותו הרגע, כי הייתה ישיבה ומישהו היה צריך לצעוק משהו . . . [זה ברקע]קצת . . . זה מה שנחמד בזה, ומה שאני רואה עכשיו - איך כל כך הרבה אנשים חוזרים על אותם Patterns של שגיאותוכל מה שאני רוצה להגיד זה “גם אני הייתי שם!” - ועכשיו אני בחוץ, אני לא עושה את השגיאות, אני רק רואה את השגיאות - בואו נעצור רגע, בואו נחשוב . . . בואו נעשה משהו יותר טוב הפעם.(רן) כן . . . טוב - תודה יאיר, תודה רבה! היה כיף והיה מעניין - ובהצלחה והמשך הצלחה ב-Polar Squad.נשמור על קשר - להתראות! האזנה נעימה ותודה רבה לעופר פורר על התמלול!

[קישור לקובץ mp3] שלום וברוכים הבאים לפודקאסט מספר 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: שירתתי בצבא, הייתי חוקר עבירות מחשבעבדתי אצל שי אגסי ב-Better Placeהייתי ב-Intel Security - מה שהיה Mcafee - אז יש לי קצת רקע ב-Securityולפני שפתחנו את 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 . . . (רן) לא, “גיבורים בעל כורחם” הייתה סדרה אמיתית, בדרך כלל על חיילים שהגיעו לכל מיני מצבים מאוד קשים ואז נאלצו להראות את הגבורה שלהם - אז כמו שהם לא בחרו להיכנס לשם, גם אתה לא בחרת להיכנס לשם אבל יצאת בגבורה . . .(שמעון) כן, זה מה שקרה . . .אז באמת, אחרי 4 וחצי שנים נפלאות ומדהימות ב-Iron Source, יצאתי לדרך עם השותף של - אייר זילברמן - ופתחנו את Datree.מה שאנחנו עושים היום זה עוזרים למנוע מ-Misconfigurations להגיע ל-Production - בסביבת Kubernetesנכון, זו בעיה הרבה יותר רחבה מ-Kubernetes, וצריך אותה בכל מקום - אבל אין מה לעשות, אתה סטארטאפ ואתה צריך להתמקדאולי זה כבר לפרק אחר - עשינו שינוי מ-Top-Down ל-Bottom-Up, ל-Product-led Growth [אייר כבר עשה את הפרק הזה . . . ] - והיה לנו חשוב לעשות Flow מאוד ברור ומאוד פשוט - אתה מגיע לאתר והדבר הראשון ששאתה רואה מול הפנים שלך זה Copy-Paste של curl לטרמינל ואתה מתקין את ה-CLI . . .בשבוע שעבר חצינו את רף ה-5,000 Star-ים . . .(רן) מזל טוב! . . .(שמעון) תודה רבה, אנחנו באמת מאוד גאיםוככה יצאנו לדרך - כדי לעזור למתכנתים לעשות את הדבר הנכון.(רן) אוקיי, אז 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 - כש-Gatekeeper זה אותו דבר, מריץ את ה-Rego Policies - אבל זה עובד כ-Admission Webhook Controller בתוך Kubernetes.קצת דומה למערכות הפעלה - System Callsבעצם, כשמתרחשת פעולה . . . .(רן) רגע, שנייה, בוא - אני אעצור אותך . . . יש פה הרבה מושגים ואני רוצה לפרוט אותם.אז קודם כל, ה-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, שלושים חוקים, שהם, נקרא לזה “נכתבו בדם”מתוכם 21 מופעלים ב-Default ו-9 כבויים.ואתה יכול להריץ את זה על Helm Chart-ים שלך או על Kubernetes YAML-יםלאחר מכן, אתה יכול להיכנס ל-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, לך תתקין את זה” . . . מבחינתי זה אחד הדברים שאותי, כאילו, מדליקים.(רן) ואתם בתל אביב . . . אי שם . . .(שמעון) כן . . .(אורי) לא נורא . . .(רן) שיהיה בהצלחה, תודה שבאת.(שמעון) איזה כיף - תודה רבה!(רן) להתראות האזנה נעימה ותודה רבה לעופר פורר על התמלול!

With time to market pressures constantly increasing, technology organizations are moving away from traditional waterfall development workflows and towards Agile/DevOps software development practices. Originally introduced in enterprise, IT, and data center contexts, these methodologies have made their way into embedded engineering organizations, but at the potential expense of software quality. Can embedded tech companies, especially safety- and security-critical ones, afford to sacrifice quality for speed? Brandon and Rich debate.Later, the Insiders are joined by Yannick Moy of AdaCore to discuss how the MISRA C coding standard, which was originally developed in 1998, is holding up given the complete overhaul of automotive (and other) technology stacks since the standard’s inception. Is C, a notoriously compliance-challenged language, still the best bet for safety-critical systems that are now operating alongside a host of other connected applications?Finally, Perry Cohen looks into the true cost of bad software in this week’s Tech Market Madness. After reviewing Herb Krasner’s “The Cost of Poor Software Quality in the U.S.: A 2020 Report,” he finds out just how much defunct software projects, bad legacy code, and operational software failures set back the industry, and considers how DevQualOps could help recoup some of those losses while maintaining time to market.

La comunidad agilista tiene una cita los próximos 25 a 28 de enero en el Agile Trends Festival, un evento online y gratuito patrocinado por el Banco Santander que va a reunir a los más destacados expertos internacionales en el universo agile. Organizaciones ágiles, valor y eficiencia, producto e innovación y RR.HH y cultura son, por este orden, las temáticas que se abordarán cada día, a través de 80 sesiones, repartidas en ponencias, mesas redondas, talleres y debates. Flavio Leomil Marietto, Agile & DevOps de Santander Corporativo, explica la apuesta de su entidad por esta iniciativa que celebra em 2021 su segunda edición.Podcast ORH Futuro, con Maite Sáenz.

Akshay Anand, ITSM product ambassador at AXELOS, and David Crouch, senior advisor at Beyond20, join ASG CEO Mitch Ashley to share best practices and learnings from introducing and adopting Agile and DevOps in large organizations. Akshay and David discuss overcoming change management challenges and obstacles to increase adoption.

Estas metodologías que compilan en el Word, escalan en el mundo real? En este episodio invitamos a Nicolas Esmoris de Accenture para charlar un poco sobre las complejidades de los proyectos grandes. Cualquiera puede leer el how-to de ágiles o DevOps pero que pasa cuando tenés más de un equipo o más de 50 personas. En este episodio participan Andrea (@peorth), Ariel (@ajolo), Edu (@jedux) y Nicolas (@obiwanae).

Not too long ago we held a hugely popular two-day DevOps 2020 event. Due to the popularity of the speeches, we have now made them also available in our podcast. Guy Herbert is a Risk Futurist at Atlassian. Guy leads participants through the agile and DevOps development processes and the interactions with compliance during that process. He talks about how to use technology and process to improve organisations' development speed as well as hitting their compliance objectives. All DevOps 2020 event videos: https://hubs.ly/H0rnJgj0

The 9/11 boat lift in New York City and the Montgomery Bus Boycott of 1955-56 were both hugely successful projects, with important lessons for Project Managers. The leaders did speedy but effective planning and set clear goals. They hit all the milestones, and adapted as they went along. They communicated effectively and strategically. They were alert to risks and responded swiftly and decisively. In this episode we hear from two project managers who have studied these historic events through a project lens. Listen, learn, and get a free PDU! PDU Information Use the following information in PMI’s CCRS system to register the PDUs for this podcast: PDU Category: Online or Digital Media Provider Number: 4634 PDU Claim Code: 4634SUUQ11 Activity Number: PMPOV0075 PDUs for this episode: 1 About the Speakers: Mike Hannan is a leading-edge thinker and renegade who believes that we all must do more to unleash our boundless potential and solve increasingly complex global issues. He envisions a community-centric, expert-guided “power-to-the-edge” solution to most of these issues. He is a frequent speaker at annual corporate conferences, PMI events, and in the Agile & DevOps communities, with extensive experience coaching & training portfolio executives, PMO leaders,and PMs, and is lead author of the best-selling book, The CIO’s Guide to Breakthrough Project Portfolio Performance.   Shaun M. Simms, PMP, SAFe, PMO-CP, CSSGB, constantly seeks to find an individual's strength to empower them, and in the process improve organizations.  An award winning project manager with a portfolio over $1B, his favorite projects are those that bring equity to our society.  He is intrigued by the power of projects to change the world, and the unity it can bring teams. Shaun is currently on the Board of Directors for PMI Metro St. Louis, and the Advisory Board for Missouri State University's CX Certification.

In dieser Folge tauschen sich Stephan Lange, Managing Director ASG DevOps Services bei Accenture SolutionsIQ, mit Host Stephan Niklas zu Agile DevOps, Erfolgsfaktoren, KPIs und neuen Denkmustern aus. Dabei ist klar: Über Business Agility zu sprechen ist leicht – und wird im heutigen dynamischen IT-Markt häufig getan. Um allerdings mit Business Agility und Agile DevOps Erfolg zu haben, braucht es mehr als Worte. Mitarbeiter, die auf allen Ebenen befähigt sind essenziell für zuverlässige, schnelle Lieferzeiten und Produktinnovationen. Es geht um mehr, als nur die Einführung neuer Tools und Prozesse. Die eigentliche Herausforderung ist die Fähigkeit, alte Verhaltensmuster zu durchbrechen | SolutionsIQ auf der DevOpsCon 2019 in München

Read more stories like this here! https://thenewstack.io/ Prisma, from Palo Alto Networks, sponsored this podcast, following its Cloud Native Security Live, 2020 Virtual Summit held Feb. 11, 2020. Agile development teams may able to meet software release and update cadences at faster and faster rates — but ultimately, their deployments are only as good as the underlying code. Applications that lack robustness or have vulnerabilities that are discovered until only after its too late can defeat the whole purpose of Agile DevOps. The hard truth is that policies and practices must involve testing and monitoring from the outset of code development while extending throughout the entire CI/CD lifecycle. The main theme of this edition of The New Stack Makers podcast recorded live at Palo Alto Networks' studio in Santa Clara, CA, is how to protect software throughout the entire supply chain. The guests were: Dr. Chenxi Wang, a managing general partner for Rain Capital, a keynote speaker and a “Forbes” contributor. Rochelle Mattern, a Google Cloud customer engineer at Google. Gareth Rushgrove, a director of product management at Snyk The New Stack Publisher Alex Williams hosted this episode.

CollabNet VersionOne and XebiaLabs has announced a new mission: to build an integrated Agile DevOps platform together. The company's new CEO Ashok Reddy and president Derek Langone explain exactly what that means and what enterprises can expect from this merger.

Part 2 of our interview with Carri Bugbee and Joe Butson. Alan Annis, of Rocket Walk, gets their take on the tactical aspects of Agile Marketing.Discussion Includes:- Backlog grooming through prioritization- Kanban vs. Scrum- Virtual scrum boards. How do you choose a program?- The value of retrospectives- Project size estimationCarri has over 20 years of experience in managing marketing/creative teams, campaigns, projects, and events. She is often called upon to provide training or guidance to marketing teams (and executives) to help boost their knowledge and usage of social media, digital platforms/tools, and Agile methodologies.Joe is an Agile coach with experience in Agile DevOps, Scrum, Kanban, Scaled Agile Framework (SAFE), Disciplined Agile Delivery, XP, and Lean software development. He is a seasoned Agile practitioner and expert in helping cross-functional teams increase productivity, collaborate better, and cultivate collegial work environments. 

Alan, Co-Founder of Rocket Walk, discusses the strategic side of Agile Marketing with Carri Bugee and Joe Butson. Carri has over 20 years of experience in managing marketing/creative teams, campaigns, projects, and events. She is often called upon to provide training or guidance to marketing teams (and executives) to help boost their knowledge and usage of social media, digital platforms/tools, and Agile methodologies. Joe is an Agile coach with experience in Agile DevOps, Scrum, Kanban, Scaled Agile Framework (SAFE), Disciplined Agile Delivery, XP, and Lean software development. He is a seasoned Agile practitioner and expert in helping cross-functional teams increase productivity, collaborate better, and cultivate collegial work environments.  Discussion Includes:- Tips for implementing Agile Marketing- Benefits of Agile Marketing- Creating environments that promote both collaboration and individual responsibility- How to get team buy-in to change processes- How to create teams that are both happy and productive- Benefits of cross-trainingIf you'd like more information on Agile Marketing, or if you are interested in appearing as a guest on our show, please contact us at info@rocketwalk.com or visit our website, www.rocketwalk.com

SHOW: 71SHOW OVERVIEW: Brian talks with Chris Short (@ChrisShort, Technical Marketing @RedHat, CNCF Ambassador, writes at DevOps’ish) about DevOps 10th birthday, how Kubernetes helps DevOps, and the exciting news that Chris will be co-hosting PodCTL.SHOW NOTES:Try OpenShift 4 - http://try.openshift.comLearn OpenShift - http://learn.openshift.comRed Hat announces Global Transformation Office - https://www.redhat.com/en/blog/introducing-red-hat-global-transformation-officeChris’ DevOps’ish Homepage (subscribe to the newsletter) - https://devopsish.com/SHOW TOPICS:Topic 1 - Welcome to the show. Let’s talk a little bit about your background and the plethora of things you’re working on these days.DevOps’ish: Weekly newsletter covering cloud-native, DevOps, open source, and industry news Cloud Native Ambassador: Our Super Bowl is coming up (KubeCon)Ansible Operators (get your stickers at KubeCon)OpenShift team helping customers getting their clusters up and runningTopic 1a - BIG NEWS! Chris Short is joining the show to be a new co-host. Topic 1b - MORE BIG NEWS! Kevin Behr, Jabe Bloom, John Willis, Andrew Clay Shafer are joining Red Hat to create the Global Transformation OfficeTopic 2 - A couple of weeks ago, the DevOps community (and DevOps Days) celebrated its 10yrs anniversary. You’ve been involved in that community for a number of years. What are the big trends happening around DevOps these days? (have we figured out the difference between DevOps and SRE?)Topic 3 - One of the common challenges that companies often talk about it scaling Agile/DevOps across their company. What are some of the things you’re seeing that enable success? What are some of the common mistakes that companies make in trying to scale? Topic 4 - We tend to talk about Kubernetes quite a bit on this show. As you’re beginning to work with Kubernetes more, are you finding that it helps in scaling Agile and DevOps? Topic 5 - You’re going to be hosting a number of the PodCTL shows going forward. What are some of the topics that you hope to cover in 2019 and 2020?FEEDBACK?Email: PodCTL at gmail dot comTwitter: @PodCTLWeb: http://podcast.podctl.com

DevOps breaks down software development silos to encourage free communication and constant collaboration. Agile, an iterative approach to development, emphasizes frequent deliveries of software. In this podcast, Eileen Wrubel, technical lead for the SEI’s Agile-in-Government program, and Hasan Yasar, technical manager of the Secure Lifecycle Solutions Group in the SEI’s CERT Division, discuss how Agile and DevOps can be deployed together to meet organizational needs. Listen on Apple Podcasts.

BMJ Chief Digital Officer Sharon Cooper joined CIO UK Editor Edward Qualtrough to discuss end-to-end transformation, Agile, DevOps, open source and the CDO role during episode four of the CIO UK podcast. Find out how CDO Cooper and her team have used Agile, DevOps and open source technology for a complete back-end and front-end transformation at the BMJ. Cooper also discusses CIOs taking on product ownership and her concept of moving from IT to IP thinking.

DevOps suplanta Agile? Ainda precisamos de Agile agora que temos DevOps? Dá pra fazer DevOps em projetos não ágeis? Discutimos tudo isso e muito mais num episódio polêmico! Feed do podcast: www.lambda3.com.br/feed/podcast Feed do podcast somente com episódios técnicos: www.lambda3.com.br/feed/podcast-tecnico Feed do podcast somente com episódios não técnicos: www.lambda3.com.br/feed/podcast-nao-tecnico Victor Hugo, Giovanni, Quaiato e Brandão gravando o podcast Pauta: Pq estão dizendo que DevOps substitui Agile? DevOps é evolução do Agile? Sequestraram o Agile? Unindo soft e hard skills Como dar os próximos passos? Links Citados: Podcast do 10deploys sobre As metodologias Ágeis ainda são válidas em tempos de DevOps? Artigo do Atlassian avaliando se DevOps e Agile são amigos ou inimigos Participantes: Emmanuel Bradão - @egomesbrandao Giovanni Bassi - @giovannibassi Victor Hugo Germano - @victorhg Vinicius Quaiato - @vquaiato Edição: Luppi Arts Créditos das músicas usadas neste programa: Music by Kevin MacLeod (incompetech.com) licensed under Creative Commons: By Attribution 3.0 - creativecommons.org/licenses/by/3.0

Intel Shift changes directions on this high impact conversation with 3 top thought leaders on analytics and AI. In this show Dez Blanchfield, Intel’s Bob Rogers and Montefiore MD Michelle Gong soundoff on AI and Analytics. Starting off with a discussion around the advances that have taken place in analytics over the past 5-10 years followed up with some insights from Bob Rogers, a Harvard phD on the differences between advanced analytics and AI. The conversation then turned to Dr. Michelle Gong who shared some fascinating ways the hospital is utilizing advanced analytics to improve patient care. One example included using data identifiers to better predict when patients would require the assistance of a clinician. The episode concludes with some best of breed advice from the panel on how to apply analytics and AI into your business today. Tune in to hear these great insights and more. Dez Blanchfield, Chief Data Scientist, Gara Guru As an Industry Analyst, Business & Technology Consultant, covering Digital transformation, Cloud, Big Data & Analytics, Internet of Things, Machine 2 Machine, Cyber Security, Cyber Risk & Resilience & Smart Cities, Dez has invested his professional career of some two and a half decades thinking out and influencing the development roadmaps of technology companies, aligning them to the customer experience demands and possibilities of forward thinking digital enterprises. He sits on and works with boards of government and private sector organisations, to help uplift the digital quotient of organisations as a thought leader and practitioner across a broad range of disruptive technologies. He enjoys assisting organisations to disrupt themselves before being caught on the back foot by emerging new entrants or competitors. Passionate about leveraging the possibilities of new and emerging technology business, he is currently focused on bringing the likes of Cloud, Big Data & Analytics, Machine Learning, Cognitive Computing, Robotic Process Automation, Cyber Resilience, Blockchain and Agile DevOps to organisations to ensure their enduring success. Michelle Ng Gong, MD, MS, Director of Critical Care Research, Division of Critical Care Medicine, Jay B. Langner Critical Care Service Department of Medicine, Montefiore Medical Center Dr. Gong is the Associate Director for Academic Affairs, the Director of Critical Care Research in the Division of Critical Care Medicine at Montefiore Medical Center and Professor in Medicine and Epidemiology and Population Health at Albert Einstein College of Medicine. After receiving an engineering degree at the University of Pennsylvania, Dr. Gong went on to earn a medical degree at the Yale University School of Medicine. She then completed her postdoctoral training at the Beth Israel Hospital in medicine and at the Brigham and Women’s Hospital in the Harvard Combined Program in Pulmonary and Critical Care Medicine. She also studied at the Harvard School of Public Health, receiving her Master’s degree in Epidemiology. Prior to coming to Albert Einstein College of Medicine and Montefiore Medical Center, she was Assistant Professor of Medicine in the division of Pulmonary, Critical Care and Sleep Medicine at the Mount Sinai School of Medicine. She joined the Einstein/Montefiore faculty in July 2009. Dr. Gong is recognized nationally and internationally for her expertise in critical care research. A model clinician-researcher, her scientific projects influence her clinical care, and her patients influence her research. Her overall research focus has been on the prediction and prevention of acute critical illness and their complications. Continuously funded by the NIH for over 16 years for her research, her current projects range from acute respiratory distress syndrome (ARDS) to prevention of delirium, treatment of severe influenza and the development of new electronic acute care interfaces. Bob Rogers, PhD, Chief Data Scientist, Big Data Solutions, Data Center Group Bob Rogers, PhD, applies his experience solving problems with big data and analytics to help Intel build world class customer solutions. Prior to joining Intel, Bob was co-founder and Chief Scientist at Apixio, a big data analytics company for healthcare. He believes that accurate understanding of patient clinical and genomic data, physician behavior, and the characteristics of the healthcare delivery network are foundational to a better future for healthcare, and that Big Data analytics is essential to driving this transformation. Bob began his career as an astrophysicist, developing computer models of physical processes near super-massive black holes. He became interested in computational intelligence and incorporated research on artificial neural networks into his academic work. He co-authored the book “Artificial Neural Networks: Forecasting Time Series,” which led to a twelve-year career managing a quantitative futures trading fund based on computer models he developed. In 2006, Bob transitioned into healthcare at Carl Zeiss Meditec, where he was responsible for new product development for the diagnostic device that is the global standard of care for glaucoma. He received his BS in Physics at UC Berkeley and his PhD in Physics at Harvard.

Does Your Business Need An Agile-DevOps Makeover? by Ryn Melberg

Automate. Rinse. Repeat. Every day at every hour and every minute there are developers writing code, committing code to the repo, building snapshots, checking out stuff, debugging it, profiling it and generally making things happen continuously. So, why not have performance testing be part of that continuous world? It’s a hot topic in this edition of PerfBytes where we are joined by our fellow pancake-loving co-originator Carlos Chidiac as we debate the value and pragmatics of integrating performance into your continuous integration and continuous delivery process automation. Don’t be scared by James’ Perf Rant about CPT, Agile & DevOps and Carlos who both agree that ‘Speed Kills’ when it comes to your attempts to accelerate performance through automation. Mark shares a few technical tips and we generally advise you to be aware of the pitfalls of trying to promote speed over quality.Episode formally sponsored by www.flood.io, check it out!

Automate. Rinse. Repeat. Every day at every hour and every minute there are developers writing code, committing code to the repo, building snapshots, checking out stuff, debugging it, profiling it and generally making things happen continuously. So, why not have performance testing be part of that continuous world? It’s a hot topic in this edition of PerfBytes where we are joined by our fellow pancake-loving co-originator Carlos Chidiac as we debate the value and pragmatics of integrating performance into your continuous integration and continuous delivery process automation. Don’t be scared by James’ Perf Rant about CPT, Agile & DevOps and Carlos who both agree that ‘Speed Kills’ when it comes to your attempts to accelerate performance through automation. Mark shares a few technical tips and we generally advise you to be aware of the pitfalls of trying to promote speed over quality.Episode formally sponsored by www.flood.io, check it out!

IBM.COM/DEVELOPERWORKS Scott Laningham and John Swanson run down new content highlights on a new series on Agile DevOps, Spring Roo, Using Hadoop with Couchbase, investment analysis with IBM Rational Focal Point, an IBM SmartCloud Enterprise 60 day free trial, and more.

IBM.COM/DEVELOPERWORKS Scott Laningham takes a quick look at four new content pieces on developerWorks, IBM's premier resource for software developers and other IT professionals