רן, אלון, ודותן בפרק מספר 59 של באמפרס (371 לא-קוסמי-ואפילו-לא-ראשוני למניין רברס עם פלטפורמה) - סקירה של טכנולוגיות ודברים מעניינים מהזמן האחרון. הפרק הוקלט ערב כנס רברסים 2019, ובחסות חברת ForeScout (שהיא גם ספונסרית של הכנס).
רן - 

• מאחורי הקלעים (ידוע גם כ”שאלת הראיון הקלאסית”) - “מה קורה כש…”: גרסת Kubernetes - מההקשות על המקלדת, דרך שלל הפרוטוקולים ועד שהביטים מגיעים ליעדם
• אז זו גרסת Kubernetes - מה קורה לכל אחד מהרכיבים החל מ - kubectl Deploy דרך ה- Kubelets ועד לפרישה מוצלחת, קריאה מעניינת לכל מי שעוסק בעולם הזה
• רגע - מה זה בכלל Kubectl Deploy?! למי שמעולם לא השתמש ב - Kubernetes אולי לא בהכרח כדאי להתחיל מכאן, אבל למי שכן זו דרך טובה להבין מה קורה בפנים
• עוד מעולם Kubernetes - פרויקט קוד פתוח חדש של חברת RANCHER בשם k3OS
• החברה מספקת תשתיות בעיקר ל Kubernetes, וזו מערכת הפעלה שהיא “K8s native” - יש node של K8S שמגיע עם מערכת ההפעלה (בלי למשל להתקין קודם Ubuntu ועליו K8s וכו’)
• המערכת מאוד “רזה” ומינימליסטית, ומכילה רק את מה ש-K8s צריך, מה שמאפשר להריץ אותה על חומרה מאוד בסיסית (“חלשה”), שמתאימה למכונות קצה (Edge) דוגמאת Raspberry Pi וכו’.
• מה בעצם יש להרוויח מהרצת K8s על חומרה חלשה? זה לא שיהיה אפשר להריץ המון משימות (כי החומרה, ובכן,  חלשה…)
• יש מקרים בהם נרצה רק את ה - Orchestration features, בלי צורך ב - Scale, למשל: הרבה מאוד רכיבים קטנים (VPN Gateway?) בהרבה מקומות בעולם. באופן הזה מתקבל מישור ניהול אחיד ונוח להכל ביחד (גם ל-Data Center וגם עבור תחנות הקצה)
• ה - Workload מן הסתם יפוצל באופן לא אחיד, אבל הניהול יהיה ממקום אחד, עם אותם כלים ואותו Monitoring וכו’.
• יתרון אפשרי נוסף הוא שיקולי Security ו - Hardening (לא מריצים מה שלא צריך, חלק שאין לא יתקלקל), חוץ מזה צריך שפחות חומרה כמעיין Side Benefit
• האם נריץ על המקרר? כנראה שלא, אבל שווה לבדוק
• ואם כבר מחפשים צרות - מה קורה עם Updates? יש סעיף שמתייחס לזה, אבל כרגיל זו נקודה עדינה ששווה לשים לב אליה
• שאלת בונוס - האם האייטם הקודם רלוונטי לכאן? כן . . . בסוף זה עדיין K8s. ההבדל המשמעותי הוא במערכת ההפעלה (מעיין Linux שהורידו ממנו כמעט הכל והוסיפו K8s)
• ויש עוד דברים, למשל - כנס GitHub Universe, שכלל כמה הכרזות מעניינות, בהן - 
• תוכנית חדשה בשם Sponsors - עכשיו אפשר לקבל sponsorship לפרוייקטי קוד פתוח דרך GitHub
• הנה לינק ל - Keynote בדקה הרלוונטית
• יש אינטגרציה ואגרגציה למערכות קיימות (למשל Gittip), ו- GitHub מספקים את הממשק ומציגים את הפרטים בחזית הבמה של הפרויקט
• אולי יקח זמן, אבל עם פוטנציאל למהפכה אמיתית - מאפשר ליותר מפתחים לעבוד לבד או בקבוצות קטנות עם בסיס כלכלי
• ראוי לציין שזה בסך הכל מאוד קל - הוספה של קובץ קונפיגורציה ל Repo וזהו בגדול
• נקודה שעלולה להסתבך - לאן בדיוק הולך הכסף? צריך להגדיר לאיזה Contributor מגיע מה, ומאחורי הקלעים חבויה בעיה לא פתורה של איך בדיוק מחלקים כסף בפרויקט קוד פתוח, או יותר נכון - מהו מבנה האחזקה של פרויקט Open Source ואיך מעדכנים אותו (למשל כשיש Contributor ראשי שכבר לא כל כך תורם וכו’)? . . . ומה בעצם ההבדל בין זה לבין Bug bounty? כסף כרגיל מסבך את העניינים . . .
• אולי יהיה Use Case מעניין לחברות שיוכלו להקצות זמן רשמי לעבודה על קוד פתוח תמורת קבלות
• כרגיל יהיה יותר מעניין כשיכנס לסיפור Corporate Money (אלפי $ ומעלה) עם הצבת דרישות (SLA, תמיכה וכו’), פותח אפיק שקודם לא היה קיים - עד עכשיו היה אפשר לעבוד בחברה או לפתח מודל עסקי סביב הקוד הפתוח (Elastic Search style  וכו’, ואז AWS מגיעים וזה כבר Rabbit hole חדש בפני עצמו . . . ); עכשיו אולי יש משהו באמצע למפתחים קטנים שרוצים להתפרנס מהתחום.
• יהיה מעניין לפרויקטים ללא גב של Corporate (למשל D3, כנראה שה - Linux foundation יסתדרו גם בלי)
• היו ניסיונות למערכות תגמול של פרויקטי תכונה, ובטח יצוצו עכשיו עוד סטארטאפים בתחום
• ועוד הכרזה - GitHub Package Registry
• מאפשר לארח Registries בסגנון npm, Maven, Rubygems וכו’ - ב - GitHub
• לא שאי אפשר היה קודם, אבל אפשר לקוות לאינטגרציה יותר טובה (ואולי גם Security משופר)
• עדיין בבטא, כמו ה - Sponsors.
• מצגת של מפתח Go ותיק בשם Dave Cheney תחת הכותרת Clear is better than clever
• יש גם וידאו
• משתמש ב - Go כמדיום, אבל האמירות עצמן מאוד כלליות (ולא בהכרח צריך להכיר Go לעומק על מנת להנות מהמצגת) - איך לכתוב קוד שהוא קל להבנה, תחזוקה וקריאה, תוך טענה שזה עדיף על קוד חכם
• אמ;לק - אל תתחכמו
• כתוב ומוצג מאוד יפה, לא נכנס למחקרים וכו’ אלא מאוד Down to Earth ואינטואיטיבי - רק שבכל זאת נוטים לפספס הרבה פעמים
• מתחבר לקו של Clean Code ו - Uncle Bob, וזו עוד שכבה, מומלץ לחפש עוד מחקרים בנושא
• מאמר של Facebook על מערכת פנימית בשם Tupperware - כלי ה - Orchestration ו - Deployment הפנימי של Facebook (סוג של “ה - K8s המקומי”)
• לא קוד פתוח, אבל המאמר מתאר את ה - Design Principals וה - Trade-offs שנלקחו
• זה לא היה ממש סודי גם קודם, אבל המאמר כן צולל יותר לעומק על שינויים שנעשו לאחרונה - למשל העובדה (?) ש - Facebook רצים על חומרה יחסית חלשה (שצורכת פחות חשמל, הרבה שימוש במעבדים מבוססי ARM), מה שמכתיב החלטות Orchestration שונות ממקומות אחרים.
• היה מאמר של Uber שעסק ב - Workloads עם דפוסים שונים (Online לעומת Batch וכו’) על אותה חומרה לניצול מקסימלי - וטען שזה נכון עבור סוגים ספציפיים (וקונפיגורציות ספציפיות) של חומרה, ולא בהכרח נכון עבור חומרה יחסית “רזה” (כשלפעמים עדיף לשים workload ספציפי על חומרה ספציפית לניצולת טובה יותר).
• באופן דומה, יש הרצאה של AWS על איך ה - Framework של Lambda עובד  - בהתחלה ניסו לשים את האפליקציות של אותה החברה על אותם השרתים ולא הגיעו לניצולת טובה, ואז התחילו לנסות ב - Random - ועכשיו בכלל עברו להיעזר ב - Machine Learning לניצולת מקסימלית
• בסוף זה כנראה עניין של רמת ה - Fragmentation שניתן להגיע אליה באופן יעיל, משהו שחברה שיש לה Ownership מלא על כל ה - Stack, כמו Facebook או Uber, יכולה לעשות ו - AWS למשל לא יכולים.
• יש עוד דברים מעניינים, והמאמר עצמו מעניין ברמה ההנדסית ויחסית מפורט (שוב - לא קוד פתוח)
• מאמר ישן של Peter Norvig (בין היתר משמש כ Head of Research ב - Google) על איך ללמוד לתכנת בעשר שנים
• אמ;לק - דני סנדרסון אמר את זה קודם (לימוד שחייה בהתכתבות וכו’), כל הסדנאות של “למד לתכנת ב-21 ימים” לא שוות הרבה, והוא מגבה בהרבה טיעונים מעניינים על הטמעת חשיבה אלגוריתמית וכו’
• עוד נקודה מעניינת - המאמר תורגם להרבה מאוד שפות, כולל עברית (לא תרגום מלא ומדלג על חלק, אבל נחמד לראות)

אלון - 

• מזמן לא עסקנו ב - K8s, אז עכשיו Tinder פרסמו מאמר על המעבר שלהם ל - Kubernetes
• מסתבר שהיו להם המון קשיים במעבר, והמאמר הוביל להרבה תגוובת בסגנון “הנה דוגמא למה לא כולם צריכים לעבור ל - K8s” . . .
• המאמר הזה אינו מופע יחיד - צרות DNS ו - Network ועוד - בהתחלה זה נחמד, אבל אז רוצים מעיין “K8s ענק שמנהל את כל הצי” לטובת “ניצול משאבים נכון”, ואז מגיעים כל שאר האילוצים והכל מסתבך, ו - DNS הופך להיות single point of failure . . . מה גם שיש עננים שאינם של Google שעליהם כל הסיפור עובד פחות טוב, ולא תמיד נעים שצריך להיות Core Developer של K8s כדי לפתור בעיות
• חשוב לזכור שב - Scale ש - Tinder רצים עליו כנראה שתמיד יהיו בעיות, שלא בהכרח היו נמנעות גם בלי מעבר ל- K8s.
• מצד אחד הייתה מערכת שעבדה לפני כן, וכמות הבעיות ושנתיים עבודה לא נראים שווים את זה
• מצד שני, אמנם תרופת קסם זה בטח לא, ושנתיים עבודה זה כנראה הסדר גודל שצריך לקחת בחשבון - אבל בסוף הגיעו להישגים מרשימים.
• ובואו לא נתחיל עם מה יש לדבר על הענן של Google. לפחות החיפוש אחלה.
• קצת עצוב - How @DigitalOcean just killed our company
• חברה בשם @raisupcom ש @DigitalOcean החליטו מסיבה כלשהי שהם Malware, ומשם העניינים הסתבכו. מאוד.
• העסק לגיטימי, המערכת החליטה שהם לא - גם אחרי שתוקן ידנית. לא ברור איך נגמר אבל מרמז בעדינות שעדיף אולי לשקול לבחור ספק ענן אחר.
• ואם כבר ספקי ענן אהובים - Google outage