דיון: סיווג סוגי תקשורת במערכות ווב

הנה ניסיון לדיון שלא היה נפוץ כ"כ בהיסטוריה של הבלוג. אני מקווה שהוא עדיין יהיה מעניין למגוון אנשים – וילמד משהו חדש.

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

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

אנחנו (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.

עדיין יש לי שאיפה לתת "סקירת מנהלים" על נושאים – ולתת הזדמנות לאלו שיכולים לקבל מזה משהו מזוקק ותמציתי – לקבל זאת.

 

בקיצור: אשמח להערות, מחשבות, או סיווגים קיימים ומאירי-עיניים שאתם מכירים למגוון טכנולוגיות התקשורת שמקובלות כיום. אני השקעתי קצת בגיגול – ולא מצאתי משהו משביע רצון ורלוונטי עבורנו…