על רגל אחת: Micro Services ולמה זה טוב לכם?

האסטרטגיה הטכנולוגית שמפרקת את המוצר לגורמים ומרכיבה אותו מחדש – Micro Services

shutterstock lego

מאת: ריק פרנץ, 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:

image2

באפליקציה של Amazon כל מרכיב פונקציונלי מייצג שירות נפרד וכל המרכיבים בונים יחד את הפונקציונליות הכוללת, שהיא האפליקציה וממשק המשתמש. שימו לב ש־Micro Service מספר 3 – "Basic Product Info" – מופיע בכמה מסכים ובמיקומים שונים באפליקציה. הוא איינו לא מתנהג כעמוד באפליקציה, אלא כרכיב פונקציונלי בתוך המערכת, הנשלף בעת הצורך.

image3

אותם רכיבים פונקציונליים, אפוא, יכולים לשמש להרכבת כמה אפליקציות ותרחישים, ללא צורך לכתוב אותם מחדש לשם הטמעה בכל אפליקציה ובכל טכנולוגיה (IOS, Web, Android או Tech Next).

מדוע שימוש ב־Micro Services נחשב לאסטרטגיה מוצלחת?

אחד הדברים הקשים ביותר לתחזוקה במערכות גדולות ומורכבות הוא שינוי. אם כל מרכיב במערכת, ולו הקטן ביותר, "מכיר" את החלקים האחרים (את מיקומם, את תפקידם ואת דרכי הקונפיגורציה שלהם) אזי התלות בין המרכיבים גבוהה. במקרה כזה, כאשר מבצעים שינוי כלשהו במערכת, יש לבצעו בכל אחד מהמרכיבים המושפעים ממנו. אם רוצים לבנות פונקציונליות שניתן לשנות ולהטמיע במהירות, כזו שמחיר הבעלות עליה משתלם ביחס לאורך החיים של האפליקציות שנבנות עליה – כדאי להימנע מאסטרטגיה כזו.
"הלקח העיקרי ש[אדריאן] קוקרופט למד בנטפליקס הוא שמהירות היא הקלף המנצח בשוק. אם נשאל אנשי פיתוח האם הם חושבים שתהליך פיתוח אטי הוא טוב יותר, איש לא יגיד לנו 'כן'. גם מנהלים ולקוחות לעולם לא יתלוננו ויגידו שתהליך הפיתוח מהיר מדי" (Micro services at Netflix: Lessons for Team and Process Design).

חמשת היתרונות של אסטרטגיית ה־Micro Services

  1. היא מאפשרת לצוותים רבים לעבוד באופן עצמאי ובמינימום תלות ביניהם (ומהר).
  2. ה־Time-to-Market של פונקציונליות מרכזיות בממשק הינו קצר יותר.
  3. שיפורים ותיקוני באגים יכולים להתרחש כל הזמן (אין צורך לחכות לשחרור גרסה גדולה ואפשר להגיב לצרכי המשתמשים מהר – תוך ימים או שבועות במקום חודשים, רבעונים או שנים).
  4. תוכנית הבדיקות מתכווצת (יש לבדוק אך ורק את החלקים שהשתנו, ולפיכך התחזוקה משתלמת יותר והוצאות הלקוח פוחתות).
  5. המרכיבים ניתנים לשימוש חוזר בבניית פונקציונליות משתמש חדשה (תרחישי משתמש חדשים ניתנים לבנייה בקלות ובמהירות, בלי יותר מדי קידוד, וההתנהגות לרוחב הממשק קבועה).

קצה הקרחון

מלבד כל אלו, אסטרטגיית ה־Micro Services מאפשרת להרחיב את אסטרטגיית ה־Hub באמצעות מינוף טכנולוגיית ענן אחרות כמו אלו שמספקות AWS, גוגל ומיקרוסופט. באופן כללי, השירותים שבהם משתמשים הלקוחות לא ישכנו יותר ב־Data Center יחיד. לפיכך יש צורך באסטרטגיה שתאפשר חיבוריות ופריסה המחזקת את היכולות שמספקים שירותי הענן ומרחיבה את חווית השימוש בהם. חשבו על תוכנות מייל, אנטי־ספאם, שירותי קבצים, ניהול קמפיינים, מערכות HR, מערכות כרטוס וכיוצא באלו. הלקוחות יבקשו מוצרים שמשתלבים בכל אלו ומרחיבים את היכולות והשירותים שניתנים להם דרכם.

חזון

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

בצד הטכני

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

קרדיט תמונה: lego via shutterstock

הכתבה בחסות Jive

העובד צריך להיות במרכז החשיבה. לכולנו יש רעיונות טובים ומוחות חריפים, אבל החיבור בין מגוון העובדים והמוחות בצורה חכמה, יעילה ובעלת משמעות – הוא הנוסחה להצלחה. Jive Software מתמחה בכך ומציעה פלטפורמה חברתית לשיפור התקשורת ושיתוף הפעולה בין העובדים והעלאת רמת הפרודקטיביות שלהם. המוצרים של Jive מתאימים לארגונים בכל הגדלים ומציעים מגוון פתרונות המאפשרים לעובדים בארגון לעבוד טוב יותר יחד: צ׳ט לקבוצות בארגון (במובייל ובדסקטופ), רשת חברתית ל-Employee Collaboration ו-Community Application עבור לקוחות .

כתב אורח

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

הגב

4 Comments on "על רגל אחת: Micro Services ולמה זה טוב לכם?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
Jako
Guest
הדוגמטיות בעולם התוכנה פשוט בלתי נתפסת. לגישת ה-microservices המוצעת יש גם חסרונות ברורים: 1. בזבוז משאבים בתקשורת בין השירותים – נדרש serialization/deserialization, שימוש מנופח בזכרון, מעבד ושאר משאבי חומרה אחרים לביצוע פעולה שהיתה יכולה להיות טריוואלית בארכיטקטורה מונוליתית. 2. בזבוז משאבים, או לחילופין הרעה בביצועים כתוצאה מכך שהשרותים מחזיקים cache נפרד. 3. בסיס הקוד הופך להיות קשה לתחזוקה כאשר כל קריאה עטופה בשכבות. 4. נדרשת הרבה פעמים מעורבות של אנשי ops כדי להגדיר סביבות. microservices היא לא "בשורה", אלא שיטה ישנה עם יתרונות וחסרונות, עלויות ותמורה. באופן כללי, מי שלא יודע לפתח מערכת מונוליתית, שלא יצפה שהמערכת ה"מודולרית" שלו תתפקד.… Read more »
אפוא
Guest

אפוא

Eli Safra
Guest

שני ההבדלים העקריים בין SOA לMicroServices הם:
1. SOA דוגלת בDRY (אל תחזור על עצמך) לעומת MicroServices שמקפידה על כך שכל אלמנט יהיה עצמאי גם במחיר של שכפול קוד או מידע

2. בSOA מישמים את מודל הטרנזקציות ACID לעומת זאת בMicroServices עובדים עם BASE

באנגלית זה נשמע יותר טוב:

•Different “sharing model”

•Service –share as much as you can
•Micro-service–share nothing
•Different Transaction model
•Service–Atomicity, Consistency, Isolation and Durability (ACID)
•Micro-service – Basic Availability, Soft state and Eventual consistency (BASE)

תיבי
Guest

כמה חרטות, כמה טרמינולוגיה מצוצה מהאצבע מחבורת "ארכיטקטים" משועממים שכל מאודם הוא להמציא עוד באז ולהביא עוד כניסות לבלוג המסריח שלהם ולקבל עוד "Endorsements" בפרופיל הלינקדין שלהם שיביאו אותם לאורגזמה היי-טקיסטית זמנית עד לבאז וורד חסר המשמעות הבא. בחיאת, כל מתכנת אמיתי (רמז, לא התכוונתי למתכנתי Angular או React) עם ראש ונסיון של 10 שנים ומעלה יודע, גם בלי הבאז החדש Micro Service, גם בשנות ה90 וגם בשנות ה2000 המוקדמות, לבנות מערכת שבנויה מחלקים שניתנים לשיתוף עתידי. DRY או WET, פשוט תגשו לזה בצורה הכי לוגית שהמוח שלכם מצליח לקלוט ותפסיקו לאכול כל חרטוט מהבלוג הזמני והחם של התקופה.

wpDiscuz

תגיות לכתבה: