בדיקות והבטחת איכותMenu

כיצד ניתן "לעשות סדר" ביישומים מונוליטים ולעבור לארכיטקטורת MicroService?

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

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

השיטה הזאת היא ההפך הגמור מתפיסת הDevOps וה-פריסה הרציפה (Continuous Delivery) מאחר וכל שינוי דורש תיאום בין הפונקציות השונות והתלויות הפונקציונאליות ותלויות הקוד הופכות להיות הדוקות יותר ויותר ופועל היוצא מכך שניהול השינויים הופך להיות כואב בכל פעם מחדש מאחר והם הופכים להיות שבירים באופן תדיר.

אז  איך בעצם ארכיטקטורת microservice משפרת את תהליכי מחזור שילוח (Continuous Delivery) ?

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

החברות המובילות  היום בשוק שיישמו את תפיסת microservices הינם Netflix וAmazon .

הם החליטו שבמקום לבנות יישום מונוליטי אחד שמטפל בכל היבטי השירות שלהם הם יבנו יחידות שירותים קטנים שממשים פונקציות עסקיות בודדות והגבולות בין היחידות אלה הם ה APIs פונקציונלים החושפים את יכולות הליבה של כל שירות, למשל עבור Amazon הם יצרו יחידות שירות שונות כגון : עגלת קניות, חשבוניות, ניהול מלאי ועוד , כאשר כל יחידה עצמאית עם ממשק שמוגדר שמתממשק ליתר השירותים, היתרון הבולט בשיטה שכל יחידה מנוהלת ע"י צוות קטן שאחראי על היבט השירות שהוא מייצא ליישום, האחריות הינה משלב הקוד, בדיקת כשלים, טיפול, אריזה ופריסה לייצור ,בצורה מהירה ואג'ילית ובתפיסת ה DevOps משלב הקוד לפריסה ועד מעבר לייצור וייחצון השירות שמאפשר לפרוס יחידות קטנות בצורה רציפה ואמינה. מיותר לציין שקלה יותר לניהול.

אז למה הDocker  הוא כזה מתאים Microservices?

Docker הוא רכיב מצוין ליישום microservice  , מאחר והוא יכול לבודד שירות או תהליך  אחד במכולה (containers) , אריזה של מכולה (container) אחד שמכילה שירות עסקי או תהליך קלה ליישום , לניהול ולעדכון, אך אין זה מפתיע שעם ריבוי השימוש בdocker הביא את הצורך בכלים שיודעים לנהל תרחישים מורכבים יותר כגון: כיצד לנהל שירות יחיד באשכול שירותים?, או מספר מופעים של אותו שירות בין השרתים המארחים, או כיצד ניתן לתאם בין מספר רב של שירותים ברמת הפריסה והניהול?

באמצעות ה Kubernets (כלי open source של google) ניתן לנהל ולפרוס מכולות של Docker מרובות מאותו סוג באמצעות מערכת תיוג (Tag) אינטליגנטית, יש צורך לתאר את המאפיינים של השרת והשירות כגון: מעבד, זיכון, מספר מופעים ועוד ... וה kubernets יקצה את המשאבים הזמינים ביותר התואמים את המאפיינים מבלי שנצטרך לדאוג איפה אלה נמצאים פיסית, שכן מערכת התיוג מאפרת לראות את התמונה הברורה של המשאבים הקיימים והזמינים בצורה דינמית. ניתן לייצג רמה נוספת של קיבוץ "Pod" , קיבוץ זה מאפשר לקבץ משאבים שמתוייגים בתג אחד או יותר.

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

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

 

 

                              

 

מחברת המאמר: סנדרין קאלק, DevOps& Innovation Unit Business Manager, נס  


 

עוד בנושא...

עוד פרסומים בנושא אשר עשויים לעניין אותך