יום ראשון, 29 בספטמבר 2019

377 Bumpers 61

פרק מספר 61 של באמפרס (377 למניין רברס עם פלטפורמה) - רן, אלון, ודותן מתאוששים מהבחירות (שוב) עם סקירה של טכנלוגיות ודברים מעניינים בשוק התוכנה הלוהט מהזמן האחרון, לפחות עד שיפורסמו התוצאות הרשמיות (ממשלת אחדות של React ו-Rust?! שמעתם את זה לראשונה כאן)

רן - 
  • בלוג-פוסט מעניין שמגיע מ - Palo Alto Networks אחד ממייסדיה ישראלי) - השוואה של Security Features עבור Containers שונים - An Overview of Sandboxed Container Technologies
    • צעד אחורה לפני הצלילה - דוגמא נפוצה ל - Containers Technology זו Docker: טכנולוגיה שנחשבת פחות בטוחה מוירטואליזציה מלאה כיוון שכל ה-  Containers משתמשים באותו Kernel, ואעפ”י שננקטים הרבה צעדים על מנת לבודד בין ה - Containers השונים, הבידוד אף פעם לא מוחלט ותמיד יש חשש מזליגה של מידע או השפעה מאחד לשני - בעיה קיימת, שרירה וידועה בעולם ה - Containers נכון להיום, וכל הזמן מחפשים עבורה פתרונות שונים.
    • הבלוג-פוסט המדובר מציג את מה שנחשב כ - state of the art נכון להיום: מה הן ה  -Containers Technologies הקיימות היום ואיזו רמה של בידוד נלקחת על מנת לספק רמה גבוהה יותר של Security
      • ה - trade-off הקלאסי הוא Performance vs. Security.
    • יש כאן תיאור של Use-cases שונים וגם תיאור הנדסי של איך כל טכנולוגיה עובדת, וזה מאוד מעניין.
    • סקירה קצרה של מה שמתואר (אמ;לק)
      • לא טכנולוגית Containers (בתור התחלה . . . ) אבל נותנת מענה ל Use Case דומה - UniKernel: מעיין מערכת הפעלה שיש בה תוכנית אחת, למעשה - מערכת הפעלה שלמה שכל מה שהיא עושה זה להריץ את התוכנית שלכם (אם Zaphod Beeblebrox היה מתכנת וכו’); כיוון שכך - היא מאוד מוקשחת (כוללת רק את מה שהתוכנית שלכם צריכה - ולא יותר). כאמור - לא באמת Container אבל Use Case דומה - עם startup time מאוד קצר, מבנה מינימליסטי וכו’.
      • מ-IBM מגיעה Container Technology בשם IBM Nabla - גם אם לא שמעתם על זה קודם (כאילו יש משהו של IBM שהוא לא AS400, Mainframe או משהו מהשכבה הגיאולוגית הזו כן שמעתם עליו), זה קיים - וברשימה.
      • טכנולוגיה של Google בשם gVisor - טכנולוגיה שמשמשת את Google פנימית (וגם עבור App Engine לפני הרבה זמן), היום היא כבר מופיעה כקוד פתוח, ומהווה ברירת מחדל או משהו בסגנון עבור Kubernetes; מה שמעניין כאן הוא השימוש ב User-level Kernel - יש Kernel אבל ב - User level, כך שהוא לא משותף - אלא הרבה Kernels קטנים.
      • יש את Amazon Firecracker - שעליו כבר דיברנו כמה פעמים (וגם כאן וכאן).
      • וגם את OpenStack Kata - שגם עליו לא שמענו קודם (זאת אומרת - על OpenStack כן, Kata פחות - המושג עצמו מוסבר יפה ב - Phoenix Project).
    • בסופו של דבר - סקירה מאוד יפה ומעמיקה מומלץ.
    • אז בכל זאת TL;DR לאמ;לק? חלק מהטכנולוגיות ברמת בשלות גבוהה וחלק פחות; וכל אחת מהן לוקחת איזשהו Trade-off בין Performance ל - Security, וכל אחד צריך למצוא את המקום הנכון בשבילו - אין פתרון קסם אחד.
    • יש גם טבלת סיכום בסוף המאמר, עם Features שונים כמו הפעלה דומה ל - Docker, האם הקוד פתוח (כן, כולם), וכו’ - יכול לעזור לבחור.
    • בשורה התחתונה - אנחנו יודעים ש - Docker הכי פופלארי אם אתם בעניין של מיינסטרים (אפילו לא מופיע בסקירה . . . ), אבל גם סביר להניח שהוא הכי פחות בטוח (Secured), אז אם חשוב לכם Security כי למשל את מריצים workloads מגורמים שהם Un-trusted ואתם חייבים לשים לב; אם כל ה - workload שלכם פנימית אז הסכנה אולי פחות גדולה ועדיין מומלץ לשים לב ולמנוע מבעייה באחד ה - Containers לזלוג לאחרים.
    • שורה תחתונה, שוב: ה - trade-off הקלאסי של Performance vs. Security, עם רמות בשלות שונות של הפלטפורמות השונות: gVisor ו - Firecracker ברמת בשלות גבוהה יחסית והשתיים האחרות פחות, אבל אף אחת לא פופלארית ברמה של Docker למשל.
    • צריך לקחת בחשבון שלפעמים בענייני Security הדברים הכי פופלאריים הם גם הכי מסוכנים - אם מישהו מנסה Brut-force ויודע שרוב הסיכויים הם לנחות על Docker אז אולי ישקיע בזה יותר וזה סיכון.
    • מצד אחד - אולי ככל שהפלטרפרומה יותר פופלארית כך היא תהווה מטרה יותר גדולה ל Hackers, ומצד שני  - יותר עיניים יסתכלו עליה כך שיותר באגים ימצאו ואולי כך היא תהפוך ליותר קשיחה. מאזן אימה . . .
  • הבוטים באים! AWS Chatbot: ChatOps for AWS
    • איפה נועםר?
    • אז AWS פרסמו פלטרפורמה בשם AWS Chatbot, שיכולה להוות נדבך משמעותי ב - Chat-Ops על AWS.
    • רגע - ChatOps?
      • מדובר ביכולת לנהל סביבת Production דרך צ’אט - אם זה Deployment או Provisioning למכונות, Scale up או Scale down, ניטור (Monitoring) . . . הכל דרך צ’אט.
      • שיטה מקובלת בכל מיני חברות, אחת המפורסמות היא GitHub.
      • יתרונות - שקיפות: אף פעם לא עושים SSH לאיזשהו Server, הכל דרך צ’אט אז כולם רואים מה קורה, וגם יכולים ללמוד איך לעשות את זה בפעם הבאה לבד.
    • ובחזרה לאייטם - AWS Chatbot, מאפשרת לממש ChatOps על AWS.
    • רן השתמש (בקטנה) לצרכי עבודה - פונקציות Lambda שמדווחות על Events ב-AWS, או כאלה ש”מאזינות לצ’אט” ועושות פעולות על AWS, ויש גם דברים אחרים.
    • זו פלטפורמה קצת יותר הוליסטית, שיכולה להוות נקודת התחלה די טובה, בהנחה שאתם עובדים תחת AWS ורוצים ChatOps.
    • אז עכשיו רק חסר להוסיף את זה עם פקודות קוליות ל Alexa . . . רק לחבר לשירות Text to Speech שלהם (Polly) וזהו?
      • תכל’ס - מה הסיכוי שזה כבר קיים? כל ה-Echo Devices גם ככה מקשיבים כל הזמן, אז אפשר להתחיל להרים מכונות כבר כשמתמעורר הדיון בפינת הקפה, ואז כשסוף כל סוף מגיעה הפקודה זה מוכן ממש מהר. נשאר רק לממש Delay קטן כדי למנוע חשדות ולהפחית Creepiness .  . . אין על SkyNet.
      • האם אפשר לשדר את כל הפקודות הקוליות בתדר שרק מכונות “שומעות”, ואז לעשות Hacking לכולם? בטח גם זה כבר קיים . . . מסביר מלא דברים.
    • וברצינות (יחסית) - זה עובד רק על AWS או שניתן לבצע אינטגרציה עם מערכות אחרות?
      • מה שהם מממשים עובד רק על AWS, עם ה - Backend של AWS - למשל EC2, ELB ,S3 וכאלה, אבל אפשר לקחת Design דומה, וקונספטואלית לעשות משהו דומה עבור פלטפורמה אחרת - וזה גם קיים -
      • אחד הראשונים היה HUBOT של GitHub, והוא עדיין די פופלארי (על אף הרבה re-writes, במקור זה היה ב CoffeeScript, אבל יש מצב שיש כיום בעולם יותר מפתחי Cobol מ-CoffeeScript…)
      • יש גם פלטפורמה חדשה שנכתבה ב-Go, עם השם הקליט joe
    • טרנד אחר שמתכתב עם זה הוא GitOps, אבל זה אולי לפעם אחרת.
  • הכרזה של AWS על POP חדש בישראל - AWS CloudFront launches a POP in Israel
  • ואם ב-AWS עסקינן - עוד הכרזה קטנה על Improved VPC networking for AWS Lambda functions
    • למי שהתעסק על Functions ו-VPC יודע שהייתה בעיה בחיבור של Lambda עם VPC - כשה-Cold start עולה משמעותית יותר לאט (עד כדי 8-10 שניות, לעומת סדר גודל של עד שנייה אחת).
      • יש לזה הרבה “תירוצים” של חיבורים ותשתיות וכו’
    • עכשיו - נפתרה הבעיה, ובחיבור של Lambda עם VPC לא אמור להיות שינוי משמעותי ב-Cold start, שזה די מגניב כי זה הפריע לשימוש ב-Lambda במקרים מסויימים, למשל אם היה צריך להתחבר ל-Database שמאחורי VPC.
  • האייטם הבא - GitHub: בהמשך להכרזה מלפני לא מעט זמן על GitHub Actions, אז GitHub Actions now supports CI/CD, free for public repositories
    • הכרזה על Workflows, שזה בעצם CI/CD - בחינם עבור פרויקטים פומביים (Public).
    • למעשה ניתן להשתמש עכשיו ב GitHub Actions על מנת להריץ CI, באותו אופן שבו יכולתם להריץ למשל CircleCI או Travis-CI וכו’.
    • בכל מקרה - עכשיו זה מובנה בתוך GitHub וזה די נחמד
    • רן כבר השתמש בזה בפרויקט (טיזר להמשך . . . )
    • ה-Feature כולו עדיין ב-Beta, אבל אתם יכולים להגיש בקשה להתקבל ל-Beta (רן התקבל, רק אומרים).
    • אז רן מימש GitHub CI - פרויקט שנכתב ב-Go, ורואים למעשה Tab חדש בתוך הפרויקט, שנקרא Actions, ושם ניתן לראות את ה-CI Process שלכם ואיך הוא רץ - בכל פעם שאתם עושים Push (בין אם זה על Master או על Branch), ואם פותחים Pull Request אז רואים שה-CI רץ ומה הסטטוס כו’.
    • קצת באיחור לעומת GitLab, שם הפיצ’ר גם קצת יותר בשל . . .
      • באופן כללי, GitLab נוטים לאשר יותר Features לעומת GitHub, אם כי אולי יש כאן מעיין שינוי מגמה של GitHub, וניסיון להיות יותר הוליסטיים, לעומת הגישה המינימליסטית עד כה (אנחנו source code hosting, ושכל השאר יתרכזו בכל השאר).
      • למה בעצם לעבור? דותן ניסה למצוא סיבה לעבור מ Travis-CI ל-GitHub Action, ולא כל כך מצא . . . בינתיים זה באמת לא ממש יותר טוב, אולי למעט זה שהכל Baked-in. הכל במקום אחד.
      • ל-GitLab למשל יש פיצ’ר נחמד שעדיין אין ב-GitHub, שמאפשר לעשות Merge רק אחרי שה-build עובר בהצלחה, וזה יכול היה להיות נחמד. תיאורטית אפשר גם היה לתפור משהו כזה עם Travis-CI, אבל בינתיים חסר.
      • ועדיין - הכל באותו המקום, וזה נראה כיתרון היחיד.
      • מה שכן - actions קצת יותר גמיש ויכול לתת קצת יותר מאשר CI, אלא כל סוג של Action. אולי נחמד.
  • הפרויקט המדובר שבו רן השתמש ב GitHub Action נקרא go-grpc-channelz
    • מי שמתמש ב-gRPC מכיר את הקונספט של Channels - אבסטרקציה מעל Connections, בין Client לבין Server, והם לפעמים מורכבים - יש Name resolution ויש Load Balancing ו-Life cycle ו-Reuse, ומושגים מגניבים כמו “ריבוב של הודעות על אותו Connection” ו”פיזור של RPC אחד על הרבה Connections” ועוד.
    • בסופו של דבר - יש לוגיקה לא פשוטה, וכשרוצים לדעת לאן ה - gRPC Client מחובר כרגע ומה המצב שלהם  (יש שגיאה?) - קשה לדעת עם הכלים שהם built-in.
    • אז gRPC חושפים מעיין ממשק שנקרא ChannelZ - למעשה מדובר באוסף קריאות שניתן לעשות ל-gRPC, ובאמצעותן לקבל הבנה של הסטטוס של כל ה-Channels וה-Sockets.
    • רן לקח את הAPI הזה ובנה סביבו UI - אפשר להתחבר ל-Server תוך כדי Troubleshooting, ולראות את הסטטוס של כל ה-Connections.
      • עובד גם עבור Client וגם עבור Server.
    • הפרויקט משוחרר בקוד פתוח, ב-Go.
    • דותן ואלון משתמשים ב-gRPC? לא . . .
  • ועוד אחד - אתר חדש בשם Infrastructure.AWS
    • מומלץ לפתוח על מחשב נייד ולא על iPad או מכשיר נייד אחר - מראה אנימציה / אילוסטרציה של פרישת AWS בעולם
    • רואים כל כדור הארץ ואת ה - regions השונים, ואת ה - Availability Zones, את ה - POP (ישראל עדיין לא מופיעה נכון לרגע ההקלטה. אנטישמים?! ד”ש לוורנר ב-1 באפריל הבא).
      • מה אומר שמישהו ממש ממפה ידנית? . . . יש המון נקודות.
    • ממשק יפה - ויש גם הסברים טקסטואליים אם אתם רוצים להבין מה זה מה, ובאיזו חומרה מדובר (בגדול - איפה יש Custom Hardware ומה עושים איתה). מגניב, צעצוע נחמד.
    • זה גם מסביר מאוד יפה את הקונספט של Availability zones - זה מעיין “Common Knowledge” שבכל Region יש כמה Availability zones, והם מופרדים גיאוגרפית לפחות בכמה קילומטרים, וזה מוסבר יפה, לפעמים אפילו עם תמונות (ואדי גדול, שבצד אחד זה Availability zones אחד ובצד השני Availability zones אחר).
    • אפשר גם לנתח יותר לעומק (בהנחה שהמידע מדויק לרמה הזו) - נראה למשל שבאיטליה כל תלוי ב Availability zones במילאנו, וכו’. מעניין עבור תכנון של DR.
      • מצד שני - גם אם רואים קו אחד, יש מצב שבפועל המספר שונה. האם בין ארה”ב לאירופה יש באמת ארבעה קווים?
      • אפשר לראות לאן הולכות (תיאורטית) היציאות של כל Data Center וכו’. מעניין.

דותן - 
  • מישהו שמע על VSCode dev containers? על VSCode כנראה שכן, על Dev Containers כנראה שבתחילת המשפט הנוכחי . . .  - 
    • אז יש כזה פיצ’ר, ומטרתו היא לארוז את כל סביבת הפיתוח שלכם לתוך Container, ו”לחווט” בין ה - VSCode לבין ה - Container כך שה-VSCode “חושב” שהוא עובד עם סביבת פיתוח שנמצאת בתוך ה - Container, כך שלא צריך סביבת פיתוח על המכונה שלכם (מטריקס ל - VSCode?).
    • פיצ’ר שנראה מגניב - דותן לא ניסה, אבל כן זוכר שעשה דברים כאלה ידנית, ועל פניו נראה שיש כאן הרבה פוטנציאל עבור דברים שבהם צריך להיכנס קצת יותר לעומק לתוך Container ולהבין מה קורה (Debugging וכאלה).
    • המאמר המקושר מתאר Setup של פיצ’ר, וגם מסביר איך זה עובד.
    • מי שמנסה וחווה - אנא שלח גלויה (אפשר יחד עם התשובה לשאלה של אלון ממקודם, אין צורך בשתיים - דואר ישראל גם ככה עלול לקרוס מאחת).
  • כאן יש פרזנטציה או מעיין Workshop על Go Tooling
    • למי שמכיר את ה - extension של VSCode עבור Go, וגם בכלל את ה - tools  עבור Go - יש כבר המון כאלה.
    • כאן יש מעבר על הרבה מהם, הסברים על הלוגיקה ועם הרבה מאוד קישורים (בתוך הוידאו)
    • אחד הקישורים הוא גם כל החומרים של ה - workshop ב - GitHub, כולל המצגת - ממש מגניב, אפשר גם לעבור offline.
    • זה רק עם VSCode או כללי? ההדגמות הן על VSCode, אבל בסופו של דבר - כל מערך הכלים שבתוך ה - Extension קיים גם כמערך כלים נפרדים “בצד”, ודותן מכיר אותם גם בלי קשר ל - VSCode.
    • ה - Extension של VSCode מאוד מוצלח - הבא בדירוג הוא אולי VIM, ונראה ששניהם שואבים מאותו רעיון של לבנדל (!Bundle) את הכלים למקום אחד, וליצור “workflow מושלם”.
    • יש גם Plug-in חדש ל VIM ב-Go - שגם כתוב ב-Go (עדיין ב-Alpha).
      • המפתח המקורי של VimGo הודיע על יציאה לחופשה בלתי מוגבלת - אבל יש מי שיחליף אותו כך שה-Plug-in ללא ישאר בודד
      • ה - Plug-In החדש עדיין לא כולל את כל מה שיש ב Vim-Go, אבל יש גם כמה דברים חדשים ואמור להיות מעניין.
      • אכן Vim-Go היה ה-Extension המוביל בשוק עד ש-VSCode הכינו כזה Extension, ונראה שגם Microsoft תומכים בזה; נראה שהם עושים הרבה דברים נכון ודותן בינתיים מאוד נהנה, בטח ביחס לסטנדרט הקודם ב-Vim (שנתמך ע”י Fatih Arslan).
  • כלי שנקרא Sampler - ויזואליזציה מעל CLI
    • כן - מטורף
    • דמיינו Dashboard ב Command Line - עבור כל פקודה, אם הפלט נראה כמו סדרת-זמן כלשהי (Time Series, מאקסל כלשהו אולי) - אפשר לייצר מזה גרף שיופיע אוטומטית ב - Dashboard, ואפשר לעשות Channeling של כל הפלט לתוך ה - dashboard הזה.
    • כל הפקודות הן הפקודות הרגילות שאתם מריצים גם ככה.
    • אפשר להשתמש גם בכלים Built-in וגם ב - Shell Scripts או כלי CLI למינהם, וליצור מעיין Grafana בתוך הטרמינל שלכם.
  • קצת מעבר ל - React ו-Hooks - כלי שמקנוורט (Conversion, כן?) מ-Class Containers ל-Hooks, אוטומטית.
    • רגע - לא אמרנו שלא אוהבים Hooks? סבלנות . . . יחסי אהבה-שנאה וכו’.
    • הכלי הזה הופך את Class components אוטומטית למבוססי-Hooks. נחמד עבור מי שרוצה להריץ על כל הקוד וישר Deploy ל-Production. 
  • בהקשר דומה - Reactive Hooks: אם כבר המרתם את הכל ל-Hooks, ונשאר לכם רק RX לא מומר, אז הנה פתרון (?)
    • ספרייה שלוקחת את RX ונותנת Hooks כך שתוכלו לחבר ל - React שלכם.
  • אבל אמרנו אהבה-שנאה, לא? אז הנה זה מתחיל - React issue שבו מישהו מתחיל לגרד את פני השטח ומראה בעיית Performance, אם אתם משתמשים יותר מדי ב-Hooks.
    • השיחה מאוד מגוונת, וחלק טוענים שזה בעצם כל הרעיון ושהבעיה היא בכלל במקום אחר (רמז: ה- Design לא נכון), שזה אולי לפעמים נכון - אבל בסוף מצביע על זה שאתה לא באמת רוצה שכל העולם יעבור ל-hooks ותיהיה בעיית Performance . . .
    • מה שבאמת מעניין כאן הוא ש Tom Dale (“כוכב ב-Java” שדעתו חשובה, לפחות לדותן) מפרסם טוויט שבו הוא אומר (אמ;לק) שהוא מסתכל על Hooks אבל עדיין לא ממש מבין את הרעיון ולא בטוח שזה באמת גורם לקוד להיות יותר קריא או מובן”.
      • יש כאן סוג של Magic ,אבל לא ברור עד כמה זה “טוב” או “נכון”. 
      • דותן חותם על זה.
      • משם מתפתחת שיחה, כל אחד מוזמן לבחור צד בסיפור.
    • אלון - לא עבדתי מאסיבית עם Hooks אבל די אוהב אותם, אם אתה מסתכל על מפת התפתחות עולם ה-JavaScript, לא כל כך ברור האם Hooks ישאר איתנו - כרגע View צובר תאוצה, ואולי משם תבוא הישועה.
    • דברים כמו זה ש-Hook צריך להיות במקום מסויים בקוד ולא בתוך Expression מסויים כי זה אסור . . . אי שם במורד הטוויט יש גם תגובות של Dan Abramov
    • זה הופך את החלק React ליותר שפת High-level ופחות JavaScript-ית - מעיין מטא-שפה: יש חוקים של JavaScript וקוד, אבל אם אתה רוצה להשתמש ב-hooks אז החוקים לא בהכרח מתקיימים, וחלקם לא ממש הגיוניים אם אתה מגיע מתוך חשיבה של מפתח.
    • מצד שני - היו פעם פרויקטים של React-TV וכאלה שלא ברור מה מצבם - משהו הוליסטי שמחליף את המנוע מאחורה - ואז אולי hooks כן לוקח למקום טוב? . . .אולי.
    • זו שיחה שלא ממש קרתה עדיין, אבל מתישהו תיהיה ככל שיהיו יותר Tom Dale שיעלו את זה.
    • שם הבלוג-פוסט כפי שמופיע ב Almanac מבחזרה לעתיד - “React is not JavaScript”
  • מפה לשם הייתה גם הכרזה על ה - iPhone החדש
    • אלון טוען שצפה בזה כבר ב-2018 . . .
    • דותן צפה בזמן אמיתי (גרסת 2019), ובשלב ה”יש לנו 3 מצלמות!” ויכולות ה -Slow motion הוצג גם ה -  SlowFies . . . מפה לשם - ניסיון לרכוש את הדומיין, בעלות עליו למשך 5 דקות תמימות ואז מכתב ביטול. יש מצב שלעוד כמה אנשים עברה המחשבה של “הנה אני עושה מכה ופורש” באותו הרגע.
    • או לפחות אופציה לפינה חדשה בפרק על רעיונות לאופורטוניסטים.
  • ומכן - ל Domain-Driven Design w/typescript
    • שפת TypeScript היא Strongly-typed (או לפחות Flavor כזה), ולקח זמן עד שהתחילו לחשוב עליה ככזו.
    • המאמר מנסה לבטא דומיין מסובך יחסית, ו - Domain Driven Design זה הפתרון לבעיה מסוג זה, ומתוארת דוגמא קלאסית של הפעלה על TypeScript.
    • מי שמחפש לבטא Domain שלם באופן שיהיה ניתן לתחזוקה (Maintainable) סבירה וניתנת להבנה ועל הדרך גם Clean Code - זו מתודולוגיה טובה לזה. ומי שרוצה גם לשלב TypeScript - זה בשבילך.
  • קצת Kubernetes - שני Dashboards מעניינים, שבאים להחליף את ה - Default - 
    • הראשון הוא kontena kube dashboard
    • והשני - octant של VMWare
    • יחסית לסטנדרטי - שניהם טובים יותר, ויש עוד כאלה שלא מופיעים בלינקים כי הכל נראה די אותו דבר - שווה לעקוב, יש פוטנציאל ליותר ממה שניתן ב - Default.
    • אם אתם משתמשים ב - GKE, אז שם יש דשבורד שונה - לא עשיר, אבל יש לו Extension features, כמו היכולות לאינטגרציה עם מערכות חיצוניות וכו’.
    • לטובת ה-Default יאמר שהוא עדיין באיזושהי אבולוציה, אבל נראה שמי שמפתח אותו קצת נתקע עם פרויקט גדול מדי ולוקח זמן לעדכן.
  • קצת כאוס - פרויקט ב - GitHub בשם kube-entropy: מייצר Chaos Engineering מעל K8s
    • יש מי שטוען שאפשר פשוט לתת ל-K8s לעבוד וזה יקרוס לבד.
    • מי שבכל זאת רוצה - דותן בחן, כלי נחמד.
    • דותן מתכונן להתחיל - בתקווה שלא יגמר במאמר של “3 שנים אחרי  איך נלחמנו ב-DNS” וכו’.
  • אבל דווקא יש מאמר כזה - של Ian Eyberg, בשם Kubernetes is in Hospice
    • מאמר קצת פסימי, אבל גם מעיין משב רוח מרענן - הוא טוען ש K8s זה סוג של “בית הבראה” (במובן הלא טוב), ומתאר את כל הבעיות שהוא מצא.
    • דותן מאוד התחבר, בוודאי תוך כדי ניסיון לבנות תשתיות לתוך K8s - בפוקוס הזה, מגלים את כל ה-WTF, ואיך כל זה בדיוק אמור לגדול ולהתפתח . . .
    • דברים כמו CRD וענייני Network? כאלה.
    • יש בעיה ב-API, ויש פתרון - וגם הוא לא משהו ומציף בעיות אחרות, וכך הלאה.
    • בשבוע שעבר רן פגש את Kelsey Hightower בענייני עבודה - מדובר באחד ה - Advocates העיקריים של K8s, שמטייל בעולם ומספר על כל הטוב (וגם הרע - לא ה - Developer Advocate הקלאסי)
      • אחד היתרונות והחסרונות של K8s זה שהיא מתפתחת מאוד מהר - לא הייתם רוצים לעבוד עם פלטפורמה “מתה” שלא מתפתחת, אבל זה גם קשה לקום כל שני ורביעי ולגלות שה-API השתנה . . . הגבינה כל הזמן זזה.
    • דוגמא ספציפית - יש מישהו שאחראי על הכניסה ל - Cluster (מעיין Mission Control), ויש לצורך העניין חמישה Components , וכל אחד בודק את ה - Component של עצמו (“אם ה - Image מתחיל באות A אז בסדר, אחרת לא ב - Cluster” וכו’). נוצר מצב בו כל מי שה-Pod עובר דרכו על מנת לקבל אישור יכול לא רק לעשות ולידציה ולאשר (או לא) כניסה ל - Cluster, אלא יכול גם לשנות אותו (כקלט לבא בתור)
      • נוצר מצב בו כל אחד יכול “לעבוד על החבר שלו” במורד הזרם של ה - Admission, וככה אפשר להכניס Image “בכוח” לתוך K8s.
      • תיקנו את זה - אבל באמצעות הרצה כפולה. ומה אם מישהו משנה שוב? נריץ פעם שלישית? לא ברור . . . אולי זה לא ככה ב - Core של K8s, אבל בפריפריה ובחלקים ה-Beta-יים זה די ככה, וקריטי ל-Production.
    • לסיכום - K8s זז מהר וזה מדהים וההתנהלות “מושלמת” ומתוארת ב - GitHub Repos והכל - אבל ה - Hype לוקח את העגלה ושם אותה הרבה לפני הסוסים, מה שמקשה על ההתמודדות (עם כל הסוסים).
    • עוד רשמים מ - Kelsey Hightower: נראה ש-K8s זו מפלצת שיודעת לעשות המון דברים, אבל עדיין לא ממליץ להריץ על זה מערכת של State-full Containers, כי זה עדיין לא מוכן - אפילו שיש Features שמאפשרים את זה, ויש כאלה שעושים את זה.
      • השאלה היא כמה שומעים את הקול שלו מבפנים, אל מול עוד מישהו שניסה להריץ איזשהו State-full-Whatever וכתב על מאמר שתיאר את ההצלחה הגדולה - אבל לא נמצא ב-core של K8s, ואולי הניסון שטחי או לא ברור, אבל הבא שקרא את זה לא שם לב לזה, וזה שאחריו בטוח לא ו . . .  טלפון שבור.
      • בסופו של דבר, כל אחד רוצה לנסות בעצמו ולראות אם זה באמת עובד. לפעמים זה לא. בשביל זה יש Chaos Engineering.
  • עוד סקירה על תשתית בשם Flannel - למי שרוצה להכנס לעומק, די ספציפי ונישתי
    • אחד המודלים הראשונים שלומד מי שנכנס ל-K8s הוא ה-Networking, והוא יחסית מורכב.
    • למעשה יש מימוש של Overlay מעל ה - Network הבסיסי ומוודא שהוא Plug-able, כש - Flannel הוא אחד ה - Plug-ins.
    • או שלא בוחרים בכלל ולוקחים משהו מהענן  - שזו גם בחירה.
      • יש את Calico ואת זה של AWS, וב-Google משתמשים גם במשהו דומה.
    • בכל אופן - מאמר שצולל לתוך Flannel (או פלנלית - תלוי בגודל ה - Cluster).
  • מאמר על Slack - חברה שעוסקת בפרויקטי תוכנה, והם החליטו שהם מסרבים להצטרף ל-Slack של הלקוח
    • מרגישים את מה שכל משתמש ב-Slack מרגיש - יש בעיה עם פרודקטיביות, זה גורם לך להרגיש עסוק יותר וכו’.
    • חוץ מזה - מתארים גם את ה”לאמר לא ללקוחות” - כי slack “גונב” להם את הפוקוס (ואת שמחת החיים - לא אמרו, אבל נשמע ככה).
  • הודעה של Mozilla על זה שהם יורדים מ-IRC - המקום המתילוגי שבו הם מנהלים את כל הקהילה שלהם.
    • היסטורית היה להם IRC Server משלהם, חלקנו עוד זוכרים בתור ילדים
    • ופתאום מגלים שיש המון אלטרנטיבות - Slack, וגם Discord ,שהם הספיקו כבר לפסול - ויש עוד.
    • מעניין עבור מי שמחליט לרדת מ-Slack יכול לעקוב ולהבין אילו אפשרויות Self-hosted יש ובמה הם יבחרו.
    • מה לגבי Microsoft Teams? מישהו יודע האם Yammer עוד חי? נראה ש-Teams זה המקביל Slack, שאלון שמע עליו דברים טובים.
    • רגע - Mozilla תבחר ב - Microsoft? למה לא בעצם? . . . נשלח להם גלויה (והדואר קרס סופית)
  • עוד מאמר על Slack ופרודוקטיביות - קצת יותר ארוך ועוסק בצוותים ואנשים
    • למי שלא שם לב ש-Slack הורס לו את הפרודוקטיביות, שווה לקרוא ולראות האם את מזהים את עצמכם.
  • ומשהו לגבי Rust - יש כאן Meeting Notes שנקרא Rust in Large Organizations
    • מנוהל ע”י Niko Matsakis
    • לוקחים כמה חברות גדולות - Microsoft, Mozilla, Facebook ועוד - ומנסים לדבר על מהם הם צריכים מ-Rust ואיך עושים את זה. כל השיחה מתומללת - ממש מעניין.
    • דותן שמח - זה קצת עונה על שאלת ה”מי מממן את Rust?” ואיפה הגופים הגדולים בסיפור.
  • וחצי קשור: עבור מי שפעם שיחק ב Diablo 1 - אז עכשיו יש מימוש ב WebAssembly
    • ל-Rust יש כבר מימוש לא רע ל WebAssembly, ואנשים כבר משתמשים בזה על ה - Browser.

ולחלק האמנותי - 
  • ועוד - מהי מילת הקסם?
  • ולסיום - קצת Deep-fake, והפעם: Deep fake CEOs
    • יש לא מעט כאלה על תמונות וב-YouTube, ויש ראיון של Connan Obrain עם מרואיין שמתחלף
    • בכל אופן - כאן מישהו עשה את זה על הקול של מנכ”ל של חברה, והצליח להוציא סכום מאוד גדול מהחברה (אנשים חשבו שזה המנכ”ל, ועשו את מה שהוא ביקש…). מצחיק כנראה את כולם חוץ מאותם.

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