יום חמישי, 31 בינואר 2019

360 Via

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

לפני הכל, חדשות מרגשות - כנס רברסים השביעי (Reversim Summit 2019) יוצא לדרך!
  • 17-16 ביוני 2019 - עדכנו ביומן slightly smiling face
  • ספונסרים יתקבלו בברכה - אם החברה שלכם רוצה להיות בשורה הראשונה בכנס, זה הזמן לתפוס מקום.
  • וגם אתם - ה Call for Papers נפתח! - בואו ספרו על משהו מעניין שעשיתם או למדתם וחושבים שכדאי לשתף - הגשות עד סוף פברואר (28/2)

אז Via - השיחה תעסוק גם בצד העסקי וגם בצד האלגרוריתמי, ובשביל זה גיא ואודי כאן - 
    • גיא מנהל את פהעילות העסקית של Via בישראל, מגיע מרקע של ניהול פרויקטים והיום ב-Via מתרכז בהשקת השירות בישראל - במהרה בימינו (שמעתם כאן לראשונה. בערך).
    • אודי -  מתימטיקאי, 15 שנים בתחום, מנהל קבוצת אלגוריתמים ב-Via (הרחבה על אלגוריתמים בהמשך, יש למה לחכות עם הספר של קורמן)

אז מהו המוצר של Via?
  • חברה טכנולוגית שפיתחה מערכת לתחבורה ציבורית חכמה
  • האלגורתים יודע  לאסוף ולחבר אנשים על מנת לשתף נסיעה על אותו רכב - בכ-30 ערים בעולם, כשנוסע מזמין נסיעה האפלקיציה מנחה אותו להגיע לנקודת העלייה (פינת הרחוב הקרובה למשל), ומאפשרת לחלוק את הנסיעה עם עוד אנשים
    • איך זה נראה? מיניבוס, לרוב של מפעיל קיים או של העירייה, או מונית גדולה שבאה ואוספת ומסיעה באיזור מוגדר.
    • המוצר יודע גם לספק מערכת למפעיל קיים - טאבלט עבור הנהג שמקבל הנחיות נסיעה והורדת / העלאת נוסעים (יש גם אפליקציות לנוסעים, מפעילי נסיעה וכו’) - וגם להפעלה עצמאית ע”י Via (אמסטרדם, לונדון ועוד)
    • מכירים Uber, Gett וכו’? אז מעיין שילוב של Uber ואגד עם אלמנט של On-Demand והרבה טכנולוגיה.
    • בישראל יש פיילוט עם חברת דן שמובל ע”י משרד התחבורה והאוצר - נדבך נוסף לשירות של דן בתל אביב, רמת גן וגבעתיים.
      • מיניבוסים של דן עם חוויית שירות מלאה של Via, שיסעו במרחב פוליגון מסויים (תמיד רציתם לנסוע בפוליגון? הנה זה בא); ממוקד באיזורי התעסוקה ותחנות הרכבת - במטרה להוריד את הרכבים הפרטיים מהכביש עד כמה שניתן - הרכב הפרטי מוגדר כמתחרה האמיתי.
      • מזמינים נסיעה, קובעים יעד - ונוסעים עם עוד אנשים (קצת דומה ל- UberPool)
    • בישראל יש כזה כבר? אין סיבה שלא כל האוטובוסים יעבדו ככה, במקום לעבוד עם תחנות וזמנים קשיחים
      • בהינתן שאנחנו יודעים איפה כל נוסע נמצא (אם הוא רוצה ובוחר לשתף נקודת מוצא ויעד), אין סיבה לא “לדבר” עם אמצעי תחבורה אחרים. עם או בלי Via - זה משהו שכבר קורה.
      • לדוגמא - נוסעים ב-Via, יורדים ליד תחנה של אופניים שיתופיים וממשיכים איתם לרכבת
  • עוד נדבך - רכב חשמלי
    • קצת פחות PR מהרכב האוטונומי לאחרונה ועדיין מהפכה ענקית - Via מנהלת צי כזה בברלין. גם ירוק יותר וגם מאפשר לנהל את צריכת האנרגיה של הרכבים כך שהנוסע אדיש למצב הסוללה
      • עוד יותר קריטי בוואן של 8-10 מקומות.
  • רגע - כשמישהו נכנס לאוטובוס היום, המסלול קבוע והוא יודע לאן נוסעים ומתי מגיעים, בערך. עם Via הנוסע לא באמת יודע מה יהיה המסלול
    • מקביל היום למצב בו אתה היום נוסע במונית, נתקע בפקק - ומחליט לרדת ולהמשיך ברגל. 
    • המערכת יודעת לחשב מקרים כאלה בזמן אמת ולהגיד מתי כדאי לקום ולהמשיך ברגל - בכל פעם תתקבל תוצאה אחרת בהתאם למצב הנתון.
      • הסתיים משחק כדורגל? שכונה חדשה אוכלסה מאז שנקבע המסלול של הקו? רכבת תחתית כבר נבנית (15-20 שנה וזה כאן)? המערכת של Via מגיבה בזמן אמת.
    • החשש מאוד רלוונטי, והאחריות של מוצר היא שזה לא יקרה - שהדרך תיהיה היעילה ביותר עם העיקופים המינימליים - על מנת שהלקוח יחזור וישתמש במוצר כי החווייה טובה.
  • התשלום - גמיש לגמרי, נקבע יחד עם המפעיל (מרחק, זמן וכו’) - יקר מתחבורה ציבורית אבל זול ממונית ספשייל.
    • מחזיר לניגוד האינטרסים בין תשלום לפי זמן לבין המסלול היעיל ביותר - ולאותה תשובה של מחוייבות ארוכת טווח ללקוחות חוזרים ולא ניסיון למקסם רווח במפגש יחיד.
  • מעבר לזה - הניסיון התפעולי מאפשר לפתח מוצרים לשיפור חוויית משתמש - תמרוץ נהגים, למשל
    • הנהגים הם גם לקוחות, שמעודדים אותם לאסוף כמה שיותר נוסעים ולחזור ולהפעיל את השירות גם מחר. אם הנהג נתקע צריך לספק לו רכב אחר, למשל.
    • הנהג יכול להתערב באלגוריתם- לא לקבל נוסע למשל? בקצרה - לא. אין 100% שליטה (לא, אסור לחשמל נהגים סוררים), אבל בגדול המשוב מהנהגים מאוד חיובי.

ברלין, ניו-יורק - איפה עוד?

החברה אמריקאית, הוקמה ע”י שני יזמים ישראלי - אורן שובל ודניאל רמות
  • אורן נסע במונית שירות בתל אביב, שמע את השיחה של הנהג עם הסדרן והניח שב-2012 אפשר לעשות את זה טוב יותר, פנה לחבר שלו דניאל שישב בניו-יורק - ושם גם נפתחה האופרציה הראשונה.
  • מרכז הפיתוח בתל אביב עם כ-200 מהנדסים, אופרציה בכל העולם.

נגענו בכל מיני בעיות שקשורות באלגוריתמים, הגיע הזמן לחזור לזה קצת
  • אנחנו רוצים לשמור על הלקוחות מרוצים, ושגם הנהג יהיה מרוצה, ולהתאים את הרכבים החשמליים . . . הרבה אילוצים ובעיות אופטימיזציה.
  • למשל, עליתי על רכב - התשובה ל-”מתי אגיע ליעד?” לא ברורה לגמרי
  • וזה רק מסתבך, כי צריך להגדיר מהו בעצם “עיקוף” - פילוסופית, אולי זו הדרך הכי טובה ואתה לא יודע וזה רק נראה כמו עיקוף, אז האם זה באמת עיקוף? זן ואומנות אחזקת האופנוע מעולם לא היה רלוונטי יותר.
    • ונניח שהגדרנו עיקןף - מהו “עיקוף סביר”? וזה רק אתגר אחד.
  • ועוד אחד - לאן הרכבים נוסעים כשהאגם קפוא (או סתם נגמרת הנסיעה במהלך היום)? הרכב ריק ועכשיו מה?
    • אפשר לעמוד במקום (לא תמיד באמת אפשר); אפשר ללכת לשתות משהו; אפשר לנסות להגיע לאן שצפויים להיות בו נוסעים; ויש עוד
    • ל-Via יש את המידע והדרך לחזות לאן לנהג כדאי לנסוע, גם כשהוא לא יודע לחזות בעצמו
  • עוד גרסא של השאלה הזו - על הנהג להיות זמין בשעת פתיחת השירות בבוקר, אבל איפה להמתין? 
    • נניח שיש N נקודות אפשריות (כן, הגענו לשלב הזה בשיחה), ונניח אפילו שאנחנו יודעים בדיוק איפה צפויים לעמוד הלקוחות
    • מי שצריך הסעה ב-6:00 רוצה שהיא תיהיה שם, אין לו סבלנות לחכות (היה מעדיף אפילו להזמין קודם - ואם עשה כך אז אני יודע איפה הוא צפוי להיות)
      • בסינגפור Via מימשה את הפי’צר הזה בדיוק
    • אז איפה הנהג צריך לחכות על מנת להביא למינימום את משך ההמתנה הצפוי? פתרון אחר בתכנות לניארי הוא להניח יש מספר מסויים של נקודות העיר, ושאנחנו יודעים מה הזמן הצפוי להגעה מכל נקודה לכל נקודה - וסכום הזמנים של כל נסיעה שתקרה בפועל הוא משך זמן הנסיעה הצפוי וזו הפונקציה שאנחנו רוצים להביא למינימום.
    • בעיית הסוכן הנוסע היא עדיין בעיית NP קשה, ו P<>NP נכון לזמן הקלטת הפרק, והסוכן עדיין נוסע. אולי ב-Via, אבל נוסע.
    • יותר מזה - זה לא סוכן בודד, ויש המון תלויות בין הרכבים לנוסעים ולקשרים בינהם.
    • אז יש לנו N רכבים ו-M נוסעים - ו-N x M משתנים - וגם הם (הנה זה בא) בוליאנים (0 או 1 - אי אפשר לאסוף חצי נוסע עם רבע רכב, וגם אם אפשר זה לא יראה טוב) - והאילוצים כולם לינאריים.
      • ויש גם את עניין היעד שהוא גם אילוץ
      • ויש עוד פילוסופיה - האם הממוצע עונה על הדרישה? - 100 נוסעים המתינו דקה והנוסע ה-101 המתין שעה - האם זה מצב קביל? צריך להגדיר האם זה הוגן
    • באינטרנט מסתכלים על אחוזונים (95% מקבלים שירות טוב), וזה אפשרי גם ברמת המוצר, כשאפשר להוסיף תיקונים - אם אני יודע מראש שאני עומד לאחר אני יכול לשלוח לנוסע הודעת התנצלות, אולי עם פיצוי (“הנסיעה עלינו”, “תחזיק מעמד” וכו’) - אני יודע לטפל ולהגיב בזמן אמת 
      • מי אמר עמוד אינטרנט שמציג ספינר כשהוא איטי?
    • אפשר להציב חסמים ולהגיד שמעל זמן תגובה מסויים אנחנו לא מעוניים לתת את השירות כי הוא יהיה שירות לא טוב, ואנחנו בוחרים להגיד “לא” מאשר לתת שירות בכזו רמה.
  • רגע, מכל זה - מה זה בכלל תכנות ליניארי?
    • שיטה לפתרון בעיה שאותה ניתן לתאר באמצעות אוסף של משוואות ליניאריות (לא ראיתם את זה בא?)
    • האילוצים מיוצגים כאי-שיוויונות לינאריים (X+Y>4, כאלה) - משוואות ממעלה גבוהה יותר יהיו הרבה יותר מסובכות לפתרון, אילוצים לינאריים יחסית קל לפתור בזמן סביר
    • עוד משהו - הפתרון למשוואות ליניאריות לרוב יהיה רציף, ולנו יש משתנים בוליאניים (0 או 1), ולא סביר לאסוף חצי נוסע (הוא עלול להגיב לא טוב אם ננסה).
    • אל דאגה - יש פתרון! הבעיה הזו שקולה לקבוצת בעיות הידועה בשם Transportation Problems
      • דווקא לא בהקשר של תחבורה אלא יותר של הובלת מסעות
      • וכאן יש תכונה (של מטריצות) שמכונה יוני-מודולאריות (Unimodular) - ובלי להיכנס יותר מדי ל-PTSD מאלגברה א’ זה מבטיח שהתוצאה תיהיה גם בשלמים. כן, זה עובד.

האם הבעיה נפתרת בכל פעם מחדש, או שבכל עיר נקודות האיסוף קבועות פחות או יותר?
  • את הבעיה אנחנו פותרים כל הזמן, וזו נגזרת של בעיית ה-”לאן הרכבים נוסעים כשהם מתרוקנים?” שהזכרנו קודם
  • בהינתן שאנחנו יודעים מהי התמונה הכוללת של היצע וביקוש, אפשר ליצור מערכת אופטימלית ברמת המכלול. כשיש שירותים שפעילים 24/7 זה פחות רלוונטי, אבל כשיש שעת התחלה וסיום זה בדיוק מה ש-Via עושים.

מה לגבי חוסר איזון? בבוקר יש תנועה מהעיר אל איזורי התעסוקה, עד ש”העיר ריקה ממכוניות” וכולם יסיימו את הנסיעה באיזורי התעסוקה. ובערב הפוך . . .
  • בהנחה שכולם משתמשים ב-Via, אפשר לחכות במקום . . . מעבר לזה זה כבר איזון של השוק.
  • המערכת מתפתחת לענות על אתגרים של היצע וביקוש
    • הרבה יותר נוסעים מעדיפים את השירות דווקא בערב - בבוקר התנועה יחסית קבועה בשעה קבועה, אבל אחרי העבודה מגוון האפשרויות הרבה יותר גדול, והתועלת של שירות כמו Via גדלה.

מתי נסיעה מסתיימת?
  • כשכולם יורדים, כולם הגיעו לעבודה ואף אחד עדיין לא רוצה לחזור
  • המערכת מפנה את הרכב למקום שבו צפוי הביקוש הבא (בהתאם למערכת כולה)
  • כשיש רכב אוטונומי, הנסיעה אף פעם לא נגמרת - מתקיים עכשיו ניסוי באוסטרליה שבו Via בוחנת בדיוק את זה
    • השלב הבא - נוסעים אוטונומיים שיסעו ברכבים עם נהגים אמיתיים?

איך מבטיחים הוגנות לנהג?
  • ובכן - מתייחסים אליהם כאל לקוחות . . . הנוסע מחכה 3 דקות ונוסע עוד 20 דקות, בעוד שהנהג הוא הפנים של השירות כל הזמן
    • מובילים אותו לנקודת מנוחה כשצריך, מספקים תמריצים לעבודה טובה וכו’ (השכר שונה בהתאם לביצוע).
    • האם קורה שנהגים חורגים מהמסלול? כן . . . יש בקרה ותגמול, וחישוב מסלול מחדש כשצריך
      • חשוב שהנהג יעקוב אחרי המסלול כפי שנקבע, כי אפליקציה כמו Waze למשל תנחה אותו למסלול הקצר ביותר, בעוד Via תחפש מסלול אולי קצת יותר ארוך אבל עם סיכוי לאסוף עוד נוסעים
      • יש גם התחשבות באירועים נקודתיים (הסתיים קונצרט והדרך כבר לא כל כך קצרה וכו’)
      • ועוד נקודה - לא בבהכרח צריך להגיע לנקודה המדוייקת: אפשר להגיד לנוסע לרדת וללכת ברגל את 50 המטרים האחרונים, ולא להשקיע עוד 20 דקות בלהקיף את הבלוק או להיתקע בפקק כדי להיכנס לרחוב חד-סטרי מהכיוון הנכון כדי להגיע לנקודה המדוייקת.

עוד נושאים לסיום?
  • מתרגשים מכך שהשירות מגיע לישראל (גם כאן) - מרכז הפיתוח יוכל להרגיש את המוצר באופן יומיומי
  • ב-Via מגייסים slightly smiling face - מפתחים, אלגוריתמאיות, Data Scientists . . .

הפתרון האידיאלי - לצאת לפריפריה! הכי טוב :-)

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

יום רביעי, 30 בינואר 2019

Summit 2018: Monitoria - A Monitoring Democracy / Yaron Idan

Monitoring is important - but as your company grows it becomes harder to keep an eye on all the different moving parts. As the times roll by and the company grows new technologies are being added to the stack and it’s essential to make sure those can be monitored reliably out there in the wild. We want to share how we transformed monitoring from a one man job to something every developer and Product Manager cares about and actively participates in. This talk will introduce you to open source tools that can enable such a solution. Walking you through a cultural transformation that makes monitoring accessible to everyone.



MP3

Summit 2018: Gain velocity by switching to Safe Mode / Vlad Ioffe

About a year a go we decided to move from AngularJS to Angular, after 1.5 weeks of development and refactoring we were live in prod. Result were: 0 bugs, 0 down time and most important 0 time was spent on QA. In the never ending progress of Front-End frameworks, you need to iterate fast without breaking your app. In this presentation I want to show the pipeline we built for our web apps, this pipeline gives us very fast way to reach production with very high confidence that no bugs reached production, We will talk about development, testing, build & deployments and how to combine it all to one bullet proof pipeline.



MP3

Summit 2018: Open-source: A Love/Hate Relationship / Uri Shamay

Open source software is one of the biggest game-changers in our world. It has a lot of benefits, the most critical one being minimizing the time to market. But it’s not a free meal, and you should take care of many aspects when choosing one:

 - Bug fixes (“wait a minute, I need to know $lang?!”)
 - Security (“who the f*** gave full access to my credentials dir”)
 - Stability in different bad cases (“why did jobs execute dozens of times when workers lost connection”)
Those can catch you one day in a very unpleasant situation.

In this talk I will take you on a tour of some key indicators that you need to bear in mind when choosing an open-source library or component.



MP3

יום שבת, 26 בינואר 2019

Summit 2018: Breaking into my 3D Printer's Firmware / Uri Shaked

A few months ago, I got my new 3D Printer. As a Kickstarter project, it came as half-baked product - its firmware topped with many annoying bugs. In hope to fix some of them, I went to look into the firmware, but alas - it was encrypted with some sort of substitution cipher. In this talk I will show you how I used some data science, statistics, ARM architecture knowledge and much guesswork to defeat the encryption of the firmware. We will see some Python code and I will walk through some IDA scripts I built especially for this mission. Let the firmware's secrets reveal themselves!



MP3

Summit 2018: Daddy, where is my Arduino? / Uri Nativ & Roni Nativ

It’s almost midnight. Me and my daughter are looking for jumpers, matrices and resistors. There is a bug in the game we’re building, and it doesn’t seem as if we are going to bed anytime soon.

Teaching kids recursion and data structures didn’t create the thrill I thought it would. But building games does! My daughter Roni and I will talk about introducing kids to the world of programing, 3D printing, Scratch, Arduino, Ali Express orders and hot glue. We’ll cover the existing tools from which kids can learn how to code, at what age should they start, and which projects to choose.

And why girls at school are anxious about coding? Is it a boy’s club already before high-school?



MP3

Summit 2018: How shit works: Time / Tomer Gabel

In this talk we'll take a hard look at one of the most commonly used, and at least as commonly misunderstood, elements in software engineering: time. Time is so fundamental to the way humans experience reality that we don't normally give it a second thought, but it's just as fundamental to software systems. Without a correct model for working with time BAD THINGS HAPPEN: data is persisted out of order, exceptions occur where they shouldn't be possible, and production systems blow up.

We'll cover the various common representations of time, acknowledge their caveats and deficiencies, and hopefully learn a few new tools and practices along the way.



MP3

יום חמישי, 24 בינואר 2019

359 Serverless with Erez Berkner from Lumigo

פודקאסט מספר 359 של רברס עם פלטפורמה - אורי ורן מארחים את ארז ברקנר לשיחה על עננים נטולי שרתים (Serverless . . .), א-סינכרוניות ואנטי-חומר.


לפני הכל, חדשות מרגשות - כנס רברסים השביעי (Reversim Summit 2019) יוצא לדרך!
  • כן, כבר - 17-18 ביוני 2019, הצוות מתחיל להתאסף, ואם אתם (או אתן, או החברות שאתם עובדים בהן) רוצים להיות ספונסרים ולהתחבר לכנס הנפלא הזה, רוצו לתפוס מקום slightly smiling face 
  • ממש עוד מעט יפתח גם ה -  Call for Papers - אם יש לכם סיפור מעניין, אנחנו רוצים לשמוע, זה המקום. אם חיפשתם רעיונות ליעדים לשנה החדשה, הרצאה בכנס (או לפחות הגשת הצעה רשמית) יכולה להיות אחלה אופציה.

אז איפה הסרבר שלי?
  • ארז מפתח כבר הרבה שנים, התחיל בתור ילד בין 10 עם Commodore 64 ותכנות בבייסיק; תואר ראשון בזמן התיכון ושירות צבאי ביחידה טכנולוגית של משרד ראש הממשלה (בטח מותג מחדש מאז כ - Data Science).
  • אחרי הצבא, הרבה שנים (14) ב - Check Point (בהתחלה כמפתח קרנל של Linux), שם גם נוצר הקשר עם אביעד מור, היום השותף (וה-CTO) ב-Lumigo.
  • פגישה עם עולם ה-Serverless דרך עולמות ה-Cloud (ארז) וה - Emerging Technologies (אביעד), וב-2017 מעבר והקמה של -Lumigo.

אז -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 - הרבה שירותי מדף שצריך לחבר בינהם.

אז מה בכל זאת חדש?
  • יש שני סוגים עיקריים של בעיות - או בעיה מקומית בפונקציה (ואז מסתכלים פנימית ומוצאים Root Cause), או ששורש הבעיה נמצא איפשהו במעלה ה - Stack, וצריך להבין איפה לחפש.
  • בעולם המסורתי, אפשר להסתכל על ה - Stack Trace ולראות איך הגעתי לכאן, אילו פונקציות נקראו ומה לא עבד.
    • למשל - פונקציית ה - Lambda שלי רוצה להשתמש ב - Header, שלא נמצא . . למה? שאלה טובה - הרבה דברים יכלו להתרחש בדרך שעשויים היו לגרום לשירותים להיעלב אחד מהשני ולא להגיב כמו שצריך. 
      • בארכיטקטורה מונוליטית אפשר לראות מה נכנס, לבדוק בנקודת הבקרה הקרובה ולראות האם משהו חסר או נעלם או לא עבר כמו שצריך, ויש את כל ההיסטוריה מסודרת כדי לתחקר.
    • אם הקוד אינו סינכרוני, קשה יותר להבין את ה-Flow, אם כי זה שה - Business Logic מפוצל להרבה מקומות לא ייחודי ל - Serverless ונכון גם ל - microServices למשל.
    • מה שמתווסף בעולמות ה - Serverless זה שאין נגישות לשרת שרץ “מתחת”, ואין אפשרות לתכנן Agent שיבדוק מה קורה. מה שכן, אם אתה זה ששולח מידע ושולף חזרה, אפשר להצמיד לקטע המידע משהו שינטר אותו: על מנת לראות תמונה כוללת, צריך מזהה חד-חד-ערכי לאורך כל השירותים. במקרה א-סינכרוני זה הופך ליותר מאתגר, כי אין מטה-דאטה שאפשר להיצמד אליו, צריך למצוא דרך אחרת.
    • בעולמות ה - microServices הבעייה דומה, עם כמה פתרונות - כלים בסגנון OPENTRACING ו- Zipkin, סוגים של Agents שניתן להתקין על המכונה או להזריק לשירות (ספרייה כלשהי) ונותנים מענה.
    • במקרה של Serverless יש יותר גורמים מחוץ לשליטה ישירה - מעבר לשירותים שצריכים לתקשר אחד עם השני יש גם מעיין תווח בין לבין, שעליהם יש פחות שליטה (אם בכלל), וקשה ליצור המשכיות ל - Trace דרכם.
      • זה עוד יותר סבוך כאשר התקשורת היא א-סינכרונית - שולחים Work Item ורוצים לעקוב אחרי השובל (עקבה, Trace . . .) שלו. אין (לא מכירים) פתרון סטנדרטי לזה - יש הרבה המצאות מקומיות.
      • שמענו (כאן) על Istio למקרים דומים, אבל זה עדיין לא עונה לעניין הא-סינכרוניות, יותר לתקשורת פנימית.
  • אז כאן יש חדש - הכוונה ב - 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 צומח סביבה ומאפשר את השימוש בה.

אז ממש לפני סיום - חזרה ל - Lumigo: עוד קצת על החברה, איפה היא נמצאת, את מי מגייסים . . .
  • החברה צעירה, גייסה סכום משמעותי לפני כחצי שנה בהובלת Grove Ventures, פיטנגו ומירון קפיטל
  • עדיין קטנים - 5 מפתחים בצוות ה - Core, וכבר עם לקוחות ב - Production שעובדים איתם על בסיס שבועי.
  • העתיד הוא גדילה  - טכנולוגית (לעננים נוספים) וגם של צוות הפיתוח (לפחות x5 בשנתיים הקרובות)
  • טכנולוגיה? 100% Serverless, משתמשים במוצרים של Lumigo על השירותים שלנו
    • מבוססי AWS, המערכת בנויה ל - Scale.
    • מתחילים לפתח פתרונות בעולמות ה  -Machine Learning, על מנת לזהות דפוסים ולפתח את הטכנולוגיה.
    • אז Serverless? יש! Machine Learning? יש! סגור.

הגעתם עד כאן? יש מצב שתאהבו גם את פרק 340 - Serverless With Adam Matan על קהילת ה - Serverless בישראל.
זה - וכנס רברסים 2019 מתחיל לנוע. Stay Tuned.








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