במאמר הזה מוסבר איך ליצור את תשתית הענן הבסיסית לעומסי העבודה שלכם. הוא יכול גם לעזור לכם לתכנן איך התשתית הזו תתמוך באפליקציות שלכם. התכנון הזה כולל ניהול זהויות, מבנה הארגון והפרויקט ורישות.
המסמך הזה הוא חלק מסדרה של כמה מאמרים בנושא מעבר אלGoogle Cloud:
- העברה אל Google Cloud: איך מתחילים
- מעבר אל Google Cloud: הערכה וגילוי של עומסי העבודה
- מעבר ל- Google Cloud: תכנון ובניית הבסיס (המסמך הזה)
- מעבר אל Google Cloud: העברת מערכי נתונים גדולים
- העברה אל Google Cloud: פריסת עומסי העבודה
- העברה אל Google Cloud: מעבר מפריסות ידניות לפריסות אוטומטיות שמבוססות על קונטיינרים
- מעבר אל Google Cloud: אופטימיזציה של הסביבה
- מעבר ל- Google Cloud: שיטות מומלצות לאימות של תוכנית העברה
- מעבר אל Google Cloud: צמצום עלויות
התרשים הבא מדגים את תהליך ההעברה.
המסמך הזה שימושי אם אתם מתכננים העברה מסביבה מקומית, מסביבת אירוח פרטית, מספק אחר של שירותי ענן אלGoogle Cloud, או אם אתם בודקים את האפשרות להעברה ורוצים לדעת איך היא תיראה. המסמך הזה עוזר לכם להבין את המוצרים הזמינים ואת ההחלטות שתצטרכו לקבל כשאתם בונים בסיס שמתמקד בתרחיש שימוש של העברה.
אפשרויות מוכנות להטמעה:
לקבלת הנחיות נוספות בנושא שיטות מומלצות לתכנון הבסיס, אפשר לעיין במאמרים הבאים:
- עיצוב אזור נחיתה לעיצוב בסיס באופן כללי.
- Google Cloud Well-Architected Framework לקבלת הנחיות לגבי שיטות מומלצות לתכנון מערכות.
כשמתכננים את המעבר ל- Google Cloud, צריך להבין מגוון נושאים ומושגים שקשורים לארכיטקטורת ענן. בסיס שתכנונו לקוי עלול לגרום לעיכובים, לבלבול ולזמן השבתה בעסק, ולסכן את הצלחת ההעברה לענן. המדריך הזה מספק סקירה כללית של Google Cloud מושגי יסוד ונקודות להחלטה.
בכל חלק במסמך הזה מוצגות שאלות שאתם צריכים לשאול ולענות עליהן לגבי הארגון שלכם לפני שתבנו את הבסיס שלכם ב-Google Cloud. השאלות האלה לא ממצות את הנושא, והמטרה שלהן היא לעזור לצוותי הארכיטקטורה ולמנהלים בעסק לנהל שיחה על מה שמתאים לארגון. התוכניות שלכם בנוגע לתשתית, לכלים, לאבטחה ולניהול החשבון הן ייחודיות לעסק שלכם וצריך לשקול אותן לעומק. אחרי שתסיימו לקרוא את המסמך הזה ותענו על השאלות לגבי הארגון שלכם, תוכלו להתחיל בתכנון הרשמי של התשתית ושירותי הענן שתומכים בהעברה אלGoogle Cloud.
שיקולים לארגונים
כדאי לשאול את השאלות הבאות לגבי הארגון שלכם:
- אילו אחריויות בתחום ה-IT עשויות להשתנות בינך לבין ספק התשתית כשעוברים אל Google Cloud?
- איך אפשר לתמוך בדרישות שלכם לעמידה בתקנות, למשל HIPAA או GDPR, במהלך המעבר ל-Google Cloudואחריו?
- איך אפשר לקבוע איפה הנתונים שלכם יאוחסנו ויעובדו בהתאם לדרישות שלכם בנוגע למיקום אחסון הנתונים?
מודל האחריות המשותפת
האחריות המשותפת שלכם ושל Google Cloud עשויה להיות שונה מהאחריות שאתם רגילים אליה, ולכן חשוב להבין את ההשלכות שלה על העסק שלכם. יכול להיות שהתהליכים שהטמעתם בעבר כדי להקצות משאבים, להגדיר אותם ולצרוך אותם ישתנו.
כדי לקבל סקירה כללית של היחסים החוזיים בין הארגון שלכם לבין Google, ושל ההשלכות של שימוש בספק ענן ציבורי, מומלץ לעיין בתנאים ובהגבלות ובמודל האבטחה של Google.
תאימות, אבטחה ופרטיות
לארגונים רבים יש דרישות תאימות שקשורות לתקנים, לתקנות ולאישורים של התעשייה והממשלה. עומסי עבודה רבים בארגונים כפופים לבדיקה רגולטורית, ועשויים לדרוש אישורים על תאימות מצדכם ומצד ספק שירותי הענן שלכם. אם העסק שלכם מפוקח על ידי HIPAA או HITECH, חשוב שתבינו מהן האחריות שלכם ואילו שירותים מפוקחים. Google Cloud מידע על Google Cloud אישורים ותקני תאימות זמין במרכז המשאבים בנושא תאימות. מידע נוסף על תקנות ספציפיות לאזור או למגזר זמין במאמר בנושא Google Cloud ו-General Data Protection Regulation (התקנות הכלליות להגנה על מידע, GDPR).
אמון ואבטחה חשובים לכל ארגון. Google Cloud מיישמת מודל אבטחה משותף להרבה שירותים.
Google Cloud עקרונות האמון יכולים לעזור לכם להבין את המחויבות שלנו להגן על הפרטיות של הנתונים שלכם ושל הלקוחות. במאמר סקירה כללית על תכנון האבטחה בתשתית של Google תוכלו לקרוא מידע נוסף על הגישה של Google לתכנון אבטחה ופרטיות.
מידע נוסף על הטמעה של תצורת בסיס מאובטחת ב-Google Cloudזמין במאמר בנושא Google Cloud פלטפורמה מאובטחת מינימלית.
שיקולים לגבי מיקום הנתונים
המיקום הגיאוגרפי יכול להיות גם שיקול חשוב לצורך עמידה בדרישות. חשוב לוודא שאתם מבינים את הדרישות שלכם לגבי מיקום הנתונים ומיישמים מדיניות לפריסת עומסי עבודה באזורים חדשים כדי לשלוט במיקום שבו הנתונים שלכם מאוחסנים ומעובדים. הסבר על השימוש באילוצים על מיקום משאבים כדי לוודא שאפשר לפרוס את עומסי העבודה רק באזורים שאושרו מראש. כשבוחרים את יעד הפריסה של עומסי העבודה, צריך לקחת בחשבון את האזורים שבהם שירותים שונים זמינים Google Cloud . חשוב להבין את דרישות התאימות לרגולציה ואת האופן שבו אפשר ליישם אסטרטגיית ניהול שתעזור לכם לוודא שאתם עומדים בדרישות.
היררכיית המשאבים
כדאי לשאול את השאלות הבאות לגבי הארגון שלכם:
- איך המבנה הארגוני והעסקי הקיים שלכם מתאים ל-Google Cloud?
- באיזו תדירות צפויים שינויים בהיררכיית המשאבים?
- איך מכסות הפרויקטים משפיעות על היכולת שלכם ליצור משאבים בענן?
- איך אפשר לשלב את פריסות הענן הקיימות עם עומסי העבודה שהועברו?
- מהן שיטות העבודה המומלצות לניהול של כמה צוותים שעובדים בו-זמנית על כמה פרויקטים? Google Cloud
תהליכים עסקיים, ערוצי תקשורת ומבנה דיווח נוכחיים משתקפים בעיצוב של Google Cloud היררכיית המשאבים. היררכיית המשאבים מספקת את המבנה הנדרש לסביבת הענן שלכם, קובעת את אופן החיוב שלכם על צריכת המשאבים ומגדירה מודל אבטחה להענקת תפקידים והרשאות. חשוב להבין איך ההיבטים האלה מיושמים בעסק שלכם היום, ולתכנן איך להעביר את התהליכים האלה אל Google Cloud.
הסבר על Google Cloud משאבים
משאבים הם הרכיבים הבסיסיים שמהם מורכבים כל שירותיGoogle Cloud . משאב הארגון הוא הרמה העליונה בהיררכיית המשאבים ב- Google Cloud . כל המשאבים שמשויכים לארגון מקובצים בצומת שלו. המבנה הזה מספק הרשאות גישה מרכזיות ושליטה בכל המשאבים ששייכים לארגון.
ארגון יכול להכיל תיקייה אחת או יותר, וכל תיקייה יכולה להכיל פרויקט אחד או יותר. אפשר להשתמש בתיקיות כדי לקבץ פרויקטים קשורים.
Google Cloud פרויקטים מכילים משאבי שירות כמו מכונות וירטואליות (VMs) של Compute Engine, נושאי Pub/Sub, קטגוריות של Cloud Storage, נקודות קצה של Cloud VPN ושירותים אחרים של Google Cloud . אפשר ליצור משאבים באמצעות מסוף Google Cloud , Cloud Shell או ממשקי Cloud API. אם צפויים שינויים תכופים בסביבה, כדאי לאמץ גישה של תשתית כקוד (IaC) כדי לייעל את ניהול המשאבים.
ניהול הפרויקטים Google Cloud
במאמר בחירה של היררכיית משאבים לאזור הנחיתה ב- Google Cloud Google Cloud תוכלו לקרוא מידע נוסף על תכנון וניהול של היררכיית משאבים. Google Cloud אם אתם כבר עובדים ב- Google Cloud ויצרתם פרויקטים עצמאיים כבדיקות או כהוכחות להיתכנות, אתם יכולים להעביר פרויקטים קיימים ב- Google Cloud לארגון שלכם.
ניהול זהויות והרשאות גישה
כדאי לשאול את השאלות הבאות לגבי הארגון שלכם:
- מי ישלוט בגישה למשאבים שלGoogle Cloud , ינהל אותה ויבצע ביקורת עליה?
- איך ישתנו מדיניות האבטחה והגישה הקיימות שלכם כשתעברו אל Google Cloud?
- איך תאפשרו למשתמשים ולאפליקציות שלכם אינטראקציה מאובטחת עם שירותיGoogle Cloud ?
ניהול זהויות והרשאות גישה (IAM) מאפשר להעניק גישה מפורטת למשאבים ב- Google Cloud . Cloud Identity הוא שירות נפרד אך קשור שיכול לעזור לכם להעביר ולנהל את הזהויות שלכם. כדי להבין איך אתם רוצים לנהל את הגישה למשאביGoogle Cloud , צריך להבין איך אתם רוצים להקצות, להגדיר ולתחזק את IAM.
הסבר על זהויות
ב-Google Cloud נעשה שימוש בזהויות לאימות ולניהול של הרשאות הגישה. כדי לגשת למשאבים שלGoogle Cloud , חבר בארגון צריך להיות בעל זהות ש- Google Cloud יכול להבין. Cloud Identity היא פלטפורמה של ניהול זהויות כשירות (IDaaS) שמאפשרת לכם לנהל באופן מרכזי משתמשים וקבוצות שיכולים לגשת למשאבים של Google Cloud. אם תגדירו את המשתמשים ב-Cloud Identity, תוכלו להגדיר כניסה יחידה (SSO) לאלפי אפליקציות של תוכנה כשירות (SaaS) מצד שלישי. האופן שבו מגדירים את Cloud Identity תלוי באופן שבו מנהלים את הזהויות.
מידע נוסף על אפשרויות הקצאת זהויות ל-Google Cloudזמין במאמר איך מחליטים איך להוסיף זהויות ל-Google Cloud.
הסבר על ניהול הרשאות גישה
המודל לניהול הרשאות הגישה מורכב מארבעה מושגי ליבה:
- חשבון משתמש: יכול להיות חשבון Google (למשתמשי קצה), חשבון שירות (למוצרי Google Cloud ), קבוצה ב-Google או חשבון Google Workspace או Cloud Identity שיש לו גישה למשאב. חשבונות משתמש לא יכולים לבצע פעולות שהם לא מורשים לבצע.
- תפקיד: אוסף של הרשאות.
- הרשאה: קובעת אילו פעולות מותרות במשאב. כשאתם נותנים לחשבון משתמש תפקיד, אתם נותנים לו את כל ההרשאות שהתפקיד כולל.
- מדיניות הרשאות ב-IAM: מקשרת בין קבוצה של חשבונות משתמשים לתפקיד. כשרוצים להגדיר לאילו חשבונות משתמשים תהיה גישה למשאב, צריך ליצור מדיניות ולצרף אותה למשאב.
הגדרה נכונה וניהול יעיל של חשבונות ראשיים, תפקידים והרשאות הם הבסיס לאבטחה ב- Google Cloud. ניהול הגישה עוזר להגן עליכם מפני שימוש לרעה פנימי ומפני ניסיונות חיצוניים לגישה לא מורשית למשאבים שלכם.
הסבר על גישה לאפליקציות
בנוסף למשתמשים ולקבוצות, יש סוג נוסף של זהות שנקרא חשבון שירות. חשבון שירות הוא זהות שהתוכניות והשירותים שלכם יכולים להשתמש בה כדי לאמת את עצמם ולקבל גישה למשאבים של Google Cloud .
חשבונות שירות בניהול המשתמש כוללים חשבונות שירות שאתם יוצרים ומנהלים באופן מפורש באמצעות IAM, וחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, שמובנה בכל הפרויקטים של Google Cloud . סוכני שירות נוצרים אוטומטית ומריצים תהליכים פנימיים של Google בשמכם.
כשמשתמשים בחשבונות שירות, חשוב להבין את פרטי הכניסה שמוגדרים כברירת מחדל באפליקציה ולפעול לפי השיטות המומלצות שלנו לשימוש בחשבונות שירות כדי למנוע חשיפה של המשאבים לסיכון מיותר. הסיכונים הנפוצים ביותר הם הרחבת הרשאות או מחיקה בטעות של חשבון שירות שאפליקציה קריטית מסתמכת עליו.
שיטות מומלצות
מידע נוסף על שיטות מומלצות לניהול יעיל של זהויות וגישה מופיע במאמר בנושא אימות מפורש של כל ניסיון גישה.
חיוב
אופן התשלום על Google Cloud המשאבים שאתם צורכים הוא שיקול חשוב לעסק שלכם, וחלק חשוב מהקשר שלכם עם Google Cloud. אתם יכולים לנהל את החיוב בGoogle Cloud מסוף באמצעות החיוב ב-Cloud, לצד שאר סביבת הענן.
המושגים של היררכיית משאבים וחיוב קשורים זה לזה באופן הדוק, ולכן חשוב מאוד שאתם ובעלי העניין בעסק שלכם תבינו את המושגים האלה.
מידע נוסף על שיטות מומלצות, כלים וטכניקות שיעזרו לכם לעקוב אחרי העלויות ולשלוט בהן זמין במאמר אופטימיזציה של עלויות.
קישוריות ורשתות
מידע נוסף על תכנון הרשת ב- Google Cloud
אם סביבת המקור נמצאת אצל ספק אחר של שירותי ענן, יכול להיות שתצטרכו לקשר אותה לסביבת Google Cloud שלכם. מידע נוסף זמין במאמר בנושא תבניות לחיבור ספקי שירותי ענן אחרים ל- Google Cloud.
כשמעבירים נתונים ועומסי עבודה של סביבת ייצור אל Google Cloud, מומלץ לשקול איך הזמינות של פתרון הקישוריות יכולה להשפיע על הצלחת ההעברה. לדוגמה, אם תספקו את Cloud Interconnect בהתאם לטופולוגיות ספציפיות, תקבלו תמיכה בהסכם SLA ברמת הייצור.
כשמעבירים נתונים מסביבת המקור לסביבתGoogle Cloud , צריך להתאים את יחידת השידור המקסימלית (MTU) כדי להתחשב בתקורה של הפרוטוקול. כך אפשר לוודא שהנתונים יועברו בצורה יעילה ומדויקת. השינוי הזה יכול גם לעזור למנוע עיכובים שנגרמים מפיצול נתונים ומבעיות בביצועי הרשת. לדוגמה, אם אתם משתמשים ב-Cloud VPN כדי לחבר את סביבת המקור לסביבת Google Cloud , יכול להיות שתצטרכו להגדיר את ה-MTU לערך נמוך יותר כדי להתאים את תקורה של פרוטוקול ה-VPN בכל יחידת שידור.
כדי למנוע בעיות בחיבור במהלך המעבר אלGoogle Cloud, מומלץ:
- מוודאים שרשומות ה-DNS נפתרות בסביבת המקור ובסביבתGoogle Cloud .
- מוודאים שניתוב הרשת בין סביבת המקור לבין סביבתGoogle Cloud מופץ בצורה נכונה בין הסביבות.
אם אתם צריכים להקצות ולהשתמש בכתובות IPv4 ציבוריות משלכם ב-VPC, תוכלו לעיין במאמר בנושא הוספת כתובת IP משלכם.
הסבר על אפשרויות DNS
Cloud DNS יכול לשמש כשרת DNS ציבורי. מידע נוסף על הטמעה של Cloud DNS זמין במאמר שיטות מומלצות לשימוש ב-Cloud DNS.
אם אתם צריכים להתאים אישית את האופן שבו Cloud DNS מגיב לשאילתות בהתאם למקור או ליעד שלהן, תוכלו לעיין במאמר סקירה כללית של מדיניות DNS. לדוגמה, אתם יכולים להגדיר את Cloud DNS להעברת שאילתות לשרתי ה-DNS הקיימים שלכם, או לבטל את התגובות של DNS פרטי על סמך שם השאילתה.
שירות נפרד אך דומה, שנקרא DNS פנימי, כלול ב-VPC. במקום להעביר ולהגדיר ידנית את שרתי ה-DNS שלכם, אתם יכולים להשתמש בשירות ה-DNS הפנימי עבור הרשת הפרטית שלכם. מידע נוסף זמין במאמר סקירה כללית של DNS פנימי.
הסבר על העברת נתונים
ניהול רשתות מקומיות ותמחור שלהן שונים באופן מהותי מניהול רשתות בענן ותמחור שלהן. כשמנהלים מרכז נתונים משלכם או מתקן שיתוף מיקום, התקנת נתבים, מתגים וכבלים מחייבת הוצאה קבועה מראש. ב-Cloud, אתם מחויבים על העברת נתונים ולא על עלות קבועה של התקנת חומרה, בנוסף לעלות השוטפת של תחזוקה. כדי לתכנן ולנהל את עלויות העברת הנתונים בענן בצורה מדויקת, חשוב להבין את עלויות העברת הנתונים.
כשמתכננים את ניהול התנועה, יש שלוש דרכים שבהן מתבצע חיוב:
- תעבורת נתונים נכנסת (ingress): תעבורת נתונים ברשת שנכנסת לסביבתGoogle Cloud שלכם ממיקומים חיצוניים. המיקומים האלה יכולים להיות באינטרנט הציבורי, במיקומים מקומיים או בסביבות ענן אחרות. תעבורת נתונים נכנסת (ingress) היא בחינם ברוב השירותים ב-Google Cloud. שירותים מסוימים שמטפלים בניהול תעבורה שפונה לאינטרנט, כמו Cloud Load Balancing, Cloud CDN ו-Google Cloud Armor, מחייבים לפי כמות תעבורת הנתונים הנכנסת שהם מטפלים בה.
- תעבורת נתונים יוצאת (egress): תעבורת נתונים ברשת שיוצאת מהסביבה שלכם ב-Google Cloud בכל דרך שהיא. חיובים על תעבורת נתונים יוצאת חלים על Google Cloud שירותים רבים, כולל Compute Engine, Cloud Storage, Cloud SQL ו-Cloud Interconnect.
- תעבורה אזורית ותעבורה בין אזורים: תעבורת נתונים ברשת שחוצה גבולות אזוריים או גבולות בין אזורים ב- Google Cloud עשויה להיות כפופה גם לחיובים על רוחב פס. החיובים האלה יכולים להשפיע על האופן שבו תבחרו לתכנן את האפליקציות שלכם לצורך תוכנית התאוששות מאסון (DR) וזמינות גבוהה. בדומה לחיובים על תעבורת נתונים יוצאת, חיובים על תעבורת נתונים בין אזורים ובין אזורי זמינות חלים על הרבהGoogle Cloud שירותים, וחשוב לקחת אותם בחשבון כשמתכננים זמינות גבוהה והתאוששות מאסון. לדוגמה, שליחת תנועה לרפליקה של מסד נתונים באזור אחר כפופה לחיובים על תנועה בין אזורים
אוטומציה ושליטה בהגדרת הרשת
ב- Google Cloud, השכבה הפיזית של הרשת עוברת וירטואליזציה, ואתם פורסים ומגדירים את הרשת באמצעות רשת מוגדרת בתוכנה (SDN). כדי לוודא שהרשת מוגדרת באופן עקבי וניתן לשחזור, צריך להבין איך לפרוס את הסביבות ולבטל את הפריסה שלהן באופן אוטומטי. אפשר להשתמש בכלים של IaC, כמו Terraform.
אבטחה
הדרך שבה אתם מנהלים את המערכות שלכם ב-Google Cloudושומרים על האבטחה שלהן, והכלים שבהם אתם משתמשים, שונים מהדרך שבה אתם מנהלים תשתית מקומית. הגישה שלכם תשתנה ותתפתח לאורך זמן כדי להתאים לאיומים חדשים, למוצרים חדשים ולמודלים משופרים של אבטחה.
האחריות שאתם חולקים עם Google עשויה להיות שונה מהאחריות של הספק הנוכחי שלכם, והבנת השינויים האלה היא קריטית כדי להבטיח את המשך האבטחה והתאימות של עומסי העבודה שלכם. אבטחה חזקה שניתן לאמת אותה ועמידה בדרישות הרגולטוריות הן לרוב דרישות שקשורות זו לזו. הן מתחילות בשיטות ניהול ופיקוח חזקות, ביישום עקבי של שיטות מומלצות ובזיהוי ומעקב פעילים של איומים. Google Cloud
למידע נוסף על תכנון סביבה מאובטחת ב- Google Cloud, אפשר לעיין במאמר בחירת אבטחה לאזור הנחיתה ב- Google Cloud .
מעקב, התראות ורישום ביומן
מידע נוסף על הגדרת מעקב, התראות ורישום ביומן זמין במאמרים הבאים:
פיקוח
כדאי לשאול את השאלות הבאות לגבי הארגון שלכם:
- איך אפשר לוודא שהמשתמשים מקבלים תמיכה ועומדים בדרישות התאימות, ושהם פועלים בהתאם למדיניות העסק?
- אילו אסטרטגיות זמינות לכם כדי לתחזק ולארגן את המשתמשים והמשאבים ב-Google Cloud ?
ניהול יעיל הוא חיוני כדי להבטיח את האמינות והאבטחה של הנכסים ב- Google Cloudולשמור עליהם. כמו בכל מערכת, האנטרופיה גדלה באופן טבעי עם הזמן, ואם לא בודקים אותה, היא עלולה לגרום להתפשטות של הענן ולאתגרים אחרים שקשורים לתחזוקה. ללא ניהול יעיל, הבעיות האלה עלולות להצטבר ולהשפיע על היכולת שלכם להשיג את היעדים העסקיים ולצמצם את הסיכון. תכנון מוקפד ואכיפה של סטנדרטים לגבי מוסכמות שמות, אסטרטגיות תיוג, בקרות גישה, בקרות עלויות ורמות שירות הם מרכיב חשוב באסטרטגיית המעבר לענן. במובן רחב יותר, תהליך הפיתוח של אסטרטגיית ניהול יוצר תיאום בין בעלי העניין וההנהלה העסקית.
תמיכה בתאימות רציפה
כדי לתמוך בתאימות של משאביGoogle Cloud בכל הארגון, כדאי ליצור אסטרטגיה עקבית למתן שמות למשאבים ולארגון שלהם. ב-Google Cloud יש כמה שיטות להוספת הערות למשאבים ולאכיפת מדיניות עליהם:
- תגי אבטחה מאפשרים לסווג משאבים כדי לקבל תובנות בנושא אבטחה מ-Security Command Center, ולאכוף מדיניות על קבוצות של משאבים.
- תוויות יכולות לעזור לכם לעקוב אחרי ההוצאות על משאבים בחיוב ב-Cloud, ולספק תובנות נוספות ב-Cloud Logging.
- תגים לחומות אש מאפשרים להגדיר מקורות ויעדים במדיניות חומת אש בין רשתות גלובליות ובמדיניות חומת אש בין רשתות אזוריות.
מידע נוסף זמין במאמר בנושא סיכון ותאימות כקוד.
המאמרים הבאים
- כך מטמיעים ב- Google Cloud בסיס מאובטח.
- כדאי להמשיך בהעברה לענן ולבדוק איך מעבירים את הנתונים אל Google Cloud.
- איפה אפשר לקבל עזרה בתהליך ההעברה?
- מומלץ להשתתף בקורס ההדרכה של Google Skills בנושא מעבר אל Google Cloud.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחברים:
- Marco Ferrari | Cloud Solutions Architect
- Travis Webb | Solution Architect