אפשרות ראשונה: קיום מקבילי

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

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

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

מערכת המלצות מבוססות דמיון

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

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

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

1. אנו מתחילים במצב בו קיימת המערכת הישנה
2. כתיבת שלד לארכיטקטורה חדשה והזנת בסיס הנתונים החדש בסרטים
3. כתיבת פיצ'ר סרטים ראשון: "מצא סרטים נוספים עם אותם שחקנים"
4. כתיבת פיצ'ר סרטים שני: "מצא סרטים נוספים של אותו הבמאי"
5. הזנת בסיס הנתונים החדש בשירים מהמערכת הישנה וכתיבה מחדש של אחד הפיצ'רים הישנים: "מצא שירים נוספים מאותו הז'אנר"
6. כתיבת פיצ'ר סרטים/שירים: "מצא סרטים שפס הקול שלהם מכיל שיר מסויים"
7. כתיבה מחדש של אחד הפיצ'רים הישנים: "מצא שירים נוספים של אותם הזמרים"
8. כתיבה מחדש של פיצ'ר השירים השלישי: "מצא שירים נוספים מאותו מקום וזמן"
9. …לאחר שכל השירותים הועברו למערכת החדשה: הורדה של המערכת הישנה

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

יתרונות

• רמת השירות שלנו אינה יורדת כלל, לא ביכולות ולא ביציבות.
• הארכיטקטורה החדשה עוברת "טבילת אש" ותקופת ייצוב בצורה מסודרת, כיוון שלא תלויים בה פיצ'רים קריטיים (ישנים).
• המעבר של כל פיצ'ר למערכת החדשה נעשה בצורה מסודרת ונבדק היטב, ככל האפשר בפני עצמו וללא תלות בחלקים אחרים של המערכת.

חסרונות

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

מתי זה יתאים?

• כאשר פיצ'רים שונים של המערכת אינם תלויים באופן הדוק זה בזה.
• כאשר יש לנו התחייבות או צורך שלא לשנות את היכולת/יציבות של מערכת קיימת.
• כאשר יש לנו יכולת (משאבים, כח אדם) לתחזק ולהריץ את שתי המערכות במקביל.

 

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