פודקאסט מספר 359 של רברס עם פלטפורמה - אורי ורן מארחים את ארז ברקנר לשיחה על עננים נטולי שרתים (Serverless . . .), א-סינכרוניות ואנטי-חומר.
לפני הכל, חדשות מרגשות - כנס רברסים השביעי (Reversim Summit 2019) יוצא לדרך!
- כן, כבר - 17-18 ביוני 2019, הצוות מתחיל להתאסף, ואם אתם (או אתן, או החברות שאתם עובדים בהן) רוצים להיות ספונסרים ולהתחבר לכנס הנפלא הזה, רוצו לתפוס מקום
- ממש עוד מעט יפתח גם ה - Call for Papers - אם יש לכם סיפור מעניין, אנחנו רוצים לשמוע, זה המקום. אם חיפשתם רעיונות ליעדים לשנה החדשה, הרצאה בכנס (או לפחות הגשת הצעה רשמית) יכולה להיות אחלה אופציה.
אז איפה הסרבר שלי?
- ארז מפתח כבר הרבה שנים, התחיל בתור ילד בין 10 עם Commodore 64 ותכנות בבייסיק; תואר ראשון בזמן התיכון ושירות צבאי ביחידה טכנולוגית של משרד ראש הממשלה (בטח מותג מחדש מאז כ - Data Science).
- אחרי הצבא, הרבה שנים (14) ב - Check Point (בהתחלה כמפתח קרנל של Linux), שם גם נוצר הקשר עם אביעד מור, היום השותף (וה-CTO) ב-Lumigo.
- פגישה עם עולם ה-Serverless דרך עולמות ה-Cloud (ארז) וה - Emerging Technologies (אביעד), וב-2017 מעבר והקמה של -Lumigo.
- החברה עוזרת למפתחים שמשתמשים בטכנולוגיות Serverless לזהות בעיות בסביבה ולמצוא את שורש הבעיה מהר - Monitoring, Alerting & Root-Cause Analysis.
- מסתכלים על כל עולם ה-Run Time - מה צריך על מנת להבין (קודם כל) שמשהו שאינו כשורה, ואז המסע אל הפתרון.
- למה ב - Serverless זה שונה לעומת microServices למשל?
- כדי להבין Serverless, צריך להסתכל על האבולוציה של המעבר מעולמות ה- On Premise לכיוון ה - Cloud.
- פעם היינו משתמשים בשרתים שישבו (פיסית) בחדר שרתים כלשהו בחברה; היום עברנו לעולם של Public Clouds, ואנחנו שוכרים שרתים לפי זמן וצורך (אם נשאר לנו כסף), שזה עדיף על לקנות שרת.
- אורי מרים גבה, עד כמה שאפשר באודיו.
- השלב הבא הוא האחריות - השרת הפיסי נמצא אצל ספק הענן, ואם מדברים על Dockers אז גם עניין האחריות לתחזוקה של מערכת ההפעלה עצמה יוצא החוצה.
- משם ממשיכים ל - Serverless: כל השרת ומערכת ההפעלה וכל מה שצריך בשביל Scaling ועוד - כל האחריות עוברת לספק הענן (AWS, GCP, Azure וכו’). החברה צריכה לכתוב רק את הקוד הייחודי שלה, להעלות לענן, והכל רץ לפי הצורך. אמריקה.
- רצנו קדימה, קצת יישור קו על מושגים -
- כשאומרים Serverless, מתכוונים לכל מיני דברים, לפעמים מאוד שונים, ואם יש דבר אחד שבטוח כן יש בו זה, ובכן - שרתים (Servers).
- יש סוגים שונים של שימושים, החל מפלטפורמות להרצת פונקציות (Lamdba של AWS או פתרונות מקבילים של Azure ו - GCP ועוד), דרך Database כשירות שמאפשר להריץ קוד בתוכו ועוד הרבה.
- הכל ביחד הם “שירותים ללא שרת”, ואליהם אנחנו מתייחסים כאן כעולם ה-Serverless - הרבה שירותי מדף שצריך לחבר בינהם.
- דברים כמו Google Cloud BigQuery כרגע מחוץ ל - Scope.
אז מה בכל זאת חדש?
- יש שני סוגים עיקריים של בעיות - או בעיה מקומית בפונקציה (ואז מסתכלים פנימית ומוצאים Root Cause), או ששורש הבעיה נמצא איפשהו במעלה ה - Stack, וצריך להבין איפה לחפש.
- בעולם המסורתי, אפשר להסתכל על ה - Stack Trace ולראות איך הגעתי לכאן, אילו פונקציות נקראו ומה לא עבד.
- למשל - פונקציית ה - Lambda שלי רוצה להשתמש ב - Header, שלא נמצא . . למה? שאלה טובה - הרבה דברים יכלו להתרחש בדרך שעשויים היו לגרום לשירותים להיעלב אחד מהשני ולא להגיב כמו שצריך.
- בארכיטקטורה מונוליטית אפשר לראות מה נכנס, לבדוק בנקודת הבקרה הקרובה ולראות האם משהו חסר או נעלם או לא עבר כמו שצריך, ויש את כל ההיסטוריה מסודרת כדי לתחקר.
- אם הקוד אינו סינכרוני, קשה יותר להבין את ה-Flow, אם כי זה שה - Business Logic מפוצל להרבה מקומות לא ייחודי ל - Serverless ונכון גם ל - microServices למשל.
- מה שמתווסף בעולמות ה - Serverless זה שאין נגישות לשרת שרץ “מתחת”, ואין אפשרות לתכנן Agent שיבדוק מה קורה. מה שכן, אם אתה זה ששולח מידע ושולף חזרה, אפשר להצמיד לקטע המידע משהו שינטר אותו: על מנת לראות תמונה כוללת, צריך מזהה חד-חד-ערכי לאורך כל השירותים. במקרה א-סינכרוני זה הופך ליותר מאתגר, כי אין מטה-דאטה שאפשר להיצמד אליו, צריך למצוא דרך אחרת.
- בעולמות ה - microServices הבעייה דומה, עם כמה פתרונות - כלים בסגנון OPENTRACING ו- Zipkin, סוגים של Agents שניתן להתקין על המכונה או להזריק לשירות (ספרייה כלשהי) ונותנים מענה.
- במקרה של Serverless יש יותר גורמים מחוץ לשליטה ישירה - מעבר לשירותים שצריכים לתקשר אחד עם השני יש גם מעיין “תווח” בין לבין, שעליהם יש פחות שליטה (אם בכלל), וקשה ליצור המשכיות ל - Trace דרכם.
- אז כאן יש חדש - הכוונה ב - Serverless היא להוציא החוצה גורמים שיכולים להיות סוג של Commodity, ובמקרה הזה - ניסיון להוריד מהמפתח את הצורך להתמודד עם כל הבקשות מהשירותים השונים, ואפשרות לעשות את מה שהוא עושה טוב ולהשאיר למערכת את הטיפול בשאר.
איך נראה המוצר?
- שירות SaaS, מתחברים (API) לספק הענן הרלוונטי לחברה (Non-intrusive), ויודעים להגיד עבור כל טרנזקציה שעוברת את המקום בו היא התחילה, הנתיב שעברה ומה קרה בכל אחד מהשירותים.
- כשיש בעיה, יודעים לנתח איפה ולמצוא את המקור.
- דוגמא - שולחים הודעה ל - DynamoDB (בלי “להגיד” ל-Lumigo). איך הקסם קורה?
- יש ספרייה של Lumigo שניתן להוסיף לפונקציית ה - Lamdba (שורה אחת), ומאפשרת להבין מאיפה הגעת ולאן אתה הולך.
- המידע הזה מאפשר לעשות Zoom-out ולתת בחזרה את התמונה הכוללת.
- כן, זה אומר מתן אפשרות להיכנס ממש לקוד, ה - Agent נמצא בתוך ה - Lambda.
- איך מבינים מכל זה מהו ה - Flow? ובכן, שאלה טובה - זה ה - IP של Lumigo . . . יודעים לחבר מה קורה גם מעבר לבקשות א-סינכרוניות, ולשרשר את זה לכדי סיפור. אפשר לעשות את זה בעצמך, אבל למה כשיש מוצר מדף?
אני מפתח - מתי אני יודע שאני מפספס משהו?
- יש אפליקציית Serverless, וחשוב לך שברגע שיש בעיה המענה יהיה מהיר? אז.
- מכוון בעיקר לאפליקציות שהן קריטיות למודל העסקי ויש צורך לנטר אותן, ולהבין מהי ההשפעה המדוייקת על מקרים ומשתמשים ספציפיים.
מה לגבי ה - Trade-off הקבוע לענייני ביצועים (Performance) - כמה אני משלם כל הזמן עבור מענה למשהו שקורה בתדירות לא בהכרח מאוד גבוהה?
- כרגע השירות מתבצע בצורה א-סנכרונית ללוג שאוסף את המידע, מה שגורם לכך שההשפעה על זמן הריצה של הפונקצייה הוא אפסי (mSec בודדים).
- זה לא היה המודל הראשוני - נוצר כמענה לפידבק מלקוחות.
- המשמעות היא שיש (קצת?) לכלוך בלוג, ולא רק דברים שהמשתמש שם בעצמו (“אתה נמצא בטרנזקציה X” וכו’).
מה לגבי חברות שכבר קיימות, ולא התחילו “נקי” על Serverless - ערב-רב של טכנולוגיות, מוצר שכבר קיים בשוק, המון אילוצים (מקרה היפותטי כמובן, שואל בשביל חבר) - האם יש מענה?
- אז מסתבר ש - Serverless אינו Technology-less, ולא באמת מחליף הכל. ה - Stack הטכנולוגי משלב גם Containers ושירותי SaaS דוגמאת Twilio או Stripe ודומיהם.
- הפוקוס של Lumigo הוא אפליקטיבי, מבט על הטרנזקציה קצה-לקצה, ללא קשר לספק הענן, ה - Container הספציפי או שירות 3rd party כזה או אחר.
- לגבי אותם שירותי 3rd-Party למיניהם - בגלל שהפתרון “יושב” על הפונקציה (ה - compute עצמו), גם אם פונים לשירות חיצוני ניתן לנטר את הבקשה שיוצאת וחוזרת, והמעטפת נותנת מענה גם לזה.
בסופו של דבר, אנחנו זו טכנולוגיה שמדברים עליה הרבה ו(עדיין?) לא הרבה מאמצים בפועל. האם ניתן לראות טרנדים שכבר רצים בתחום הזה? ומה אחר כך?
- בעולמות ה - Serverless רואים אימוץ מאוד נרחב (מעל 100K לקוחות ב - AWS) - רובם לאו דווקא מריצים את ה - Core Business שלהם ככה, ובטוח שחלק לא מבוטל מזה הם ניסויים למיניהם, ועדיין -
- חוזרים ומלווים את הארגונים, ורואים שיש תהליך Bottom-up פנים ארגוני שבו ה”משחקים” הללו הופכים למשהו רציני שמחלחל לתוך הארגון ולמערכות יותר קריטיות (לפחות עד שמישהו מקבל את החשבונית).
- לאן השוק הולך? יותר אחריות שיורדת מהכתפיים של המפתח, ועוברת לספק הענן - יותר ויותר ספריות שהופכות ל - Commodity שספקי הענן (שזיהו מלמעלה את הטרנדים) מספקים כשירותים.
- פה נכנסנו לפינה . . . הסאב-טקסט הוא של הורדת אחריות מהמפתח, ויש בזה (גם) בעיה.
- המפתח עלול להתחיל להתייחס לכל החלק הזה כאל סוג של “קסם שמישהו אחר עושה”, ואם יש שם בעיה - היא לא שלי . . . הקסם לא עבד. זה נחמד, רק שיש מישהו אחר (הלקוח . . .) שמסתכל על אותו מפתח וטוען שנמכר לו שירות שהוא מצפה שיעבוד, ואתה (המפתח) אחראי לזה, End to End. אי אפשר להעביר את האחריות למישהו אחר.
- בסופו של דבר עניין של ניהול סיכונים - יש עלות להשארת הכל בתוך הארגון, ויש עלות להתמודדות עם מקרים שבהם צריך לתת מענה לתקלות שהשליטה בהם פחות ישירה. צריך רק לשים לב שאם (חלילה) AWS$ מפשלים, אתה עדיין אשם.
- ויש לזה גם צד אחר - בעולם ה- Serverless רואים מפתחים שלוקחים הרבה יותר אחריות, ומתחילים לטפל ב - Production, כחלק מהנפילה הכללית של מחיצות בין Dev לבין Ops. זה לא ייחודי ל - Serverless, אבל כן מועצם כיוון שהכל הוא סוג של קונפיגורציה והגבולות מאוד מטושטשים.
- אורי מזכיר מקרה בסיום אחד מסבבי ה - OpsSchool (הרשמו בהמוניכם!), שבו עלתה השאלה האם מקצוע ה -DevOps בעצם מתחיל להיות מיותר בעולם של Serverless.
- ה -déjà vu (המיידי, יש הרבה) הוא לימי תחילת ה - Public Cloud - בהתחלה אין מערכות מספיק מורכבות כדי שיהיה צורך “לטפל במערכת”. לאט (ולפעמים מהר) זה גדל, ומגיעה רמת מורכבות שבה יש צורך בדלגציה לשירותים מסויימים. מישהו אמר No-Ops?! אז זה לא באמת קורה.
- הטכנולוגיה צומחת, ו-Ecosystem צומח סביבה ומאפשר את השימוש בה.
- החברה צעירה, גייסה סכום משמעותי לפני כחצי שנה בהובלת Grove Ventures, פיטנגו ומירון קפיטל
- עדיין קטנים - 5 מפתחים בצוות ה - Core, וכבר עם לקוחות ב - Production שעובדים איתם על בסיס שבועי.
- העתיד הוא גדילה - טכנולוגית (לעננים נוספים) וגם של צוות הפיתוח (לפחות x5 בשנתיים הקרובות)
- טכנולוגיה? 100% Serverless, משתמשים במוצרים של Lumigo על השירותים שלנו
- מבוססי AWS, המערכת בנויה ל - Scale.
- מתחילים לפתח פתרונות בעולמות ה -Machine Learning, על מנת לזהות דפוסים ולפתח את הטכנולוגיה.
- אז Serverless? יש! Machine Learning? יש! סגור.
הגעתם עד כאן? יש מצב שתאהבו גם את פרק 340 - Serverless With Adam Matan על קהילת ה - Serverless בישראל.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול
אין תגובות:
הוסף רשומת תגובה