שלום, הבר! אני מציג לתשומת לבך תרגום המאמר של המחבר .
בתקופה שבה עולם ה-IT הולך בהדרגה לעבר מיקרו-שירותים וכלים כמו Kubernetes, רק בעיה אחת הופכת יותר ויותר בולטת. הבעיה הזו - גרסאות מיקרו-שירות. ובכל זאת, קהילת ה-IT מאמינה שהמצב הנוכחי הרבה יותר טוב מזה דור קודם של טכנולוגיות. עם זאת, ניהול גרסאות של שירותי מיקרו היא בעיה מורכבת מאוד. הוכחה אחת לכך יכולה להיות מאמרים כמו .
אם אתה עדיין לא מבין את הבעיה בקריאת הטקסט הזה, תן לי להסביר. נניח שהמוצר שלך מורכב מ-10 מיקרו-שירותים. כעת נניח שגרסה חדשה אחת משוחררת עבור כל אחד משירותי המיקרו הללו. רק גרסה אחת - אני מקווה שכולנו יכולים להסכים שזו עובדה מאוד טריוויאלית וחסרת משמעות. אולם כעת, בואו נסתכל שוב על המוצר שלנו. עם גרסה חדשה אחת בלבד של כל רכיב, יש לנו כעת 1^1 - או 2 תמורות של איך המוצר שלנו יכול להיות מורכב.
אם עדיין יש אי הבנה כלשהי, הרשו לי לפרק את המתמטיקה. אז יש לנו 10 מיקרו-שירותים, כל אחד מקבל עדכון אחד. כלומר, אנחנו מקבלים 2 גרסאות אפשריות לכל מיקרו-שירות (ישנה או חדשה). כעת, עבור כל אחד ממרכיבי המוצר, אנו יכולים להשתמש בכל אחת משתי הגרסאות הללו. מבחינה מתמטית, זה אותו דבר כאילו היה לנו מספר בינארי של 10 ספרות. לדוגמה, נניח ש-1 היא הגרסה החדשה, ו-0 היא הגרסה הישנה - אז ניתן לסמן תמורה אפשרית אחת כ-1001000000 - כאשר הרכיבים ה-1 וה-4 מתעדכנים, וכל השאר לא. מהמתמטיקה אנו יודעים שלמספר בינארי בן 10 ספרות יכולים להיות 2^10 או 1024 ערכים. כלומר, אישרנו את קנה המידה של המספר שאנו עוסקים בו.
בואו נמשיך את ההגיון שלנו - מה יקרה אם יהיו לנו 100 מיקרו-שירותים ולכל אחד יהיו 10 גרסאות אפשריות? כל המצב הופך לא נעים למדי - יש לנו כעת 10^100 תמורות - שזה מספר עצום. עם זאת, אני מעדיף לתייג את המצב הזה כך, כי עכשיו אנחנו כבר לא מסתתרים מאחורי מילים כמו "kubernetes", אלא מתמודדים עם הבעיה כפי שהיא.
למה אני כל כך מוקסם מהבעיה הזו? חלקית בגלל שעבדנו בעבר בעולם ה-NLP וה-AI, דנו הרבה בבעיית ההתפוצצות הקומבינאטורית לפני כ-5-6 שנים. רק שבמקום גרסאות היו לנו מילים בודדות, ובמקום מוצרים היו לנו משפטים ופסקאות. ולמרות שבעיות ה-NLP וה-AI נותרו ברובן בלתי פתורות, יש להודות שנעשתה התקדמות משמעותית במהלך השנים האחרונות (לדעתי, אפשר להתקדםоעדיף היה שאנשים בתעשייה יקדישו קצת פחות תשומת לב ללמידת מכונה וקצת יותר לטכניקות אחרות - אבל זה כבר מחוץ לנושא).
בואו נחזור לעולם של DevOps ושירותי המיקרו. אנו מתמודדים עם בעיה ענקית, מתחזה לפיל בקונסטקאמרה - כי מה שאני שומע לעתים קרובות הוא "רק קח kubernetes והגה, והכל יהיה בסדר!" אבל לא, הכל לא יהיה בסדר אם הכל יישאר כמו שהוא. יתרה מכך, פתרון אנליטי לבעיה זו אינו נראה מקובל בשל מורכבותו. כמו ב-NLP, ראשית עלינו לגשת לבעיה זו על ידי צמצום היקף החיפוש - במקרה זה, על ידי ביטול תמורות מיושנות.
אחד הדברים שעשויים לעזור זה משהו שכתבתי בשנה שעברה . חשוב גם לציין שתהליך CI/CD מתוכנן היטב עוזר מאוד בהפחתת וריאציות. עם זאת, מצב העניינים הנוכחי עם CI/CD אינו טוב מספיק כדי לפתור את בעיית התמורות ללא כלים נוספים לרכיבי חשבונאות ומעקב.
מה שאנחנו צריכים זה מערכת ניסויים בשלב האינטגרציה, שבה נוכל לקבוע את גורם הסיכון לכל רכיב, וגם לקיים תהליך אוטומטי לעדכון רכיבים שונים ובדיקות ללא התערבות מפעיל – לראות מה עובד ומה לא.
מערכת ניסויים כזו יכולה להיראות כך:
- מפתחים כותבים מבחנים (זה שלב קריטי - כי אחרת אין לנו קריטריון הערכה - זה כמו תיוג נתונים בלמידת מכונה).
- כל רכיב (פרויקט) מקבל מערכת CI משלו - תהליך זה מפותח כעת היטב, ונושא יצירת מערכת CI עבור רכיב בודד נפתרה במידה רבה
- "מערכת האינטגרציה החכמה" אוספת את תוצאות מערכות ה-CI השונות ומרכיבה פרויקטים של רכיבים למוצר הסופי, מפעילה בדיקות ולבסוף מחשבת את הדרך הקצרה ביותר להשגת פונקציונליות המוצר הרצויה בהתבסס על רכיבים קיימים וגורמי סיכון. אם עדכון אינו אפשרי, מערכת זו מודיעה למפתחים על הרכיבים הקיימים ומי מהם גורם לשגיאה. שוב, למערכת הבדיקות יש כאן חשיבות קריטית – שכן מערכת האינטגרציה משתמשת במבחנים כקריטריון הערכה.
- מערכת CD, אשר לאחר מכן מקבלת נתונים ממערכת האינטגרציה החכמה ומבצעת את העדכון ישירות. שלב זה מסיים את המחזור.
לסיכום, עבורי אחת הבעיות הגדולות ביותר כעת היא היעדר "מערכת אינטגרציה חכמה" כזו שתקשר את הרכיבים השונים למוצר ובכך תאפשר לך לעקוב אחר אופן הרכבת המוצר בכללותו. אני אהיה מעוניין במחשבות הקהילה על זה (ספוילר - אני כרגע עובד על פרויקט , שיכולה להפוך למערכת אינטגרציה חכמה כל כך).
דבר אחרון שאני רוצה להזכיר הוא שבעיני, מונוליט אינו מקובל עבור כל פרויקט אפילו בגודל בינוני. עבורי, ניסיונות לזרז את זמן היישום ואיכות הפיתוח על ידי חזרה למונוליט גורמים לספקנות רבה. ראשית, למונוליט יש בעיה דומה של ניהול רכיבים - בין הספריות השונות שהוא מורכב מהן, עם זאת, כל זה לא כל כך בולט ומתבטא בעיקר בזמן שהמפתחים מבלים. התוצאה של בעיית המונוליט היא חוסר האפשרות הוירטואלית לבצע שינויים בקוד - ומהירות פיתוח איטית במיוחד.
שירותי מיקרו משפרים את המצב, אבל אז ארכיטקטורת המיקרו-שירותים מתמודדת עם הבעיה של פיצוץ קומבינטורי בשלב האינטגרציה. כן, באופן כללי, העברנו את אותה בעיה משלב הפיתוח לשלב האינטגרציה. עם זאת, לדעתי גישת המיקרו-שירותים עדיין מביאה לתוצאות טובות יותר, וצוותים משיגים תוצאות מהר יותר (כנראה בעיקר בגלל הקטנת גודל יחידת הפיתוח - או גודל אצווה). עם זאת, המעבר ממונוליט למיקרו-שירותים עדיין לא שיפר את התהליך מספיק - הפיצוץ הקומבינטורי של גרסאות המיקרו-שירותים הוא בעיה עצומה, ויש לנו פוטנציאל רב לשפר את המצב תוך כדי פתרון.
מקור: www.habr.com