מיקרוסרביסים מול מונוליט - מה באמת עדיף¶

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

קודם כל - מה זה בכלל שני אלה¶

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

מיקרוסרביסים (microservices) זה גישה שבה כל תחום עסקי הופך לשירות עצמאי משלו - שירות משתמשים, שירות תשלומים, שירות התראות - שכל אחד רץ בנפרד, נבנה בנפרד, ולפעמים אפילו נכתב בשפת תכנות שונה. הם מתקשרים ביניהם דרך רשת, בדרך כלל עם קריאות API או הודעות.

היתרונות האמיתיים של מונוליט¶

מונוליט הוא לא "השיטה הישנה והמיושנת". הוא הבחירה הנכונה לרוב הפרויקטים, במיוחד בהתחלה, ויש לזה סיבות טובות:

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

מתי מונוליט הופך לבעיה¶

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

היתרונות האמיתיים של מיקרוסרביסים¶

כשהבעיות האלה אמיתיות, מיקרוסרביסים פותרים אותן בצורה אלגנטית:

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

והמחיר האמיתי שאף אחד לא מספר לכם עליו¶

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

תקשורת ברשת היא לא בחינם. קריאה בין שירותים יכולה להיכשל, להיות איטית, או להגיע בסדר לא צפוי. פתאום צריך להתמודד עם עולם שלם של תקלות שבמונוליט פשוט לא היו קיימות.
עקביות נתונים הופכת לכאב ראש. אין עוד עסקה אחת שמכסה את כל השינויים. צריך פתרונות כמו saga pattern, ולפעמים לחיות עם עקביות סופית (eventual consistency).
דיבוג מבוזר קשה פי כמה. כשבקשה עוברת דרך שבעה שירותים, למצוא איפה בדיוק היא נכשלה דורש תשתית ניטור ומעקב רצינית שצריך לבנות ולתחזק.
תקורה תפעולית ענקית. יש עכשיו עשרות שירותים לפרוס, לנטר, לאבטח ולתחזק במקום אחד.

אז איך בוחרים נכון¶

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

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

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

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

לסיכום¶

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