מאת: ריק פרנץ, VP Engineering at Jive Software.
מי שחי ועובד בתעשיית ההיי-טק ודאי שמע בשנתיים־שלוש האחרונות את המושג Micro Services. בשביל חלק מהקוראים מדובר בחדשות ישנות, אולם חלקנו טרם הפנמנו את הבשורה. חשוב שנבין מהם העקרונות שגורמים לנו לשנות את ארכיטקטורת המוצר שלנו ולהתאימה לאסטרטגיית ה־Micro Services, וכיצד מומלץ ליישם את עקרונות האסטרטגיה.
מהו Micro Service?
"המושג Micro Services מייצג סגנון של ארכיטקטורת תוכנה בו אפליקציות מורכבות בנויות מיחידות קטנות ועצמאיות המתקשרות ביניהן באמצעות language-agnostic APIs. השירותים קטנים, נבדלים זה מזה ומיועדים לביצוע משימות מוגדרות ומצומצמות" (ויקיפדיה)
לא מדובר, אפוא, בטכנולוגיה חדשה כי אם באסטרטגיית תכנון מוצר. לאסטרטגיה זו השלכות טכניות, אולם את אלו נשאיר לכתבה אחרת. עם זאת, ישנם חוקים באשר לסגמנטציה הפונקציונלית של ה־Micro Services, ובאשר למה שצריך ולא צריך לעשות בהם.
יצירה של Micro Services מתחילה בחלוקה או בפירוק של פונקציונליות ששימשה באופן מסורתי לניהול תהליכים גדולים ומורכבים. הסגמנטציה יוצרת מרכיבים אטומיים המבצעים משימות קטנות וייעודיות. המרכיבים הקטנים נאספים יחד לממשק משתמש אחד, API או שכבת Orchestration ומשלימים יחד משימה עסקית אחת (רישום הזמנה, למשל). ההקפדה על החלוקה בין הפונקציות השונות היא לב האסטרטגיה. אין זה אומר שאי אפשר "לערבב" את הפונקציות השונות בממשק המשתמש ולהפכו לאינטואיטיבי, פשוט ויפה יותר, אולם ההפרדה הלוגית בין השירותים היא שחשובה. העיקרון הבסיסי, אפוא, הוא שיוך של אחריות פונקציונלית מינימלית ונפרדת לכל מרכיב בתוך המנגנון השלם. ראו, למשל, את אפליקציית המובייל של Amazon, המורכבת מאוסף של Micro Services:
באפליקציה של Amazon כל מרכיב פונקציונלי מייצג שירות נפרד וכל המרכיבים בונים יחד את הפונקציונליות הכוללת, שהיא האפליקציה וממשק המשתמש. שימו לב ש־Micro Service מספר 3 – "Basic Product Info" – מופיע בכמה מסכים ובמיקומים שונים באפליקציה. הוא איינו לא מתנהג כעמוד באפליקציה, אלא כרכיב פונקציונלי בתוך המערכת, הנשלף בעת הצורך.
אותם רכיבים פונקציונליים, אפוא, יכולים לשמש להרכבת כמה אפליקציות ותרחישים, ללא צורך לכתוב אותם מחדש לשם הטמעה בכל אפליקציה ובכל טכנולוגיה (IOS, Web, Android או Tech Next).
מדוע שימוש ב־Micro Services נחשב לאסטרטגיה מוצלחת?
אחד הדברים הקשים ביותר לתחזוקה במערכות גדולות ומורכבות הוא שינוי. אם כל מרכיב במערכת, ולו הקטן ביותר, "מכיר" את החלקים האחרים (את מיקומם, את תפקידם ואת דרכי הקונפיגורציה שלהם) אזי התלות בין המרכיבים גבוהה. במקרה כזה, כאשר מבצעים שינוי כלשהו במערכת, יש לבצעו בכל אחד מהמרכיבים המושפעים ממנו. אם רוצים לבנות פונקציונליות שניתן לשנות ולהטמיע במהירות, כזו שמחיר הבעלות עליה משתלם ביחס לאורך החיים של האפליקציות שנבנות עליה – כדאי להימנע מאסטרטגיה כזו.
"הלקח העיקרי ש[אדריאן] קוקרופט למד בנטפליקס הוא שמהירות היא הקלף המנצח בשוק. אם נשאל אנשי פיתוח האם הם חושבים שתהליך פיתוח אטי הוא טוב יותר, איש לא יגיד לנו 'כן'. גם מנהלים ולקוחות לעולם לא יתלוננו ויגידו שתהליך הפיתוח מהיר מדי" (Micro services at Netflix: Lessons for Team and Process Design).
חמשת היתרונות של אסטרטגיית ה־Micro Services
- היא מאפשרת לצוותים רבים לעבוד באופן עצמאי ובמינימום תלות ביניהם (ומהר).
- ה־Time-to-Market של פונקציונליות מרכזיות בממשק הינו קצר יותר.
- שיפורים ותיקוני באגים יכולים להתרחש כל הזמן (אין צורך לחכות לשחרור גרסה גדולה ואפשר להגיב לצרכי המשתמשים מהר – תוך ימים או שבועות במקום חודשים, רבעונים או שנים).
- תוכנית הבדיקות מתכווצת (יש לבדוק אך ורק את החלקים שהשתנו, ולפיכך התחזוקה משתלמת יותר והוצאות הלקוח פוחתות).
- המרכיבים ניתנים לשימוש חוזר בבניית פונקציונליות משתמש חדשה (תרחישי משתמש חדשים ניתנים לבנייה בקלות ובמהירות, בלי יותר מדי קידוד, וההתנהגות לרוחב הממשק קבועה).
קצה הקרחון
מלבד כל אלו, אסטרטגיית ה־Micro Services מאפשרת להרחיב את אסטרטגיית ה־Hub באמצעות מינוף טכנולוגיית ענן אחרות כמו אלו שמספקות AWS, גוגל ומיקרוסופט. באופן כללי, השירותים שבהם משתמשים הלקוחות לא ישכנו יותר ב־Data Center יחיד. לפיכך יש צורך באסטרטגיה שתאפשר חיבוריות ופריסה המחזקת את היכולות שמספקים שירותי הענן ומרחיבה את חווית השימוש בהם. חשבו על תוכנות מייל, אנטי־ספאם, שירותי קבצים, ניהול קמפיינים, מערכות HR, מערכות כרטוס וכיוצא באלו. הלקוחות יבקשו מוצרים שמשתלבים בכל אלו ומרחיבים את היכולות והשירותים שניתנים להם דרכם.
חזון
כשנסיים לארגן מחדש את המוצר שלנו (לא נוכל לעשות זאת בבת אחת) לפי העקרונות החדשים, נוכל לעדכן את השירותים השונים, לתקן באגים ולשפר את הפונקציונליות של המוצר מדי שבוע. נוכל ליצור "קהילת מיניונים" של Micro Services ולהשתמש בדרישות הלקוחות כדי לפתח מוצר במהירות תנועת העננים (מתישהו היה צריך להשתמש במטפורה הזו).
בצד הטכני
סוף-סןף אנחנו צועדים אל עבר השינוי: מאפשרים למפתחים, לצוותי ה־Professional Services ולשותפים להרחיב את המוצר באמצעות Micro Services. בעתיד הלא רחוק תתקיים גמישות שתאפשר לנו להטמיע Micro Services ב־Data Center שלנו או בענן ציבורי, בהתאם לצרכים העסקיים.
קרדיט תמונה: lego via shutterstock