שירותים זעירים – שינוי גדול

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

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

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

shutterstock

כמו להוסיף לבנה של לגו

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

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

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

shutterstock

5 טיפים לשימוש יעיל יותר ב- Microservices

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

1. ארזו את האפליקציה בקונטיינטר. מה קורה כשרוצים לקחת Microservice מסביבת פיתוח לבדיקות ואז לייצור? זה לא בהכרח יעבוד חלק בגלל בעיות תאימות. "זה כמו לבוא עם מתכון של עוגה למטבח שאתה לא מכיר. אתה לא יודע אם המוצרים במקרר זהים", מסביר לב אנדלמן, CTO ב-TeraSky של  Cloudו-Devops. אז לפעמים העוגה תצא דומה, לפעמים פחות טעימה ולפעמים היא תישרף". כאן נכנסים לתמונה הקונטיינרים. אם נמשיך את אנלוגיית העוגה של אנדלמן, הקונטיינר מכיל את אוכל מבושל שצריך רק לחמם ולהגיש. ואם נחזור לנמשל, כי נהיינו כבר רעבים, הקונטיינר כולל דברים כמו הקוד עצמו, קבצי הגדרות, והתלות במערכת ההפעלה (ספריות עבודה, API וכדומה). כך אפשר לנייד את הקונטיינר בין הסביבות השונות, ולהוציא אותו מהן חזרה במקרה שצריך עדכון או תיקון.

2. השתמשו באוטומציה. ״אריזה של קוד לקונטיינטר זה תהליך פשוט, אבל לעשות את זה באופן יעיל ובטוח זה קצת יותר מאתגר, ובמיוחד שהחלק הזה לרוב נופל על הפיתוח, שאין להם ידע עניין ורצון לתחזק את זה, מפתחים רוצים לפתח, לא לתחזק קונטיינרים״, מסביר קובי שממה, מנהל מכירות ב-VMware Tanzu, שמלווה חברות בתהליך הזה, ״צריך להבין איך מתחזקים בייס-אימג', שהוא רכיב חשוב בקונטיינר, בונים שכבות יעילות ויודעים לטפל בעדכונים שמתגלים כבעיתיים. יש צורך במענה אוטומטי שלוקח את קוד המקור של המפתח, ובונה ממנו קונטיינר מאובטח ויעיל, ומתעדכן בצורה מתמשכת על כל שינוי שהמפתח עושה. אפשר לעשות את זה באמצעות טכנולוגיות כמו Tanzu Build Service״.

3. דאגו לאבטחה וגיבויים. טכנולוגיות חדשות מביאות הרבה יתרונות ויכולות. עם זאת, לא מעט פעמים בטכנולוגיות כאלה לא תמיד דואגים לפרקטיקות הוותיקות, כמו למשל גיבויים ואבטחת מידע. חברות אנטרפרייז וארגונים ותיקים, בין השאר בתחום הרפואה והפיננסיים, מחויבים ברגולציה ולכן מראש מחפשים טכנולוגיות שתומכות בדרישות האלה. סטארט-אפים, לעומתן, הם בדרך כלל המאמצים המוקדמים של הטכנולוגיה. הם לא בהכרח כפופים לאותן רגולציות ולכן ירוצו להטמיע את הטכנולוגיות החדשות, ובפועל יסכנו את המידע ששמור אצלן. ״חשוב לזכור״, אומר שממה, ״שאף אחד לא ביטל את הצורך בגיבויים, באבטחת מידע, או בצורך לנטר את כל הרכיבים של הסביבה, רק בגלל שהתוכנה שלנו רצה על פלטפורמה חדשה בשם Kubernetes. צריך להבין את ההבדלים, בהקשרים האלה, בין מערכות ישנות (Legacy) למערכות מבוססות קונטיינרים של Kubernetes ואז לפעול בהתאם עם הכלים הנכונים והגישות המתאימות״.

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

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