יום ראשון, 25 בנובמבר 2018

Summit 2018: To DB or not to DB, or, Why Databases are like Religions / Amit Lichtenberg

One DB to rule them all? Hardly. Typical applications start their life with one DB, usually the one most fashionable, reliable, well-documented, referenced-on-google, or all of the above. Soon enough you find out not only that that DB you chose early on is actually wrong for you, but that it’s really hard to get rid of. In this talk you’ll see how in under two years, our application turned from single-DB, small & tidy, into a monster running four+ databases (on a good day), while testing and abandoning more than a few others on the way. I’ll discuss lessons learned the hard way on the process - about choosing a database, writing good code, making good products, and life in general.



MP3

Summit 2018: Going Full Rewrite - The Incremental Way / Alex Badyan

After coming to the realization that our backend system cannot scale for much longer and that new features are very difficult to add, we decided to write it from scratch.
With hundreds of thousands of users actively engaging our system, we don’t have the privilege to start over and grow slowly.
We rewrote the applicative layers while still relying on the old data store and then wrote a new db and app stack layer, replacing the legacy one piece by piece.
We implemented a migration system that is always on, meaning that every change in the old system makes its way to the new system, making the two systems eventually equivalent.
I will discuss the challenges and lessons learned.



MP3

Summit 2018: What I learned from 10 Yrs of "playing" with Neuroevolution - / Al Yaros

Bio-Inspired algorithms such as Genetic Algorithms and Swarm intelligence can be competitive alternative for Training Deep Neural Networks for Reinforcement Learning. My journey in this domain started 10 years ago by building a RL-DNN bot that compete in a 3D racing simulator named Torcs. (demo available on my Youtube channel) - In this talk I'll show a different approach to train a deep neural network that can drive and control a racing car that outperforms a human driver in simulated racing environment - laying the foundations to try and solve any kind of RL problem differently.



MP3

יום חמישי, 22 בנובמבר 2018

355 Technology Trends with Assaf Natanzon

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

  • אסף עובד ב Dell EMC (הרצליה) ומתמקד בשני היבטים -
    • העתיד של Data Protection - לא במובן של Security אלא של גיבוי (Backup) ואחזור מידע (Data Recovery) - טרנדים +5 שנים קדימה.
    • עבודה עם Dell Capital - זרוע ההשקעות של Dell, שאחראית על השקעות בכל הפורטפוליו (כולל Pivotal וכו’), עזרה בכל הקשור להערכות שווי (Evaluation) של חברות.

  • מה מפתחים היום בישראל?
    • המשרד הישראלי של Dell מתבסס על מספר רכישות - אסף עצמו הגיע רשמית ל-Dell לפני שנתיים עם הרכישה של EMC, ולשם דרך סטארטאפ בשם Kashya שעסק ב-Continuations Replication - טכנולוגיה שמאפשרת ליצור עותק של Block Device מרחוק, ולאפשר חזרה לכל נקודה בזמן לאחר מכן.
      • היום זה נמצא בתוך מוצר שנקרא RecoverPoint, ויש גם עבודה של גרסא למכונות וירטואליות (Virtual Machines).
      • יש עוד שני מוצרים תחת RecoverPoint  -גיבוי לענן (כרגע ל-AWS) ועוד אחד שעדיין לא מדברים עליו.
  • נראה שהעולם מתקדם בשני כיוונים, לכאורה סותרים - מצד אחד לקחת מערכת בודדת ולהפוך אותה לאמינה ככל האפשר, ומצד שני להניח ששום מערכת לא אמינה לחלוטין, ולפתח דרכים להתמודד עם זה (Clustering למשל).
    • חשוב להבדיל בין שני פרמטרים - זמינות (Availability) ויכולת אחזור (Recoverability):
      • עצם העבודה שהמערכת אמינה לא מגן מפני טעויות, למשל כשמישהו מחק טבלה ממסד נתונים, ועכשיו צריך לשחזר מנקודה שקודמת לטעות.
      • עולם ה-Disaster Recovery - במקרה של אסון טבע שמשמיד איזור שלם, כאשר מבחינת Latency לא תמיד ניתן לפזר את המערכת על מרחקים מספיק גדולים כדי לשלול את ההסתברות לנזק בכל המקומות במידה מספקת. וגם אם כן - זה לא מגן מטעות אנוש או באג לוגי.
  • סיכוי מול סיכון - מה הסיכוי שמשהו כזה יקרה בחיי חברה, ותצטרך לעלות חזרה מגיבוי - פעם בחמש שנים בערך זו הערכה סבירה? ואם כן, אנחנו מדברים על חזרה ברזולוציה מאוד גבוהה (שניות בודדות?) - יש דרישה כזו?
    • ראשית, בעולם הגיבוי (Backup) הדרישות לא כאלה חמורות (לא שניות), וגם הערכת ההתפלגות הרבה יותר נפוצה מפעם בחמש שנים - זה יכול לקרות אפילו כשאיבדתי גישה לקובץ במחשב הנייד שנמחק בטעות ואני רוצה לשחזר, וזה הרבה יותר תדיר.
    • עולם ה-Disaster Recovery עוסק לרוב באירועים פיסיים (שריפה, שטפון, וכו’)
    • בהיבט של תקלה לוגית, השאלה היא כמה מידע אתה מוכן לאבד - נקודת אחזור פעם ביום? כך שש שעות? כל רבע שעה במקרה של של Virtual Machines (אם כי במקרה כזה הביצועים יהיו בלתי נסבלים)?
    • זה גם תלוי הקשר - רבע שעה של טרנזקציות בבנק זה לא משהו שאתה מוכן לאבד, כנ”ל לגבי רבע שעה של עסקאות ב-Amazon למשל.
    • טכנולגיית ה-Continuous Replication משלבת בין Disaster Recovery והצורך לעלות עם אתר חלופי כמה שיותר מהר, ועולם הטעויות הלוגיות, בו נרצה לחזור כמה שיותר מהר לנקודה שקדמה לתקלה או לטעות. הרעיון היה לא להתבסס על Snapshots של ה - Storage (כי הביצועים מחרידים, ב-VMware למשל זה עדיין די ככה).

  • חזרה לכיוון הברזלים, וגיבוי ל- Block Device - “מה שיושב מתחת למערכת הקבצים” - 
    • דיסק (פיסי או לוגי), שמקצה מרחב כתובות (0 --> גודל הדיסק) ומאפשר פעולות בסיסיות (כתיבה, קריאה)
    • מערכת ההפעלה היא זו שמתקשרת עם ה - Block Device (איפה לאחסן את הקבצים, מה לקרוא וכו’)
    • מערכת הקבצים יוצרת מעיין שכבת אבסטרקציה מעל ה - Block Device, שמאפשרת אחסון קבצים, מצביעים ועוד
      • דוגמאות ל - Block Device עשויים להיות SSD פיסי, שירות EBS של AWS ואחרים.
    • את הבלוק הזה לוקחים, ויוצרים עבורו העתק מתמשך (Continuous Replication) - 
      • צריך איזשהו דרייבר בדרך, Data Tap בין ה- Block Device לבין מי שכותב אליו (גרסה וירטואלית של מחבר T) - בעבר ידענו לשים את זה בתוך מערכת ההפעלה, או בתוך ה-Storage עצמו אם זו מערכת פיסית.
      • במערכות וירטואליות ו-Containers, אותו Data Tap יכול להיות חלק ממערכת ההפעלה של ה-VM, או בתוך ה-Hypervisor עצמו.
      • האתגר הוא ההתנהלות כשמתרחשות תקלות - לדעת לא לאבד אף כתיבה כשמשהו נופל, לאפשר למכונה להמשיך מאותה נקודה ולא להתחיל לקרוא מהדיסק את כל המידע מחדש וכו’.
      • אתגרים נוספים הם לנהל את המערכת כך שניתן להגיע לכל נקודה בזמן, וכמובן ביצועים (Performance) וזמינות (Availability).
    • ה-Data Tap יוצא אל המערכת (הרפליקציה) דרך הרשת - במקרה הזה יש רכיב (Appliance) וירטואלי בדרך, שיודע לבצע בקרה ואופטימיזציה (ולהכיל Policies במידת הצורך), ולשלוח את המידע למכונה אחרת שמנהלת עותק מרוחק - שמכיל עותק של ה-Virtual Machine ו-Journal (בדומה ל Redo Log / Undo Log של Oracle), ובכך מאפשר לנוע על ציר הזמן של הגיבוי
      • מזכיר שפירמוט מהיר (q/) של Device לא באמת מוחק הכל אלא בעיקר את ה-MBR ועוד כמה רכיבים - סיפור מלפני ~17 שנים, שבו לקוח ביקש לשחזר מידע לאחר Format/Q וזה היה מהיר במידה שגרמה לו לחשוד ברמאות. בפעם הבאה הוא ימחק כמו שצריך.

  • ולנושא אחר - הצד המדעי / הנדסי של חשיבה על פטנטים (אולי יעניין אתכם גם - יש פרק ישן של רברסים על הצד המשפטי) - העבודה היומיומית, המטרות, המוטיבציה
    • למוטיבציה יש כמה מקורות - 
      • הגנתית - החברה לא מעוניינת שיתבעו אותה על פעילות שהיא עושה, ולכן מגנה על תהליכים ומוצרים (ויוצרת סוג של “מאזן אימה” מול אוסף הפטנטים של המתחרים)
      • פטנטים מעלים את השווי של החברה - מעבר למוניטין הרשום, זה נחשב כמדד לחדשנות בחברה
      • מה המוטיבציה למהנדס הבודד? בדומה לאקדמיה, יש כאן סוג של פרסום ומיתוג עצמי, ובחברות גדולות זה בדרך כלל גם מלווה בתמריץ כלכלי.
      • לאסף עצמו יש בערך 250 פטנטים רשומים ועוד סדר גודל דומה בסטטוס Pending.

    • איך נראית עבודה על פטנט?
      • קודם כל צריך לחשוב על רעיון (אסף העביר לא מזמן סשן בסנט פטרסבורג על איך חושבים של רעיונות חדשניים), ואז צריך להגיש מסמך . . .
      • בארגונים גדולים (Corporate) יש ועדה של מומחים בתחום, שאמורים לדון ולאשר את הפטנט להגשה; לאחר מכן ממונה עו”ד (מהחברה או חיצוני), שצריך להפוך את תיאור הפטנט למסמך פטנט רשמי, שבהתחלה עלול להראות קצת סתום עם תיאור מפורט של מה הפטנט עושה ועל מה הוא מגן (Claims), בשפה משפטית.
      • הפטנט מוגש למשרד פטנטים (בארה”ב, בסין, בכל העולם - שיקולי עלות/תועלת), מוגדר כ-Pending, ואז יש תהליך של ~3 שנים (ממוצע) עד לסטטוס Granted.
      • כמה זמן עבודה למהנדס עצמו על הפטנט? המסמך עצמו לוקח שעה-שעתיים, ועוד 30-60 דקות עם העו”ד. יש כאן עניין של ניסיון - בפעמים הראשונות הכל לוקח יותר זמן.
      • בסטארטאפ הכל פחות מובנה: “צריך פטנטים” --> Brainstorm --> מחליטים ושולחים, תלוי כמה תקציב הוקצה לכך (עניין יקר, אז לא שולחים הרבה - עשרות אלפי $, כולל העו”ד).

  • חלק שלישי - טרנדים בטכנולוגיה. אסף יושב בצומת מרכזי יחסית בכובע של Dell Capital, ורואה טרנדים בחומרה ותוכנה
    • תוכנה - Functions as a Service ו- Serverless Computing. הכל הופך יותר מהיר ופשטות הפיתוח מהווה גורם משמעותי. 
    • מכיוון ה-Data Protection זה קצת הפוך - מאוד קל להשתמש בשירותים חיצוניים, וקל להגיע לאפליקציה אחת עם מספר גדול של מסדי נתונים חיצוניים. למפתח מאוד כיף והכל הכי פשוט שיש, אבל איש ה-Backup עומד בפני סיוט, כי צריך לדעת לגבות ולשחזר הכל --> זה חייב להיות אוטומטי.
      • היום צריך בכל פעם סקריפט חדש של איש ה-IT, וזה לא Scalable במיוחד
      • ברמת הבלוק, אם למשל יש Kubernetes שרץ תחת VMware, תיאורטית אפשר לקחת Snapshots ואת זה כבר יודעים לעשות.
      • עיקר הבעיה היא ברמת הניהול בסביבת Cloud Native - ואיך להפוך אותו לשקוף ככל הניתן: אני יכול לעשות מאות גיבויים (וספקי הענן השונים מאפשרים את זה בקלות יחסית), אבל צריך לנהל אותם - מה קורה כשזה נכשל? מי שולח דוחות? איך משלמים על כל הנפח הזה? איך יוצרים קטלוג ויודעים מה נמצא איפה? לחברות גדולות (עם סיכון גדול במקרה של אובדן מידע) זה מאוד חשוב.
        • שיטת ה “בוא נחכה שיבוא האקר עם רשימת כרטיסי האשראי של הלקוחות ואז נשלם לו שיתקן” פחות מומלצת.
    • טרנד בולט נוסף - Edge Computing
      • הולך להיות מאוד בולט עם עליית המכוניות האוטונומיות (הערכת סדר גודל של 8Tb ביום - אין היום איך לשלוח את זה לענן באופן יעיל)
      • בהקשר של Edge Computing מדובר לרוב על מעיין micro Clouds במערכת היררכית, כשחלק מהעיבוד נעשה מקומית וחלק עולה לענן.
        • שעון חכם יכול לשלוח הכל לענן לניתוח, זה לא כל כך הרבה מידע כיום. מעבר לזה כבר הופך מורכב.
        • אנחנו מדברים על Data Centers שיכולים לשבת אצל ה-ISP או במחשב חזק של הרכב, שיעבד הרבה מהנתונים מקומית ויתקשר עם הענן ברמות שמעל.
      • מתחילים להופיע Frameworks בנושא - GreenGrass של Amazon וגם  EdgeX Foundry של Dell. ב-VMworld הייתה גם הכרזה על שיתוף פעולה בין VMware לבין Microsoft בנושא.

    • מה לגבי Dell - ככל שהעולם הולך לכיוון של Public Clouds, הכל יושב אצל ספקי הענן המרכזיים, והם מתחילים יותר ויותר לייצר את החומרה עבור עצמם, במקום לרכוש (מ-Dell למשל).
      • חברה כמו Amazon אכן מייצרת חומרה לעצמה (הרכישה של Annapurna Labs הייתה חלק מזה), אבל לרוב שירותי ענן זולים כשהחברה קטנה. כשגדלים זה כבר לא כל כך זול והשיקולים משתנים, כך השהדרישה לחומרה מחברות כמו Dell קיימת.
      • מעבר לזה, יש את עניין האמינות - EBS לא אמין כמו Symmetrix VMAX (בגרסא האחרונה זה PowerMax) למשל, אין התחייבות לאמינות שחברה הרבה פעמים דורשת מהשרתים שלה.
        • יש גם חלקים שלמים בתעשיות גדולות (בנקים למשל) שעדיין עובדים על Mainframe, והמעבר ל-Cloud Native יקח עוד זמן.
      • ועדיין - איך חברה כמו Dell מסתכלת קדימה בעולם שהולך לכיוון Serverless?
        • ראשית, הכל יהיה קיים גם בתוך ה-Data Centers של החברות - מעל Kubernetes יש את PKS, יש שיתוף פעולה בין VMware ל-Amazon שמאפשר לרכוש חומרה שמריצה VMware בתוך AWS, ובאופן כללי כולם הולכים לכיוון של Multi-Cloud.
        • לאורך זמן, יש דברים יקרים בענן - המון Storage ללא תנועה, המון Compute שרץ כל הזמן. Serverless יהיה יעיל עם פרופיל השימוש מוטה Peaks, אבל על פרופיל עבודה קבוע יחסית, שירותי ענן עשויים להתגלות כמאוד יקרים ביחס לחומרה בבעלות החברה. 
        • תמיד יש ענייני רגולציה ו-Compliance, שגורמים לחברות בסקטורים מסויימים לא לזוז, וגם אם כן - המעבר מאפליקציות סטדרטיות ל-Cloud Native לוקח זמן.
        • מעבר לכל זה, יש את כל מה שהזכרנו לגבי התפתחות ה-Edge Computing, שם יש ל-Dell פוטניאל עצום - Data Center נייד על גבי משאית, או בתוך רמזור למשל.
    • עוד טרנד לפני סיום - Persistent Storage: אחרי המעברים מדיסקים מגנטיים ל-SSD, היום רואים את המעבר לפרוטוקולים של NVMe שמדברים על Latency הרבה יותר נמוך, זכרונות של 3D XPoint ו - N-RAM, שישנו את האופן שבו אפליקציות נראות, בעולם שמוטה זכרון (Memory centered) - יכולות גישה מאוד מהירה לזכרון עם עקביות (Persistence) של דיסק.
      • ניתן להריץ בתוך המחשב שלך עם כמויות מאוד גדולות של זכרון; כשרוצים לצאת החוצה עדיין צריך לשלם ב-Latency - יש איזה עניין לא פתור עם מהירות האור, בעיקר עם זה שאי אפשר לעבור אותה (אלא אם אתה ברמזור בישראל, ואז הקול של הצפצוף קודם לאור מהרמזור).
      • ברגע שנעבור לעולם מוטה זכרון, הרבה מה-Best Practices הנוכחיים יצטרכו להיות מתוקפים מחדש, וחלקם לא יהיו רלוונטיים (למשל - אם הנחנו שהגישה לזכרון מהירה x1000 מגישה לדיסק, לא בטוח שזה עדיין נכון).

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

יום רביעי, 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, אתם כראה צריכים כזה. תבדקו.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול