מתי לעבור ממונוליט למיקרוסרביסים

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

הסימן הראשון - כאב פריסה אמיתי וחוזר

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

הסימן השני - חלק אחד צריך קנה מידה שונה לגמרי

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

הסימן השלישי - צוותים דורכים אחד על השני

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

הסימן הרביעי - יש גבול עסקי ברור וטבעי

הפיצול הכי בריא קורה כשיש גבול עסקי ברור (bounded context, מושג מרכזי ב-Domain Driven Design) בין חלקי המערכת - למשל, ניהול משתמשים לעומת עיבוד תשלומים לעומת שליחת התראות. אם אתם לא מצליחים לצייר גבול כזה בבירור, זה סימן שהמונוליט עדיין לא "בשל" לפיצול, ופיצול בשלב הזה יגרור גבולות שרירותיים שידרשו הרבה תקשורת מיותרת בין שירותים.

איך מבצעים את המעבר בפועל

ברגע שזיהיתם כמה מהסימנים האלה יחד, לא מדובר בפיצול הכל בבת אחת. הגישה הבטוחה נקראת strangler fig pattern - "תבנית התאנה החונקת", על שם הצמח שגדל סביב עץ קיים ובהדרגה מחליף אותו. בפועל זה אומר:

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

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

הטעות שכדאי להימנע ממנה

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

לסיכום

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

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

מתלבטים אם הגיע הרגע לפצל את המערכת שלכם? הצטרפו לקהילה בדיסקורד ותביאו את הפרטים הספציפיים.