Podcasts about term c

פודקאסט מספר 368 של רברס עם פלטפורמה - אורי ורן מארחים בכרכור בערב חג הפועלים את שחף ואת אלכס להמשך סדרת Outbrain ושיחה על Kubernetes (להלן k8s) ו - Dyploma (בהמשך).הפרק בחסות Applied Materials, שהם (גם) ספונסרים של Reversim Summit 2019 (שוב רמז, כן. שריינו תאריכים ובואו בהמוניכם, יש אג’נדה).אפלייד מטריאלס היא מובילה עולמית בתחום ייצור השבבים והיחידה העסקית הישראלית שלה, בפארק המדע ברחובות, עוסקת בבקרת תהליך הייצור. קבוצת התוכנה בישראל מונה כ – 350 מפתחים העוסקים במגוון רחב של תחומים (DSP , deep learning , עיבוד תמונה , UI/UX , Frontend & Backend ) ובמגוון רחב של שפות (python, Java, C++ ועוד). יחד הם מתמודדים מול אתגרים בחזית הטכנולוגיה, פתרון בעיות מורכבות וחשיבה מחוץ לקופסא. הסיפוק של להיות חלק ממוצר פיזי, המורכב כולו כאן ומשלב תוכנה וחומרה שלבסוף מגיע ליצרניות המעבדים המובילות בעולם, הוא עצום. רב הסיכויים שהנייד דרכו אתם מאזינים לנו עכשיו עבר במהלך ייצורו במכונות הייצור והבדיקה של אפלייד מטריאלס. באפלייד שמים דגש על עבודת צוות, אפשרויות להתפתחות אישית וצמיחה והכל תוך איזון בין קריירה לחיים אישיים. לפני הכל - אלכס - 5 וחצי שנים ב - Outbrain, מוביל את קבוצת ה  -Core Services: אחראים “מהרצפה שמחזיקה את השרתים” דרך Networking מערכות הפעלה, Provisioning ועד Deployment Pipeline - שזה שחף . . .שחף - ראש צוות Delivery ב - Outbrain (חלק מהקבוצה של אלכס), אחראי על כל מה שקשור ב  -Build & Deploy, שילוב של DevOps ו - Backend.לא מזמן (יותר משנה, אבל עבר מהר) היה פרק שהתרכז ב Networking עם k8s ב - Outbrain; הפעם אנחנו מתמקדים יותר ברגע שלפני - למה בכלל לשקול k8s? איך זה קרה?בתור התחלה - זה לא קרה . . . במשך תקופה ארוכה היה רצון אבל כנראה שהיה חסר תמריץ מתאים; ככה חלפו משהו כמו שנתיים עם נסיונות שונים שלא צלחו.בסופו של דבר הגיע שילוב תמריצים מספיק טוב, למספיק בעלי עניין - מחיר - ציפייה לחסכון משמעותי בעלויות שרתיםגמישות - ב - Outbrain רצים על Bare Metal, וה - Lead time של מכונות הוא ארוך. ככל שיהיה ניתן לקצר אותו כך גמישות התפעול תגדל, לפחות תיאורטית.עבור מי שרץ על ענן - אין Lead Time, יש כפתור (“אני רוצה מכונה!”) וזהו (+ חשבונית. נחזור לזה).כשהשרתים הם של החברה, צריך לספק כוח חישוב זמין (אתה הענן).מכאן הגיע הצורך ב - Orchestration ו - (הנה זה בא) Containerization (כן, זו באמת מילה).אתגר לאקדמיה - קופסונים? אורי מציע המכלה. תחשבו על זה שנייה.בסוף הכל מתכנס ל - Velocity - רוצים שאנשים יוכלו לזוז יותר מהר, גם ב - Production וגם ב - Development.אז הכוכבים התיישרו - ואיפה אנחנו היום?מנהלים כיום שלושה Data Centers, כשכל אחד כמה מכיל מספר k8s clusters.סדר גודל של כ - 1500 מכונות ב - Production (עם כמה Containers של כמה צוותים על כל מכונה)מבחינת Distinct services - כ ~500 שרצים על ה - Clustersמעבר לכך יש Clusters שמיועדים לבדיקות וכו’ - משהו כמו עשרה Clusters בסך הכל.כל ה - Production workload רץ על k8s, או שיש גם מקומות אחרים (Batch cases, etc)?ה - Databases עדיין לא רצים ב - k8s; כל ה - workload שהוא Stateless (למשל Java services) רצים בתוך Containers.מה לגבי Batch processing - גם שם? עוד חזון למועד, אבל יש שאיפה גם בכיוון ה - State-full.עבור החלק הזה יש מערכות workflow פנימיות שנכתבו ב - Outbrain; יש שימוש ב - Containers על מנת לבודד למשל ספריות של Hadoop (על מנת להיות Self-contained), אבל כיום לא בתוך k8s (אולי בעתיד).ולחלק השני של הכותרת - מהי Dyploma?מההתחלה - שחף הגיע ל - Outbrain לפני שנתיים וחצי, והתבקש לפתח מערכת Build & Deploy על k8s: “הנה סט הדרישות - בהצלחה”.המטרה הייתה מערכת שיודעת לעשות Deployment על k8s, ליצור Object Orient service שלוקח את ה - Java client, לבנות עבורו את ה - flow וכו’.בגדול - “זה השרת שלי, ככה קוראים לו וככה ניגשים אליו - אני רוצה Build & Deploy על k8s”. אפשר לציין גם את מספר ה - instances ,נתוני זכרון ו - CPU - וזהו בגדול. המפתח לא צריך להכיר k8s, רק את Dyploma, מה שאמור להאיץ מאוד את קצב העבודה.בעצם - Dyploma היא Service שעוטף את k8s ומאפשר לעשות את כל ההגדרות (Routing וכו’).התלבטות נפוצה בשימוש ב - k8s (רן שואל בשביל חבר) היא שימוש ישיר או בתיווך מעטפת - אפשר להגיד “הנה ה - Cluster, תעשה מה שאתה רוצה” (צור pods, שלח yml. וכו’), ואפשר גם לכתוב כלי (כמו Dyploma, אבל יש עוד כלים דומים בשוק שעוטפים את k8s). מה הביא לבחירה בכלי מעטפת? מהי הפרספקטיבה לאחר שנה ומשהו?כדי להכיר את k8s צריך להיכנס לעולם שהוא לא בהכרח חלק מהיום-יום של כל מפתח. יש את ה Tech Savvy שרצים ללמוד כל דבר חדש ויש את אלה שפחות, ומחפשים את הכפתור של Build & Deploy שמאפשר ליצור את ה - Instances ולהמשיך הלאה - התרגלו לטוב.גילוי נאות לגבי “התרגלו לטוב” - על המערכת הקודמת היה אחראי אחד בשם רן תבורי.כשמתכננים API תמיד קיימת ההתלבטות של רמת החשיפה למפתח, כשבדיעבד לא כל ההחלטות מתגלות כנכונות - לפעמים דברים שנדמה היה שהגיוני להחביא יכולים היום (עם הסביבה העשירה של ספקי הענן השונים) לתת המון כוח למפתח שיודע להשתמש בהם, ולפעמים הפוך.נניח שהתחלנו מאפס (בלי מצב נתון שהמפתחים כבר התרגלו אליו) - אילו החלטות נראות כיום כנכונות לאור הניסיון ב - Outbrain?ההתחלה הייתה עם CLI, ותוך ניסיון למסך מידע שלא חיוני למפתח - והפידבק מרוב המשתמשים היה בסגנון “אחלה, תן לי להתמקד בקוד”.עם הזמן התקדמנו ועוד Services עברו מה Bare metal ונוספו עוד משתמשים - וגילינו שיש Pipelines שנבנים (build) ב - Jenkins ועובדים מול ה - API של Dyploma. כמות הנפילות נמוכה יחסית והידע הנדרש לא רב מדי.מבנה ה - Services ב - Outbrain (וה - Templates שמסתמכים עליהם) הוא מנגנון שחוזר על עצמו, ואין צורך בורסטיליות מאוד גבוהה - לא ממציאים את k8s מחדש וזה טוב מספיק עבור חלק גדול מאוד מה - use cases.עם הזמן נוספו עוד use cases - משתמשים רוצים UI (רגילים . . . ואפשר לעשות יותר לעומת CLI ל - API).בשלב הזה (לאחר שנה וחצי) כבר ראינו את הצורך בתמונה רחבה, של dashboard שמאפשר לראות כל ה  -Deployment, ניהול של כל ה - clusters ממקום אחד (Federation)מדובר לא רק ב - Production אלא גם Staging ו - Testing (לא בהכרח חשוף למפתחים, רק למי שצריך).לאחרונה התחלנו לעבוד על Cluster ב - GCP, ובגלל אופן העבודה של Dyploma מול k8s החיבור היה מאוד פשוט (צריך רק את ה - Key, בלי Plug-ins או Controllers וכו’)מדובר בעצם על תהליך Setup היברידי - מפתח יכול לבחור ריצה על Bare metal או בענן, ועבורו זה פחות או יותר שקוף - לא בהכרח מודע האם הריצה היא על מכונה פיזית או בענן (שזה גם פיזית בסוף, אבל במקום אחר).משהו שהיה חשוב לשמר בעבודה עם Dyploma, ולא להמציא משהו חדש.המפתח ממשיך לדבר ב”שפה של Outbrain”, אבל על k8s.ההפרדה ל Production/ Staging/ Test - אלו לא clusters שונים של k8s, אלא הפרדה לוגית שמתרחשת ברמת האפליקציההאפליקציות מפרידות בין Production/ Staging/ Test באמצעות תיוג (tagging) שמוזרק כשמרימים אותן, ולא “יודעות” באיזה cluster הן רצות (אפשר לדעת, אבל לרוב זה לא מעניין - מעניין מהו ה Data Center).התקשורת אינה מתרחשת באופן הקלאסי של k8s (חזרה לפרק על Networking) - מכיוון שמיישמים שכבה של Fabric מעל k8s ולא משתמשים ב Plug-ins, לכל Container יש IP משלו והוא מתקשר עם האחרים דרך תשתית התקשורת, בלי שום דבר באמצע.מכאן נובע שכל מה שנמצא “בדרך” - אבסטרקציות כמו Services למינהם - לא נמצא בשימוש.משתמשים ב - Consul לצורך Service Discovery, ורושמים כל Container שעולה (אין בחירה) - מעצם זה שהמפתח הגדיר deployment הוא נרשם עם כל ה - meta data שמוזרק ל - Consul.קיימים גם clusters שכוללים Workloads מכמה מקורות (Production/ Staging/ Test) - עשוי להיווצר מצב של “גניבת משאבים” ביניהם?כן - ובגלל זה יש יישום של Preemption (מגיע service גדול - מי זז?)נותנים תעדוף ל - Deployment באמצעות Dyploma: ב - k8s תעדוף מוגדר ע”י מספר, והגדרנו שמות לתחומי עדיפות שונות (Bronze, Silver, Gold, Diamond), שחלקו מוגדר ע”י המפתח וחלקו מחושב בתוך Dyplomaלא רוצים ש Services עם instance בודד יתקעו בתור ויצרו Downtime, למשל.מה שלא ב Production מקבל כמובן תעדוף יותר נמוך.בחזרה ל - Work flow של המפתח - עד עכשיו התמקדנו בכך ש Dyploma מנהלת את ה- Clusters של k8s עבור המפתח (שלא נדרש להכיר k8s על בוריו). יש גם מעבר לכך - Dyploma מתחילה