מונוליט מול מיקרו-שירותים: באיזה מהם כדאי להתחיל בפועל?

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

מהו מונוליט, בדיוק?

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

מהם מיקרו-שירותים, בדיוק?

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

מונוליט מול מיקרו-שירותים במבט מהיר

אז באיזה מהם כדאי להתחיל בפועל?

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

מתי מיקרו-שירותים באמת משתלמים?

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