יום שבת, 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 מפתחים

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


יום שלישי, 23 באוקטובר 2018

351 Bumpers 52

רן, אלון, ודותן בפרק מספר 52 של באמפרס (351 למניין רברס עם פלטפורמה).


  • כנס רברסים 2018 עבר בהצלחה גדולה (1600 משתתפים, ~1,100 בכל אחד מהימים!) המצגות (וגם התמונות) כבר פורסמו, כל ההקלטות יועלו בקרוב (אודיו לפודקאסט ווידאו ל-YouTube).

רן - 
  • עורך Vim Editor עבר פורט ל - WebAssembly, מאפשר להרץ Vim בתוך הדפדפן עם WebAssembly.
  • זוכרים שפעם הייתה שפה בשם QBasic? אז עכשיו אפשר להריץ Serverless QBasic! צעצוע נחמד שמאפשר לכתוב פונקציות ב QBasic ולהריץ על AWS.
  • ספריה חדשה מבית היוצר של Go בשם Go Cloud - אבסטרקציה להרבה מה-API של ספקי תשתיות הענן השונים. זו ספרייה משותפת שהיא “Go Native”, שמקשרת בין העננים השונים עם ממשק שנראה אותו הדבר. לא קונספט חדש (ונסיונות קודמים לא ממש הצליחו באופן יוצא דופן), אבל שווה לבדוק.
  • קצת על kubernetes - פלטפורמת KNative יוצרת ממשק שהוא מעיין PaaS (אולי קצת כמו Heroku) מעל K8s: לוקח את קוד המקור ועושה את מה שצריך (Build, Events, Serving). נראה מעניין.
  • חדשות מחיפה! Istio הוא מעיין Service Mesh שמפותח ע”י כמה חברות (גוגל, IBM ועוד), ועכשיו יוצאת גרסא 1.0 שלו (ספוילר! מתוכנן פרק עם אחד מהמשתמשים של Istio בקרוב), כשחלק ניכר ממנו פותח במעבדות IBM בחיפה - Kudos :-)
  • עוד ביקור ב ZEIT, שהפעם הוציאו פלטפורמה שנקראת Serverless Docker Beta, שמאפשרת להריץ Dockers כ-Serverless (לפחות רעיונית). 
    • לכל Container לוקח זמן לעלות (כמה שניות ולפעמים גם יותר), כשמצד שני Serverless אמור להבטיח Deployment on Demand ברגע שצריך.
    • הרעיון כאן הוא שלא צריך להכיר AWS Lambda או Google Cloud Functions - מובטח שה-Container יעלה תוך מקסימום שנייה אחת, ואז ניתן לגדול (Scale) “מיידית” (תוך זמן מאוד קצר).
    • נשארים עם Dockers כשכבת אבסטרקציה, ומתמודדים עם בעיית ה-Setup time.
  • בלרינה (Ballerina) - שפה שהיא “Cloud Native Programming Language”
    • מאפשרת לתכנת API ו-microServices בענן במבנים שהם Native לשפה. 
      • לשפות הגנריות (Go, Java, …) אין נגיעה ספציפית ל-Deployment או ל-Build למשל - וכאן יש. ברמת העיקרון זה אמור להקל מאוד על הפיתוח.
    • לפי ה-Commits (שלהם טובים), מדובר בצוות פיתוח שעובד ב-WSO2 (שעושה Service PaaS), כך שיכול להיות שההקשר כאן הוא של שירותים ל-Enterprise וכו’.
  • עוד חברה עם מקורות (יזם) ישראליים - Elastic יצאו להנפקה ראשונית (IPO) בשבועות האחרונים, כרגע זה נראה כמו הצלחה יפה. כל הכבוד!
  • לפני כמה שנים התפרסם לוח עם Latency Numbers שכל מפתח צריך לדעת (כמה זמן לוקח לגשת ל-RAM, לדיסק, וכו’); כאן יש פרויקט שמראה פרספקטיבה לאורך זמן של המספרים האלה ,ואת השינויים לאורך השנים (מאז 1990). 
    • סביר להניח ש-Best Practices שהיו נכונים עד לפני כמה שנים כבר לא רלוונטיים (שלא לומר הפוכים) היום לתעדוף נכון של ארכיטקטורה. נכון להרבה דברים.
  • קצת מתכתב עם האייטם על QBsic - פרוייקט בשם WWWBasic מהווה מימוש של שפת Basic בתוך הדפדפן (!).
    • יצא כפרויקט רשמי תחת ה-GitHub של Google.
    • מראה איך אפשר לתכנת יחסית בקלות, והכל רץ בתוך הדפדפן, גם ככלי לימודי וגם כנוסטלגיה.
    • ספוילר! - אין מספרי שורות (יש מצב שיש אפשרות להוסיף אם אתם ממש חייבים “GoTo 20” וכו’).
    • השלב הבא - להפוך את זה ל-Serverless עם ה-QBasic מהאייטם מתחילת הפרק. שם העתיד. אולי.
  • חדשות טריות יחסית - Microsoft מצטרפת ל- Open Invention Network, שבו חברים (בין השאר) Google, IBM וה-Linux Foundation, ובכך חושפת מעל ל-60K פטנטים שעד עכשיו היו פרטיים שלה.
אלון - 

דותן - 

החלק האמנותי - 

  • וגם לסיום - כנס רברסים 2018 עבר בהצלחה גדולה המצגות (וגם התמונות) כבר פורסמו, כל ההקלטות יועלו בקרב (אודיו לפודקאסט ווידאו ל-YouTube).

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