יום חמישי, 22 ביולי 2021

414 Cloud Native Challenges with Liran from Rookout


שלום וברוכים הבאים לפודקאסט מספר 414 של רברס עם פלטפורמה - התאריך היום הוא ה-18 ביולי 2021, ואנחנו בעיצומו של גל איש-לא-יודע-כמה, וגם לא יודעים האם זה עיצומו . . . השעה היא 2100 בערב, שעון יקנעם-עילית, ויונתן מצטרף כ-Co-Host - היי יונתן! טוב שאתה פה איתנו שוב.
והיום נמצא איתנו לירן מחברת Rookout - ברוך הבא, מה שלומך?
(לירן) מצויין - קצת מאוחר, אבל זו שעה מצויינת לפודקאסט.
(רן) לתל אביבים זה כמעט בוקר . . .


אז תיכף תספר לנו קצת מה איתך ועל החברה - הנושא שלנו להיום, בקצרה, זה האתגרים המעניינים שיש מאחורי דברים שהם Cloud-Native, שזה בעצם גם העיסוק של החברה שלך.
אז ככה בשתי מילים - מי אתה? מה אתה עושה? מה עשית לפני זה?
  • (לירן) אז אני לירן חיימוביץ’, Co-Founder ו-CTO ב-Rookout
    • לפני שהצטרפתי ל-Rookout הייתי איזה עשר שנים במשרד ראש הממשלה, בוגר קורס אר”מ, למי שככה, מתעסק בדברים האלה.
    • בגדול, לפני חמש שנים החלטתי להקים סטארטאפ - וכמה חודשים אח”כ קרמה עור וגידים Rookout . . .
      • ו-Rookout היא חברה שמספקת כלים למפתחים, שמאפשרים להם “לצלול” לתוך הקוד לשהם, לדבג אותו להבין מה הוא עושה - גם כשהוא רחוק.
      • אני לא חושב שיש משהו יותר רחוק, היום, מאשר Cloud-Native ו-Cloud בכלל.
(רן) כן . . . אז מניח שאת המונח “Cloud-Native” לא מעט מהמאזינים שמעו [יש קרבורטור], יש גם ממש ארגון - CNCF - Cloud Native Computing Foundation , ואני מניח שזה שגור בפי רבים, And yet - כל אחד שומע את זה וכנראה מבין משהו אחר, מתכוון למשהו אחר.
לפי ראייתך - מה המשמעות של Cloud-Native?
  • (לירן) וואו, “לפי ראייתי” . . . קשה לי קצת להגיד שזה לפי ראייתי ולהגדיר את זה, אבל איך שאני תופס את זה, זה שלפני 10-15 שנים התחיל עולם ה-Cloud, עם ה-S3 של AWS ועם ה-Google App Engine ועם טכנולוגיות כאלה
    • ובהתחלה, התצורה הייתה יותר כזה Lift & Shift” - בוא ניקח את האפליקציות שכתבנו ל-Data Centers ונריץ אותן בענן
    • ומה שהבנו, תוך כמה שנים, זה שאנחנו לא מנצלים את המקסימום שהענן יודע לתת לנו, את המקסימום שהענן יודע להציע לנו
    • יש המון יתרונות, שאפשר לדבר עליהם שעות - אני לא אכנס לזה עכשיו, כי על זה  . . . נדבר רק על היתרונות של הענן . . .
    • ובעצם - Cloud-Native זה אוסף של טכנולוגיות, אוסף של תפישות, אוסף של שיטות עבודה - שנועדו לאפשר לנו לבנות את אפליקציות שלנו בצורה אחרת, בצורה שיותר ממנפת את היתרונות הייחודיים של הענן, את האלסטיות שלו, את ה-Scale שהוא מאפשר לנו - ובעצם לבנות אפליקציות גדולות יותר, טובות יותר, מודרניות יותר.
(רן) אז אם אני אסתכל רגע, לדוגמא - דיברת על Lift & Shift, אז נגיד שהיה לי איזשהו שירות Backend-י, שמכיל נגיד 50 מכונות - אז אני יכול לקחת את אותן 50 מכונות ורק להרים אותן באחד מספקי הענן - ולזה אנחנו קוראים Lift & Shift.
      • כנראה שזה יעלה לי הרבה יותר . . . כי עלות של מכונה On-demand היא יותר יקרה מאשר מכונה שהיא כבר שלי, אם קניתי אותה.
      • היתרון המשמעותי של הענן זה שהוא מאפשר לך לא להחזיק את כל ה-50 בכל זמן נתון, למשל . . .
    • (לירן) עצם העובדה שאתה מסתכל על זה כעל “50 מכונות” - זה בדיוק התפיסה של Data Center . . . אתה מתכנן מראש - 
      • “אני, בשביל לעמוד ביעדים שלי, צריך להגדיר 50 מכונות” - 
      • אני יודע כמה CPU, כמה RAM, כמה דיסק-קשיח יהיה בכל אחת מהן,
      • אני יודע מה יהיה התפקיד של כל אחת מהן
      • ואני חושב במונח הזה של “50 מכונות”
    • היום, ב-Cloud, אנחנו יכולים להרים מכונה בסדר גודל של בין 15 ל-60 שניות, הרבה פעמים
      • לפעמים כמה דקות, תלוי בתפקיד שלה.
      • ו-Container-ים אנחנו יכולים להרים לפעמים בשניות בודדות
    •  וזה מאפשר לנו לחשוב בעולם אחר -
      • מאפשר לנו לעלות הרבה יותר מהר, לרדת הרבה יותר מהר
      • אנחנו יכולים לתכנן את ה-Capacity  שלנו ברמה של דקות קדימה - ולא שנים או חודשים.

(רן) אז אלה חלק מהיתרונות של הענן - ואמרנו באמת שלא נבזבז את כל הפודקאסט בלדבר על היתרונות, אבל כמובן שאלו חלק מהיתרונות.
אולי צריך לציין שזה לא תמיד היה ככה - כשהתחיל -S3, או כשהתחיל EC2, אז הדברים לא היו בהכרח ככה. 
    • זאת אומרת - להרים מכונה יכול היה לקחת דקות ארוכות, מחירי ה-Storage היו שונים . . . 
אבל עם הזמן זה משהו שבהחלט קרה, ונולדו טכנולגיות חדשות - Lambda לדוגמא, ויש עוד דוגמאות אחרות - שבעצם מאפשרות שינוי פרדיגמה, שינוי שיטה.
אבל - עם כל דבר טוב, גם יש כמה אתגרים . . . אז יש לא מעט אתגרים בלאמץ Cloud-Native, ובעצם פה אתה . . . על זה אנחנו רוצים לדבר.
אילו אתגרים מעניינים אתה חושב שכדאי להתחיל איתם?
  • (לירן) אז אני אהיה קצת אנוכי, ואני אסתכל על זה מהפרספקטיבה שלי - בסוף, רוב הקריירה שלי, רוב הרקע שלי היה כמפתח תוכנה, כמהנדס תוכנה, ואני אנסה להסתכל על זה מהפרספקטיבה שלי - של איפה מפתחי תוכנה “סובלים” בעולם ה-Cloud.
  • ואחד הדברים שקורים למפתחי תוכנה זה שפתאום הם מאבדים שליטה - אם פעם היינו מריצים את האפליקציה שלנו עם איזשהו שרת Java Enterprise או איזשהו  WSGI ב-Python, משהו כזה שקל להרים מקומית, פתאום אנחנו עוברים לטכנולוגיות שנבנו עבור הענן.
    • נורא קל וטוב ומדהים להריץ אותן בענן - אבל יכול להיות פתאום נורא קשה להריץ אותן על ה-Laptop שלנו . . . .
      • בין אם זה Serverless, שלא באמת קיים על ה-Laptop שלנו
      • בין אם זה ב-Kubernetes, שהוא מאוד מאוד גדול ויקר במשאבים, בעבודה מקומית ובעבודה קטנה - הוא מדהים ב-Cloud ולא כזה טוב אצלנו.
      • בין אם זה כל מיני תלויות ב-Cloud
      • בין אם זה כל מיני שירותים של AWS - זה SQS ו-SNS ו-Databases מנוהלים
    • פתאום בכל הדברים האלה,  כשאתה מתחיל לעבוד מקומית - זה מאתגר.
    • או שאתה עובד עם ה-Cloud המרוחק בכל פעם, עם בעיות Connectivity ו-Latency ועם חוסר או פחות שקיפות, או כשאתה מרים כל מיני סימולטורים אצלך, שהם הרבה פחות איכותיים והרבה פחות מסמלצים . . .

(רן) אז אנחנו בעצם מדברים על חוויית המפתח, שהיא נפגעה . . . דרך אגב, שווה להגיד שלפני, אני חושב, שני פרקים דיברנו על הנושא של Serverless עם ינון מ-Via וגם הנושא הזה עלה - ואני חושב שהבעיה היא די ברורה: כל מי שאי פעם פיתח פונקציות Lambda או המקבילים שלהן מבין את הבעיה - זה רץ בענן, אבל להריץ על המחשב שלך . . .  אולי תצליח, אבל זו לא תיהיה אותה הסביבה.
וכמובן הזכרתי את כל השירותים שמסביב - אם אתה צריך איזה SQS אם אם אתה צריך S3 או אם אתה צריך משהו אחר, אז אתה צריך או להשתמש ב-Service המרוחק, ואז עדיין יש לך חווייה גרועה כי זה איטי - או להשתמש באיזושהי סימולציה מקומית, אבל אז לא בטוח שהסימולציה באמת פועלת אותו הדבר, לצורך העניין . . . אולי לדברים הבסיסיים כן, אבל הרשאות או דברים כאלה לא תמיד עובדים כמו שצריך - ואז אתה מקבל את הזבנג שלך ב-Production.
אוקיי, אז האתגר של חוויית הפיתוח . . . דרך אגב, יונתן - אצלכם יש Workloads שהם גם ב-Cloud וגם לא ב-Cloud [פרק 382 Carburetor 27 - k8s and multi-cloud], באיזו גישה נקטתם בהקשר של חוויית מפתח?
  • (יונתן) אז אצלנו רוב האפליקציות ורוב ה-Services רצים ב-Cloud - אבל כזה שהוא שלנו, זאת אומרת Private Cloud ולא Public Cloud.
  • אנחנו, מבחינת Debugging - אולי נדבר על זה אח”כ, יש פה גם עניין של גישות, אני חושב, של האם אתה רוצה בכלל לדבג (Debug) ב-Production ואיך אתה עושה את זה - 
    • אבל מבחינת סביבת הפיתוח עצמה, אנחנו עובדים ב-Remote - זאת אומרת שאתה מריץ את ה-Service שאתה רוצה לדבג (to debug) אותו לוקאלית, וכל שאר ה-Services שאתה נסמך עליהם, Databases וכו’, הם ב-Remote.
(רן) ואם הם צריכים אותך, דרך אגב? יש איזשהו Tunnel כזה שגם הם יכולים לקרוא לך?
  • (יונתן) אם הם צריכים אותך - לא . . .  אבל אם אתה צריכים שניים שמדברים אחד עם השני, אז אתה יכולים להרים את שניהם לוקאלית, שזה נגיד יחסית פשוט.
    • אבל  לא תוכל לקבל פתאום, לא יודע . . . הודעות Kafka משירות אחר.
  • (לירן) הודעות Kafka או webhooks נגיד, שמכניסים . . . 
  • וגם - להרים Service אחד, בטח אם זה Service שאתה מכיר, אותו ועובד עליו טוב זה עוד קל - 
    • ברגע שאתה מצרף אליו את ה-Service השני זה כבר יותר מורכב, במיוחד אם זה Service שאתה פחות מכיר, או Service של חבר שלך
    • וזה נוטה להיות אקספוננציאלית-יותר-קשה ככל שהמספר עולה . . .
  • כשמדברים עליו Design “נכון” של Cloud Native, כשאתה חושב על זה . . . אם אתה עושה אינקפסולציה (Encapsulation) נכונה, אתה תמיד עובד על Service אחד, אפילו עובד עם Unit Testing - והכל מדהים.
    • אבל ברגע שהאבסטרקציה (Abstraction) הזו מתחילה להישבר, ברגע שאתה צריך שני microServices או שלושה microServices, אז זה ניהיה הרבה יותר Messy [לא זה] ו“מציק”.

(רן) גם בוא לא נשכח, שאני מניח שהרבה מהלקוחות לא מתחילים מוצר מאפס . . .  הרבה מהלקוחות הם אולי במצב קצת יותר טוב מ-Lift & Shift, אבל בכל זאת הם לא מתחילים את כל הארכיטקטורה שלהם מאפס.
אז עושים כמה התאמות לענן, כדי באמת להינות מה-Benefits שלו, אבל עדיין לא הכל כל כך נקי וברור - ולא תמיד משתמשים באבסטרקציה (Abstraction) הנכונה, ואז זה ניהיה יותר מורכב.
אז איך יוצאים מהסמטוחה הזאת? . . .
  • (לירן) אז באמת, כמו שיונתן אמר, יש את הגישה ה . .. נקרא לזה “אופטימלית”, שבאה ואומרת “אני מרים את הקוד שלי על המחשב שלי, וכל השאר שיהיה מרוחק, שיהיה בענן”
    • שזה עובד חלק מהזמן . . . 
    • זה בעיקר עובד כשה-Scope מוגדר היטב, כש”המערכת יחסים” פשוטה, כשאפשר לבדוק טוב מאוד עם Unit Testing
    • ובעיקר כשהשירותים בענן לא צריכים אותי - כשאני לא צריך לקבל דברים מה-Kafka, כשאני לא צריך לקבל דברים ב-webhooks, כשלא צריך לפתוח Tunneling אלי.
    • זה יכול לעבוד מאוד טוב - ואז אני באמת יכול לעבוד עם כל הכלים המסורתיים שלי.
    • דרך אגב - למי שמתעניין בזה, יש ל-Kubernetes כלי שנקרא Telepresence: זה Open source שעוזר לעשות את זה.
      • זה עדיין לא תמיד הדבר הכי קל והכי פשוט - אבל זה יכול קצת לעזור עם Port-Forwarding ו“שטויות” אחרות.
    • (רן) דרך אגב - מאוד מעניין איך הוא עובד, ברמת ה-Networking, אבל זה לפודקאסט אחר . . . יש שם הרבה טריקים ושטיקים . . . טוב, כל Kubernetes עושה שטיקים ברמת ה-Networking, אבל גם Telepresence באופן ספציפי  . . .
    • (לירן) שטיק אחד גדול זה, Kubernetes . . . 
  • ואז יש לך את האופציה - שתי הקיצוניויות האחרות:
    • אחת זה באמת להרים את כל הסביבה מקומית - שזה הולך וניהיה יותר ויותר קשה ככל שהסביבה יותר מורכבת, אבל אם יש לך נגיד שניים-שלושה-חמישה, אולי עשרה microServices, אתה עוד יכול להסתדר עם זה.
      • אני כן אגיד שהרבה פעמים זה כאב ראש - הרבה פעמים אתה מוצא את עצמך מתחזק בעצם שני סטים של Deployment-ים, נגיד Kubernetes ו - Docker-Compose מקומית.
      • אפילו אם אתה עושה Kubernetes מקומית - עדיין כנראה שה-Load Balancer יהיה שונה מקומית ומרוחק, יכול להיות שה-Database יהיו שונים ומרוחקים, אופרטורים  . . . כל מיני Provider-ים שנמצאים בסביבה ה-Cloud-ית לא בהכרח יהיו זמינים מקומית, ואתה תמצא את עצמך מתחזק שתי קונפיגורציות.
    • והאופציה השלישית, שהיא לקחת את הכל ל-Cloud - להגיד ש”אני מרים את כל הסביבה שלי ב-Cloud”, ואז בעצם כל שינוי בסביבה זה בעצם אומר איזשהו תהליך Deployment ו-CI/CD ו-Build.
      • יש כלים, פה ושם, כמו Skaffold, כמו Tilt, כמו Garden, שעושים לזה אופטימיזציה ומנסים לעשות את זה הכי קל והכי מהר.
      • אבל זה עדיין שרת מרוחק, שאתה מפתח עליו, שאתה מנטר אותו מרחוק - ואין לך את אותה רמה של יכולת “לצלול לתוך הקוד” שלך ולהבין אותו, כמו שאתה יכול מקומית.
(רן) אני חושב ש . . . (א) יש כל מיני קומבינציות שונות, אבל קטיגורית יש גם את האופציה של Dev-Container - לפתח על Container מרוחק, שאולי נמצא בתוך ה-Datacenter, וכל מה שאתה עובד עליו זה איזשהו Frontend, איזשהו IDE שמדבר איתו, אבל ה-Codebase עצמו והקומפילציה והכל נמצאים מרוחק.
אבל פה, דרך אגב, אני חייב להגיד שמעבר לחוויית המשתמש - דיברנו על Latency, דיברנו על חוויית המפתח - אבל מעבר לזה, יש גם את העניין הזה של “אתה מלכלך”... אתה מלכלך את Production, אתה משתמש בדאטה של Production, אתה יכול בטעות “לשתות” הודעות מ-Kafka שלא היית אמור לשתות, או לכתוב ל-Database שלא היית אמור לכתוב אליו - וזו בעיה לא של חוויית מפתח, זו בעיה של הנכונות של ה-Production . . .
  • (יונתן) או של ה-Isolation . . . 
(רן) !Isolation - זו המילה שחיפשתי!
  • (לירן) יש הרבה חברות שבהן זה לא בא בחשבון בכלל להתקרב ל-Production בתור מפתח - ואז כן, איך אתה עושה בעצם Isolation?
    • האם אתה רץ באותו Cluster? ב-Cluster נפרד? על אותו Account או ב-Account שונה?
    • הרבה אתגרים . . . .
  • העולם הזה, של Remote Development, הוא סופר מעניין - 
  • זה סופר-מגניב וזה וסופר-מבטיח, אבל לא הייתי ממליץ לאף אחד לבנות את ה-Development Environments שלו על . . . 
(רן) אני מכיר כבר כמה שעושים את זה . . .
  • (לירן) באמת?
(רן) . . . לא חברות גדולות . . .אבל כן.
(יונתן) אם אני לא טועה, אפילו באינטל, לפני 15 שנה, עבדו ב-VNC על שרתים מרוחקים - וככה עבדו.
(רן) יכול להיות - אבל האם המפתחים אהבו את זה?
(יונתן) שאלה . . .
  • (לירן) יש עכשיו כל מיני Web-first IDEs שנועדו להיות Hosted, ואמורים לתת חווייה מאוד טובה, אבל הבעיה היא שוב - עד כמה הם יכולים לבנות סביבת פיתוח מלאה.
    • זה לא רק להריץ את הקוד - זה להריץ אותו, זה לדבג אותו, זה לספק את כל המעטפת שאתה רגיל ואוהב מה-Laptop שלך.

(רן) ובכל אופן - את בעיית ה-Refresh, שדיברנו עליה קודם - זה לא פותר . . . זה אולי עושה אותה אפילו יותר גרועה, במובן הזה שעכשיו זה נורא קל להריץ דברים בתוך ה-Datacenter של Production, אז למה שלא תעשה את זה כל הזמן? . . . 
  • הנה -  שכחת איזשהו Service באוויר ופתאום הכל נתקע בלילה. . . 
אילו פתרונות, דה-פקטו, אתה רואה שאנשים באמת מוצאים בשטח?
  • (לירן) אז האמת שאנחנו רואים שאנשים מאמצים קצת מכל דבר, איזשהו שילוב של הדברים
    • קצת יש לי פרספקטיבה - אתה יכול להגיד שאף אחד מהפתרונות האלה לא טובים, ואתה יכול להגיד שהפתרונות האלה, כל אחד מהם טוב למשהו ספציפי.
    • אבל אף אחד מהם לא נותן מענה לכולם כל הזמן.
  • בסוף, אנחנו רואים שכל חברה שאנחנו עובדים איתה, כל חברה שאני מדבר איתה, מוצאת איזשהו שילוב
  • מן הסתם, ככל שאפשר לעבוד יותר מקומית אז זה יותר קל, וזה משהו שמפתחים מתרגלים אליו.
  • אבל הרבה פעמים זה לא עובד - ואיפה שזה לא עובד, אז עוברים לדברים היותר מורכבים - 
    • להריץ את הכל Containerized מקומית, להריץ את הכל ב-Cloud, זה נורא תלוי ב-Use cases.
    • דיברנו קצת על ה-Use case של ה-Incoming Data, של “אני רוצה עכשיו להרים webhook או להרים API ולראות מה קורה כשפונים אליו - אז כנראה שאני אצטרך להרים אותו ב-Cloud
    • לעומת זאת, אם אני יכול יותר למשוך Data מאיזשהו Database, יש סיכוי טוב שאני אוכל להריץ את הקוד מקומית, עם איזשהו Batch Process, ולדבג אותו תוך כדי - והחיים שלי יהיו יותר יפים.
  • ואז, בעצם, כשאתה מריץ את הקוד מרוחק, אז אתה היום קצת נופל לכלי-Production  . . . זאת אומרת, אתה כבר לא יכול לעבוד עם ה-Debugger כמו שאתה רגיל, ואתה גם לא יכול לערוך קוד on-the-fly ולראות את זה.
    • עובדים הרבה יותר באוריינטציה כמו שהיית עושה Troubleshooting ב-Production - עובדים עם כלי Observability, עם לוגים, עם מטריקות, עם Tracing - ומנסים להשתמש בכלים האלה כדי להבין מה קורה עם הקוד.
      • מכיוון שה-Deployment-ים הם הרבה יותר איטיים, הרבה יותר מוסרבלים.

(רן) כן, וזה, נראה לי, מביא אותנו גם קצת לאתגר הבא, של המורכבות , זאת אומרת - אם בעבר דברנו על ה-Scenario שהיה לך איזשהו AppServer, ובתוך ה-AppServer הייתה לך לוגיקה נורא-נורא מסובכת, אבל כל זה היה בתוך איזשהו Server בודד, או אולי פרוש על איזה Server אחד או שניים - נגיד AppServer ו-Database, אבל לא הרבה יותר מזה - 
היום, למעשה, לוגיקה פרושה על פני מספר Server-ים, אולי מספר פונקציות, תורים, Database-ים, Hook-ים ועוד הרבה מאוד פטנטים אחרים . . . חלקם חדשניים וחלקם אולי לא כל כך - אבל לפעמים אתה מגלה שנגיד HTTP Request של User בודד עובר בקלות דרך עשרה-חמישה-עשר דברים שונים, כשלא כולם זה בהכרח בבעלותך . . .  זאת אומרת, יכול שחלק מהם בבעלות ה-Cloud Provider, חלק מהם אצל איזשהו Hook, נגיד שאתה כותב קובץ ומייצר Hook וכו’.
זה ניהיה מורכב . . . איך מטפלים? איך מבינים את המורכבות הזאת? איך מבינים כשיש בעיות?
  • (לירן) זה ניהיה מורכב, זה ניהיה מאוד מורכב . . . 
  • דווקא בעולם הזה, כלי ה-Observability שיש לנו היום הם מאוד מאוד טובים.
  • אני לא יודע, ככה . . . חבר’ה בקהל שמקשיבים לנו, האם יצא להם לשמוע את המונח “Observability”
    • זה מונח שמדבר בעצם על היכולת להבין מה קורה במערכת - מבחוץ.
      • להבין האם היא במצב תקין או לא במצב תקין
      • ואולי טיפה למה . . .
    • יש היום אוסף של כלים כאלה, החל מעולמות הלוגים המסורתיים שאליהם אנחנו רגילים, דרך עולמות המטריקות - Prometheus וזה - ועד רמות ה-API, שזה כלים שהם קצת יותר כבדים, שמאפשרים יותר לצלול לעומק, ובאמת לעקוב, ברזולוציה מאוד בסיסית, על הבקשות האלה - בקשות HTTP ובקשות אחרות לאורך המערכת, לראות אילו Services עובדים . . . 
    • וכל הכלים האלה נותנים לנו איזשהו פידבק ראשוני, של כמה שגיאות יש במערכת, כמה זמן לוקח למערכת - ואולי גם מכווינים אותנו בערך לאיזו קומפוננטה (Component) עושה בעיות, איזו קומפוננטה חווה קשיים..

(רן) אבל שוב, אני אקשה - דיברנו על קשיים . . .  - אז אם פעם יכולת ללכת ל-JBoss שלך . . . יונתן, אני יודע שאתה נזכר בזה גם . . .
(יונתן)  !WebSphere [הוזכרו גם ב-412 Serverless at Via]
(רן) WebSphere . . . אז אתה יכול ללכת אליו, ולשים שם Breakpoint . . .להגיד “אוקיי, עכשיו אני אשלח Request, ונראה מה קורה ב-Breakpoint”.
ועכשיו - אתה אולי, במקרה הטוב, יכול באמת להתחבר ולשים Breakpoint, וגם לא תמיד, אבל בדרך, אתה לא תראה את כל ה-Stack . . . יהיה לך מאוד מאוד קשה להבין מה ה-State שהביא אותך עד לשם, ושוב - לא תמיד אפשר לייצר Breakpoints, ברמה הטכנית.
  • (לירן) זה באמת החסרון הגדול של שימוש בכלי Observability למטרות פיתוח.
  • כלי Observability הם מאוד מאוד Rigid באופי שלהם - צריך להגדיר מראש מה רוצים לעשות, צריך להכניס את הלוגים לקוד, צריך להכניס את המטריקות לקוד . . .
  • הכלי Tracing, דרך אגב - ה-API-ים יודעים לנטר איזשהו overview ראשוני, בעצמם, Out-of-the-Box, אבל מעבר ל-Basic זה, אתה צריך להוסיף בעצמך כל נקודה שאתה רוצה לנטר.
    • וגם בכל פעם שאתה רוצה לשנות - זה אומר לשנות קוד, לעשות re-Deployment . . .
  • עכשיו - כשמדובר על הקוד שלך, במיוחד אם זה רכיב שאתה עובד עליו עכשיו, אז זה לא כזה נורא
    • בטח בסביבת Dev, לבנות את ה-Java, לעשות Transpile ל-JavaScript, לבנות את ה-Container, לעשות לזה Deployment . . . בין חמש לעשרים דקות ואתה מסודר.
  • אבל זה הרבה יותר כואב כשזה לא הקוד שלך - בין אם זה microService ליד, שאותו אתה כבר פחות מכיר - 
    • פחות מכיר את ה-Build שלו, פחות מכיר את התהליכים שלו, פחות מכיר את ה-Deployment שלו.
  • וזה יכול להיות גם Open Source  . . . 
  • זה יכול להיות עכשיו איזשהו קוד Open source, ועכשיו לפתוח את הקוד Open Source הזה בשביל להוסיף Log ולהבין איך עושים Re-build ל-Package ואז את ה-Dependencies שלך להפנות ל-Package שבנית . . . 
  •  - זה כבר יכול להיות סיפור בהיקף של איזה חצי-יום ויותר, וזה די מבאס.

(יונתן) זה אולי מבאס - אבל יש גם הצד השני: עבודה כזאת שאתה עושה - על להוסיף מטריקה במקרים מסויימים, לזרוק Event . . . - זה קשה, אבל זה גם נכס
    • זה נשאר איתך
    • כש-Debugging הוא . . . אתה עושה Debugging, ואחרי זה הוא נעלם
      • במקרה הטוב הוא נעלם, ולא משאיר אחריו שום State
    • וכל הידע שצברת משם הוא כבר לא שם, זאת אומרת - אני לא אומר שלא צריך Debugging בכלל, אבל מבחינתי, מי שפותח Debugger אז זה קצת “מוצא אחרון”’, זה אומר שאולי היה חסר לו משהו לפני זה
      • או שלפעמים, באמת, יש דברים שאי אפשר בלי - אבל זו גישה קצת אחרת.
  • (לירן) אני ממש בעד Observability ואני אוהב Observability, כש-Observability זה בערך אחד הדברים הכי חשובים
    • שווה להשקיע את הזמן בלבנות Observability מצויין למוצר - על אחת כמה וכמה ב-Production
    • זה סופר חשוב שהמפתחים שבנו את הקוד יקחו אחריות על זה - שהם יודעים מה קורה איתו, שהוא מדלוור (Delivers) ערך ללקוחות קצה - והדרך היחידה לעשות את זה זה עם לוגים ומטריקות ועם Observability.
  • הבעיה עם זה היא ש-Observability זה הרבה משחק של ניסוי וטעיה - אתה לא תמיד יודע בהתחלה איזה לוג הכי חשוב . . .
    • כמות הפעמים שראיתי בקריירה שלי מפתח שם Log - ובא ואומר “זה סופר-סופר חשוב!” - רק שזה קורה 10,000 פעם בשנייה ומפיל את המערכת, או לפחות מקפיץ את החשבון של ה-Elastic . . .
    • (רן) זו מערכת מאוד חשובה, כנראה, אם היא קוראת 10,000 פעמים בשנייה . . . 
    • (יונתן) . . . או שאולי אתה מגלה פתאום שזה לא היה כזה חשוב כמו שחשבת . . .
    • (לירן) או שאתה מגלה שאיזושהי מטריקה . . . אתה רוצה לשלוח איזושהי מטריקה ואתה מגלה ששלחת אותה בשעות במקום בשניות, ועכשיו המערכת Input לא מצליחה לקלוט אותה . . . 
  • בסוף, אני חושב שאת ה-Observability הכי טוב הכנסנו כתוצאה מתקלות - 
    • ב-Rookout, משהו לא עבד, תחקרנו ותחקרנו והבנו למה זה לא עובד - וגם הבנו איך לשפר את ה-Observability שלנו כדי שבפעם הבאה זה לא יקרה, או כך שנדע על זה יותר מהר ויותר בקלות.
  • זה פשוט תהליך איטרטיבי (Iterative) . . .
(רן) את זה כנראה אפשר להגיד על כל דבר בחיים - את הדברים הכי טובים אתה עושה רק אחרי שטעית [ד”ש לדאגלס], אבל כן - אני לגמרי מזדהה עם התופעה הזאת.
  • (לירן) ובהקשר הזה - הטענה שלי כלפי הכלי Observability הקיימים  זה פשוט האיטיות . . . המסורבלות . . .
    • כשאני כבר יודע מה אני רוצה, אני אעשה לזה את ה-Commit, אני אעשה לזה את ה-Deployment, 
      • והכל יהיה בסדר, בטח למי שיש CI/CD איכותי
      • זה יקח את השעה-שעתיים
    • הבעיה שזה תהליך של ניסוי וטעיה, שלעפמים לוקח לי עשרה או אפילו עשרים ניסיונות לדעת מהי המטריקה שאני צריך לדעת, מה ה-Log שאני צריך
      • ואת זה - זה מה שאנחנו ב-Rookout מאמינים - שהרבה יותר כיף וקל ומועיל לעשות את זה באיטרציות זריזות
      • להצביע על שורה -לקבל ממנה Log; להצביע על שורה - לקבל ממנה מטריקה
      • לראות שזה באמת מה שאתה רוצה, לראות שזה באמת מה שרצית לראות
      • ואז בעצם לקבע את זה בכלים כאלה ואחרים כך שזה יגיע באופן קבוע, וישמר את הידע הזה לאורך זמן.
(יונתן) אז זה בעיקר כלים כדי להבין מה קורה במערכת או שזה גם כדי לשנות התנהגות - לשנות לוגים או לשנות If-ים?  . . .
  • (לירן) הפרספקטיבה שלנו ב-Rookout, מה שאנחנו עושים, זה שאנחנו רוצים להפוך את העולם הזה, של Observability, לדינאמי - 
    • שתוכל, כמפתח, לבוא ולהצביע על כל שורה בקוד שלך ולהגיד “אני רוצה לדעת מה קורה פה, אני רוצה לדעת איך הגעתי לפה”
      • גם ברמה ה-Stack trace וגם ברמת Tracing - איפה הבקשה הזאת עברה קודם? מהם הערכים של המשתנים שלי? 
    • וגם לנצל את הדברים האלה בצורה קצת יותר חכמה - “תייצר לי פה מטריקה חדשה”, “תייצר לי פה Log חדש”
    • וכשאנחנו גם מבינים שיש פה כל מיני תוספות ומורכבויות נוספות על Production
      • למשל: “אני רוצה לראות מה קורה כשמגיעים לשורה הזאת בקוד” - אבל עבור לקוח ספציפי.
      • או - “תראה לי איך הקוד שלי מטפל כשהלקוח הזה שולח לי פה בקשה”
      • “תראה לי איך הקוד שלי מטפל, כשקיבלתי מה -S3 איזושהי הודעת שגיאה”.
  • (רן) נגיד Conditional Breakpoints . . . משתנה ש”כאשר הערך שלו מגיע ל-X אז תעצור”
  • (לירן) כן - הטכנולוגיה שאנחנו אוהבים לקרוא לה “Non-breaking breakpoints”, שזה אומר שנותנים לך בעיה שהיא דומה ל-Breakpoint, מראים לך את מה שה-Breakpoint היה מראה - אבל לא עוצרים לך את הקוד בעצם.

(יונתן) עכשיו יותר ויותר שרתים - לפחות כאלה שצריכים להתמודד עם Scale גדול - הם א-סינכרוניים, זאת אומרת שדברים לא בהכרח קורים בסדר שלהם, ה-Stack trace יכול להיראות כמו גיהינום.
איך אתם מתמודדים עם זה?
[דיברת על אינטל - אז Out-of-Order Execution]
  • (לירן) אז אנחנו מתמודדים עם זה בכמה דרכים - הכי משמעותי זה בגדול לעקוב אחרי Request-ים
  • (רן) כי זה הכל אותו הדבר, לא? . . . 
  • (לירן) בערך . . . כמו כל תקן טוב.
  • באמת צריך לחשוב, ככה - גם לראות את ה-Stack Trace הקלאסי, של “מאיפה הקוד שלך הגיע?”, אבל גם לראות את ה-Stack Trace הלוגי של ה-Span-ים ושל ה-Trace-ים, של “מאיפה הבקשה הזאת הגיעה?”, “איך היא נכנסה למערכת?” ו”איפה היא בשלב הזה, כרגע?”

(רן) אתגר נוסף, שאני בטוח ש . . . - אני בטוח שאפשר להמשיך לדבר על Observability, אבל בוא נמשיך - אז אתגר נוסף שאני יכול לחשוב עליו זה אם מישהו, ונחזור ל-Scenario שהיה לך Web Server אחד ו-Database, והיית משחרר אליו גרסא, אז אתה יודע: היית משחרר גרסא 5 ואחר כך גרסא 6 ואחר כך גרסא 7 . . . אולי 7.1, אולי 7.2 - אבל אוקיי, אתה יודע וכבר די ברור לך מה קורה שם.
היום ב-Production, ודרך אגב - זה אולי לא ייחודי ל-Cloud אבל זה ניהיה יותר קל ב-Cloud Native - יש לך הרבה מאוד Services, הרבה מאוד רכיבים אחרים, ולכל אחד יש גרסא אחרת לחלוטין.
אני מנחש שב-Outbrain משחררים הרבה מאוד גרסאות ביום . . . 
(יונתן) נכון - וגם לא כל הזמן לאותו ה-Service יש את אותה הגרסא ב-Production: לפעמים מריצים A/B Testing, אם אתה מריץ כמה Flavour-ים  . . .
(רן) נכון . . .  אז בכל זמן נתון, נגיד לכל Service יש גרסא אחת או שתיים ב-Production - ובנוסף, יש כמה מאות של Services שונים - ובנוסף, יש רכיבים שהם לא שלך, שגם לפעמים מקבלים Update או כל מיני דברים כאלה, מוזרים . . . וקשה מאוד לקבל תמונה קוהרנטית של “רגע, אז מה יש עכשיו ב-Production? איזה קוד נפרש עליו?” . . .
  • (לירן) קשה להחריד . . . למעשה, לפני איזה שנתיים-שלוש, כשהיו לנו אתגרים ראשונים - היה מוצר, התחלנו אצל לקוחות, היו לנו את הפידבקים שלהם - והיינו בשוק מכמה לקוחות מתקשים להבין מה לעזאזל רץ להם ב-Production . . . 
  • זאת אומרת - הם בוחרים שרת, מתחילים לשים עליו Breakpoint-ים - וה-Breakpoint-ים לא קופצים להם . . .  אז אנחנו אומרים להם: “חבר’ה - זו לא הגרסת קוד שרצה לכם ב-Production”, והם עונים: “זה כן” . . .
    • ואחרי שעתיים של Support אומרים: “חבר’ה, זה לא הקוד שרץ לכם ב-Production, ה-Breakpoint-ים לא קופצים כי אתם מסתכלים על גרסא חדשה, והגרסא ב-Production היא מלפני שבוע” - או הפוך . . .
    • ואחד הדברים הכי משמעותיים שראינו במוצר זה הצורך להביא עבור הלקוחות את הקוד - 
      • לא לסמוך על המפתח שנמצא בקצה שיתחיל להבין איזה קוד נמצא עכשיו איפה, אלא שברגע שהוא בוחר שרת או Service או Deployment ב-Kubernetes או Whatever - להראות לו “תקשיב - זה מה שרץ שם כרגע”.
      • יש סיכוי טוב שכבר בזה הוא מצא את ה-Bug,  כי בעצם זו בכלל לא הגרסא שהוא חשב . . . 
      • ואם לא - אז ברגע שהוא מתחיל לדבג, הוא לפחות רואה בעיניים בעיניים באמת איך הקוד שנמצא שם מתנהג, ולא איך הקוד שהוא חושב שנמצא שם מתנהג . . .

(רן) אז איך זה עובד ברמה הטכנית? זאת אומרת - יש את הסיפור המפורסם, אני מניח שהרבה מכירים, על חברת Algo-Trading, שבטעות השאירו איזשהו שרת ב-Data center שלהם עם הגרסא הלא נכונה, וככה הפסידו את המכנסיים והתחתונים שלהם, ופשטו רגל . . .
  • (לירן) 400 מליון דולר . . . 
(רן) כן . . . אז אני לא זוכר את שם החברה [Knight, הזכרנו בפרק הקודם], אבל בטוח שנמצא את זה ברפרנס [טו-שה . . .] - אז איך זה עובד ברמה הטכנית? זאת אומרת - מה, לכל גרסא יש איזושהי חתימה, ואתה מוצא את החתימה שלה וככה אתה מוצא את ה-Code base?
  • (לירן) אז האמת שפשוט בנינו סט של Best Practices, שאפשר גם למצוא בבלוג שלנו הרבה מהם, על איך לתייג גרסאות - 
    • אם זה ברמת ה-CI, לדחוף את ה-Git-Commit
    • בין אם זה של כל מיני קונפיגוקציות של Maven ו-Gradle ו-MSBuild - על איך לקנפג את זה כך שזה ישים בארטיפקטים (Atrifacts) את ה-Hash-ים.
    • בין אם זה ברמת Containers - אנחנו פשוט מצאנו כמה קבצים ב - .git המסתורי הזה שנמצא לכם בכל מקום - רק קחו את השלושה-ארבעה קבצים האלה, זרקו אותם פנימה - ותוכלו לדעת בדיעבד איך ה-Container.
    • חשוב גם להגיד שכחברה אנחנו, כמדיניות, לא נוגעים בקוד-מקור של הלקוחות - אנחנו לא מעבירים source-code ,לא מזיזים Source-code - ולכן זה מאוד חשוב לנו למצוא דרכים שהלקוחות יוכלו לעשות את זה בעצמם, בלי שבעצם הדאטה הזה יעבור דרכנו.
(רן) הבנתי . . . 

(יונתן) תגיד - בעצם, החברה שלך מוכרת מוצרים למהנדסים? אתה CTO, אתה מנהל את המהנדסים האלה . . . מה הם אומרים על המוצר שלכם?
  • (לירן) מה המהנדסים שלנו אומרים? . . .
(יונתן) כמשתמשים . . .
  • (לירן) אני חושב שזה אחד הדברים הכי כיפיים, גם כמי שכנראה שמגייס עובדים ומנהל עובדים, אבל גם באופן כללי - לפתח מוצר שאתה מבין מה הוא עושה, שאתה מכיר את ה-User-ים, שאתה רואה את ההנאה שלהם בעיניים - זה מאוד מספק.
  • כשהחבר’ה באים ונפגשים עם לקוחות, ורואים את המפתחים אצל הלקוחות שלנו יושבים באמצע הלילה ומדבגים באגים, ושוברים על זה את הראש - ואז הם רואים איך Rookout עוזר להם - וזה ממש ממש מאיר להם את העיניים.
(יונתן) אין כמו לראות אחרים מדבגים באמצע הלילה . . .
  • (לירן) רק בסופ”ש שעבר, לקוח התקשר אלינו, שבאותו לילה הם התעוררו בשתיים בלילה לדבג איזה משהו, הייתה תקלה בProdcution - והם פתרו אותה איתנו ב-15 דקות
    • אז אם כבר העירו אותך בשתיים בלילה כי המערכת נשברה וצריך לטפל בזה - לפחות שזה יקח 15 דקות ולא תישאר ער עד הבוקר . . .
(רן) ברור . . .  מזל שלא משלמים לכם לפי שעות . . . .

בסדר - אז יש אתגרים, אני בטוח שיש עוד, אבל אנחנו מתקרבים לקראת סיום.
אז קודם כל - אני בטוח שכל מי שפיתח בסביבה שהיא Cloud-Native מזדהה, לפחות עם חלקם.
חלקם פתורים בתעשייה, במידה מסויימת, וחלקם לא - אני בטוח שככל שנפתור, ככה יווצרו עוד בעיות . . . תיהיה לנו עוד עבודה.
אבל זה מעניין מאוד, ואתגרים סופר-רלוונטיים למפתחים.

לפני השיחה שלנו, לפני שהתחלנו להקליט, סיפרת לנו שהתחלת פודקאסט [!]
  • (לירן) כן - אז האמת שבשבוע שעבר הקלטנו את שני הפרקים הראשונים של הפודקאסט שלנו - זה הולך להיות ה-Production-first Mindset, זה השם שלו.
  • אני מאמין שככה - בעוד שבוע-שבועיים תתחילו לראות פרקים של זה ב-Spotify וב-Apple ובכל המקומות האחרים שאתם אוהבים לראות ולקלוט פודקאסטים.
    • אז אתם מוזמנים גם להקשיב לנו.
(רן) מעולה - רעיון טוב. והוא יהיה באנגלית?
  • (לירן) הוא יהיה באנגלית - אנחנו מראיינים גם הרבה חבר’ה מהארץ, כל מיני יזמים כמו רון רייטר ואופיר ארליך
  • וגם כל מיני טכנולוגים מחו”ל כמו  Steve Chin - חבר’ה מאוד רציניים שיספרו גם מהפרספקטיבה שלהם על האתגרים של ה-Cloud Native ובאופן כללי על האתגרים של להביא קוד ל-Production ומה שזה אומר.

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

אין תגובות:

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