זהירות, עבודות בכביש: 7 אתגרים במעבר ל-Microservices
המעבר לפתרונות microservices כבר החל. האם יכול להיות שמחלקת הרכש היא שמכתיבה ארכיטקטורת תוכנה?
מקור: Pixabay
מאת אסף שלי
שירותי ענן עוברים מהפיכה אמיתית במעבר למודל מבוסס microservices. מדובר בשינוי בתשתיות, בשפות הפיתוח, ובניהול התוכנה. כמו בכל פרוייקט תוכנה, מימוש נכון מוביל לחסכון בעלויות ולקיצור בלוחות הזמנים. מימוש שגוי גורר הגדלת העלויות, ביצועים ירודים, וקושי בניהול תצורה. בעולם של microservices ההבדלים הם מאד משמעותיים וההפרש יכול להגיע עד למספר מכפלות.
רוב מערכות ה-microservices שאנו מוצאים היום מבוססות קונטיינרים של Docker. מדובר בעצם בסוג של SOA (Service Oriented Architecture) עם מספר מאפיינים יחודיים:
1. כל microservice הוא בעצם cluster של מספר שרתים ווירטואליים. המערכת תגדיל באופן אוטומטי את מספר העותקים של השירות לפי הצורך.
2. כל microservice מתנהג כמיני-מוצר עצמאי שמאחוריו צוות agile. עדכוני תוכנה נשלחים ללא צורך לקמפל מחדש את כל המוצר. יתרון נוסף הוא ש- microservices שונים יכולים להיות כתובים בשפות תכנות שונות, למשל python עבור אלגוריתמיקה, ו- java עבור תקשורת מול מערכות תשתית.
3. השירותים השונים מנוהלים בין מכונות וירטואליות באופן אופטימלי ובעזרת מערכת orchestration.
המעבר ל-microservices בגלל העלויות
העלויות של תוכנה בענן מבוססות על מודל של שימוש. ככל שצורכים יותר משאבים משלמים יותר. לרוב המוצרים בענן יש שעות עומס ושעות שפל. כדי להסביר את הבעיה נקח לדוגמה שרת של שיחות טלפון. בצהריים יש הרבה שיחות ובלילה מעט ולכן במהלך היום נדרשים הרבה עותקים של השרת ובלילה מעט. אם מדובר בשרת מונוליטי שמטפל גם בשיחות וגם בניהול התשלומים, אז כדי להכפיל את הרכיב שמטפל בשיחה אנחנו מכפילים גם את הרכיב שמנהל תשלומים וצורכים סתם משאבי ענן יקרים. בחלוקה ל- microservices יהיה רכיב נפרד לטיפול בשיחות והוא ישוכפל באופן אוטומטי כאשר יהיה עומס. הרכיב שמנהל תשלומים ישוכפל על בסיס העומס העצמי שלו. מדובר בחסכון משמעותי במשאבי ענן.
חשוב להדגיש שהמודל של microservices לא מביא איתו ארכיטקטורת תוכנה טובה יותר כמו שהביא תכנות מונחה עצמים (OOP). לא מדובר בשיפור ביצועים כמו המעבר למחשוב מקבילי או GPU, ולא מדובר בצורך לשפר זמינות ואמינות כמו במעבר לענן. המוטיבציה העיקרית למעבר ממונוליטי ל- microservices היא עלויות. לקוח סיפר לי שמבטיחים לו שבמעבר משרתי on-prem אל הענן יגיע לחסכון של 40% בהוצאות המחשוב. כשבחן ארגונים דומים שביצעו את המעבר גילה שהעלויות גדלו ב- 40% אם לא התבצע מימוש נכון של microservices.
קיימים כמה אתגרים עיקריים במעבר אל microservices
1. באז באז באז
כשמתחילים להכנס לתחום microservices מגלים שהתחום רווי במסרים שיווקיים שמשכנעים אותנו לעבור מ- Monolith אל Microservices. קל יחסית להבין מה לא צריך לעשות אבל קשה להבין מה צריך לעשות. יש הרבה מאד פתרונות חלקיים בניהם קוד פתוח לא מתוחזק או מוצרים ישנים שעברו הסבה חלקית, ולכל הפתרונות האלה יש סיפור יפה שלא באמת מסביר הרבה ברמה הטכנית. למשל הביטוי side-car מתייחס לרכיב קטן שמותקן על כל image של כל microservice, ליד שרת ה- web. הרכיב הקטן הזה הוא בעצם שרת web בפני עצמו שמבצע פענוח של REST API. בעצם במקום שרת אחד יש שניים שפועלים אחד אחרי השני.
2. DevOps
אנשי DevOps הם המומחים שמבינים את ההגדרות הפנימיות של המערכות ויודעים לכתוב את כל קובצי הקונפיגורציה ב-XML, YAML, ושאר צורות הטקסט המורכבות. הם גם מכירים כל מיני פתרונות שקיימים בשוק ואיך להתקין ולקנפג אותם. אנשי DevOps הם לא קוסמים והם לא יורדים מהשמיים עם מטריה. יש שאלות שהן שאלות ארכיטקטורת תוכנה שלא אנשי DevOps צריכים לענות עליהן. נתקלנו במקרה שבו אנשי DevOps בחרו בבסיס נתונים קסנדרה במקום מונגו DB והבעיה המערכתית התגלתה רק אחרי שהמערכת עלתה לאוויר.
3. Design Patterns
אין. למשל Stateless Services: כל בקשה שמגיעה לשירות יכולה להגיע לכל עותק שנמצא ב-Cluster. המשמעות היא שאי אפשר להחזיק מידע באיזה משתנה בזכרון אלא צריך לשמור אותו במקום מרכזי. איך לשמור? לא ברור. יש מידע שצריך להשמר בבסיס נתונים, יש מידע שצריך להישמר בזיכרון (על redis למשל), יש מידע ששייך למשתמש, יש מידע ששייך לשירות, וכד'. איך עושים singleton, איך עושים dispatcher ששולח הודעה למספר microservices? כל ארגון ממציא לעצמו.
4. סוגי מוצרים
האמת היא שאנחנו עוד לא שם. אפשר לשמוע כדוגמאות ל- microservices את נטפליקס ואת Wix באותו המשפט. מה שמטריד את נטפליקס הוא זמינות המערכת. מכיוון שמדובר בוידאו הם מוכנים להפסיד כמה פריימים רק כדי לשמור על רציפות השירות. לעומתם פתרון כמו Wix חייב לשמור על אמינות המידע, גם אם התשובה מגיעה באיחור של שלוש שניות. זה משמעותי מאד לארכיטקטורה של המערכת ולביטויים כמו Eventual Consistency.
5. לא כל דבר הוא microservice
בעולם של OOP כל דבר הוא אובייקט. יש מי שלקחו את המודל הזה (בעידוד קבלני משנה) ומפרקים תוכנה להרבה microservices. לא כל דבר הוא microservice. יש קוד קיים בשפת קובול שעובד. לא צריך לפרק להרבה חתיכות קטנות שכתובות ב-Javascript. יש הרבה סיבות להגדיר microservice, למשל מקום שבו משתמשים ב-thread-pool בפתרון מונוליטי מתאים להיות microservice. למשל חלק בתוכנה שנמצא בשימוש אינטנסיבי לפרקי זמן קצובים, כמו פתרונות תקשורת (שיחות טלפון, וידאו, אימיילים, וכד'), אנליטיקה שיכולה לקרות פעם ביום או פעם בשבוע, וכד'. מצד שני רכיבים שמתעדכנים באופן תכוף בשימוש ב- Continuous Integration גם יהפכו ל-microservice. יש סיבות נוספות אבל רוב המערכות הקיימות צריכות הסבה של 5% עד 20%. לא יותר מזה. בהרבה מקרים ההתעקשות להסב את כל המוצר תהרוג את הפרוייקט עוד לפני שהחל.
6. ניהול תוכנה
כל עולם microservices נולד מהתשתיות כלפי מעלה ומונע קדימה על ידי צוותי DevOps. ברמת תשתית microservices הוא פתרון מדהים. ברמת ניהול התוכנה, קצת פחות. למשל אין הגדרה של Interface. כל מתכנת כותב בקוד את המימוש של הפונקציות ואת הקריאות לפונקציות וברוב המקרים אין שימוש אמיתי בכלי YAML. נוצר מצב שמסמך ארכיטקטורה הוא המלצה שלא ניתנת לאכיפה, בעיקר בסביבה שבה יש מספר שפות פיתוח. במצב הקיים יש צורך בעבודת ניהול ידנית.
7. ניהול מוצר
תארו לעצמכם אפליקציה שמאפשרת לבצע תשלום באינטרנט. אם לחצנו על לחצן ולא התבצע תשלום, נלך אל המתכנת ונשב איתו עד שהוא יעבור על כל תהליך התשלום וימצא את הבעיה. בעולם של microservices, כל צוות אחראי על microservice עצמאי. בשביל להבין מה קרה בתוכנה צריך לטייל בין מספר צוותים שכל אחד מהם עובד על מודול אחד במערכת, יתכן שאפילו ללא הכרות עם שפת התכנות שבה נכתב המודול הבא. בסביבה כזאת צריך מאד להתאמץ אם רוצים לוודא פרטיות של משתמש ואבטחת מידע.
אין פה כוונה לומר שלא צריך microservices, להיפך. ככל הנראה שם נמצא העתיד של עולם התוכנה. צריך רק להיכנס מפוכחים, להתחיל עם דרישות ארכיטקטורה נכונות, להסב רק את מה שנותן החזר השקעה, ולא לצפות מאנשי DevOps לפתור את כל הבעיות של המוצר וארכיטקטורת התוכנה. הם יכולים לעזור רק איפה שהם יכולים לעזור.
הכותב הינו יזם טכנולוגי, ושותף-מייסד בחברת owrita
כתב אורח
אנחנו מארחים מפעם לפעם כותבים טכנולוגים אורחים, המפרסמים כתבות בתחומי התמחות שלהם. במידה ואתם מעוניינים לפרסם פוסט בשמכם, פנו אלינו באמצעות טופס יצירת קשר באתר.
הגב
6 תגובות על "זהירות, עבודות בכביש: 7 אתגרים במעבר ל-Microservices"
* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.
כתיבה נכונה ומדויקת! תודה רבה!
אמת
סוף סוף מישהו שאומר את האמת !
לפעמים אני תוהה אם אתם קוראים את הכתבות לפני שאתם מפרסמים אותן
עוד בנושא: