פודקאסט מספר 353 של רברס עם פלטפורמה - אורי ורן מארחים במוצאי חג הבחירות המוניציפליות את שי ארליכמן לשיחה על פרויקט Istio (תזכורת לפודקאסט 351 / באמפרס 52). שי הוא CTO ומייסד משותף (Co-founder) של missinglink, שמספקת פלטפורמה לחברות עם Stack של למידה עמוקה (Deep Learning) ולמידת מכונה (Machine Learning), ועוזרת להן לנהל את הפיתוח והמידע - כלים שהתרגלנו אליהם בעולם קוד המקור ועדיין פחות נפוצים בתחומים הללו.החברה גדלה וכבר יש לקוחות משלמים, המוצר מפותח כבר שנתיים (ומשוחרר לשוק כמעט מההתחלה), הלקוחות הם המפתחים (קהל מאתגר :-)).חלק מ-Samsung Next, ממוקמים בשרונה בתל אביב (!Sharona  - לא להסתבך עם אבשלום קור). אז מה זה Istio?מפרש ביוונית. מתכתב עם ההגה של Kubernetes. יהיו עוד רפרנסים לים בהמשך . . .אז מה הבעיה?בפיתוח אפליקציות 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. הבעיה היא שזה מאוד מוגבל מבח