479 Durable Distributed Workflows With Eric From Remitly רברס עם פלטפורמה podcast

内容由רברס עם פלטפורמה提供。所有播客内容（包括剧集、图形和播客描述）均由 רברס עם פלטפורמה 或其播客平台合作伙伴直接上传和提供。如果您认为有人在未经您许可的情况下使用您的受版权保护的作品，您可以按照此处概述的流程进行操作https://zh.player.fm/legal。

רברס עם פלטפורמה »
479 Durable distributed workflows with Eric from Remitly

9d ago

MP3•单集首页

[קישור לקובץ mp3]

פרק 479 של רברס עם פלטפורמה, שהוקלט ב-8 באוקטובר 2024, תאריך עצוב. אורי ורן מארחים את אריק מחברת Remitly לשיחה על Distributed Workflow Engines.

00:50 אריק ו-Remitly

(רן) אז קצת לפני זה - קצת ספר לנו עליך וקצת על החברה.

(אורי) באיזו שפה ספרת לנו? . . .

(אריק) ספרתי ברוסית.

(אורי) אוקיי, אז הנה - כבר פרט Intro שלא ידענו עליך . . .

(אריק) לגמרי. אני יודע רוסית - אבל אני אוקראיני.

(רן) יודע, אך לא אוהב.

(אורי) אמרנו שמדברים על טכנולוגיה, לא? . . .

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

הצטרפתי לסטארט-אפ בשם Rewire, ממש חצי שנה לפני הרכישה - ואז Remitly העולמית באה וקנתה אותנו, ומאז אני כבר שנתיים וחצי בחברה.

ו-Fun Fact עליי - הייתי פעם טכנאי מכונות תפירה . . .

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

אוקיי, מעולה, נחמד לשמוע. אז הזכרת פה שתי חברות, Remitly ו-Rewire. מה עושים?

(אריק) אז מה ש-Remitly עושה - היא מספקת שירותים פיננסיים ללקוחות שצריכים לנהל כספים ביותר ממדינה אחת.

יש לנו מיליוני משתמשים, שמעבירים עשרות-מיליארדי דולרים בשנה.
היא הונפקה ב-2021, אז אם יעניין מישהו.

(רן) אז בגדול זה חברות רב-לאומיות, כן? כמעט כל חברה רב-לאומית עושה את זה גם, או שהן אולי לא?

(אריק) אז אני אפקס את זה, כי מה שאנחנו עושים זה בעיקר העברת כספים בינלאומית, בעיקר למהגרים, כן? אנשים.

אם ראיתם את הפיליפינים שעומדים בתור בדואר? - זה שלנו.

(רן) אז כמו Wise, למשל? זו הנישה?

(אריק) זה בין המתחרים שלנו. Wise נועדו יותר ל-Digital Nomads, אנשים שיש להם יכולות כלכליות.

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

(רן) אוקיי, אז העברות כספים בינלאומיות זה Remitly. ו-Rewire זה גם?

(אריק) Rewire זה הסטארטאפ הישראלי, שהמוצר שלו עדיין רץ מאוד חזק בארץ.

אבל זה פשוט אחד מהמוצרים של החברה, והוא לאט-לאט משתלב לתוך Remitly העולמית.

(רן) הבנתי. אני יכול רק לדמיין שבתהליך כזה של העברת כספים יש איזשהו Workflow, נכון? יש איזשהו תהליך שקורה - ולכן התכנסנו כאן.

03:42 מה זה Workflow?

אז בוא נדבר: מה זה Workflow? מה הצרכים-המוצריים שהולידו את מה שאנחנו הולכים לדבר עליו עכשיו?

(אריק) אז Workflow - כעיקרון ההגדרה שלו זה פשוט “תהליך”, כן? תהליך שכאילו, זו המילה שלו בעברית, שהוא מורכב מכל מיני פעולות.

אם ניקח אפילו דברים שכל אחד מכיר, לא יודע - “אתה רוצה להזמין משהו”, כי אני עבדתי בחברות eCommerce: אתה מזמין משהו, מחייבים אותך, שולחים לך הודעה, מישהו אוסף את זה במחסן, שולח . . . יש תהליך שלם.
ואתה רוצה לעקוב אחרי זה ולדעת מה קורה שם.

תראה, בעולם פשוט - למי אכפת? אז זה נפל . . . כאילו, בוא נראה, בעולם הכי פשוט זה לא יפול, כן?

זה ירוץ, חלק - בניתי Script לוקאלית, והוא עובד.

(רן) אבל האופטימים לא שורדים, זה אנחנו יודעים . . . [Only the Paranoid Survive, וגם הם מג’עג’עים לאחרונה . . . ]

(אריק) לא, ולא רק שלא שורדים - אם אנחנו מדברים על Scale עכשיו, על מיליונים כאלה.
אם אני מסתכל על התהליך הזה, אפילו מה שתיארתי עכשיו - איפה הוא יכול ליפול?

הוא יכול ליפול בהמון דרכים, בין אם זה...

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

השרת שעליו זה רץ יכול ליפול

יכול להיות שחייבת את לקוח אבל לא לא רשמת כי השרת נפל.

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

אנחנו עובדים אפילו לפעמים עם ספקים שיש להם שעות מסוימות שהם לא עובדים בהן. נגיד הסינים ידועים בזה שהם פשוט במהלך הלילה, השרתים שלהם כבויים לחלוטין.

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

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

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

(אורי) אנחנו מדברים גם על ה-Recoverability שלו - האם הוא יכול גם לתקן את עצמו?

(אריק) כן, אז העניין הוא או שהוא מתקן את עצמו, או שאתה נותן לו - נותן את האפשרות למפתח לבוא וסוג של לעשות Upgrade.

זאת אומרת, Upgrade לתהליך, בזמן שהוא רץ, כדי שאתה מתקן אותו, ואתה לא יודע, מבטל הכל, מתחיל מההתחלה.
כי יש גם מערכות כאלה.

אז אנחנו מדברים על כלים שנועדו להפוך את כל הניהול והעבודה עם ה-Workflow-ים בכללי למשהו שהוא הרבה יותר נגיש למתכנת, למפתח, נותן את ה-Visibility הזה.
ויש, אם אנחנו נעשה Zoom-in לכלי הספציפי שאנחנו מדברים עליו, שזה Temporal - אז הוא נותן לנו הרבה מהדברים האלה, ואפילו טיפה מעבר.

(רן) אוקיי, אז הפתרון שבחרתם, זה כלי בשם Temporal - אבל הוספתם אליו או מעליו עוד פונקציונליות או שכבות נוספות, או פיצ'רים שתיכף תספר לנו עליהם - שלא היו קיימים בכלי המקורי.

(אורי) אני רק רציתי לשאול - רבים ממאזיננו מכירים Workflow-ים של Data: יש Workflow Engines ויש Airflow, הרבה משתמשים ב-Airflow, או Workflow אחר של ETL-ים או דברים כאלה שקשורים ל-Data. זה דומה? זה שונה?

(אריק) אני חושב שזאת שאלה מעולה.
נגיד, כלים כמו Airflow - הם נועדו יותר למה שנקרא ETL, כן? - Extract Transfer Load.

שזה באמת, אתה מעביר Data ממקום למקום, משנה אותו טיפה בדרך.

הרבה שימושים, אם זה ב-Machine Learning, אתה יודע - אתה מעביר את זה ל-Data Lakes, כדי ש-BI יוכלו לבנות על זה כל מיני אנליטיקות מגניבות . . .

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

(אריק) אז אני חושב שהשוני - כי אנחנו, הפוקוס המרכזי שלנו פה הוא מה שנקרא Business-Logic Workflows.

השוני ביניהם הוא גם בצורך שלך בעמידות - כי אם אתה אומר “יש לי מיליון שורות ב-Database, שאני רוצה להעביר אותן ממקום למקום”.
אם עכשיו התהליך הזה לא עובד במשך שעה, מאיזושהי סיבה, או שהצלחתי להעביר 500 אלף, אבל עוד איזה 2-4 באמצע נכשלו - איפה יותר אכפת לי מזה?

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

(אורי) בוא נאמר ככה - כשיש לך המון לקוחות שמחכים לדאטה, שהוא יהיה Visible ושיהיה . . . זה כואב. זה כואב, לצורך העניין, באותה מידה כמו שלקוחות מחכים למשהו.

(אריק) כן, כן,

(רן) אז אני חושב, אורי, אני אנסה רגע - ואריק, תקן אותי - קודם כל, אתה צודק: זאת אומרת, יש דמיון בין כלים כמו Airflow לבין Temporal, שתכף נדבר עליו. בגדול, Workflow Engines מסוגים שונים, יש יש גם Drools, אם אתה זוכר, ויש AWS Step Functions, ויש azkaban . . . זאת אומרת שלא חסרים כלים.

אני חושב שהצורך של Remitly הוא בעצם בכלי, שהלקחות שלו הם לא מפתחים, אלא הם החברה כולה, בגדול. זה אחד. שתיים - Scale שונה לגמרי. אני מדבר על מיליוני-טרנזקציות (Transactions), או מיליוני תהליכים, שרצים במקביל.

קשה לי לדמיין ש-Airflow מסוגל לסחוב דבר כזה, הוא לא נועד לזה. אולי זה אפשרי, אבל . . . .

(אורי) אולי. אצלו, האתגר הוא שכל Data זה . . . כאילו, כל Flow מריץ, פשוט.

(רן) כן - אבל פה מדובר על מיליוני Workflows. ה-Workflows עצמם הם אולי “Lightweight” כאלה, זאת אומרת - הם יכולים לקחת אולי כמה ימים, כי יש דברים באמצע, אבל הם לא “Data Heavy”, אוקיי? ויש מאפיינים אחרים, נגיד של נגיד שקיפות, שהוא צריך. זאת אומרת, קשה לי לדמיין . . . לתת Airflow לאנשי התמיכה, והלגיד להם “בוא, תדבג (Debug) את הגרף”, כאילו - “תבין מה קרה”.

אז כן, אז משתמש-הקצה - הוא שונה לגמרי, כנראה, באופי.

(אריק) כן, אני חושב שתמיד נקודה חשובה, שאנשים מפספסים אותה, זה שגם יש לנו לקוחות פנימיים - BI, Data, זה גם עוד Interface מאוד משמעותי ונקודה טובה שאנשים מפספסים אותה.
אבל, לגמרי - אנחנו, מעניין אותנו הפרט, לעומת מקרים אחרים, שלפעמים מעניין אותך ה-Batch של ה-Data.

אז אנחנו באמת חייבים, ברמת הפרט, ברמת הזמנה הספציפית, ברמת ההעברה הכספית - לדעת בדיוק מה קורה שם, לדעת איפה, מה הסטטוס שזה נמצא בו, ולא לאבד את זה בשום שלב בדרך.
ובמקביל, אם יש הזמנה אחרת שהיא “רצה” - אז לתת לה לרוץ.

(אורי) גם בוא נודה על אמת - אתה מתעסק פה עם כסף של אנשים, אז זה חייב להיות ממש מדויק, אבל גם עם “אופי טרנזקציוני” (Transactional) יותר, שכאילו . . .

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

(אורי) אבל גם מאוד חשוב לדעת מה ה-State - איפה ה-Flow נמצא.

12:37 על כוראוגרפיה (Choreography) ואורקסטרציה (Orchestration)

(רן) אוקיי, אז הזכרנו כמה פעמים את השם של הכלי - Temporal - אבל לא ממש הסברנו מה הוא. אז תן לנו ככה איזשהו “גיץ” של מה זה Temporal - מאיפה הוא הגיע ומי פיתח אותו, למה ומה אתם עושים איתו. הרבה שאלות . . .

(אריק) אז אני רק אזכיר: יש בעולם הזה של ניהול Workflow-ים - Workflow-ים Business-יים - אנחנו, לרוב, יש כזה . . . לא יודעים אם “ריב”, אבל יש לנו שתי דרכים מאוד מרכזיות, שבדרך כלל מתעסקים בזה, שזה או כוראוגרפיה (Choreography) או אורקסטרציה (Orchestration).

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

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

(רן) כן, זו הפעם ראשונה שאני שומע את ההבדלה הזאת, בין כוריאוגרפיה לאורקסטרציה, אז בוא נראה האם הבנתי, בוא נראה האם הפנמתי: אז נגיד, אורקסטרציה זה באמת Workflow Engine, והזכרנו פה כמה כאלה - Airflow ו-Temporal - אז יש מנהל אחד, שהוא אחראי על כל התהליך ואתה יכול לבוא ולשאול אותו “תגיד, מה קורה עם X?” והוא ידע להגיד לך מה קורה עם X. בכוריאוגרפיה, אני מנחש, אולי microservices? זאת אומרת, כל אחד אולי מכיר אותו ואולי את השני שכנים שלו, אבל הוא לא מבין את כל המערכת, אין Service אחד, אין microservice אחד “טיפוסי”, שבאמת מכיר את כל שאר המערכת ויודע לבוא ולהגיד מה המצב בהכל.

אני כמובן מוציא מהכלל נגיד שירות Monitoring, שאולי זאת העבודה שלו, אבל בגדול, microservice עצמו . . . זאת אומרת, אין איזשהו Orchestrator ב-microservices.

(אריק) אני חושב שכשאנחנו מדברים על אורקסטרציה (Orchestration), אתה עדיין יכול שיהיה לך microservices, ואחד מהם עושה לך אורקסטרציה (Orchestration) לשאר ה-microservices, אבל ככלל . . .

כאילו, גם בכוראוגרפיה (Choreography), אתה יכול לרצות לשלוח את כל המידע של הסטטוס הגלובלי לנקודה מסוימת, אבל המטרה בכוראוגרפיה (Choreography) זה שלא תיהיה לך נקודת-כשל אחת.
לעומת זאת, באורקסטרציה (Orchestration), אתה יוצר - בכוונה - נקודה אחת מרכזית, שהיא . . . כמו “מנצח על תזמורת”.

(רן) אז Database מבוזר, או “האינטרנט”, יכול להיות דוגמה לכוראוגרפיה (Choreography), אני מנחש . . . אוקיי, בסדר.

15:04 מי בנה אותו?

(רן) אז אורקסטרציה (Orchestration) - Temporal. מי הוא?

(אריק) אז כשאנחנו מדברים על אורקסטרציה (Orchestration), ואנחנו אמרנו “תהליכים” - אנחנו רוצים שהתהליכים האלה יהיו עמידים.

יש מושג כזה שנקרא Durable Execution - שזו אבסטרקציה (Abstraction) של בדיוק כל הדיבור הזה על ה-State.
התפקיד שלה זה לשמר את המצב של התוכנה.

זאת אומרת, כל פעולה שנעשית, מבחינת האבסטרקציה - היא אומרת “אני עושה את הפעולה, ישר סיימתי אז אני לוקח את התוצאה, שומרת את זה אצלי ב-Database, הולכת לפעולה הבאה, שומרת את זה אצלי ב-Database” . . . .
ותמיד יודעת איפה אני.

והמטרה של זה היא שאם ה-Orchestrator שלי או משהו אצלי נפל - אני קם ואני יכול . . . .

נגיד, אם אנחנו מדברים על Kubernetes ויש לי כמה Pod-ים, אז אם Pod אחד נפל, Pod אחר יכול לקום.

והוא יודע באיזו נקודה זה התהליך עצר, ויכול להמשיך.

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

(אריק) בדיוק, בדיוק. אז הקונספט הזה של Replay - רק ברמה של קוד.
אז תדמיין . . . . ניכנס ל-Temporal יותר, כי Temporal בסופו של דבר, זו אימפלמנטציה (Implementation) של הקונספט הזה.

יש כמה אימפלמנטציות, ו-Temporal היא מאוד מפורסמת, היא גם באה מ-Uber . . .

(אורי) . . . היא באה ב-Uber . . . .

(אריק) ל-Uber היה . . . יש כלי פנימי שקוראים לו Cadence, אז החבר'ה שיצרו את זה ב-Uber יצאו, עשו את הכלי Open Source הזה, שנקרא Temporal.

(רן) אז אני יכול לדמיין שב-Uber, אז Temporal [כנראה ש-Cadence] הוא הכלי הפנימי שלהם והוא זה שנגיד מנהל את הנסיעות, וכל נסיעה זה איזשהו Task, ויש לה איזשהו Workflow מוגדר של לקוח שהזמין, ואז נהג קיבל, ואז הם נפגשו וכו' . . . .

(אריק) לגמרי.

(אורי) עובד - חוץ מביוון . . .

(רן) טוב, את זה אפשר להגיד על הרבה דברים, אורי . . .

(אורי) לא, הקונספט הזה - של נהג קיבל, הגיע, מתי, לא . . . .

(רן) האנשים עובדים, חוץ מביוון . . . אוקיי, אז זאת אומרת - Temporal צמח ב-Uber, ואחר כך יצרו גרסת Open Source שלו - ואתם מצאתם אותו ככה?

(אריק) אני מכיר את Temporal עוד מהחברה הקודמת - עבדתי ב-Avo, שכבר נסגרה.
עשינו גם תהליך מאוד מורכב, eCommerce וזה - ואנחנו לא השתכנענו אז ש-Temporal הייתה מספיק בשלה [לא, כי אבוקדו . . . ]

וגם זה דרש שינויים מאוד גדולים.

ברגע שאנחנו ב-Remitly החלטנו לבנות איזשהו מוצר חדש, הייתה לנו הזדמנות לבנות מערכת “From the Ground Up”.
ב-Rewire, אנחנו ידענו את כל הצרכים האלה, וכמו כל סטארטאפ, כמו כל חברה, בנינו כלים משלנו - בדיוק לעשות את כל הדברים האלה . . . .

לנהל את ה-State, לנהל Re-Try-ים, לנהל את כל הדברים המורכבים האלה.

כמובן שלא עשינו את זה טוב כמו כלי שנבנה לטובת זה כמו Temporal - אז ברגע שהייתה לנו את ההזדמנות לבנות Form Scratch, קפצנו ישר על הדבר הזה.

(רן) שנייה . . . אתה אומר “Form Scratch”, אבל למעשה זה להשתמש בכלי - להשתמש ב-Temporal, אבל “להתחיל אותו נקי”.

(אריק) להתחיל “נקי” - כי התחלנו מוצר חדש.
אז אני אומר - אתה מתחיל מוצר חדש, אתה יכול לבנות, לבחור את ה-Technical Stack שלך - אז זה היה מאוד No-Brainer מבחינתנו, כי פשוט זה “ישב לנו מאחורה” כבר הרבה זמן.

(רן) כן, אבל אתה אומר שפעם אחת “עשיתם את הטעות הזאת” - אני עושה ככה “מרכאות באוויר” [מיתרונות הטקסט] - ושאמרתם, או אולי לא הכרתם את ה-Temporal, אבל בניתם כלי כזה בעצמכם. הבנתם מה האתגרים, ואז אמרתם “אוקיי, Never Again! אנחנו הפעם הולכים לחפש כלי שיודע “לתת לנו את ה-80%".

19:20 השלמות

(רן) אבל כמו שאנחנו יודעים - זה רק 80%. זאת אומרת, זה אף פעם לא הכל.

אז איפה . . . או איזה השלמות הייתם צריכים לעשות?

(אריק) אז אני אכניס לפה עוד אחד מהדברים שיכולים להתקשר - אנחנו מדברים הרבה על Race Conditions.

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

יומית, חודשית - לא משנה מה.

(רן) אז אם המגבלה היא אלף, ואתה פעמיים שולח אלף בו-זמנית - אז אתה עלול לעבור את המגבלה.

(אריק) כן, גם בתור . . . כאילו, אנחנו חברה גלובלית, וחברה שכמו כל חברה בנינו microservices . . . .

אז אם זה היה Service אחד, Database אחד - אז זה No-Brainer להשתמש בטרנזקציה, ב-Database, וסגרת את העניין.

אבל ברגע שאנחנו רצים בכמה microservices - איך אתה יוצר טרנזקציה, Across-Services? זה משהו שהוא קצת יותר קשה.
אז מה שעשינו - בנינו מערכת Distributed Locks מעל Temporal - ככה שכל Workflow כזה שרץ, אנחנו כאילו אומרים לו “היי! תקשיב - אני רוצה לנעול את המשתמש הזה, למהלך הריצה של הפעולה הזאת”.

וזה משהו שהיינו צריכים, כדי לוודא שאין מצב שיש לנו . . . שלקוחות עוברים, נגיד, את המגבלות היומיות שמותר להם לעשות.

(רן) כן, אז סוג של Two-phase Commit כזה - של “אני מתחיל פעולה, תנעל”, ובסוף לעשות לזה שחרור . . . . אז למעשה זו מערכת Locking כלשהי.

(אריק) כן.

(רן) אוקיי, שזה משהו שלא היה קיים ב-Temporal?

(אריק) Temporal - מה שהיא נותנת לך . . . היא נותנת לך הרבה גמישות.
איך ש-Temporal בנויה, כמו שאמרנו, יש לנו את ה-Workflow, וה-workflow זה פשוט קוד, כן?

כאילו, זה Polyglot, אז כאילו - תבחר כל שפה שאתה רוצה . . .

אנחנו עובדים בעיקר עם Node.js, ויש לנו עוד כמה צוותים שעובדים עם Go.
זה לא משנה, השפה - זה פשוט פונקציה. פונקציה שקורית . . .

כאילו, אתה יכול פשוט לקרוא את הקוד הזה - אין שם איזשהו Boilerplate

נגיד, יש Step Functions או דברים כאלה, שאתה מגדיר את ה-Workflow שלך ב-JSON, או ב-Airflow, אם אני לא טועה אז גם, אתה מגדיר את זה ב-Python, אבל מגדיר את זה באיזשהם Pipe-ים כאלה.

וזה - פה אנחנו מדברים נטו-קוד: פונקציות שקוראות לפונקציות.

אתה יכול לעשות שם If-ים, אתה יכול לעשות שם For-Loop, אתה יכול לעשות שם קוד . . .

(רן) כן, זאת אומרת - אין DSL נוסף, זה השפה - זה Node או זה Go, אבל אין DSL נוסף “שעוטף”, ושיכול להוסיף מורכבות ושצריך קונטקסט כדי להבין אותו. זאת אומרת, faמגיע מפתח חדש לחברה, והוא פתאום צריך להבין כל מיני דברים שלא כתובים בקוד.

22:22 מה עם לא-מפתחים? ועם Code Versioning?

(אורי) רגע, אמרנו לפני כן שה-Workflow-ים האלה יכולים לשמש, או שיכולים להשתמש בהם, גם אנשים שהם לא מפתחים . . .

(אריק) אז אני לא יכול להגיד שלא-מפתחים, אבל אני חושב שגם מפתחים ברמות מאוד התחלתיות יכולים להיכנס, ומאוד בקלות להבין מה כתוב שם.
כי בסופו של דבר, זה פשוט קוד, כן? אם אתה יודע לכתוב פונקציה פשוטה, עם Loop-ים . . . אתה יודע, אתה מסיים כמה קורסים באוניברסיטה, אתה יכול לקרוא Workflow.
כמובן, אתה צריך את הרמות-החשיבה היותר גבוהות, להתמודד עם דברים יותר מורכבים - אבל אני חושב שמה ש-Temporal מביא, וזה אחד מהדברים הכי חזקים לעומת המתחרים שלו, זה Mental-Model יותר קל.
כי הוא לקח לעצמו הרבה מה-Heavy Lifting לתוך הפלטפורמה.

הוא מנהל לך את ה-Failure-ים, הוא נותן לך Re-Try-ים, הוא נותן לך את הכל - ככה שכשאתה רץ ב-Workflow, ויש לך שורה שאומרת “תשלח לי את ההודעה” - אז זה קורה לפונקציה מאחורי הקלעים.

מבחינתך, זו פשוט שורה בקוד, שאתה באמת קראת לפונקציה.
והוא יודע להכניס את זה ל-Queue, לשמור את ה-State, לדאוג שאיזשהו Worker יריץ את הקוד . . .
ואנחנו יכולים להיכנס בדיוק לאיך שהדברים האלה עובדים.

(אורי) זאת אומרת, בכל הדברים שהם . . . נקרא לזה “התוספות הפנימיות שלכם” - לעשות Locking, רק על זה דיברנו עכשיו . . . את כל זה אתם “מחביאים” מהמשתמש?

(אריק) משתדלים, כן.
אבל אני חייב להגיד שאנחנו לא היינו צריכים לבנות המון מעל Temporal.

יש איזו אימפלמנטציה (Implementation) שאתה מחבר אותו למערכת Race-ים, ו-Log-ים ו-Bug-ים וכל זה.
אבל הוא נותן לך המון - גם כי זה קוד, כן? אז תכניס איזה קוד שאתה רוצה.
אבל בסופו שעבר אנחנו לא בנינו הרבה מעל Temporal, אלא פשוט התמקצענו באיך להשתמש ביכולות שלו.

(אורי) אגב, זה מעלה לי עוד שאלה - אתם מנהלים Code Versioning של ה-Workflow-ים עצמם?

(אריק) זאת נקודה מעולה, כי התחלנו להגיד . . . הזכרנו מקודם על הנושא הזה ש(למשל) יש לנו איזושהי תקלה, ואנחנו רוצים עכשיו, בזמן אמת, לבוא ולתקן את ה-Workflow.

אז Temporal נותן מערכת שנקראת Patching.
הרי אמרנו, אם אנחנו . . . נגיד, ה-Workflow נפל באמצע, והוא מקים את עצמו מחדש, ורן - אמרת שזה מאוד דומה לאיך ש-Database-ים עובדים . . .

אז הוא עושה את ה-Replay הזה כל פעם.
ומה שאתה יכול לעשות - אתה יכול פשוט לעשות Deploy לקוד חדש, הוא יעשה Replay מההתחלה, הוא יגיע לקוד החדש שלך - והקוד החדש שלך פשוט יתווסף בתוך ה-Workflow.

(אורי) . . . והוא גם ירוץ מה-State שבו הוא נעצר . . .

(אריק) נכון. יש שם נקודה אחת, שזה אם ה-State החדש לא תואם את ה-State הישן.

כי אם נגיד אתה בנקודה מסוימת שלחת SMS - אני כל פעם נופל על SMS, אבל אפשר להגיד נגיד “לחייב את הלקוח” - ופתאום אתה כבר לא מחייב את הלקוח, אלא אתה נגיד מחכה, שמת שם איזושהי נקודה ואתה מחכה שמישהו מ-Customer Support יאשר את הדבר.

אז אם אתה תעשה את זה בצורה נאיבית, זה אמור להגיד לך “היי! אני לא מכיר את המצב הזה! הכנסת אותי למצב מוזר!” . . .
מה שצריך להגיד לו זה “היי, אני עושה לך Patch - זאת הגרסה החדשה, הנה מה שאתה עושה אם אתה בגרסה הקודמת”.
ואתה פשוט כותב קוד של if-else כזה - אם אתה בגרסה החדשה, תעשה את זה; אם אתה רצת כבר בגרסה הקודמת, אז הנה מה שאתה עושה.

(רן) אז צריך אחר כך ללכת ולנקות את זה, אני מניח . . .
(אריק) נכון, נכון - אבל זה כמו כל . . . יש לך API, אתה עשית...
(רן) כן, זה צריך להיות Backwards-Compatible לפחות גרסה אחת אחורה - אבל אם אתה בצרות אז יש לך כמה גרסאות אחורה . . . ב-Production אתה צריך לתחזק גם את זה, אבל מדי פעם ללכת ולנקות את “השובל” הזה.

(אורי) אבל השאלה שלי היא באמת על, אתה יודע - על Code Versioning, על Code Cottrol “רגיל” - יש ל-Workflow-ים עצמם?

(אריק) יש לך בדיוק שתי אופציות: אחת אמרתי - זה ה-Patch-ים,

האופציה השנייה זה שאשכרה אתה יכול לשמר את הגרסה הקודמת - בגרסאות האחרונות, Temporal אפילו יכול לשמור את הקוד שלך אצלו, בגרסה הקודמת.
ואתה יכול להגיד לו “תריץ את מה ששמרת כבר אצלך”.

הנקודה החשובה פה זה שאתה זה שמריץ את הקוד באמת, כן? או ה-Pod-ים שלך, ה-Worker-ים שלך - הם אלה שהם . . .

אפשר לחשוב על זה כמו “Subscriber-ים” להוראות שמגיעות מהמערכת של Temporal.
יש את המערכת של Temporal, והיא מחזיקה את ה-Queue-ים, היא מחזיקה את ה-State, מחזיקה את ה-Database.
והיא מודיעה לך: “תריץ עכשיו את הפעולה הזאת, תריץ עכשיו את ה-Workflow הזה”.

אז אתה מחליט איך אתה מנהל את הקוד שלך -

אתה יכול להגיד “אוקיי, תנתב את כל האלה הישנים לגרסה הזאת, שאני שומר במקביל”.

כמו שהייתי שומר Version 1 ו-Version 2 של API.

או “תנתב את שניהם לאותה נקודה” - ושם אני אעשה את ה-If-Else הזה, כן? Backwards-Compatible או לא Backwards-Compatible.
או אופציה שלישית, שזה להגיד ל-Temporal “היי, שמור את הגרסה הישנה אצלך במערכת, ותריץ את זה בנפרד”.

אבל זה משהו די חדש, רק נכנס כדי לעזור עם הקטעים האלה.

אבל לרוב, הם תמיד ממליצים לרוץ עם Patch-ים, זה הרבה יותר נוח.

כי גם אתה תמיד יודע - אתה מנהל את המעבר, ואתה יכול לעשות אותו כמה חלק או כמה לא חלק שאתה רוצה.

28:34 מערכות מבוזרות ובאגים מאתגרים

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

אז אולי תספר לנו על איזשהם באגים “מאתגרים” שאולי נתקלתם בהם, או Use-Case-ים שאולי לא חשבתם שתצטרכו ופתאום גיליתם שאתם צריכים, או כל מיני ככה, שלא צפיתם בבוקר שבוא החלטתם ש”הולכים על Temporal!”, וגיליתם אחר כך ואיתגרו אתכם.

(אריק) אני יכול לדבר על Use-Case-ים מעניינים, גם בהקשר של עוד Feature-ים מגניבים של Temporal.
אנחנו, נגיד, עובדים עם איזשהו ספק-צד-שלישי, שהוא - אתה פונה אליו ב-API, זה אחד ממה שנקרא Activities ב-Temporal - והוא מחזיר לנו תשובה.

אז הוא אומר “היי, הצלחתי לבצע את הפעולה!” או “לא הצלחתי לבצע את הפעולה” - סבבה.
בנקודה מסוימת, הספק הזה, בחלק מהפעמים, הוא מחזיר לך תשובה - אבל בחלק מהפעמים הוא אומר לך “היי, אני ב-Pending, ואני אחזיר לך Webhook”.

אז פתאום הוא מוציא אותך מהתהליך הרגיל הזה, שאתה רגיל להתמודד איתו.
(רן) “מוציא אותך מה-Zone” . . . אוקיי.

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

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

כי, לא יודע - ה-Customer Support יכול לפנות ב-UI שלהם ולעשות דברים, אז אתה לא יכול לדעת עד שהוא שולח לך.
אם שתעשה לו Polling לדוגמה, משהו כזה.
(רן) כן . . . .אז “סליחה, הכסף הזה שלך? אה, לא שלך? לא, שלך? לא. כן? 50 דולר . . . .”

(אריק) אז מה שעשינו בהתחלה - חשבנו על לקבל את Webhook-ים, ול-Temporal יש כלי מגניב כזה, שאתה אומר לו “Workflow - חכה”

“וחכה” זה יכול להיות לשעה, דקה, יום, אפילו שנה, כן?
יש Use-Case-ים שאתה משתמש ב-Temporal בשביל לעשות לך את החשבונית החודשית של לא משנה איזה שירות, כן?

אתה עושה כזה Loop, ואתה פשוט . . ה-“Wait” . . . .
(רן) “מתעורר” פעם ב-30 יום? . . .
(אריק) בדיוק.
(רן) . . . או 31, או 28 . . . זה גם מעצבן, כל החודשים האלה.

(רן) אוקיי, אז אתם מחכים ל-Webhook הזה?

(אריק) אז אנחנו אומרים לו “תחכה” - ול-Temporal יש משהו מגניב שנקרא Signal.

זה לא רק תהליך, שאתה פשוט יוצר את הגרף - אלא אתה יכול לבוא אליו מבחוץ, ולהגיד לו “היי, שומע? תעשה את הדבר הזה”.
הוא יוצר API כזה, ל-Webhook, ל-Workflow, סליחה.

אז כשאנחנו מקבלים את ה-Webhook, אנחנו יכולים או בדרך הרגילה, “הישנה” - כביכול “ישנה”, במרכאות - ללכת ל-Database ישירות ולשמור את זה.

או להגיד שאני רוצה שכל הקוד שמנהל לי, נגיד, את הטרנזקציה הפיננסית הזאת - שיהיה בתוך Workflow, כן? Workflow אחד ארוך.

שאני רואה ואני יודע בדיוק מה קורה ובין איזה שלב לאיזה שלב.
ואז אני רואה שיש לי שורה של “חכה, אני קיבלתי Webhook! אני עושה Signal לתוך ה-Workflow”.
ו-Signal זה פשוט כמו קריאת API, ואז מהנקודה הזאת ה-Workflow אומר “אוקיי, קיבלתי” ,וממשיך לרוץ.

החלק המעניין של Signal-ים, כי אתה יכול להגיד “רגע, ואם ה-Workflow נפל?”.

אז הוא זוכר והוא שומר בהיסטוריה הזאת, ב-Log שלו, שהוא קיבל את ה-Signal הזה, ומאותו רגע אתה לא צריך שה-Webhook יגיע שוב פעם או משהו כזה.
ואז הוא מקבל את ה-Input הזה - ואז הוא יכול להמשיך לרוץ איתו כרגיל.

מצד שני, אתה יכול לעשות גם Polling - שגם את זה לפעמים עשינו, כשבאמת לא סמכנו על ה...

(רן) אז נגיד שם אתה יכול לבוא ולהגיד “אוקיי, אם ה-Webhook הזה לא מגיע אחרי” - נגיד שעה - “אז תרים לי איזשהו Exception”,“תגיד לי שמשהו פה קרה” או זאת אומרת, לטפל בכל מיני מקרים כאלה, של דברים שלא קרו. זאת אומרת, עד עכשיו דיברנו על דברים שקרו, אוקיי? אתה מחכה לדברים שיקרו, אתה עושה דברים, אתה מחכה שהסינים יתעוררו בבנקים שלהם . . . . אבל לפעמים, אתה רוצה לדעת גם כשדברים לא קרו.

(אריק) אז זאת נקודה טובה, כי אם אנחנו מדברים . . . . ב-Node.js, יש לנו את ה-Sleep, אז מה שאנחנו יכולים לעשות זה להגיד לו “היי, תחכה ל-Signal הזה, שאמור להגיע מה-Webhook - או אם עברו, לא יודע, X שעות”, כן?

ואז, אם עברו X שעות, אז אולי תעשה את ה-Polling בעצמך, ישירות מהספק הזה ותתחיל תהליך, כשאתה טיפה יותר אגרסיבי עם הדבר הזה.

כי ציפית שזה יגיע - וזה לא מגיע.

בנקודה אחרת, אתה יכול - הרי זה קוד, אז אתה יכול להגיד “אוקיי, בנקודה הזאת, תתריג (Triger) תוסיף כזה משימה ל-Customer Support או ל-Operations זה משהו כזה, שיסתכלו על זה”.
ואז - אתה יודע, עוד שורה בקוד, של “תחכה לתגובה מגורם אנושי”.
(רן) כן.

34:01 כללי-אצבע

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

(אריק) אז כמו אמרנו, דיברנו על ETL-ים - Temporal יכול לעשות ETL-ים, ויכול להיות שיש כבר Use Case-ים לזה - אבל אני חושב שיש כלים כבר שמאוד מפוקסים בדבר הזה, אז הייתי נמנע מזה.
ל-Temporal, מאחורי הקלעים יש לו Queue-ים, אבל אם אנחנו מדברים על פעולה קטנה שצריכה להיות ב-Queue, אז גם - לא יודע: RabbitMQ או Pub/Sub או דברים כאלה, יש כבר את הכלים.
ברגע שאנחנו מדברים על עמידות, Temporal באמת מעולה - אבל אם לא אכפת לנו מה-Data מסיבות מסוימות לזה, ו-AdTech לדוגמה, זה תחום מאוד מפורסם, ש”מאבד מידע בכוונה”, כי פשוט זה מאוד יקר לעשות Processing . . .

(רן) לא יודע אם “בכוונה”, אבל פשוט לא מתאמץ מאוד לשמור אותו . . .
(אריק) בדיוק,

אז ה-Temporal בא עם עלות, כמו כל כלי.

ברגע שאתה שומר State, אתה שומר היסטוריה, אתה שומר הרבה הרבה דברים - הוא בא עם עלות מסוימת.
לנו, ב-FinTech ב-Remitly, מאוד אכפת לנו ואנחנו מוכנים להשקיע את העלות הזאת

כדי לוודא שהכל מגיע לסיום ואנחנו יודעים תמיד איפה הכל.

אז אם אכפת לכם מאיפה הכל נמצא, בכל רגע נתון - יש להם כלי UI מאוד טובים, שאומרים לך בדיוק.

אתה יכול לראות בדיוק את ההיסטוריה הזאת, הסתעפויות של Workflow-ים ותתי-Workflow-ים ותתי -Workflow-ים וכל הקשרים האלה, וכל ה-Re-Try-ים האלה.
סאגות למיניהן, מאוד קל לעשות שם.

(אורי) אגב, הוא כלי SaaS? או שהוא...

(אריק) הוא גם כלי SaaS, אבל בגלל שהוא Open Source, אתה יכול פשוט להריץ אותו On-Prem או, אתה יודע, “בענן שלך”, מאוד בקלות.

(רן) כן, אוקיי, אז אם Workflow זה חלק מהותי מהמוצר שלכם, אם אתם צריכים, למשל, משהו שנראה כמו טרנזקציות (Transactions), אבל לא על Database אחד אלא על איזושהי מערכת קצת יותר מבוזרת, אם אתם צריכים לחכות שהסינים יתעוררו בבוקר כדי להריץ או מחכים לאיזשהו Webhook, זאת אומרת, כל הדברים שהם ככה יחסית א-סינכרוניים (Async) או אולי איטיים ודורשים ויזיביליות (Visibility) - אז יכול להיות ש-Temporal הוא הכלי שאתם מחפשים.

36:44 סיום, סיכום ומשרות פתוחות

(רן) אוקיי, אז נראה לי שכאן אנחנו מסכמים. אולי קצת לפני זה - עוד כמה מילים על Remitly: איפה אתם יושבים בישראל? או שזה כזה...

(אריק) אנחנו יושבים ממש ליד מגדלי אלון - יש לנו קומת-קרקע מאוד יפה, מאוד מעוצבת . . .

(רן) “תל-אביבה”.
(אריק) מאוד תל-אביבה . . .

(רן) טוב. מחפשים עובדים? מגייסים?

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

כמובן מלא Engineering - אבל גם לא רק Engineering.

(רן) כמה פחות או יותר אתם באזור של הפיתוח בישראל?

(אריק) בישראל, אם אני לא טועה, אנחנו באזור ה-80 איש; ברחבי העולם אנחנו משהו כמו 500, ב-Engineering Org.

(רן) אוקיי, ויש קשר עם חברת-האם, הגדולה יותר? איפה היא נמצאת, בעצם?

(אריק) כן. חברת-האם מבוססת בסיאטל.

נבנתה לפני 12 שנה, ואנחנו גם עם מעל 10 Site-ים ברחבי העולם, אנחנו מאוד גלובליים.
כמובן, אנחנו עובדים עם לקוחות גלובליים, אנחנו גלובליים.

האזנה נעימה ותודה רבה לעופר פורר על התמלול!

154集单集

#טכנולוגיה