המסמך הזה יעזור לכם לתכנן, לעצב ולהטמיע את תהליך ההעברה של עומסי העבודה אל Google Cloud. העברת אפליקציות מסביבה אחת לאחרת היא משימה מאתגרת, גם לצוותים מנוסים, ולכן צריך לתכנן ולבצע את ההעברה בקפידה.
המסמך הזה הוא חלק מסדרה של כמה מאמרים בנושא מעבר אלGoogle Cloud:
- מעבר אל Google Cloud: תחילת העבודה (המסמך הזה)
- מעבר אל Google Cloud: הערכה וגילוי של עומסי העבודה
- מעבר אל Google Cloud: תכנון ובניית הבסיס
- מעבר אל Google Cloud: העברת מערכי נתונים גדולים
- העברה אל Google Cloud: פריסת עומסי העבודה
- העברה אל Google Cloud: מעבר מפריסות ידניות לפריסות אוטומטיות מבוססות-קונטיינרים
- מעבר אל Google Cloud: אופטימיזציה של הסביבה
- מעבר אל Google Cloud: שיטות מומלצות לאימות של תוכנית העברה
- העברה אל Google Cloud: צמצום עלויות
המסמך הזה שימושי אם אתם מתכננים מיגרציה מסביבה מקומית, מסביבת אירוח פרטית, מספק שירותי ענן אחר אלGoogle Cloud, או אם אתם בודקים את האפשרות של מיגרציה ורוצים לחקור איך זה יכול להיראות.
מתחילים את המסע
כשמתכננים את המעבר ל- Google Cloud, מתחילים בהגדרת הסביבות שמעורבות בהעברה. נקודת ההתחלה יכולה להיות סביבה מקומית, סביבת אירוח פרטית או סביבת ענן ציבורית אחרת.
סביבה מקומית היא סביבה שבה יש לכם בעלות מלאה ואחריות מלאה. השליטה המלאה על כל היבט בסביבה נשארת בידיים שלכם, למשל קירור, אבטחה פיזית ותחזוקת חומרה.
בסביבת אירוח פרטית, כמו מתקן לאחסון ואירוח שרתים (colocation facility), אתם ממקורות חיצוניים חלק מהתשתית הפיזית והניהול שלה. בדרך כלל התשתית הזו משותפת בין לקוחות. בסביבת אירוח פרטית, אתם לא צריכים לנהל את שירותי האבטחה והבטיחות הפיזיים. בסביבות אירוח מסוימות אתם יכולים לנהל חלק מהחומרה הפיזית, כמו שרתים, מתלים ומכשירי רשת, ובסביבות אחרות החומרה הזו מנוהלת בשבילכם. בדרך כלל, כבלי החשמל והרשת מסופקים כשירות, כך שלא צריך לנהל אותם. יש לכם שליטה מלאה בהיפר-ויזורים שמבצעים וירטואליזציה של משאבים פיזיים, בתשתית הווירטואלית שאתם מקצים ובעומסי העבודה שאתם מריצים בתשתית הזו.
בסביבת ענן ציבורי לא צריך לנהל את כל ערימת המשאבים בעצמכם. אתם יכולים להתמקד בהיבט של המערך שהכי חשוב לכם. בדומה לסביבת אירוח פרטית, אתם לא צריכים לנהל את התשתית הפיזית הבסיסית. בנוסף, אתם לא צריכים לנהל את ה-hypervisor של וירטואליזציית המשאבים. אתם יכולים לבנות תשתית וירטואלית ולפרוס את עומסי העבודה בתשתית החדשה הזו. אתם יכולים גם לקנות שירותים בניהול מלא, שבהם אתם מתמקדים רק בעומסי העבודה שלכם ומעבירים את הנטל התפעולי של ניהול סביבות זמן הריצה.
לכל סביבה, במסמך הזה מוערכים ההיבטים הבאים, וגם מצוין מי צריך לספק ולנהל את השירותים הרלוונטיים:
| משאבים | סביבה מקומית | סביבת אירוח פרטית | סביבת ענן ציבורית |
|---|---|---|---|
| בטיחות ואבטחה פיזית | את/ה | ספק השירות | ספק השירות |
| כבלים של חשמל ורשת | את/ה | ספק השירות | ספק השירות |
| ��ומרה (כולל תחזוקה) | את/ה | תלוי בספק השירות | ספק השירות |
| פלטפורמת וירטואליזציה | את/ה | את/ה | ספק השירות |
| משאבי אפליקציות | את/ה | את/ה | אתם (בסופו של דבר תשתמשו בשירותים שמנוהלים במלואם) |
במסמך הזה, סביבת היעד היאGoogle Cloud.
אחרי שמגדירים את סביבות המקור והיעד, מגדירים את סוגי עומסי העבודה (workload) ואת התהליכים התפעוליים הקשורים שנכללים בהיקף ההעברה. במסמך הזה נתייחס לשני סוגים של עומסי עבודה ופעולות: מדור קודם ומותאמים לענן.
עומסי עבודה ותפעול מדור קודם מפותחים בלי להתחשב בסביבות ענן. יכול להיות שיהיה קשה לשנות את עומסי העבודה והפעולות האלה, והרצה ותחזוקה שלהם עלולות להיות יקרות כי בדרך כלל הם לא תומכים בשום סוג של יכולת הרחבה.
עומסי עבודה ופעולות שעברו אופטימיזציה לענן הם ניתנים להרחבה, ניידים, זמינים ומאובטחים באופן טבעי. עומסי העבודה והפעולות יכולים לעזור להגדיל את הפרודוקטיביות והגמישות של המפתחים, כי הם יכולים להתמקד בעומסי העבודה בפועל, במקום להשקיע מאמץ בניהול סביבות הפיתוח והזמן הריצה, או להתמודד עם תהליכי פריסה ידניים ומסורבלים. Google Cloud יש ל- Google Cloud גם מודל של אחריות משותפת לאבטחה. Google Cloud אחראית לאבטחה הפיזית ולאבטחת התשתית, ואתם אחראים לאבטחת עומסי העבודה שאתם פורסים בתשתית.
בהתחשב בסוגי הסביבות ועומסי העבודה האלה, מצב ההתחלה שלכם הוא אחד מהמצבים הבאים:
- סביבת אירוח מקומית או פרטית עם עומסי עבודה ותפעול מדור קודם.
- סביבת אירוח מקומית או פרטית עם עומסי עבודה ופעולות שעברו אופטימיזציה לענן.
- סביבת אירוח פרטית או ענן ציבורי עם עומסי עבודה ופעולות מדור קודם.
- סביבת אירוח פרטית או ענן ציבורי עם עומסי עבודה ופעולות שעברו אופטימיזציה לענן.
תהליך ההעברה תלוי בנקודת ההתחלה.
העברת עומס עבודה מסביבה מקומית מדור קודם או מסביבת אירוח פרטית לסביבה שעברה אופטימיזציה לענן, כמו ענן ציבורי, יכולה להיות מאתגרת ומסוכנת. העברות מוצלחות משנות את עומס העבודה להעברה כמה שפחות במהלך פעולות ההעברה. העברת אפליקציות מדור קודם שפועלות בשרתים מקומיים לענן לרוב דורשת כמה שלבי העברה.
סוגי העברות
במסמך הזה מוגדרים סוגי ההעברות העיקריים הבאים:
- אירוח מחדש: חותכים ולוקחים
- העברה לפלטפורמה חדשה: העברה ואופטימיזציה
- רפקטורינג: העברה ושיפור
- שינוי הארכיטקטורה: המשך המודרניזציה
- בנייה מחדש: הסרה והחלפה, לפעמים נקראת הסרה והחלפה
- רכישה חוזרת
בקטעים הבאים מוגדר כל סוג של העברה, עם דוגמאות למקרים שבהם כדאי להשתמש בכל סוג.
אירוח מחדש: חותכים ולוקחים
בהעברה מסוג rehost, מעבירים עומסי עבודה מסביבת מקור לסביבת יעד עם שינויים קלים ��ו ללא שינויים או שינוי מבנה. השינויים שאתם מבצעים בעומסי העבודה לצורך ההעברה הם רק השינויים המינימליים שצריך לבצע כדי שעומסי העבודה יפעלו בסביבת היעד.
העברה מסוג rehost היא אידיאלית כשעומס העבודה יכול לפעול כמו שהוא בסביבת היעד, או כשאין צורך עסקי בשינוי. הסוג הזה של מיגרציה דורש הכי פחות זמן כי כמות השינויים הנדרשים קטנה.
יכול להיות שיהיו בעיות טכניות שיחייבו העברה של האתר למארח אחר. אם אי אפשר לבצע רפקטורינג של עומס עבודה כדי להעביר אותו, ואי אפשר להוציא אותו משימוש, צריך להשתמש בהעברה מסוג rehost. לדוגמה, יכול להיות שיהיה קשה או בלתי אפשרי לשנות את קוד המקור של עומס העבודה, או שתהליך build לא פשוט ולכן יכול להיות שלא ניתן יהיה ליצור ארטיפקטים חדשים אחרי שינוי קוד המקור.
ההעברות מסוג Rehost הן הכי קלות לביצוע, כי הצוות יכול להמשיך להשתמש באותם כלים ובאותן מיומנויות שבהם השתמש לפני כן. ההעברות האלה תומכות גם בתוכנות מוכנות. העברות מסוג rehost הן בדרך כלל המהירות ביותר, בהשוואה להעברות מסוג refactor או rebuild, כי מעבירים עומסי עבודה קיימים עם מינימום ארגון מחדש.
עם זאת, אחרי העברה מסוג rehost, עומסי העבודה שפועלים בסביבת היעד לא מותאמים לענן. עומסי העבודה האלה לא מנצלים את מלוא היתרונות של תכונות פלטפורמת הענן, כמו יכולת הרחבה אופקית, תמחור מדויק ושירותים מנוהלים ברמה גבוהה.
העברה לפלטפורמה חדשה: העברה ואופטימיזציה
בהעברה בין פלטפורמות, מעבירים את עומסי העבודה הקיימים ואז מבצעים אופטימיזציה שלהם לסביבת הענן החדשה.
העברה בין פלטפורמות מתאימה לארגונים שרוצים לנצל את כל היכולות העיקריות של הענן. היכולות האלה כוללות מחשוב גמיש, יתירות, ביצועים משופרים ואבטחה.
לדוגמה, יכול להיות שתעבירו עומס עבודה לפלטפורמה אחרת בענן כדי ליהנות מארכיטקטורת מיקרו-שירותים מבוססת-ענן או מקונטיינרים ב-Google Kubernetes Engine. עומסי העבודה האלה יפעלו בענן עם ביצועים טובים יותר ויעילות גבוהה יותר.
עם זאת, העברות בין פלטפורמות דורשות יותר עבודה מהעברות של אירוח מחדש. לפלטפורמת הענן החדשה יהיה בסיס קוד שונה, ולכן נצטרך לבצע כמה סבבים של בדיקות כדי לוודא שהכול פועל ברמה אופטימלית.
רפקטורינג: העברה ושיפור
במיגרציה של שינוי מבנה, אתם משנים את עומסי העבודה כדי לנצל את היכולות של הענן, ולא רק משנים את עומסי העבודה כדי שהם יפעלו בסביבה החדשה. אפשר לשפר כל עומס עבודה מבחינת ביצועים, תכונות, עלות וחוויית מש��מש.
��תם ��כול��ם ��שנות את ��ומסי העבודה ��זמן שאתם מעבירים אותם לענן, או אפילו לפני ההעברה. לדוגמה, אם אין לכם ניסיון רב בהעברות לענן, יכול להיות שתעדיפו לשנות את עומסי העבודה במהלך ההעברה. עם זאת, אם יש לכם ניסיון בהעברה לענן, יכול להיות שכבר יש לכם מושג לגבי השינויים שצריך לבצע בעומסי העבודה כדי לנצל את היכולות של הענן באופן מלא.
אם הארכיטקטורה או התשתית הנוכחית של אפליקציה לא נתמכות בסביבת היעד כמו שהן, צריך לבצע מידה מסוימת של שינוי מבנה כדי להתגבר על המגבלות האלה.
סיבה נוספת לבחירה בגישת הרפקטורינג היא כשנדרש עדכון משמעותי של עומס העבודה בנוסף לעדכונים שצריך לבצע כדי לבצע את ההעברה.
העברות רפקטורינג מאפשרות לאפליקציה שלכם ליהנות מתכונות של פלטפורמת ענן, כמו מדרגיות וזמינות גבוהה. אפשר גם לתכנן את השיפור כדי להגדיל את הניידות של האפליקציה.
עם זאת, העברות מסוג refactor נמשכות זמן רב יותר מהעברות מסוג rehost, כי צריך לבצע refactor של עומסי העבודה כדי שהאפליקציה תועבר.
בנוסף, כדי לבצע העברה של שינוי מבנה, צריך ללמוד מיומנויות חדשות.
שינוי הארכיטקטורה: המשך המודרניזציה
העברות עם שינוי בארכיטקטורה דומות להעברות עם שינוי מבנה. עם זאת, במקום לשנות את המבנה של אופן הפעולה של קוד העומס, העברות של שינוי הארכיטקטורה משנות את אופן הפעולה של הקוד. שינויי הקוד האלה מבצעים אופטימיזציה של עומס העבודה ומנצלים את היתרונות של מאפיינים שעברו אופטימיזציה לענן, כמו מדרגיות, אבטחה וגמישות. לדוגמה, העברה של שינוי ארכיטקטורה יכולה לקחת עומס עבודה גדול ומונוליתי ולהפוך אותו לכמה מיקרו-שירותים עצמאיים שאתם פורסים ב- Google Cloud.
מיגרציה של שינוי ארכיטקטורה היא מורכבת יותר ממיגרציה של שינוי מבנה, ולכן היא דורשת יותר זמן ומאמץ. בנוסף, העברה של ארכיטקטורה חדשה עלולה להוסיף באגים או בעיות אבטחה לעומסי העבודה החדשים. לכן, העברה של שינוי ארכיטקטורה דורשת כמה סבבים של בדיקות כדי לוודא שהכול פועל ברמה האופטימלית.
שיקום: הסרה והחלפה
בהעברה של בנייה מחדש, מוציאים משימוש אפליקציה קיימת ומעצבים וכותבים אותה מחדש כאפליקציה שעברה אופטימיזציה מלאה לענן.
אם האפליקציה הנוכחית לא עונה על הצרכים שלכם – למשל, אם אתם לא רוצים לתחזק אותה, אם העלות של העברה באמצעות אחת מהשיטות שצוינו קודם גבוהה מדי או אם היא לא נתמכת ב- Google Cloud– אתם יכולים לבצע העברה של בנייה מחדש.
העברות מסוג Rebuild מאפשרות לאפליקציה שלכם ליהנות מכל הי��רונות של תכונותGoogle Cloud , כמו יכולת התאמה אופקית לעומס, שירותים מנוהלים וזמינות גבוהה. בגלל שאתם כותבים מחדש את האפליקציה מאפס, אתם גם מסירים את החוב הטכני של הגרסה הקיימת מדור קודם.
עם זאת, העברות של בנייה מחדש עשויות להימשך זמן רב יותר מהעברות של אירוח מחדש או של שינוי מבנה. בנוסף, סוג ההעברה הזה לא מתאים לאפליקציות מוכנות מראש, כי הוא מחייב לכתוב מחדש את האפליקציה. צריך להעריך את הזמן והמאמץ הנוספים שנדרשים לעיצוב מחדש ולכתיבה מחדש של האפליקציה כחלק ממחזור החיים שלה.
העברה של בנייה מחדש דורשת גם מיומנויות חדשות. צריך להשתמש בשרשרות כלים חדשות כדי להקצות ולהגדיר את הסביבה החדשה, ולפרוס את האפליקציה בסביבה הזו.
רכישה חוזרת
העברה של רכישה חוזרת היא העברה של עומס עבודה שנרכש במקום (on-premises) אל שירות תוכנה (SaaS) מקביל שמתארח בענן. לדוגמה, אפשר לעבור מתוכנת שיתוף פעולה מקומית ומאחסון מקומי ל-Google Workspace.
מבחינת משאבים, יכול להיות שיהיה הרבה יותר קל לבצע העברה של רכישה חוזרת מאשר לבצע שינוי מבנה, בנייה מחדש או שינוי ארכיטקטורה. עם זאת, מיגרציה של רכישה חוזרת עשויה להיות יקרה הרבה יותר, ויכול להיות שלא תקבלו את התכונות הפרטניות של שליטה בסביבות הענן שלכם.
Google Cloud Adoption Framework
לפני שמתחילים בהעברה, כדאי להעריך את רמת הבשלות של הארגון באימוץ טכנולוגיות ענן. Google Cloud מסגרת ההטמעה משמשת כמפה לקביעת היכולות הנוכחיות של טכנולוגיית המידע בעסק שלכם, וגם כמדריך להגעה ליעד הרצוי.
תוכלו להשתמש במסגרת הזו כדי להעריך את רמת המוכנות של הארגון שלכם ל-Google Cloud ולבדוק מה צריך לעשות כדי לגשר על הפערים ולפתח יכולות חדשות, כמו שמוצג בתרשים הבא.
המסגרת מעריכה ארבעה נושאים:
- מידע נוסף האיכות וההיקף של תוכניות הלמידה.
- ליד (lead). המידה שבה מחלקות ה-IT שלכם נתמכות על ידי מנדט מההנהלה להעברה אל Google Cloud.
- התאמה לעומס (scale). היקף השימוש בשירותים שעברו אופטימיזציה לענן, ומידת האוטומציה התפעולית שהטמעתם.
- מאובטח. היכולת להגן על הסביבה הנוכחית מפני גישה לא מורשית ולא הולמת.
לפי המסגרת, כל נושא צריך להיות באחד משלושת השלבים הבאים:
- טקטיות. אין תוכניות עקביות שמכסות את כל עומסי העבודה האישיים שהגדרתם. הדבר שהכי חשוב לכם הוא לקבל החזר מהיר על ה��שקעות, ושההפרעה לארגון ה-IT תהיה מינימלית.
- אסטרטגי. יש תוכנית לפיתוח עומסי עבודה נפרדים, תוך התחשבות בצרכי ההרחבה העתידיים. אתם רוצים להשיג יעד לטווח הבינוני: לייעל את הפעולות כדי שהן יהיו יעילות יותר ממה שהן היום.
- טרנספורמטיבי. הפעולות ב-Cloud מתבצעות בצורה חלקה, ואתם משתמשים בנתונים שאתם אוספים מהפעולות האלה כדי לשפר את העסק שלכם בתחום ה-IT. אתם מעוניינים להפוך את מחלקת ה-IT לאחד ממנועי החדשנות בארגון שלכם בטווח הארוך.
כשמעריכים את ארבעת הנושאים בהקשר של שלושת השלבים, מקבלים את סולם הבשלות של הענן. בכל נושא אפשר לראות מה קורה כשעוברים משימוש בטכנולוגיות חדשות כשצריך, לשימוש בהן בצורה אסטרטגית יותר בכל הארגון – מה שאומר באופן טבעי הדרכה מעמיקה, מקיפה ועקבית יותר לצוותים.
מסלול המיגרציה
חשוב לזכור שההעברה היא תהליך. אתם נמצאים בנקודה א' עם התשתית והסביבות הקיימות שלכם, ואתם רוצים להגיע לנקודה ב'. כדי להגיע מנקודה א' לנקודה ב', אפשר לבחור באחת מהאפשרויות שתיארנו קודם.
התרשים הבא מדגים את הנתיב של התהליך הזה.
תהליך ההעברה כולל ארבעה שלבים:
- הערכה. בשלב הזה, מבצעים הערכה יסודית וגילוי של הסביבה הקיימת כדי להבין את מלאי האפליקציות והסביבות, לזהות את התלות והדרישות של האפליקציות, לבצע חישובים של עלות הבעלות הכוללת (TCO) ולקבוע מדדי ביצועים לאפליקציות. מידע נוסף על שלב ההערכה זמין במאמרים Migrate to Google Cloud: Assess and discover your workloads, Migrate to Google Cloud: Best practices ו-Migration Center: Start an asset discovery.
- תוכנית. בשלב הזה יוצרים את תשתית הענן הבסיסית שבה יפעלו עומסי העבודה, ומתכננים איך להעביר את האפליקציות. התכנון הזה כולל ניהול זהויות, מבנה הארגון והפרויקט, רישות, מיון האפליקציות ופיתוח אסטרטגיית העברה לפי סדר עדיפויות. מידע נוסף על תכנון ובנייה של הבסיס זמין במאמר מעבר אל Google Cloud: תכנון ובנייה של הבסיס.
- פריסה. בשלב הזה, מתכננים, מיישמים ומבצעים תהליך פריסה להעברת עומסי עבודה אל Google Cloud. יכול להיות שתצטרכו גם לשפר את תשתית הענן כדי לענות על צרכים חדשים. מידע נוסף על פריסת עומסי עבודה ב- Google Cloud ועל העברת נתונים אל Google Cloudזמין במאמרים העברה אל Google Cloud: פריסת עומסי עבודה, העברה אל Google Cloud: העברה מפריסות ידניות לפריסות אוטומטיות מבוססות-קונטיינרים והעברה אל Google Cloud: העברת מערכי נתונים ��דולים.
- אופטימיזציה. בשלב הזה, מתחילים לנצל את הטכנולוגיות והיכולות שעברו אופטימיזציה לענן, כדי להרחיב את הפוטנציאל של העסק בתחומים כמו ביצועים, יכולת הרחבה, תוכנית התאוששות מאסון (DR), עלויות, הדרכה, וגם כדי לפתוח את הדלת לשילובים של למידת מכונה ובינה מלאכותית (AI) באפליקציה. למידע נוסף על אופטימיזציה של הסביבה, אפשר לעיין במאמר מעבר אל Google Cloud: אופטימיזציה של הסביבה. מידע נוסף על עלויות מופיע במאמר מעבר אל Google Cloud: צמצום עלויות.
איך מקבלים עזרה
Google Cloud מציעה מגוון אפשרויות ומשאבים שיעזרו לכם לקבל את העזרה והתמיכה הדרושות כדי להפיק את המרב מהשירותים Google Cloud .
משאבים בשירות עצמי
אם אתם לא צריכים תמיכה ייעודית, אתם יכולים להשתמש במשאבים האלה לשירות עצמי:
- מאמרי עזרה למוצרים. Google Cloud מספקת מאמרי עזרה לכל המוצרים והשירותים שלה, וגם לממשקי API.
- מאמרי העזרה של מרכז הארכיטקטורה בקטע בנושא העברה במרכז הארכיטקטורה מפורטים תרחישי העברה רבים. לדוגמה, מקורות מידע בנושא העברת נתונים כוללים הנחיות להעברת נתונים אל Google Cloud.
- כלים. Google Cloud מספקת כמה מוצרים ושירותים שיעזרו לכם לבצע מיגרציה. לדוגמה:
- Google Cloud Migration Center היא פלטפורמה מאוחדת שעוזרת לכם להאיץ את המעבר מקצה לקצה לענן מהסביבות הנוכחיות שלכם בתשתית מקומית או בענן אלGoogle Cloud.
- Migrate to Virtual Machines הוא מוצר להעברת שרתים פיזיים ומכונות וירטואליות מסביבות מקומיות ומסביבות ענן אל Google Cloud. הכלי 'העברה למכונות וירטואליות' מאפשר להעביר מכונה וירטואלית אלGoogle Cloud תוך כמה דקות. הנתונים מועתקים ברקע, אבל המכונות הווירטואליות פועלות באופן מלא.
- Storage Transfer Service מאפשר להעביר נתונים אל Cloud Storage מספקי ענן אחרים, ממקורות אונליין או מנתונים מקומיים.
- Database Migration Service הוא מוצר שעוזר להעביר את מסדי הנתונים אל Google Cloud.
- Transfer Appliance הוא מכשיר חומרה שאפשר להשתמש בו כדי להעביר כמויות גדולות של נתונים (החל ממאות טרה-בייט ועד פטה-בייט אחד) אל Google Cloudבלי להפריע לפעילות העסקית.
- שירות ההעברה ל-BigQuery הוא פתרון מקיף להעברת מחסן הנתונים שלכם ל-BigQuery.
- מסמכים טכניים. המסמכים האלה כוללים ��וגמאות לארכיטקטורות, תיאורי מקרים, שיטות מומלצות ומדריכים מתקדמים.
- תוכן מדיה. אפשר לצפות בכל הסרטונים בGoogle Cloud ערוץ YouTube. במקורות האלה מוסבר על מגוון רחב של נושאים, החל מהסברים על מוצרים ועד לאסטרטגיות פיתוח.
- קורסים ושיעורי Lab אונליין. Google Cloud יש כמה קורסים ב-Coursera שכוללים תוכן וידאו, חומרי קריאה ושיעורי Lab. אפשר גם להשתתף בשיעורי Lab באמצעות Google Cloud Skills Boost או להשתתף בשיעורים מקוונים בזמן אמת.
שותפים טכנולוגיים
Google Cloud משתפת פעולה עם מספר חברות כדי לאפשר לכם להשתמש במוצרים שלהן. יכול להיות שחלק מהשירותים האלה יהיו בחינם, לכן כדאי לשאול את החברה ואת מנהל החשבון ב- Google Cloud .
משלבי מערכות
Google Cloud שותפים לא רק עם חברות טכנולוגיה ומוצרים, אלא גם עם משלבי מערכות שיכולים לספק עזרה מעשית. ברשימת השותפים, אפשר למצוא רשימה של משלבי מערכות שמתמחים בהעברות לענן.
Google Cloud שירותים מקצועיים
צוות השירותים המקצועיים שלנו ישמח לעזור לכם להפיק את המרב מההשקעה שלכם ב- Google Cloud.
תכנית Cloud והגדרות בסיסיות: קבלת עזרה בהעברה
הצוות של Professional Services יכול לעזור לכם לתכנן את ההעברה ולפרוס את עומסי העבודה בסביבת ייצור באמצעות חבילת Cloud Plan and Foundations. המומחים האלה מספקים לצוות שלכם הדרכה בכל שלב של העברת עומס העבודה לסביבת הייצור, החל מהגדרת הבסיס לאופטימיזציה של הפלטפורמה בהתאם לצרכים הייחודיים של עומס העבודה ועד לפריסת עומס העבודה. Google Cloud
היעדים של Cloud Plan ו-Foundations הם:
- מגדירים את הבסיס של Google Cloud .
- ליצור מסמכי עיצוב.
- לתכנן פעילויות של פריסה והעברה.
- פריסת עומסי עבודה בסביבת ייצור.
- מעקב אחרי בעיות וסיכונים.
צוות השירותים המקצועיים ידריך את הצוות שלכם בפעילויות ובתוצרים הבאים:
- עורכים סדנאות טכניות להשקת הפרויקט.
- יצירת מסמך עיצוב טכני.
- יצירת תוכנית העברה.
- יצירת מסמך מדיניות של התוכנית.
- מתן שירותי ניהול פרו��קטים.
- מתן מומחיות טכנית.
Cloud Sprint: האצת המעבר ל- Google Cloud
Cloud Sprint היא סדנה אינטנסיבית שמאיצה את המיגרציה של האפליקציה ל-Google Cloud. בסדנה הזו, Google Cloud צוות השירותים המקצועיים ינחה את אחד הצוותים שלכם בדיונים אינטראקטיביים, בסשנים של לוח לבן ובבדיקה של אפליקציות היעד להעברה Google Cloud. במהלך Cloud Sprint, הצוות של Professional Services עובד יחד עם חברי הצוות שלכם כדי לעזור לכם לצבור ניסיון מעשי בפתרונות ענן, עם פעילויות פריסה נדרשות שיעזרו לכם להבין מהם השלבים הבאים להעברות עתידיות. Google Cloud
הדרכה: פיתוח המיומנויות של הצוות
Google Cloud צוות Professional Services יכול לספק הדרכה בתחומים שונים בהתאם לצרכים של הצוות.
המאמרים הבאים
- מתי כדאי לפנות לקבלת עזרה לגבי העברות
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: Marco Ferrari | Cloud Solutions Architect