יום רביעי, 21 בנובמבר 2018

354 Bumpers 53

באמפרס מספר 53 עם רן, דותן, ואלון

רן:
  • ספרים על תרבות SRE בעיקר בגוגל ובחברות נוספות
  • השוואה בין שירותי hosted kubernetes
  • יצא AWS Service operator המאפשר לתפעל שירותי AWS דרך kubectl
  • שירות חדש ב Github בשם  Actions המאפשר לקרוא לפעולות לאחר push בצורה אוטומטית,

אלון:

דותן:


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

יום שבת, 3 בנובמבר 2018

353 Istio

פודקאסט מספר 353 של רברס עם פלטפורמה - אורי ורן מארחים במוצאי חג הבחירות המוניציפליות את שי ארליכמן לשיחה על פרויקט Istio (תזכורת לפודקאסט 351 / באמפרס 52).

  • שי הוא CTO ומייסד משותף (Co-founder) של missinglink, שמספקת פלטפורמה לחברות עם Stack של למידה עמוקה (Deep Learning) ולמידת מכונה (Machine Learning), ועוזרת להן לנהל את הפיתוח והמידע - כלים שהתרגלנו אליהם בעולם קוד המקור ועדיין פחות נפוצים בתחומים הללו.
    • החברה גדלה וכבר יש לקוחות משלמים, המוצר מפותח כבר שנתיים (ומשוחרר לשוק כמעט מההתחלה), הלקוחות הם המפתחים (קהל מאתגר :-)).
    • חלק מ-Samsung Next, ממוקמים בשרונה בתל אביב (!Sharona  - לא להסתבך עם אבשלום קור).

  • אז מה זה Istio?
  • אז מה הבעיה?
    • בפיתוח אפליקציות Web עולה השאלה של מה עושים ב-Production? הפתרון היה nginx לפני האפלקציה, שהיה משרת ודואג ללוגים, Load Balancing וכו’ (גם Caching, אם כי זה בדרך כלל בעצם Varnish ברקע).
    • ואז הגיע Docker, וניהיה מאוד קל לעשות Deploy. ועדיין - היה Load Balancer לפני האפליקציה (אותו nginx). ואז יצא Kubernetes כדי לנהל את הכל. אז מי מנהל את ה-Load Balancer? כאן הגענו ל-Istio.
    • מדובר קודם כל בסט כלים (שאמור להיות אדיש לפלטפורמה - Platform-Agnostic - אבל עובד הכי טוב מעל Kubernetes), שיוצר מעיין תווך בכל נקודה, ו”משתלט” על כל נקודות הקצה. כל בקשה (Request) מגיעה כל קודם אליו, ובעזרת מדיניות (Policy) מוגדרת הוא מחליט מה לעשות הלאה.
      • דוגמא - משתמשים עם Cookie מסוג מסויים יופנו לגרסת Canary מסויימת, והיתר לגרסה שונה. אין צורך בשני שרתים או שתי סביבות וכו’.
    • המודל הוא Layer 7 Routing - מודל OCI, שמאפשר להוסיף מאפיינים ''חכמים'', לא רק Routing אלא גם Logging (כי הוא מכיר את כל נקודות הקצה ויכול לייצר תשתית Tracing).

  • שירותי Load Balancing קיימים במגוון צורות (HAProxy ושלל כלים של רוב ספקי הענן העיקריים - ELB, ALB, GCLB וכו’). מה שייחודי ב-Istio זה המימוש המבוזר.
    • לא מרימים אף מכונה - רצים רק איפה שהשירות (Service) רץ, וה-Proxy נעשה בצורה שקופה.
    • באותם Dockers (ה-Pods) של ה-Services הרלוונטיים יש נציג (Agent) של Istio: ה-Sidecar (סירה. של אופנוע, ועדיין עוד רפרנס לים).
    • זהו אותו Proxy של Envoy שפותח ב-Lyft. לא ברור למה היה צריך עוד אחד מחדש, אבל נראה שיש להם את המשאבים ובכל מקרה יצא פרויקט מדהים. Istio הוא בעצם הרחבה (Extension) של Envoy.
    • העבודה עם Kubernetes מאוד צמודה - בגרסא 1.9 למשל נוסף Webhook Injection, שתופס את כל ה-Events שמתרחשים, ויודע להיכנס בדיוק לנקודות שצריך להתממשק בהן.
    • זהו מעיין End-point שמחצין את עצמו, ויש מאחוריו Service Discovery שימצא את השירות (Service) הנכון שאליו אני רוצה להגיע. קצת כמו Venom
    • ניתן להקביל את זה ל-Proxy מאוד חכם שעוטף, יודע לזהות את ה-End Point, מבין לאן הייתה הכוונה לפנות, ומודע לעצם הקריאה.
      • דוגמא - פנייה לשירות שנותן את זמני הזריחה והשקיעה (עינייני בית חכם), שנחסמה כיוון שלא ניתנה הרשאה ל-Istio לפנות לאותו שירות חיצוני - מעבר להשתלטות על הקלט, יש כאן גם ''הבנה'' (הסקה) עמוקה יותר לגבי הפלט הצפוי. 
        • לא מדובר על החלפה של שירותי ה-Routing, אלא מעיין ניטור שלהם. שרשרת הקריאות נשמרת וניתן לנתח אותה ולהסיק על ההתנהגות של ה-Service Mesh.

    • סיכום ביניים - Istio מאפשר שלושה שירותים של ראוטר מתוחכם:
      • ניתוב חכם (Smart routing).
      • אבטחת מידע (Security) - גורם לכל השירותים להיות MTLS.
      • לוגים (ו-Tracing). כרגע לא על הכל לגמרי אבל זה הכיוון.
        • טלמטריה, לרמה של E2E Tracing (עם מזהה לקריאה ספציפית) - שליטה על כל שרשרת הקריאות (מי הניע את מי), כשיש כלים כמו Zipkin ו-Prometheus שמאפשרים לראות מעיין “מפל” של שרשרת האירועים שנגרמו מקריאה מסויימת.
          • מכאן אפשר לנתח כל מיני דברים, כמו זמן ממוצע למשך קריאה בהשוואה להתפלגות משך הקריאות הכללית וכו’. וכל זה אמור להתבצע אוטומטית. ב-Prometheus (גרסא 1.02) יש כבר הכל בפנים, והתחלה של גרף קריאות.

    • לפחות חלק מהצוות שעובד על המוצר נמצא כאן בישראל במעבדות IBM בחיפה. הפרויקט בגדול נולד כשיתוף פעולה של IBM ו-Google, איפה זה נמצא היום?
      • הבעיה (או “האתגר” בניסוח יותר אופטימי) היא שהפרויקט אמור לתמוך “בהכל”. בדומה ל-Kubernetes שהיה צריך את ה-EKS וה-Kubernetes Engine כדי להוריד את רמת הקושי, זה עדיין לא שם. צריך לקרוא הרבה מדריכים (ולהבין מה רלוונטי). זה עדיין שווה את זה.

    • כיום, Kubernetes מאפשר רמה מסויימת של Routing ו-Load Balancing בין ה-Pods השונים באמצעות אבסטרקציה של Service. הבעיה היא שזה מאוד מוגבל מבחינת פתרון “חכם” ומצריך Plug-Ins שונים (ל-Security למשל), לא מובן מאליו בגרסת Out of the box, אם בכלל.
    • אפשר לומר ש-Istio מחליף את שכבת ה-Load Balancing של Kubernetes, ומוסיף על זה את האלמנטים שהוזכרו למעלה.

    • למה זה כל כך מסובך אם הכל זה רק Sidecar?
      • יש כאן מעבר להתקנה של Docker לצד Docker . . . 
      • ל-Istio יש ארבעה רכיבים עיקריים - 
        • מיקסר (Mixer), שתפקידו לקחת את המדיניות (Policy) ו”לערבב” לתוך ה-Sidecar.
        • פיילוט (Pilot), שתפקידו לבצע את ה-Routing.
        • יש את ה-Citadel (למעריצי Rick and Morty), שתפקידו לנהל הרשאות (Certifications), באופן בלתי תלוי במה שרץ מתחת (Kubernetes, Mesos או משהו אחר)
        • שכבה של Auto-injection, שתופסת את מה שקורה ב-Cluster על מנת לקבל החלטות.
      • למה זה כל כך הסתבך? כי זה עולם גדול, עם הרבה צרכים והרבה אפשרויות שצריך לכסות, ואנחנו רק בגרסא ראשונה. זו רק ההתחלה.

    • מתי אני יודע שאני צריך Istio?
      • שי אומר שאם אתם משתמשים ב-Kubernetes, אתם צריכים Istio. כנסו לאתר של Zipkin ותראו את רמת ה-Tracing. תבינו שאתם טסים בלי מכשירים ותרצו גם כזה. 
      • בעולם של App Engine היה Tracing Built-in - אתה רואה את הכל וכמה כל דבר לוקח. אתה מתרגל, ואז אתה מצפה לזה בכל מקום. אז Istio.
    • ובכל זאת - מה לגבי Security? נשאלת השאלה האם יש צורך שתקשורת בין Services תיהיה ברמת אבטחה מקסימלית (ומה המחיר)? שי אומר שאצלו רוב המידע מועבר בתוך ה-Private Network אז זה פחות חושב - וזה חינם.
    • האם רכיבי Istio בעננים שונים יודעים לתקשר אחד עם השני? על הנייר כן, ויש MTLS out of the Box. האם זה עובד באמת? שי לא ניסה, אבל זה אמור לעבוד (וזה גם שם של דג, כי חייבים עוד רפרנס אחרון לים).
    • עוד פיצ’ר מעניין (אם כי עלול להיות מעט מסוכן) הוא Retry לקריאה שנכשלה (למשל Outbound Call) - אפשר להגדיר Policy שתנסה שוב מספר מוגדר של פעמים, וזה לא חלק מהקוד אלא חלק מה- Policy. זה הרבה יותר נוח (לא צריך לממש את הלוגיקה).

  • כשחושבים על זה, Istio נמצא בכל מקום והכל עובר דרכו - זה לא יוצר עוד Latency?
    • כן, זה מוסיף. צריך למדוד את זה.
    • מישהו התלונן שעבור 2000 שירותים, ה-Sidecar מגיע ל-8G צריכת זכרון (יש גם בפחות) . . . עובדים על זה. בכאלה מספרים של שירותים יש כנראה עוד כמה בעיות מעבר ל-Sidecar.
    • זה מעלה משמעותית את התקורה ההתחלתית של פרויקט. שימושי יותר עבור פרויקטים בשלבים מתקדמים יותר שרוצים לגדול (או מתכננים קדימה).
    • המימוש של Envoy מאוד יעיל, כך שהחזקה של כל מפת הקריאות היא לא בהכרח בעיה ברוב המקרים אבל שוב - צריך למדוד.
    • היום כבר לא צריך לחשוב על התווך, ולדאוג האם קריאת ה-HTTP יצאה ומה לגבי ה-MTU - צריך לכתוב את הקוד, והשכבות למטה יסתדרו באופן היעיל ביותר.
    • האם Retry למשל לא כבר נמצא בתוך GRPC? לא, וכנראה שבכוונה. שימוש ב-Retry הוא סוג של פלסתר, שעלול ליצור Latency שיצטבר בלי לשים לב. כאן נכנס ה-Tracing שאמור להציף את זה.

  • לסיכום - אם אתם משתמשים ב-Kubernetes, תנו מבט על Istio, אתם כראה צריכים כזה. תבדקו.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

יום רביעי, 31 באוקטובר 2018

352 Momento with Genady Okrain

פודקאסט מספר 352, רן ואורי מארחים את גנאדי אוקראין שעובד על Momento

1:40 גנאדי מציג את עצמו, איך התחיל לפתח אפליקציות, ופרויקטים מעניינים שעבד עליהם בעבר
4:30 קצת על פיתוח אפליקציה ביוזמה של אסף הראל
6:00 עבד בסן פרנסיסקו בחברה בשם Real Good ותוך כדי עבד על מספר פרוייקטי צד
7:35 התחיל לעבוד על מומנטו ביולי 2016, אחרי כנס של אפל ולפני היציאה של iOS 10 
11:04 למה חשוב לצאת עם פיצ׳רים מתאימים ביום בו יוצאת מערכת הפעלה
13:20 גנאדי השתמש בפרויקט שעשה בעבר ולא הצליח, חילץ ממנו פיצ׳ר אחד ושחרר אפליקציה חדשה
14:35 גנאדי מספר על המודל הכלכלי של האפליקציה והדרך שהביאה אותו למודל הזה
19:50 מספר על התהליך שגרם לו להבין שהאפליקציה יכולה להיות מעין כלי לעריכת סרטים ועל הפיצ׳רים בתשלום שהוסיף בעקבות זאת
23:05 למומנטו יש 2 מליון הורדות, נוצרו בעזרתה 3 מליון גיפים ובשנה הבאה המטרה היא להגיע ל 100K משתמשים משלמים
24:15 גנאדי מספר איך הוא מתמודד בתור מפתח יחיד מול חברות עם עשרות ומאות עובדים
28:20 לדעת גנאדי המודל של subscription ב app store פותח את הדלת למפתחים להכנסות ארוכות טווח מאפליקציות
31:40 גנאדי מתאר את המהלכים השיווקיים שהוא עושה
36:00 מדברים על האתגרים ההנדסיים בפיתוח האפליקציה
37:25 לאחרונה נוסף אפקטים המתבססים על מודל של machine learning המזהה רקע מאחורי בן אדם
38:45 מודלים של machine learning רצים היום על הטלפונים ולא בשרתים יקרים
40:35 המטרה העכשוית של מומנטו היא בעיקר לגדול ולהרחיב את ערוצי השיווק למשל פייסבוק
42:15 רן מזכיר שמודבר בחברה שהיא לגמרי bootstrapped והגיע לשווי של מליוני דולרים ומדברים על היכולות של יזם להתגבר על קשיים
46:15 יוזמה נוספת של גנאדי היא Tel Aviv Coffee מפגש שבועי של מפתחים בהם משתפים רעיונות שרץ כבר 3 שנים, יש 500 אנשים בקבוצה ומגיעים כל שבוע בסביבות 30 מפתחים

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