מערך שיעור: Monolith ו-Strangler Fig

משך: 2 שעות אקדמיות (90 דקות).

מטרת השיעור: הסטודנטים יבינו מתי מונוליט מספיק ומתי לשקול פירוק, ויכירו Strangler Fig כדפוס הפירוק הבטוח.

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

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

מהלך השיעור#

דגשים להעברת השיעור#

• זהו שיעור שבו חשוב לא ליצור רושם ש"מיקרוסרביסים = מתקדם/טוב יותר" — הדגישו שוב ושוב שזו החלטה תלוית-הקשר (גודל צוות, קצב שינויים), לא שדרוג טכני אוטומטי.
• השתמשו ב-Task Manager API של הסטודנטים עצמם כדוגמה חיה לניתוח Coupling — הרבה יותר משכנע מדוגמה מומצאת.
• Strangler Fig דורש הדגמה קונקרטית של “שלב ביניים” — לא רק “לפני” ו"אחרי", אלא מצב שבו חלק מהמערכת כבר מפוצל וחלק עדיין לא, ושניהם עובדים יחד.

מושגים#

Monolith — אפליקציה שלמה אחת, נפרסת יחד. Microservices — שירותים עצמאיים, כל אחד נפרס בנפרד. Strangler Fig — פירוק הדרגתי, לא Big Bang. Coupling — רמת תלות בין מודולים.

תרגיל חשיבה#

שאלת פתיחה: “צוות של 3 מפתחים על Task Manager API קטן — האם הם צריכים מיקרוסרביסים? מה לגבי צוות של 50 מפתחים על אותה מערכת שגדלה פי 20?”

מהלך: הובילו לתובנה: אותה מערכת טכנית, החלטה שונה לגמרי לפי גודל הצוות וקנה המידה. 3 מפתחים על מונוליט קטן — מיקרוסרביסים יהיו overhead מיותר. 50 מפתחים שכל שינוי קטן דורש תיאום פריסה עם כולם — כאן מיקרוסרביסים פותרים בעיה ארגונית אמיתית.

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