שמעו קטע, לפעמים בעולם הטכנולוגי שרץ קדימה בלי לעצור לנשום זה מרגיש קצת כמו לראות פרקים חוזרים, רק עם שמות קצת אחרים. כמי שחי ונושם תוכנה עוד משנות ה-90 בשילוב של נוסטלגיה, הדבר הלוהט בעולם ה GAI שנקרא – Model Context Protocol, או בקיצור MCP. הקפיץ לי לראש מחשבה. האם בעצם MCP זה ה-DCOM של פעם?
זה בהחלט נושא ששווה לעצור ולחשוב עליו רגע, זה מה שאנסה לעשות בפוסט זה.
אני מניח שרוב מי שקורא.ת את הפוסט חושב.ת מה הוא רוצה ממני???
על רגל אחת, DCOM – Distributed Component Object Model היה הטכנולוגיה של מיקרוסופט שאפשרה לאובייקטים (רכיבי תוכנה) לתקשר בתוך מערכת ההפעלה, אפילו בימים אלו , והתוספת של D גם לתקשר דרך הרשת, כאילו היו על אותה מכונה.
בבסיס זה היה חזון מדהים – שקיפות ברמת מערכת ההפעלה וכמובן במרמת מערכות מערכות מבוזרות מורכבות מרכיבים קיימים.
במציאות? ובכן, DCOM הפך לשם נרדף למורכבות תצורה מסויטת ("Registry Hell" ו-"DLL Hell"), וכותב את זה ארכיטקט פשוט שעסק בזה לא מעט. היה צריך להיות מומחה לא קטן כדי לגרום לו לעבוד בצורה אמינה לאורך זמן.
אז מה זה MCP הזה, ואיפה ההקבלה?
Model Context Protocol , כלומר MCP שהומצא על ידי Anthropic ושוחרר כקוד פתוח מציע פתרון לבעיה המורכבת של אינטגרציה בין מודלים למקורות נתונים. הפרוטוקול מתוכן לספק דרך מאובטחת ויחסית פשוטה לחיבור בין מערכות מבוזרות. ל הבענין הוא שיתוף והעברה של ה"קונטקסט" של מודלי שפה. הקונטקסט הזה הוא למעשה הזיכרון של המודל בשיחה ספציפית: מה נאמר קודם, איזה מידע חשוב, מה המטרה עכשיו. ככל שאנחנו בונים מערכות מורכבות יותר, אולי כאלה שמשלבות כמה מודלים או "סוכנים" (Agents) שעובדים ביחד, הצורך לנהל את הקונטקסט הזה ביעילות ובצורה מבוזרת הופך להיות קריטי לחלוטין. וכן כבר היום החברות הגדולות התחילו לאמץ את הפרוטוקול
וכאן מתחילים לראות קווים מקבילים ל-DCOM, כאלה שגורמים לי להתעורר:
הבעיה המרכזית: גם DCOM וגם MCP מנסים להתמודד עם אותה בעיה מהותית – איך לנהל מצב (state) מבוזר ואיך לגרום לרכיבים שלא יושבים באותו מקום לדבר ביניהם. DCOM עשה את זה לאובייקטים, MCP מתמקד בקונטקסט של מודלים. זה אתגר מוכר.
מורכבות אינהרנטית: בואו נודה על האמת, ניהול מצב מבוזר זה מסובך. תיאום, סנכרון, טיפול בכשלים, שמירה על עקביות – אלו אותם כאבי ראש ישנים ומוכרים, ו-MCP לא יהיה חסין מפניהם. אין פה פתרון קסם.
פוטנציאל לצימוד הדוק: אם לא ניזהר, אם כל חברה תעשה מימוש משלה ל MCP משלה אנחנו עלולים למצוא את עצמנו שוב במצב שבו אי אפשר להחליף מודל אחד באחר או לשלב מערכות בלי לשכתב חצי עולם. זה בדיוק מה שקרה עם DCOM וזה פוגע בגמישות.
אתגרי ביצועים: "קונטקסט" של מודל שפה זה לא משהו קטן. להעביר כמויות כאלה של מידע ברשת יכול להיות כבד. בדיוק כמו ש-DCOM סבל מ-overhead, גם פה נצטרך להתמודד עם שאלות של ביצועים ורוחב פס.
אבטחת מידע : כבר עכשיו ניתן לראות שיש כאן חור ענקי עם אין סוף אתגרים של אבטחת מידע. אותי מפתיע שכולם מוכנים להתקין מקומית ולשתף מידע רגיש
אבל למה זה כנראה לא DCOM 2.0?
למרות הדמיון המטריד, ויש לי תחושה שאני לא היחיד שזה מטריד אותו, יש כמה הבדלים מהותיים שגורמים לי לחשוב שאולי הפעם התעשייה למדה משהו. השינויים האלה נובעים בעיקר מהתקדמות הטכנולוגיה והתפיסות הארכיטקטוניות שהתפתחו מאז שנות ה-2000 העליזות:
ההקשר הטכנולוגי שונה לגמרי: DCOM נולד לעולם אחר. עולם שלפני Web Services, REST APIs, JSON והענן המודרני. MCP מגיע לעולם שכבר חטף כמה כפות (למד בדרך הקשה) על החשיבות של פרוטוקולים פתוחים, סטנדרטים מבוססי טקסט כמו JSON, תקשורת אסינכרונית וארכיטקטורות מבוססות שירותים (Microservices) עם צימוד רפוי. אימצנו גישה של "קודם כל אנשים" שמשתפים פעולה וסטנדרטים.
פילוסופיה ארכיטקטונית בוגרת יותר: היום אנחנו מבינים הרבה יותר טוב שצימוד הדוק ותקשורת סינכרונית-חוסמת בסגנון RPC (כמו ב-DCOM) זה לא תמיד הפתרון הנכון במערכות מבוזרות גדולות. המגמה היא לכיוון APIs מוגדרים היטב, העברת הודעות (Messaging), ותכנון שמאפשר יותר גמישות ועמידות. יש יותר נכונות לשאול "למה לא?" ולנסות גישות חדשות. זה עניין של איזון.
האקוסיסטם של AI: כל העולם הזה של AI, ובמיוחד LLMs, מתפתח במהירות שיא. יש לחץ חיובי מהקהילה ומהתעשייה לכיוון של סטנדרטים פתוחים ושיתוף פעולה. אני רוצה להאמין שזה יעזור למנוע יצירה של "גינות סגורות" וקנייניות כמו אלה ש-DCOM קידם בזמנו. שוב, "קודם כל אנשים", אחר כך טכנולוגיה קניינית.
מהות ה"קונטקסט": בניגוד לאובייקט DCOM, שהיה יחידה לוגית עם מתודות, ה"קונטקסט" של מודל הוא יותר אוסף של מידע או מצב. ייתכן שהדרכים לנהל ולהעביר אותו יהיו שונות במהותן מקריאות RPC מסובכות.
2 הסנטים האישים והצנועים שלי
נחזור לשאלה לשאלה המקורית: MCP הוא ה-DCOM החדש? התשובה שלי היא: כנראה שלא, אבל ההשוואה הזו היא תמרור אזהרה חשוב שאסור להתעלם ממנו.
MCP בהחלט מתמודד עם בעיה דומה לזו ש-DCOM ניסה לפתור (ניהול מצב ותקשורת במערכת מבוזרת), ולכן הוא חשוף לאותם סיכונים: מורכבות, צימוד חזק מדי, בעיות ביצועים ונעילה לספקים (vendor lock-in). אם לא נהיה חכמים, אם לא נלמד מלקחי העבר וניישם את MCP בצורה נאיבית או מונעת מאינטרסים קנייניים, בהחלט נוכל למצוא את עצמנו חוזרים על אותן טעויות כואבות.
מצד שני, העולם התקדם. הכלים שיש לנו, הידע הארכיטקטוני, הגישות המודרניות – כל אלה שונים משמעותית ממה שהיה בשנות ה-90. יש לנו הזדמנות אמיתית לבנות פתרונות MCP שיהיו גמישים, פתוחים, ומבוססים על עקרונות נכונים כמו צימוד רפוי וממשקים ברורים. האתגר שלנו, כאנשי מקצוע שאכפת להם, הוא להיות אותנטיים בכוונות שלנו, להתעקש על מחשבה לטווח ארוך ולא להתפתות לפתרונות שנראים קלים עכשיו אבל יסבכו אותנו אחר כך.
בואו נשתמש בזיכרון של DCOM לא כדי לפסול רעיונות חדשים כמו MCP, אלא כדי להזכיר לעצמנו כל הזמן כמה חשובה ארכיטקטורה טובה, כמה קריטית היא החשיבה על העתיד, וכמה הכרחי לשאוף לפתיחות ולסטנדרטים, במיוחד עכשיו כשאנחנו בונים את היסודות לעידן המדהים הזה של בינה מלאכותית.
צריך לגשת לזה באופטימיות זהירה ועם הרבה אחריות.
מסקרן אותי מאוד לשמוע גם את דעתכם. איך אתם רואים את עתיד ניהול הקונטקסט במודלים? האם גם אתם נתקלים ב"רוחות רפאים" טכנולוגיות מהעבר שמבקרות אותנו מדי פעם?