סקירה כללית על מיגרציה ומודרניזציה

בדף הזה מופיעה סקירה כללית של המוצרים, המתודולוגיות והמסלולים הטכניים שזמינים להעברת עומסי עבודה ל- Google Cloudולמודרניזציה של אפליקציות ומערכות מחשב מרכזי.

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

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

בחירת מסלול העברה ומודרניזציה

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

העברת עומסי עבודה (workloads)

אתם יכולים להשתמש במשאבים הבאים כדי להעביר מכונות וירטואליות, מסדי נתונים רלציוניים, קונטיינרים או מאגרי אובייקטים ממרכזי נתונים מקומיים או מספקי שירותי ענן של צד שלישי, כולל AWS או Azure, אל Google Cloud:

מודרניזציה של אפליקציות

אתם יכולים להשתמש במשאבים הבאים כדי לשכתב בסיסי קוד מדור קודם, לשדרג מסגרות של אפליקציות ולעבור למיקרו-שירותים מבוססי-ענן ב-Google Cloud:

מודרניזציה של המחשב המרכזי

אתם יכולים להשתמש במשאבים הבאים כדי להעביר מערכות מיינפריים מדור קודם (כמו COBOL,‏ PL/I ו-JCL) למיקרו-שירותים מבוססי-ענן ב- Google Cloud:

Rapid Migration and Modernization Program (RaMP)

‫Rapid Migration and Modernization Program ‏ (RaMP) היא תוכנית גלובלית ליוזמות של העברה ומודרניזציה. Google Cloud‫RaMP מספק מסגרת, משאבים וכלים מוגדרים שיעזרו לכם לבצע העברות ופיתוחים ל- Google Cloud.

למידע נוסף, קראו את הסקירה הכללית על Rapid Migration and Modernization Program‏ (RaMP).

מתודולוגיות של העברה ומודרניזציה

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

האסטרטגיה תיאור תרחיש לדוגמה כלים ראשיים
חותכים ולוקחים העברת אפליקציות אל Google Cloud בלי לשנות את הארכיטקטורה או הקוד. פינוי מהיר של מרכז נתונים, תוכנה מדור קודם עם יחסי תלות קבועים. ‫Migrate to VMs
העברה לפלטפורמה אחרת העברת עומסי עבודה לפלטפורמות מנוהלות עם שינויים מינימליים בקוד. העברת מסדי נתונים רלציוניים מקומיים למסדי נתונים מנוהלים בענן, או שדרוג מנועים קנייניים ל-AlloyDB ל-PostgreSQL. Database Migration Service
Refactor (מודרניזציה) יצירת ארכיטקטורה מחדש של אפליקציות כדי להשתמש בתכונות של הענן ובמיקרו-שירותים. פירוק אפליקציות מונוליתיות לקונטיינרים או ללא שרת (serverless), והמרת קוד מדור קודם של מחשב מרכזי לשפות יעד מודרניות, כמו Java או Go. ‫Modernization Hub, ‏ Antigravity CLI,‏ Mainframe Assessment Tool
רכישה חוזרת החלפת תוכנות מקומיות בהתאמה אישית או מדור קודם בפתרונות של תוכנה כשירות (SaaS). החלפת תוכנות אירוח עצמי מדור קודם של אימייל או ניהול קשרי לקוחות (CRM) ב-Google Workspace או בשותפי SaaS. שילובים מנוהלים של SaaS
הוצאה משימוש הוצאה משימוש של אפליקציות או שרתים שאין בהם יותר צורך. סביבות בדיקה מיושנות או שרתי דיווח מיותרים. לא רלוונטי
שמירה להשאיר את האפליקציות בסביבת המקור שלהן בגלל אילוצים טכניים או אילוצי תאימות. חומרה מדור קודם עם תלות בחומרה פיזית שלא ניתן להעביר. לא רלוונטי

אסטרטגיות למודרניזציה של אפליקציות

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

  • הערכת מודרניזציה ויצירת קונטיינרים לעומסי עבודה של Java: הערכת עומסי עבודה של ‎.NET ו-Java באמצעות Modernization Hub כדי לבחון נתיבי טרנספורמציה כמו שדרוגי מסגרות, ואריזת עומסי עבודה של Java בקונטיינרים שתואמים ל-Open Container Initiative ‏ (OCI) לפריסה ב-Google Kubernetes Engine ‏ (GKE) או ב-Cloud Run.
  • שדרוג Framework וארגון הקוד מחדש: מודרניזציה של סביבות זמן ריצה מדור קודם, כמו מ-.NET Framework ל-.NET 10, ופירוק של מונוליתים למיקרו-שירותים באמצעות Antigravity CLI וכלי AI גנרטיבי.
  • טרנספורמציה ללא שרת (serverless): שינוי הארכיטקטורה של עומסי עבודה מבוססי-אירועים, משימות באצווה וממשקי API בארכיטקטורת REST, והעברה שלהם לסביבות זמן ריצה מנוהלות ללא שרת (serverless) באמצעות Cloud Run, כדי לצמצם את ניהול התשתית.

אסטרטגיות להעברת מסדי נתונים

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

  • העברה אופליין (תחזוקה מתוזמנת): הפסקת הכתיבה למסד הנתונים של המקור, ייצוא של מערך הנתונים, ייבוא שלו ל- Google Cloudוהפניה אוטומטית של מחרוזות החיבור של האפליקציה. הגישה הזו מתאימה במיוחד לעומסי עבודה לא קריטיים או לקבוצות נתונים קטנות, שאפשר להשבית אותם במהלך חלונות זמן לתחזוקה.
  • העברה אונליין (רפליקציה רציפה): יצירת תמונת מצב ראשונית של מסד הנתונים והעברת עדכוני טרנזקציות באופן רציף באמצעות סימון נתונים שהשתנו (CDC) עד למעבר הסופי למערכת אחרת (cutover). הגישה הזו מתאימה במיוחד למערכות קריטיות שדורשות זמן השבתה מינימלי והמשכיות עסקית.

אסטרטגיות למודרניזציה של מחשבים מרכזיים

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

  1. הנדסה הפוכה: שימוש ב-Mainframe Assessment Tool‏ (MAT) כדי לחלץ את הלוגיקה העסקית הבסיסית, את עצי הקריאות של התוכנית ואת הסכימות של הנתונים.
  2. הנדסה קדימה: הפיכת הלוגיקה העסקית שחולצה למיקרו-שירותים בענן בשפות היעד, כמו Java או Go, באמצעות Antigravity CLI.
  3. אימות באמצעות Dual Run: עיבוד עסקאות ייצור בזמן אמת במקביל בסביבות המחשב המרכזי ו- Google Cloudבאמצעות Dual Run, כדי להשיג שוויון פונקציונלי לפני המעבר הסופי.

המאמרים הבאים