במסמך הזה מפורטים שיקולים וגישות נפוצות ומוכחות להעברת עומס העבודה לענן. המאמר הזה מרחיב על ההנחיות במאמר עיצוב אסטרטגיה לארכיטקטורה היברידית ומרובת עננים, שבו מפורטים כמה שלבים אפשריים ומומלצים לעיצוב אסטרטגיה לאימוץ ארכיטקטורה היברידית או מרובת עננים.
עדיפות לענן
דרך נפוצה להתחיל להשתמש בענן הציבורי היא גישת עדיפות לענן. בגישה הזו, אתם פורסים את עומסי העבודה החדשים בענן הציבורי, ועומסי העבודה הקיימים נשארים במקום שבו הם נמצאים. במקרה כזה, כדאי לשקול פריסה קלאסית בסביבת מחשוב פרטית רק אם פריסה בענן ציבורי בלתי אפשרית מסיבות טכניות או ארגוניות.
לאסטרטגיה של עדיפות לענן יש יתרונות וחסרונות. היתרון הוא שהיא מתמקדת בעתיד. אתם יכולים לפרוס עומסי עבודה חדשים בצורה מודרנית, בלי הצורך להעביר עומסי עבודה קיימים (או לפחות לצמצם את הטרחה הכרוכה בכך).
לגישת עדיפות לענן יש יתרונות מסוימים, אבל היא עלולה לגרום להחמצת הזדמנויות לשיפור או לשימוש בעומסי עבודה קיימים. עומסי עבודה חדשים עשויים לייצג חלק קטן מהנוף הכולל של ה-IT, וההשפעה שלהם על הוצאות ה-IT והביצועים יכולה להיות מוגבלת. הקצאת זמן ומשאבים להעברת עומס עבודה קיים עשויה להניב יתרונות משמעותיים יותר או חיסכון בעלויות בהשוואה לניסיון להתאים עומס עבודה חדש לסביבת הענן.
בנוסף, אם תבחרו בגישה עדיפות לענן באופן קפדני, יכול להיות שהמורכבות הכוללת של סביבת ה-IT שלכם תגדל. הגישה הזו עלולה ליצור כפילויות, להוביל לירידה בביצועים בגלל תקשורת מוגזמת בין סביבות שונות, או לגרום לסביבת מחשוב שלא מתאימה לעומס העבודה הספציפי. בנוסף, עמידה בתקנות בתחום ובחוקים להגנה על פרטיות הנתונים עשויה להגביל את האפשרות של ארגונים להעביר אפליקציות מסוימות שמכילות נתונים רגישים.
בהתחשב בסיכונים האלה, יכול להיות שעדיף להשתמש בגישת עדיפות לענן רק עבור עומסי עבודה נבחרים. גישה שמתמקדת בענן מאפשרת לכם להתרכז בעומסי העבודה שיכולים להפיק את התועלת המרבית מפריסה או מהעברה לענן. הגישה הזו מתייחסת גם למודרניזציה של עומסי עבודה קיימים.
דוגמה נפוצה לארכיטקטורה היברידית עם עדיפות לענן היא כשצריך לשלב אפליקציות ושירותים מדור קודם שמכילים נתונים קריטיים עם נתונים או אפליקציות חדשים. כדי להשלים את השילוב, אפשר להשתמש בארכיטקטורה היברידית שמבצעת מודרניזציה של שירותים מדור קודם באמצעות ממשקי API, וכך מאפשרת לשירותים ולאפליקציות חדשים בענן לצרוך אותם. עם פלטפורמה לניהול API בענן, כמו Apigee, אפשר ליישם תרחישי שימוש כאלה עם שינויים מינימליים באפליקציה, ולהוסיף אבטחה, ניתוח נתונים ומדרגיות לשירותים מדור קודם.
העברה ועדכון
המושגים 'סביבה היברידית מרובת עננים' ו'מודרניזציה של IT' הם מושגים נפרדים, אבל הם קשורים זה לזה במעגל חיובי. השימוש בענן ציבורי יכול להקל על המודרניזציה של עומסי עבודה בתחום ה-IT. מודרניזציה של עומסי העבודה ב-IT יכולה לעזור לכם להפיק יותר מהענן.
היעדים העיקריים של מודרניזציה של עומסי עבודה הם:
- להשיג גמישות רבה יותר כדי שתוכלו להתאים את עצמכם לדרישות משתנות.
- להפחית את העלויות של התשתית והפעולות.
- שיפור האמינות והעמידות כדי למזער את הסיכון.
עם זאת, יכול להיות שלא יהיה אפשר לבצע מודרניזציה לכל האפליקציות בתהליך ההעברה בו-זמנית. כמו שמתואר במאמר בנושא מעבר אל Google Cloud, אפשר להטמיע אחד מסוגי ההעברה הבאים, או אפילו לשלב בין כמה סוגים לפי הצורך:
- אירוח מחדש (חותכים ולוקחים)
- העברה לפלטפורמה אחרת (העברה ואופטימיזציה)
- שינוי מבנה (העברה ושיפור)
- שינוי הארכיטקטורה (המשך המודרניזציה)
- בנייה מחדש (הסרה והחלפה, לפעמים נקראת הסרה והחלפה)
- רכישה חוזרת
כשמקבלים החלטות אסטרטגיות לגבי ארכיטקטורות היברידיות וארכיטקטורות של ריבוי עננים, חשוב לבחון את האפשרות ליישם את האסטרטגיה מנקודת מבט של עלות וזמן. כדאי לשקול גישה של מיגרציה בשלבים, שמתחילה בשיטת Lift-and-shift (העברה בלי שינויים) או בהעברה לפלטפורמה אחרת, וממשיכה בשלב הבא בארגון הקוד מחדש (Refactoring) או בארכיטקטורה מחדש. בדרך כלל, הרמה והעברה עוזרות לבצע אופטימיזציה של אפליקציות מנקודת מבט של התשתית. אחרי שהאפליקציות פועלות בענן, קל יותר להשתמש בשירותי ענן ולשלב אותם כדי לבצע אופטימיזציה נוספת באמצעות ארכיטקטורות ויכולות שמתאימות לענן. בנוסף, האפליקציות האלה עדיין יכולות לתקשר עם סביבות אחרות דרך חיבור רשת היברידי.
לדוגמה, אפשר לבצע רפקטורינג או שינוי בארכיטקטורה של אפליקציה גדולה ומונוליתית שמבוססת על מכונה וירטואלית, ולהפוך אותה לכמה מיקרו-שירותים עצמאיים שמבוססים על ארכיטקטורת מיקרו-שירותים בענן. בדוגמה הזו, ארכיטקטורת המיקרו-שירותים משתמשת בשירותי קונטיינרים מנוהלים כמו Google Kubernetes Engine (GKE) או Cloud Run. Google Cloud עם זאת, אם הארכיטקטורה או התשתית של אפליקציה לא נתמכות בסביבת הענן של היעד כמו שהן, כדאי לשקול להתחיל בשינוי פלטפורמה, בארגון הקוד מחדש (Refactoring) או בשינוי ארכיטקטורה של אסטרטגיית ההעברה כדי להתגבר על המגבלות האלה, אם אפשר.
כשמשתמשים באחת מגישות ההעברה האלה, מומלץ לשקול מודרניזציה של האפליקציות (אם רלוונטי ואפשרי). תהליך המודרניזציה עשוי לדרוש אימוץ ויישום של Site Reliability Engineering (SRE) או של עקרונות DevOps, כך שייתכן שתצטרכו להרחיב את המודרניזציה של האפליקציה גם לסביבה הפרטית שלכם בהגדרה היברידית. למרות שהטמעת עקרונות SRE כוללת הנדסה בבסיסה, היא יותר תהליך של שינוי מאשר אתגר טכני. לכן, סביר להניח שיידרשו שינויים בתהליכים ובתרבות. כדי לקבל מידע נוסף על השלב הראשון בהטמעת SRE בארגון, שהוא קבלת הסכמה מההנהלה, אפשר לעיין במאמר With SRE, failing to plan is planning to fail.
שילוב בין גישות שונות להעברה
לכל אחת מגישות ההעברה שמוצגות כאן יש חוזקות וחולשות מסוימות. יתרון מרכזי של אסטרטגיה היברידית ומרובת-עננים הוא שלא צריך להסתפק בגישה אחת. במקום זאת, אתם יכולים להחליט איזו גישה הכי מתאימה לכל עומס עבודה או לכל חבילת אפליקציות, כמו שמוצג בדיאגרמה הבאה.
תרשים קונספטואלי שממחיש את הנתיבים או הגישות השונים למיגרציה ולמודרניזציה שאפשר ליישם בו-זמנית בעומסי עבודה שונים, בהתאם לדרישות העסקיות והטכניות הייחודיות ולמטרות של כל עומס עבודה או אפליקציה.
בנוסף, לא צריך שרכיבים באותו מחסנית אפליקציות יפעלו לפי אותה גישה או אסטרטגיה להעברה. לדוגמה:
- אפשר להעביר את מסד הנתונים בקצה העורפי של אפליקציה, שמתארח ב-MySQL, אל מסד נתונים מנוהל באמצעות Cloud SQL ב- Google Cloud.
- אפשר לבצע רפקטורינג במכונות הווירטואליות של חזית האפליקציה כדי להריץ אותן בקונטיינרים באמצעות GKE Autopilot, שבו Google מנהלת את הגדרות האשכול, כולל הצמתים, שינוי הגודל, האבטחה והגדרות אחרות שהוגדרו מראש.
- אפשר להחליף את פתרון איזון העומסים בחומרה המקומית ואת היכולות של חומת האש של אפליקציית האינטרנט (WAF) ב-Cloud Load Balancing וב-Google Cloud Armor.
בוחרים באפשרות 'אירוח מחדש (העברה והפעלה)' אם אחד מהתנאים הבאים מתקיים לגבי עומסי העבודה:
- יש להם מספר קטן יחסית של תלויות בסביבה שלהם.
- הם לא נחשבים ככאלה שכדאי לבצע בהם ארגון הקוד מחדש (Refactoring), או שארגון הקוד מחדש (Refactoring) לפני ההעברה לא אפשרי.
- הם מבוססים על תוכנה של צד שלישי.
כדאי לשקול לבצע רפקטורינג (העברה ושיפור) לסוגים הבאים של עומסי עבודה:
- יש להם תלויות שצריך לפתור.
- הם מסתמכים על מערכות הפעלה, חומרה או מערכות מסדי נתונים שלא ניתן להכניס לענן.
- הם לא משתמשים ביעילות במשאבי מחשוב או אחסון.
- אי אפשר לפרוס אותן באופן אוטומטי בלי השקעה מסוימת.
כדאי לשקול אם בנייה מחדש (הסרה והחלפה) עונה על הצרכים שלכם לסוגי עומסי העבודה הבאים:
- הם כבר לא עומדים בדרישות הנוכחיות.
- אפשר לשלב אותם עם אפליקציות אחרות שמספקות יכולות דומות בלי לפגוע בדרישות העסקיות.
- הם מבוססים על טכנולוגיה של צד שלישי שהגיעה לסוף חיי המוצר.
- הם דורשים תשלום דמי רישיון לצד שלישי, וזה כבר לא משתלם.
במסגרת Rapid Migration Program מוסבר איך Google Cloud עוזרת ללקוחות ליישם שיטות מומלצות, להפחית את הסיכון, לשלוט בעלויות ולפשט את הדרך להצלחה בענן.