במסמך הזה נסביר איך לתכנן, לעצב ולהטמיע את תהליך ההעברה של עומסי העבודה אל 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 אחראי לאבטחה הפיזית ולאבטחת התשתית, ואתם אחראים לאבטחת העומסים שאתם פורסים בתשתית.
בהתחשב בסוגי הסביבות ועומסי העבודה האלה, המצב ההתחלתי שלכם הוא אחד מהמצבים הבאים:
- סביבת אירוח מקומית או פרטית עם עומסי עבודה ותפעול מדור קודם.
- סביבת אירוח מקומית או פרטית עם עומסי עבודה ופעולות שעברו אופטימיזציה לענן.
- סביבת אירוח פרטית או ענן ציבורי עם עומסי עבודה ופעולות מדור קודם.
- סביבת אירוח פרטית או ענן ציבורי עם עומסי עבודה ופעולות שעברו אופטימיזציה לענן.
תהליך ההעברה תלוי בנקודת ההתחלה.
העברת עומס עבודה מסביבה מקומית מדור קודם או מסביבת אירוח פרטית לסביבה שעברה אופטימיזציה לענן, כמו ענן ציבורי, יכולה להיות מאתגרת ומסוכנת. העברות מוצלחות משנות את עומס העבודה להעברה כמה שפחות במהלך פעולות ההעברה. העברת אפליקציות מדור קודם שפועלות בשרתים מקומיים לענן לרוב דורשת כמה שלבי העברה.
סוגי העברות
במסמך הזה מוגדרים סוגי ההעברות העיקריים הבאים:
- אירוח מחדש: חותכים ולוקחים
- מעבר לפלטפורמה אחרת: העברה ואופטימיזציה
- רפקטורינג: העברה ושיפור
- שינוי הארכיטקטורה: המשך המודרניזציה
- בנייה מחדש: הסרה והחלפה, לפעמים נקראת הסרה והחלפה
- רכישה חוזרת
בקטעים הבאים מוגדר כל סוג של העברה, עם דוגמאות למקרים שבהם כדאי להשתמש בכל סוג.
אירוח מחדש: חותכים ולוקחים
בהעברה מסוג rehost, מעבירים עומסי עבודה מסביבת המקור לסביבת היעד עם שינויים קלים או ללא שינויים או שינוי מבנה. השינויים שאתם מבצעים בעומסי העבודה לצורך ההעברה הם רק השינויים המינימליים שצריך לבצע כדי שעומסי העבודה יפעלו בסביבת היעד.
העברה מסוג rehost היא אידיאלית כשעומס עבודה יכול לפעול כמו שהוא בסביבת היעד, או כשאין צורך עסקי בשינוי או שיש צורך מועט. הסוג הזה של מיגרציה דורש הכי פחות זמן כי כמות השינויים הנדרשים קטנה.
יכול להיות שיהיו בעיות טכניות שיחייבו העברה של האתר למארח אחר. אם אי אפשר לשנות את הארכיטקטורה של עומס עבודה כדי להעביר אותו, ואי אפשר להוציא אותו משימוש, צריך להשתמש בהעברה מסוג rehost. לדוגמה, יכול להיות שיהיה קשה או בלתי אפשרי לשנות את קוד המקור של עומס העבודה, או שתהליך build לא פשוט ולכן יכול להיות שלא ניתן יהיה ליצור פריטי מידע חדשים אחרי ארגון הקוד מחדש (Refactoring) של קוד המקור.
ההעברות מסוג Rehost הן הכי קלות לביצוע, כי הצוות יכול להמשיך להשתמש באותם כלים ובאותן מיומנויות שבהן השתמש לפני כן. ההעברות האלה תומכות גם בתוכנות מוכנות. העברות מסוג rehost הן בדרך כלל הכי מהירות, בהשוואה להעברות מסוג refactor או rebuild, כי מעבירים עומסי עבודה קיימים עם מינימום ארגון מחדש.
עם זאת, אחרי העברה מסוג rehost, עומסי העבודה שפועלים בסביבת היעד לא מותאמים לענן. עומסי העבודה האלה לא מנצלים את מלוא היתרונות של תכונות פלטפורמת הענן, כמו יכולת הרחבה אופקית, תמחור מדויק ושירותים מנוהלים ברמה גבוהה.
מעבר לפלטפורמה אחרת: העברה ואופטימיזציה
בהעברה בין פלטפורמות, מעבירים את עומסי העבודה הקיימים ואז מבצעים להם אופטימיזציה לסביבת הענן החדשה.
העברה בין פלטפורמות מתאימה בעיקר לארגונים שרוצים לנצל את כל יכולות הליבה של הענן. היכולות האלה כוללות מחשוב גמיש, יתירות, ביצועים משופרים ואבטחה.
לדוגמה, יכול להיות שתעבירו עומס עבודה לפלטפורמה אחרת בענן כדי לנצל את היתרונות של ארכיטקטורת מיקרו-שירותים מבוססת-ענן או קונטיינרים ב-Google Kubernetes Engine. עומסי העבודה האלה יניבו ביצועים טובים יותר ויעילות גבוהה יותר כשהם יפעלו בענן.
עם זאת, העברות בין פלטפורמות דורשות יותר עבודה מהעברות של אירוח מחדש. לפלטפורמת הענן החדשה יהיה בסיס קוד שונה, ולכן נצטרך לבצע כמה סבבים של בדיקות כדי לוודא שהכול פועל ברמה אופטימלית.
רפקטורינג: העברה ושיפור
במיגרציה של שינוי מבנה, אתם משנים את עומסי העבודה כדי לנצל את היכולות של הענן, ולא רק משנים את עומסי העבודה כדי שהם יפעלו בסביבה החדשה. אתם יכולים לשפר כל עומס עבודה מבחינת ביצועים, תכונות, עלות וחוויית משתמש.
אתם יכולים לשנות את עומסי העבודה בזמן שאתם מעבירים אותם לענן, או אפילו לפני ההעברה. לדוגמה, אם אין לכם ניסיון רב בהעברות לענן, יכול להיות שתעדיפו לשנות את עומסי העבודה במהלך ההעברה. עם זאת, אם יש לכם ניסיון בהעברה לענן, יכול להיות שכבר יש לכם מושג לגבי השינויים שצריך לבצע בעומסי העבודה כדי לנצל את היכולות של הענן באופן מלא.
אם הארכיטקטורה או התשתית הנוכחיות של אפליקציה לא נתמכות בסביבת היעד כמו שהן, צריך לבצע מידה מסוימת של ארגון הקוד מחדש (Refactoring) כדי להתגבר על המגבלות האלה.
סיבה נוספת לבחירה בגישת הריפקטורינג היא כשנדרש עדכון משמעותי של עומס העבודה בנוסף לעדכונים שצריך לבצע כדי לבצע את ההעברה.
העברות רפקטורינג מאפשרות לאפליקציה שלכם ליהנות מתכונות של פלטפורמת ענן, כמו מדרגיות וזמינות גבוהה. אפשר גם לתכנן את השיפור כדי להגדיל את הניידות של האפליקציה.
עם זאת, העברות מסוג refactor נמשכות זמן רב יותר מהעברות מסוג rehost, כי צריך לבצע refactor של עומסי העבודה כדי שהאפליקציה תועבר.
מיגרציה של שינוי מבנה דורשת גם לימוד של מיומנויות חדשות.
שינוי הארכיטקטורה: המשך המודרניזציה
העברות עם שינוי בארכיטקטורה דומות להעברות עם שינוי בקוד. עם זאת, במקום לשנות את המבנה של אופן הפעולה של קוד העומס, מיגרציות של שינוי ארכיטקטורה משנות את אופן הפעולה של הקוד. שינויי הקוד האלה מבצעים אופטימיזציה של עומס העבודה ומנצלים את היתרונות של מאפיינים שעברו אופטימיזציה לענן, כמו מדרגיות, אבטחה וגמישות. לדוגמה, העברה של שינוי ארכיטקטורה יכולה לקחת עומס עבודה גדול ומונוליתי ולהפוך אותו לכמה מיקרו-שירותים עצמאיים שאתם פורסים ב- Google Cloud.
מיגרציה של שינוי ארכיטקטורה היא מורכבת יותר ממיגרציה של שינוי מבנה, ולכן היא דורשת יותר זמן ומאמץ. בנוסף, מיגרציה של שינוי ארכיטקטורה עלולה להוסיף באגים או בעיות אבטחה לעומסי העבודה החדשים. לכן, העברה של ארכיטקטורה חדשה דורשת כמה סבבים של בדיקות כדי לוודא שהכול פועל ברמה האופטימלית.
שיקום: הסרה והחלפה
בהעברה של בנייה מחדש, מוציאים משימוש אפליקציה קיימת ומעצבים אותה מחדש לחלוטין כאפליקציה שעברה אופטימיזציה מלאה לענן.
אם האפליקציה הנוכחית לא עונה על הצרכים שלכם – למשל, אם אתם לא רוצים לתחזק אותה, אם העלות של העברה באמצעות אחת מהשיטות שצוינו קודם גבוהה מדי או אם היא לא נתמכת ב- Google Cloud– אתם יכולים לבצע העברה של בנייה מחדש.
העברות מסוג Rebuild מאפשרות לאפליקציה שלכם ליהנות מכל היתרונות של תכונותGoogle Cloud , כמו יכולת התאמה אופקית לעומס, שירותים מנוהלים וזמינות גבוהה. בגלל שאתם כותבים מחדש את האפליקציה מאפס, אתם גם מסירים את החוב הטכני של הגרסה הקיימת והישנה.
עם זאת, העברות של בנייה מחדש עשויות להימשך זמן רב יותר מהעברות של אירוח מחדש או של שינוי מבנה. בנוסף, סוג ההעברה הזה לא מתאים לאפליקציות מוכנות מראש, כי הוא מחייב לכתוב מחדש את האפליקציה. צריך להעריך את הזמן והמאמץ הנוספים שנדרשים לעיצוב מחדש ולכתיבה מחדש של האפליקציה כחלק ממחזור החיים שלה.
העברה של בנייה מחדש דורשת גם מיומנויות חדשות. צריך להשתמש בשרשראות כלים חדשות כדי להקצות ולהגדיר את הסביבה החדשה ולפרוס את האפליקציה בסביבה הזו.
רכישה חוזרת
העברה של רכישה חוזרת מתרחשת כשעוברים מעומס עבודה שנרכש במקום (On-Premises) למקבילה של תוכנה כשירות (SaaS) באירוח בענן. לדוגמה, אתם יכולים לעבור מתוכנת שיתוף פעולה מקומית ומאחסון מקומי ל-Google Workspace.
מבחינת משאבים, יכול להיות שיהיה הרבה יותר קל לבצע העברה של רכישה חוזרת מאשר לבצע ארגון הקוד מחדש (Refactoring), בנייה מחדש או שינוי ארכיטקטורה. עם זאת, מיגרציה של רכישה חוזרת עשויה להיות יקרה הרבה יותר, ויכול להיות שלא תקבלו את התכונות הפרטניות של שליטה בסביבות הענן שלכם.
Google Cloud Adoption Framework
לפני שמתחילים בהעברה, כדאי להעריך את רמת הבשלות של הארגון באימוץ טכנולוגיות ענן. Google Cloud מסגרת ההטמעה משמשת כמפה לקביעת היכולות הנוכחיות של טכנולוגיית המידע בעסק שלכם, וגם כמדריך להגדרת היעדים שלכם.
תוכלו להשתמש במסגרת הזו כדי להעריך את רמת המוכנות של הארגון ל-Google Cloud ולבדוק מה צריך לעשות כדי לגשר על הפערים ולפתח יכולות חדשות, כמו שמוצג בתרשים הבא.
המסגרת מעריכה ארבעה נושאים:
- מידע נוסף האיכות וההיקף של תוכניות הלמידה.
- ליד (lead). המידה שבה מחלקות ה-IT שלכם נתמכות על ידי הנחיה מההנהלה להעברה אל Google Cloud.
- שינוי גודל. היקף השימוש בשירותים שעברו אופטימיזציה לענן, והיקף האוטומציה התפעולית שהוטמעה.
- מאובטח. היכולת להגן על הסביבה הנוכחית מפני גישה לא מורשית ולא הולמת.
לפי המסגרת, כל נושא צריך להיות באחד משלושת השלבים הבאים:
- טקטי. אין תוכניות עקביות שמכסות את כל עומסי העבודה האישיים שמוגדרים אצלכם. הדבר שהכי חשוב לכם הוא לקבל החזר מהיר על ההשקעות, ושההפרעה לארגון ה-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) באפליקציה. למידע נוסף על אופטימיזציה של הסביבה, אפשר לעיין במאמר Migrate to 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: accelerate your migration to 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