במסמך הזה מפורטים שיקולים וגישות נפוצות ומוכחות להעברת עומס העבודה לענן. המאמר הזה מרחיב על ההנחיות שבמאמר תכנון אסטרטגיה לארכיטקטורה היברידית ומרובת עננים, שבו מפורטים כמה שלבים אפשריים ומומלצים לתכנון אסטרטגיה לאימוץ ארכיטקטורה היברידית או מרובת עננים.
עדיפות לענן
דרך נפוצה להתחיל להשתמש בענן ציבורי היא גישת עדיפות לענן. בגישה הזו, אתם פורסים את עומסי העבודה החדשים בענן הציבורי, ועומסי העבודה הקיימים נשארים במקום שבו הם נמצאים. במקרה כזה, כדאי לשקול פריסה קלאסית בסביבת מחשוב פרטית רק אם פריסה בענן ציבורי בלתי אפשרית מסיבות טכניות או ארגוניות.
לאסטרטגיית עדיפות לענן יש יתרונות וחסרונות. היתרון הוא שהיא מתמקדת בעתיד. אתם יכולים לפרוס עומסי עבודה חדשים בצורה מודרנית, תוך הימנעות (או לפחות צמצום) מהטרחה של העברת עומסי עבודה קיימים.
גישה שעדיפותה לענן יכולה לספק יתרונות מסוימים, אבל היא עלולה להוביל להחמצת הזדמנויות לשיפור או לשימוש בעומסי עבודה קיימים. עומסי עבודה חדשים עשויים לייצג חלק קטן מהתמונה הכוללת של ה-IT, וההשפעה שלהם על הוצאות ה-IT והביצועים יכולה להיות מוגבלת. הקצאת זמן ומשאבים להעברת עומס עבודה קיים עשויה להניב יתרונות משמעותיים יותר או לחסוך בעלויות בהשוואה לניסיון להתאים עומס עבודה חדש לסביבת הענן.
גישה עם עדיפות לענן עלולה להגביר את המורכבות הכוללת של סביבת ה-IT. הגישה הזו עלולה ליצור כפילויות, להוביל לירידה בביצועים בגלל תקשורת מוגזמת בין הסביבות, או לגרום לסביבת מחשוב שלא מתאימה לעומס העבודה הספציפי. בנוסף, עמידה בתקנות בתעשייה ובחוקים להגנה על פרטיות הנתונים עשויה להגביל את האפשרות של ארגונים להעביר אפליקציות מסוימות שמכילות נתונים רגישים.
בהתחשב בסיכונים האלה, יכול להיות שעדיף להשתמש בגישת 'עדיפות לענן' רק לעומסי עבודה נבחרים. גישת 'עדיפות לענן' מאפשרת לכם להתמקד בעומסי העבודה שיכולים להפיק את התועלת המרבית מפריסה או מהעברה לענן. גישה זו מתייחסת גם למודרניזציה של עומסי עבודה קיימים.
דוגמה נפוצה לארכיטקטורה היברידית שמתמקדת בענן היא כשצריך לשלב אפליקציות ושירותים מדור קודם שמכילים נתונים קריטיים עם נתונים או אפליקציות חדשים. כדי להשלים את השילוב, אפשר להשתמש בארכיטקטורה היברידית שמבצעת מודרניזציה של שירותים מדור קודם באמצעות ממשקי API, וכך מאפשרת לשירותים ולאפליקציות חדשים בענן לצרוך אותם. עם פלטפורמה לניהול API בענן, כמו Apigee, אפשר ליישם תרחישי שימוש כאלה עם שינויים מינימליים באפליקציה, ולהוסיף אבטחה, ניתוח נתונים ומדרגיות לשירותים מדור קודם.
העברה ועדכון
מודרניזציה של IT וענן היברידי מרובה עננים הם מושגים שונים שמקושרים במעגל חיובי. שימוש בענן ציבורי יכול להקל על המודרניזציה של עומסי עבודה ב-IT. מודרניזציה של עומסי העבודה ב-IT יכולה לעזור לכם להפיק יותר מהענן.
היעדים העיקריים של מודרניזציה של עומסי עבודה הם:
- להשיג גמישות רבה יותר כדי שתוכלו להתאים את עצמכם לדרישות משתנות.
- להפחית את העלויות של התשתית והפעולות.
- שיפור האמינות והגמישות כדי למזער את הסיכון.
עם זאת, יכול להיות שלא יהיה אפשר לבצע מודרניזציה של כל האפליקציות בתהליך ההעברה בו-זמנית. כמו שמתואר במאמר העברה אל Google Cloud, אפשר להטמיע אחד מסוגי ההעברה הבאים, או אפילו לשלב בין כמה סוגים לפי הצורך:
- אירוח מחדש (חותכים ולוקחים)
- העברה לפלטפורמה אחרת (העברה ואופטימיזציה)
- ארגון מחדש (העברה ושיפור)
- שינוי הארכיטקטורה (המשך המודרניזציה)
- בנייה מחדש (הסרה והחלפה, לפעמים נקרא הסרה והחלפה)
- רכישה חוזרת
כשמקבלים החלטות אסטרטגיות לגבי ארכיטקטורות היברידיות וארכיטקטורות של ריבוי עננים, חשוב לבחון את היתכנות האסטרטגיה מנקודת מבט של עלות וזמן. כדאי לשקול גישה של העברה בשלבים, שמתחילה בשיטת lift-and-shift או בהעברה לפלטפורמה אחרת, וממשיכה בשינוי מבנה או בארכיטקטורה מחדש כשלב הבא. בדרך כלל, הרמה והעברה עוזרות לבצע אופטימיזציה של אפליקציות מנקודת מבט של תשתית. אחרי שהאפליקציות פועלות בענן, קל יותר להשתמש בשירותי ענן ולשלב אותם כדי לבצע אופטימיזציה נוספת באמצעות ארכיטקטורות ויכולות מבוססות-ענן. בנוסף, האפליקציות האלה עדיין יכולות לתקשר עם סביבות אחרות דרך חיבור רשת היברידי.
לדוגמה, אתם יכולים לשנות את המבנה או את הארכיטקטורה של אפליקציה גדולה ומונוליטית שמבוססת על מכונה וירטואלית, ולהפוך אותה לכמה מיקרו-שירותים עצמאיים שמבוססים על ארכיטקטורת מיקרו-שירותים בענן. בדוגמה הזו, ארכיטקטורת המיקרו-שירותים משתמשת בשירותי קונטיינרים מנוהלים כמו Google Kubernetes Engine (GKE) או Cloud Run. עם זאת, אם הארכיטקטורה או התשתית של אפליקציה לא נתמכות בסביבת הענן של היעד כמו שהן, כדאי לשקול להתחיל בשינוי פלטפורמה, בשינוי מבנה או בשינוי ארכיטקטורה של אסטרטגיית ההעברה כדי להתגבר על המגבלות האלה, אם אפשר. Google Cloud
כשמשתמשים באחת מגישות ההעברה האלה, מומלץ לשקול מודרניזציה של האפליקציות (אם הדבר רלוונטי ואפשרי). תהליך המודרניזציה עשוי לדרוש אימוץ ויישום של עקרונות ה-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.
בוחרים באפשרות 'אירוח מחדש (העברה כפי שהיא)' אם אחד מהתנאים הבאים מתקיים לגבי עומסי העבודה:
- יש להם מספר קטן יחסית של תלויות בסביבה שלהם.
- הם לא נחשבים ככאלה שכדאי לבצע בהם רפקטורינג, או שרפקטורינג לפני ההעברה לא אפשרי.
- הם מבוססים על תוכנה של צד שלישי.
כדאי לבצע רפקטורינג (העברה ושיפור) לסוגים הבאים של עומסי עבודה:
- יש להם תלויות שצריך לפתור.
- הם מסתמכים על מערכות הפעלה, חומרה או מערכות מסדי נתונים שלא ניתן להכניס לענן.
- הם לא משתמשים ביעילות במשאבי מחשוב או אחסון.
- אי אפשר לפרוס אותן באופן אוטומטי בלי השקעה מסוימת.
כדאי לשקול אם בנייה מחדש (הסרה והחלפה) עונה על הצרכים שלכם לסוגי עומסי העבודה הבאים:
- הם כבר לא עומדים בדרישות הנוכחיות.
- אפשר לשלב אותם עם אפליקציות אחרות שמספקות יכולות דומות בלי לפגוע בדרישות העסקיות.
- הם מבוססים על טכנולוגיה של צד שלישי שהגיעה לסוף מחזור החיים שלה.
- הם דורשים תשלום דמי רישיון לצד שלישי, וזה כבר לא משתלם.
במסגרת Rapid Migration Program מוסבר איך Google Cloud עוזר ללקוחות ליישם שיטות מומלצות, להפחית את הסיכון, לשלוט בעלויות ולפשט את הדרך להצלחה בענן.