הנה ניסיון לדיון שלא היה נפוץ כ”כ בהיסטוריה של הבלוג. אני מקווה שהוא עדיין יהיה מעניין למגוון אנשים – וילמד משהו חדש.
לאור הביקוש האדיר לעובדים בתעשייה, בחברה בה אני עובד החליטו לעשות צעד ולהסכים לקבל לא רק עובדים בעלי ניסיון משמעותי – אלא גם בוגרים שרק סיימו לימודים.
כמובן שלבוגרים יש פער ידע משמעותי בין התאוריה / לימודים כלליים בנושא (שכוללים גם נושאים מאוד לא מעשיים – כמו מתמטיקה מתקדמת) לבין תעשייה ספציפית, ארגון ספציפי, וניסיון עבודה מעשי.
אנחנו (Next-Insurance) עובדים על מערכת-מוצר וובית (Web-based). זה כבר מכתיב ידע אחר מחברות אבטחה, גיימינג (הימורים), ואפילו קצת שונה עדיין מחברות בתחום הפרסום (להלן AdTech). על כן, אנחנו משקיעים כחודשיים בבוגרים שמתקבלים בן בהרצת פרויקט עם מלווה צמוד בסט הטכנולוגיות + הדומיין העסקי הרלוונטי, והן בהשלמות תיאוריה שאנחנו רואים שחסר להם בתחום.
אחת ההשלמות הללו היא סביבת מיקרו-שירותים (Microservices) והטכנולוגיות הנובעות מסביבה כזו: היכרות עם HTTP עם REST עם טכנולוגיות ענן (ספציפית: AWS), ומכיוון שמדובר במערכת מבוזרת – ענייני תקשורת, Data Consistency וכו’.
בלימוד בוגרים יש משהו מאוד ממקד – הצורך לחזור ולהסביר / לארגן נושאים שרגילים לעבוד בהם, ואולי אנו קצת שוכחים לשאול בהם שאלות בסיסיות.
למשל: בחלק בו אני מלמד על סגנונות תקשורת, ניסיתי לסווג טכנולוגיות / כלי תקשורת נפוצים. כהחלטה אנו מנסים להרחיב את היריעה קצת מעבר לטכנולוגיות שאנו עובדים בהן כרגע בחברה – ולתת סקירה מעט יותר רחבה.
שמעו… היה ברור לי שטכנולוגיות תקשורת הן מלאות מורכבויות ואבחנות. בכל זאת – קצת הופתעתי שאני חוזר לסיווג הבסיסי שלהן שוב ושוב – ולא ממש מרוצה.
מה יצא?
הנה תוצאת הסיווג שלי לאחר שלושה סיבובים של ארגון מחדש:
החלוקה הבסיסית היא לתקשורת סינכרונית מול אסינכרונית (זה יחסית ברור).
בחלוקה המשנית, בעיקר בדרכי תקשורת אסינכרוניים – זה כבר היה הרבה יותר קשה. התחלתי בסיווג לפי בין Queue ו Steam/Bus או Other message Broker אבל ההבדלים בין SQS ל RabbitMQ עדיין הרגישו גדולים מדי להתאים לאותה קטגוריה.
כנ”ל רשימת ה “Other” גדלה וכללה כחצי מהטכנולוגיות שרשמתי – עוד סימן לסיווג חסר.
הערות קטנות:
- Query & Modification Languages הן מצד אחד סוג של RPC (בקשה-תשובה, כאשר הבקשה עשירה ומפורטת) ושקלתי להציב אותן בענף של RPC – מצד שני, הן לא תחליף באמת ל RPC ולכן בסוף סיווגתי אותן כענף נפרד.
- אולי חסרים לכם WebSocket, Server Push, או Server Side Events וכו’ – אלו בעיקר רלוונטיים מול דפדפן, וההתמקדות שלי היא בתקשורת שרת-לשרת. גם TCP ו BGP לא מוזכרים 🙂
- Thrift הוא בעיקרו בינארי, למרות שיכול גם לעבוד ב JSON ולכן הוא לא יושב “חזק” במקום.
- JSON:API הוא בחלקו ניסיון לתקנן משהו מאוד דומה ל RESTFul API – אבל גם מעודד ומקל על עבודה שהיא יותר RPC.
- על הצד האסינכרוני אין לי הערות קטנות – כי הכל שם מרגיש מאוד “בערך”…
אני (חושב שאני) יודע מה אתם אומרים…
אתם בוודאי אומרים: הגזמת! מה אתה לוקח בוגרים ומפיל עליהם את כל המורכבות הזו. תן להם לעכל את הנושאים שלב שלב, Siga Siga.
אתם כנראה צודקים ואני לא מתכוון לעבור אפילו על חצי מהטכנולוגיות האלו (בהתחלה, תכננתי על רובן – והבנתי שזו הגזמה). השלב הזה מגיע לאחר שהם מבינים לפרטים HTTP ו REST וגם טכניקות כגון Long Polling ו WebHooks.
עדיין יש לי שאיפה לתת “סקירת מנהלים” על נושאים – ולתת הזדמנות לאלו שיכולים לקבל מזה משהו מזוקק ותמציתי – לקבל זאת.
בקיצור: אשמח להערות, מחשבות, או סיווגים קיימים ומאירי-עיניים שאתם מכירים למגוון טכנולוגיות התקשורת שמקובלות כיום. אני השקעתי קצת בגיגול – ולא מצאתי משהו משביע רצון ורלוונטי עבורנו…
האם הידע שאתם מעבירים הוא תאורטי בלבד או שאתם גם מצפים מהם להתנסות קצת בטכנולוגיות שלא נמצאות בשימוש שוטף אצלכם?
מה שבשימוש אצלנו – מעשי (במסגרת מה שמספיקים).
מה שלא בשימוש אצלנו – תאורטי בלבד.
זו הזדמנות לומר תודה רבה על הבלוג, שמאפשר לי להציץ (ועוד בעברית!) לתחומים בפיתוח שאני מכירה רק באופן שטחי.
אני מגיעה מתחום המשין לרנינג. יש מקור נוסף, קורס או ספר או מאמרים שאתה ממליץ עליו שמכסים את החומר שאתם מעבירים לעובדים חדשים (מבחינת מיקרו-שירותים ועננים)? ב high level ? ניסיתי קצת טוטוריאלס ווויקיפדיה אבל אשמח למשהו מובנה יותר.
על מיקרו-שירותים שני הספרים הבולטים הם כנראה:
Building Microservices \ Sam Newman
https://www.amazon.com/gp/product/1492034029/ref=dbs_a_def_rwt_bibl_vppi_i4
Microservices Patterns: With examples in Java
https://www.amazon.com/gp/product/B08LQRCMS6/ref=dbs_a_def_rwt_hsch_vapi_taft_p1_i0
על ענן יש אינספור חומרים – קשה לי לחשוב על תוכן דומיננטי או איכותי במיוחד שקל לי להמליץ עליו. הרבה מכרות של ידע, שצריך לחצוב בהם כדי למצוא את הזהב.
את ההדרכות אצלנו מעבירים מגוון של אנשים. ספציפית אני על המבנה של המערכת ומיקרו שירותים – אולי אפרסם חלק מהחומרים בהמשך.
נושאים בסיסיים של HTTP/REST וגם קצת על Cloud Computing ו AWS – ניתן למצוא בפוסטים ישנים. פשוט להשתמש בחיפוש.
אנחנו (Centrica בישראל) נוהגים לחלק את ה״עולם״ של תקשורת בין ״מיקרו סרביסים״ לשלושה סוגים, שההבדל ביניהם הוא לוגי – צורת השימוש:
1. תקשורת סינכרונית – כפי שציינת, משמשת הרבה לבקשה/תשובה, לרוב בין הבקאנד לפרונט.
2. תקשורת א-סינכרונית – הזרמת נתונים מצד אחר לצד שני ״אחד על אחד״ (יש צד שולח אחד וצד מקבל אחד). משמש בעיקר להזרמה ועיבוד של דטה. עם שימוש בפרסיסטנסי (נגיד קינסיס של AWS) מה שדורש ידע מסויים על תקשורת בין סרביסים.
3. (וזה אולי התוספת למה שאתה כותב -) תקשורת pub/sub, כזו שמתבצעת בין אחד לרבים, ויש לכך שימושים שונים – בין עם בבקאנד (רישום של מסרים בים סרביסים שמבצעים פעולות עדכון שונות לדטה), ובן עם בין בקאנד לפרונט, שמשמש לריפרש של דטה בקצב מהיר כמו ווב סוקט
אשמח לשוחח ולהרחיב אם תרצה
תודה אורי על השיתוף!
נראה לי שהשם המקובל לסוג 2 שאתה מציין הוא notification, סוג של “הודעת שגר ושכח”.
אני חושב שעוד היבט מעניין הוא האם מעניינת אותו התשובה או לא. כלומר: אני יכול לשלוח גם הודעה ולצפות לתשובה (א-אסינכרונית) איפשהו.
כמו שאמרו, אפשר לדוש בהגדרות בלי סוף….
מעולה, לחלוטין הייתי שמח לראות יותר דיפ דייב בנושאים שסקרת פה
קיבלתי. 🙂
תודה, אולי אכניס קצת…
הי ליאור. יצא לי לאחרונה לשבור את הראש על סגנונות תקשורת הייתי ממליץ לציין להוסיף עוד סיווג לתקשורת אסינכרונית שהוא ה Delivery Guarentee כחלק מההכשרה במידה ולא נגעת בנושא. לדעתי זה חשוב לדבר על הנושא כדי להבין את ההשלכות של בחירה ב At least once למשל על אופן כתיבת הקוד עצמו.
בנוסף קיבלתי בלאקאוט מהשקף הראשון באופן שבו הוא היה מסודר ואני בטוח שאני לא היחיד. יכול להיות שניסית להעמיס את כל המידע בשקף אחד ובמקום זה איבדת את תשומת הלב של הקהל. גם העובדה ששמת (במכוון) את חלק מהטכנולוגיות (כמו Thrift) בין אזורים יוצרים בלבול במסר שהם מעבירים. ובאיזור של התקשורת האסינכרונית אם כיוונת לשים את הטכנולוגיות על ציר Routing vs Persistence אז אולי כדאי לשים ציר ולבטא את זה באופן ברור.
ובלי קשר בלוג נהדר, תמיד כיף לקרוא. 😊
היי אופיר,
מסכים ש Delivery Guarantee הוא היבט חשוב ומרכזי להתמודד איתו – ובהחלט אני סוקר אותו (בקצרה). ספציפית קשה לי לסווג כלים ע”פ המדד הזה כי מגוון כלים יכולים להציע גם at-least-once וגם at-most-once ברמת הקונפיגורציה. גם exactly-once שנראה היה פעם כייחודי ל Kafka כבר מוצע בעוד ועוד כלים (במסגרת המגבלות הנתונות).
>בנוסף קיבלתי בלאקאוט מהשקף הראשון באופן שבו הוא היה מסודר ואני בטוח שאני לא היחיד.
תודה על האמת בפרצוף. בניגוד לבלוג – מול הבוגרים אני מספר סיפור ורק משתמש בשקף כמפת התמצאות.
א. כנראה שהשקף לא יכול לעמוד בפני-עצמו (ללא ליווי והסבר) בפני newcomer.
ב. כנראה שאפשר לארגן את השקף בצורה ברורה יותר (לפחות ברמת הגרפיקה).
אראה מה אוכל לעשות עם התובנות הללו.
תודה! ותודה על הפרגון על הבלוג! 🙂
דבר ראשון שמחה לראות שיש חברות שמשקיעות בג’וניורים!
לדעתי תפסת מרובה לא תפסת
לסיווג מדויק בלתי אפשרי להגיע
אני הייתי מנסה לייצר איזה סיווג שרירותי (לדוגמא- queues) ובתוך כל קטגוריה לסווג לתת קטגוריות.
אלו נושאים לא טריוויאליים, מענין אותי כמה מהידע יכול להספג כתיאוריה בלבד ללא התנסות.
היי מרגלית,
מסכים שאי אפשר לסווג בדיוק. המטרה שלי הייתה ליצור דיון על מנת לגעת ולחדד נקודות. על משקל: “The plan is nothing, planning is everthing”.
> אלו נושאים לא טריוויאליים, מענין אותי כמה מהידע יכול להספג כתיאוריה בלבד ללא התנסות.
נקודה טובה!
האמת שהגעתי לסשן עם הבוגרים, הרגשתי שלקחתי את זה צעד אחד מתקדם מדי – ולכן בשטח, דילגתי על חלקים מהפרטים וההבחנות והבנתי שהם מבינים את עיקרי הדברים (למשל: תקשורת סנכרונית מול עבודה (execution) אסינכרונית – שזה לא אותו הדבר).
תרגול מעשי, דרך העבודה – יכול לקחת שנים עד שיווצרו מספיק הזדמנויות.
תרגיל מעשי מייד כשמסיימים – דורש הכנה רבה… לא הגעתי לשם.
הכנתי כמה תרגילים תאורטיים (תסריט עסקי –> באיזו דרך תקשורת כדאי להשתמש?) כדי לגרום לבוגרים להפעיל חשיבה.