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

1. ניהול זהות

האתגר הראשון שניתקל בו כשנעבור ממערכת מונוליט למערכת Micro Services יהיה ניהול זהות של המשתמש. במונוליט משתמש מזוהה בדרך כלל באמצעות Cookie או Token אותו הוא שולח לשרת עם כל בקשה.

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

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

2. ניטור התמודדות עם תקלות

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

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

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

3. ניהול Logs

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

4. קושי בתחזוקה כשהצוות מתחלף

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

5. ניהול גירסאות

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

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

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