פיתוח ארכיטקטורות היברידיות ומרובות עננים (multi-cloud) באמצעות Google Cloud

Last reviewed 2024-11-27 UTC

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

ערכת המסמכים לדפוסי ארכיטקטורה היברידיים ומרובי עננים (multi-cloud) מורכבת מהחלקים הבאים:

אפשר לקרוא כל אחד מהמאמרים האלה בנפרד, אבל כדי להפיק מהם את המרב, מומלץ לקרוא אותם ברצף לפני שמקבלים החלטה לגבי הארכיטקטורה.

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

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

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

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

סקירה כללית על ענן היברידי ועל סביבות מרובות עננים

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

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

המונח multicloud מתאר ארכיטקטורה שמשלבת לפחות שני ספקי CSP ציבוריים. כפי שמודגם בתרשים הבא, לפעמים הארכיטקטורה הזו כוללת סביבת מחשוב פרטית (שעשויה לכלול שימוש ברכיב ענן פרטי). הסידור הזה נקרא ארכיטקטורה היברידית ומרובת עננים.

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

שותפים ביצירת התוכן

הכותב: Marwan Al Shawi | Partner Customer Engineer

תורמי תוכן אחרים:

גורמים, שיקולים, אסטרטגיה וגישות

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

מטרות

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

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

  • אילו יעדים עסקיים מובילים להחלטה לאמץ ארכיטקטורה היברידית או מרובת עננים?
  • אילו יעדים עסקיים וטכניים אפשר להשיג באמצעות ארכיטקטורה היברידית או מרובת עננים?
  • אילו גורמים עסקיים השפיעו על היעדים האלה?
  • מהן הדרישות העסקיות הספציפיות?

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

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

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

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

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

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

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

מניעים עסקיים וטכניים

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

  • הקפדה על חוקים ותקנות בנושא ריבונות נתונים.
  • הפחתת הוצאות הוניות (CAPEX) או הוצאות כלליות על IT בעזרת ניהול פיננסי בענן ושיטות אופטימיזציה של עלויות כמו FinOps.
    • המעבר לענן יכול להתבסס על תרחישים שעוזרים להפחית את הוצאות ההון, כמו בניית פתרון לשחזור מאסון בארכיטקטורה היברידית או מרובת עננים.
  • שיפור חוויית המשתמש.
  • הגברת הגמישות והזריזות כדי להגיב לשינויים בביקוש בשוק.
  • שיפור השקיפות לגבי עלויות וצריכת משאבים.

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

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

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

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

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

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

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

כשחוקי שמירת נתונים במדינה או באזור מסוימים מחייבים אחסון של נתונים רגישים – כמו פרטים אישיים מזהים (PII) – במיקום הזה, גישה מרובת עננים יכולה לספק פתרון תואם. שימוש בשני ספקי CSP באזור אחד כדי לספק חוסן (resilience) להפסקות שירות יכול לעזור לכם לעמוד בדרישות הרגולטוריות וגם בדרישות הזמינות.

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

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

כדאי להביא בחשבון את כל הגורמים האלה כשמעריכים את האפשרות להשתמש בארכיטקטורה מרובת עננים כדי לשפר את העמידות.

כשבודקים את ההיתכנות של ארכיטקטורה מרובת-עננים, חשוב לקחת בחשבון את היתרונות לטווח הארוך. לדוגמה, פריסת אפליקציות בכמה עננים לצורך תוכנית התאוששות מאסון (DR) או שיפור המהימנות עשויה להגדיל את העלויות בטווח הקצר, אבל יכולה למנוע הפסקות או תקלות. כשלים כאלה עלולים לגרום לנזק כספי ולנזק למוניטין בטווח הארוך. לכן חשוב להשוות בין העלויות לטווח הקצר לבין הערך הפוטנציאלי לטווח הארוך של אימוץ גישת מרובה עננים (multi-cloud). בנוסף, הערך הפוטנציאלי לטווח הארוך יכול להשתנות בהתאם לגודל הארגון, להיקף הטכנולוגיה, לחשיבות של פתרון הטכנולוגיה ולתחום הפעילות.

ארגונים שמתכננים ליצור בהצלחה סביבה היברידית או מרובת עננים (multi-cloud) צריכים לשקול להקים מרכז מצוינות בענן (COE). צוות COE יכול להפוך לצינור להעברת מידע, שיעזור לצוותים פנימיים בארגון שלכם לשרת את העסק במהלך המעבר לענן. מרכז מצוינות הוא אחת הדרכים שבהן הארגון יכול לאמץ את הענן מהר יותר, להניע סטנדרטיזציה ולשמור על התאמה חזקה יותר בין האסטרטגיה העסקית לבין ההשקעות בענן.

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

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

מניעים טכניים

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

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

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

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

החלטות בנוגע לעיצוב הטכני

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

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

שימוש Google Cloud בארכיטקטורות היברידיות ומרובות עננים (multi-cloud)

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

  • יכולת פעולה הדדית
  • ניהול הענן
  • עלות
  • אבטחה

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

‫Google היא גם אחת מהתורמות הגדולות ביותר לסביבה העסקית של קוד פתוח, והיא עובדת עם קהילת הקוד הפתוח כדי לפתח טכנולוגיות קוד פתוח מוכרות כמו Kubernetes. כשמשיקים את Kubernetes כשירות מנוהל, הוא יכול לעזור לצמצם את המורכבות של ניהול ואבטחה של סביבות היברידיות ומרובות עננים (multi-cloud).

תכנון אסטרטגיה היברידית ומרובת עננים (multi-cloud)

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

מגדירים את החזון והיעדים ומגיעים להסכמה לגביהם

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

חשוב לדעת שקשה מאוד להגדיר תוכנית שמתייחסת לכל עומסי העבודה ולכל הדרישות, במיוחד בסביבת IT מורכבת. בנוסף, התכנון לוקח זמן ויכול להוביל לחזונות שונים של בעלי עניין.

כדי להימנע ממצבים כאלה, כדאי לגבש הצהרת חזון שעונה על השאלות הבאות (לפחות):

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

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

לזהות ולחדד שיקולים אחרים

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

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

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

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

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

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

תכנון אסטרטגיה של ארכיטקטורה היברידית ומרובת עננים (multi-cloud)

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

בתרשים הזרימה הבא מפורטים השלבים הלוגיים ליצירת אסטרטגיה כזו.

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

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

חשוב לזכור שהעברה היא תהליך. בתרשים הבא מוצגים השלבים בתהליך הזה, כפי שמתואר במאמר מעבר אל Google Cloud.

נתיב העברה עם ארבעה שלבים.

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

שלב ההערכה

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

כדי להתחיל, בוחרים עומס עבודה שלא קריטי לעסק או שלא קשה מדי להעברה (עם תלות מינימלית או ללא תלות בעומס עבודה בסביבות אחרות), אבל מספיק אופייני כדי לשמש כתוכנית פעולה לפריסות או להעברות עתידיות.

מומלץ שהעומס או האפליקציה שתבחרו יהיו חלק מתרחיש שימוש או מפונקציה עסקית ממוקדים, שיש להם השפעה מדידה על העסק אחרי שהם מסתיימים.

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

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

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

יש כמה סוגים של כלים, כמו Google Cloud Migration Center, שיעזרו לכם להעריך את עומסי העבודה הקיימים. מידע נוסף זמין במאמר העברה אל Google Cloud: בחירה של כלי להערכה.

מבחינת מודרניזציה של עומסי עבודה (workload), כלי הערכת ההתאמה עוזר להעריך עומס עבודה של מכונה וירטואלית כדי לקבוע אם עומס העבודה מתאים למודרניזציה לקונטיינר או להעברה ל-Compute Engine.

שלב בתוכנית

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

  1. פיתוח אסטרטגיית העברה עם סדר עדיפויות, שמגדירה גלי העברה של אפליקציות ונתיבים.
  2. זיהוי דפוס הארכיטקטורה של אפליקציה היברידית או מרובת עננים ברמה גבוהה שרלוונטי לאפליקציה.
  3. בוחרים תבנית של ארכיטקטורת רשת שתומכת בתבנית של ארכיטקטורת האפליקציה שנבחרה.

מומלץ לשלב את דפוס הרשת בענן עם העיצוב של אזור הנחיתה. העיצוב של אזור הנחיתה משמש כאלמנט בסיסי מרכזי בארכיטקטורות היברידיות ומרובות עננים (multi-cloud) באופן כללי. העיצוב צריך להשתלב בצורה חלקה עם הדפוסים האלה. אל תעצבו את אזור הנחיתה בבידוד. אפשר להתייחס לתבניות הרשת האלה כאל קבוצת משנה של עיצוב אזור הנחיתה.

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

בשלב הזה, חשוב לקחת בחשבון את הדברים הבאים:

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

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

שלב הפריסה

בשלב הפריסה, אתם מוכנים להתחיל להוציא לפועל את אסטרטגיית ההעברה שלכם. לאור המספר הפוטנציאלי של הדרישות, מומלץ לפעול בגישה איטרטיבית.

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

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

שלב האופטימיזציה

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

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

הערכת עומסי עבודה (workloads) פוטנציאליים

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

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

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

  • הפוטנציאל לבידול בשוק או לחדשנות שמתאפשרים באמצעות שימוש בשירותי ענן כדי להפעיל פונקציות או יכולות עסקיות מסוימות, כמו יכולות של בינה מלאכותית שמשתמשות בנתונים קיימים מקומיים כדי לאמן מודלים של למידת מכונה.
  • חיסכון פוטנציאלי בעלות הבעלות הכוללת (TCO) של אפליקציה.
  • שיפורים פוטנציאליים בזמינות, בעמידות, באבטחה או בביצועים – לדוגמה, הוספת אתר לשחזור נתונים (DR) בענן.
  • קיצור אפשרי של תהליכי הפיתוח וההפצה – לדוגמה, בניית סביבות הפיתוח והבדיקה בענן.

הגורמים הבאים יכולים לעזור לכם להעריך את סיכוני ההעברה:

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

הגורמים הבאים יכולים לעזור לכם להעריך את הקשיים הטכניים של מעבר:

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

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

גישות ארכיטקטוניות לאימוץ ארכיטקטורה היברידית או מרובת עננים

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

עדיפות לענן

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

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

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

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

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

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

העברה ומודרניזציה

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

היעדים העיקריים של מודרניזציה של עומסי עבודה הם:

  • להשיג גמישות רבה יותר כדי שתוכלו להתאים את עצמכם לדרישות משתנות.
  • להפחית את העלויות של התשתית והפעולות.
  • שיפור האמינות והעמידות כדי למזער את הסיכון.

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

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

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

לדוגמה, אפשר לבצע רפקטורינג או שינוי בארכיטקטורה של אפליקציה גדולה ומונוליתית שמבוססת על מכונה וירטואלית, ולהפוך אותה לכמה מיקרו-שירותים עצמאיים, על סמך ארכיטקטורת מיקרו-שירותים מבוססת-ענן. בדוגמה הזו, ארכיטקטורת המיקרו-שירותים משתמשת Google Cloud בשירותי קונטיינרים מנוהלים כמו Google Kubernetes Engine‏ (GKE) או Cloud Run. עם זאת, אם הארכיטקטורה או התשתית של אפליקציה לא נתמכות בסביבת הענן של היעד כמו שהן, כדאי להתחיל עם שינוי פלטפורמה, שינוי מבנה או שינוי ארכיטקטורה של אסטרטגיית ההעברה כדי להתגבר על המגבלות האלה, אם אפשר.

כשמשתמשים באחת מגישות ההעברה האלה, כדאי לשקול מודרניזציה של האפליקציות (אם הדבר רלוונטי ואפשרי). תהליך המודרניזציה עשוי לדרוש אימוץ ויישום של Site Reliability Engineering (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 עוזר ללקוחות ליישם שיטות מומלצות, להפחית את הסיכון, לשלוט בעלויות ולפשט את הדרך להצלחה בענן.

שיקולים נוספים

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

לארגן את הקוד מחדש

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

  • אפשר לשפר את תהליך הפריסה.
  • כדי להאיץ את קצב הפרסום ולקצר את מחזורי המשוב, כדאי להשקיע בתשתית ובכלים של אינטגרציה רציפה (CI) ופריסה רציפה (CD).
  • אתם יכולים להשתמש בשינוי מבנה הקוד כבסיס לבנייה ולניהול של ארכיטקטורה היברידית עם ניידות של אפליקציות.

כדי שהגישה הזו תפעל בצורה טובה, בדרך כלל צריך להשקיע בתשתית ובכלים מקומיים. שילוב של Google Kubernetes Engine‏ (GKE) עם Google Distributed Cloud יכול להיות שימושי בגישה הזו לסביבות היברידיות. מידע נוסף על GKE מופיע בקטע הבא. לפרטים נוספים, אפשר לעיין גם בארכיטקטורת העזר של סביבת GKE Hybrid.

ניידות של עומסי עבודה

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

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

אוטומציה של תשתית

אוטומציה של תשתית היא חיונית לניידות בארכיטקטורות היברידיות ומרובות עננים (multi-cloud). אחת הגישות הנפוצות לאוטומציה של יצירת תשתית היא באמצעות תשתית כקוד (IaC). תשתית כקוד (IaC) כוללת ניהול של התשתית בקבצים במקום הגדרה ידנית של משאבים – כמו מכונת VM, קבוצת אבטחה או איזון עומסים – בממשק משתמש. ‫Terraform הוא כלי פופולרי של IaC שמאפשר להגדיר משאבי תשתית בקובץ. בנוסף, Terraform מאפשרת לבצע אוטומציה של יצירת המשאבים האלה בסביבות הטרוגניות.

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

אתם יכולים להשתמש בכלים לניהול תצורה כמו Ansible,‏ Puppet או Chef כדי ליצור תהליך פריסה והגדרה משותף. לחלופין, אפשר להשתמש בכלי ליצירת קובצי אימג' כמו Packer כדי ליצור קובצי אימג' של מכונות וירטואליות לפלטפורמות שונות. באמצעות קובץ תצורה משותף יחיד, אתם יכולים להשתמש ב-Packer וב-Cloud Build כדי ליצור אימג' של מכונה וירטואלית לשימוש ב-Compute Engine. לבסוף, אפשר להשתמש בפתרונות כמו Prometheus ו-Grafana כדי להבטיח מעקב עקבי בסביבות שונות.

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

שרשרת כלים מאפשרת ניידות של אפליקציות.

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

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

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

לדוגמה, אפשר להשתמש במודל משאבי Kubernetes כדי ליצור אוטומטית אשכולות Kubernetes באמצעות גישת הגדרה הצהרתית. אתם יכולים להשתמש ב-Deployment Manager convert כדי להמיר את התצורות והתבניות של Deployment Manager לפורמטים אחרים של תצורות הצהרתיות ש- Google Cloud תומך בהם (כמו Terraform ומודל המשאבים של Kubernetes), כך שהם יהיו ניידים כשמפרסמים אותם.

אפשר גם לשקול ליצור אוטומטית פרויקטים ומשאבים בתוך הפרויקטים האלה. האוטומציה הזו יכולה לעזור לכם לאמץ גישה של תשתית כקוד (IaC) להקצאת פרויקטים.

קונטיינרים ו-Kubernetes

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

קונטיינרים עוזרים לתוכנה שלכם לפעול בצורה מהימנה כשמעבירים אותה מסביבה אחת לסביבה אחרת. השימוש בקונטיינרים מפריד את האפליקציות מהתשתית של המארח, ולכן קל יותר לפרוס אותן בסביבות מחשוב שונות, כמו סביבות היברידיות וסביבות מרובות עננים (multi-cloud).

‫Kubernetes מטפל בתזמור, בפריסה, בהתאמה לעומס (scaling) ובניהול של האפליקציות בקונטיינרים. הוא בקוד פתוח ומנוהל על ידי Cloud Native Computing Foundation. שימוש ב-Kubernetes מספק את השירותים שמהווים את הבסיס לאפליקציה שמתמקדת בענן. אפשר להתקין ולהריץ את Kubernetes בסביבות מחשוב רבות, ולכן אפשר להשתמש בו גם כדי ליצור שכבת זמן ריצה משותפת בסביבות מחשוב שונות:

  • ‫Kubernetes מספק את אותם שירותים וממשקי API בסביבת מחשוב בענן או בסביבה פרטית. בנוסף, רמת ההפשטה גבוהה בהרבה בהשוואה לעבודה עם מכונות וירטואליות, מה שבדרך כלל מוביל לצורך בפחות עבודת הכנה ולשיפור הפרודוקטיביות של המפתחים.
  • בניגוד לשרשרת כלים מותאמת אישית, Kubernetes נמצאת בשימוש נרחב גם לפיתוח וגם לניהול אפליקציות, כך שתוכלו להסתמך על ידע קיים, על מסמכים ועל תמיכה של צד שלישי.
  • ‫Kubernetes תומך בכל הטמעות הקונטיינרים שבהן:
    • תמיכה ב-Kubernetes Container Runtime Interface (CRI)
    • הם אומצו בתעשייה לשימוש באפליקציות
    • לא קשורים לספק ספציפי

כשעומס עבודה פועל ב- Google Cloud, אפשר להימנע מהמאמץ של התקנה והפעלה של Kubernetes באמצעות פלטפורמת Kubernetes מנוהלת כמו GKE. כך צוות התפעול יכול להפסיק להתמקד ביצירה ובתחזוקה של תשתית, ולהתחיל להתמקד ביצירה ובתחזוקה של אפליקציות.

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

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

כדי לפשט את הניהול של פריסות מרובות אשכולות, אפשר להשתמש ב-GKE כדי להריץ אפליקציות מודרניות בכל מקום ובכל קנה מידה. ‫GKE כולל רכיבי קוד פתוח מנוהלים ועוצמתיים לאבטחת עומסי עבודה, לאכיפת כללי מדיניות תאימות ולמתן יכולות מעקב ופתרון בעיות ברשת.

כפי שמוצג בתרשים הבא, שימוש ב-GKE מאפשר להפעיל אפליקציות מרובות אשכולות כציים.

דיאגרמת מחסנית שמציגה את ההזדמנויות לניהול Fleet ש-GKE מציע.

‫GKE עוזר באפשרויות התכנון הבאות לתמיכה בארכיטקטורות היברידיות ומרובות עננים:

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

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

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

שיקולים לגבי ניוד עומסי עבודה

‫Kubernetes ו-GKE מספקים שכבת הפשטה לעומסי עבודה, שיכולה להסתיר את המורכבויות וההבדלים הרבים בין סביבות מחשוב. הרשימה הבאה מתארת כמה מההפשטות האלה:

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

העברת נתונים

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

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

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

אם יש לעסק סיווג נתונים לתעשיות מפוקחות, הסיווג הזה יכול לעזור לזהות מיקומי אחסון והגבלות על העברת נתונים בין אזורים עבור סוגים מסוימים של נתונים. מידע נוסף זמין במאמר בנושא Sensitive Data Protection. ‫Sensitive Data Protection הוא שירות מנוהל מלא שנועד לעזור לכם לגלות, לסווג ולהגן על נכסי הנתונים שלכם.

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

אבטחה

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

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

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

ארכיטקטורות היברידיות ומרובות עננים (multi-cloud) יכולות ליצור אתגרים נוספים בתחום האבטחה, כמו עקביות ויכולת צפייה. לכל ספק שירותי ענן ציבורי יש גישה משלו לאבטחה, כולל מודלים שונים, שיטות מומלצות, יכולות אבטחה של תשתיות ואבטחת אפליקציות, חובות תאימות ואפילו שמות שונים של שירותי אבטחה. חוסר העקביות הזה עלול להגביר את הסיכון לאבטחה. בנוסף, מודל האחריות המשותפת של כל ספק שירותי ענן יכול להיות שונה. חשוב לזהות ולהבין את הגבולות המדויקים של האחריות בארכיטקטורה מרובת עננים.

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

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

כדי לעזור לכם לתכנן ולעצב את פתרון הענן שלכם כך שיעמוד ביעדי האבטחה והתאימות שלכם, מומלץ לעייןGoogle CloudGoogle Cloudבמרכז לשיטות אבטחה מומלצות ובתוכנית לניהול יסודות האבטחה לארגונים.

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

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

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

  • כדאי לשקול ארכיטקטורת אבטחה מאוחדת בסביבות היברידיות ומרובות עננים (multi-cloud).

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

  • שימוש במספר אמצעי אבטחה.

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

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

  • כדאי להשתמש ב-Cloud Security Posture Management‏ (CSPM) כדי לזהות ולתקן בעיות בהגדרות האבטחה ואיומים על אבטחת הסייבר. ‫CSPM מספק גם הערכות של נקודות חולשה בסביבות היברידיות ומרובות עננים.

‫Security Command Center הוא פתרון מובנה לניהול אבטחה וסיכונים ב- Google Cloud, שעוזר לזהות טעויות בהגדרות, נקודות חולשה ועוד. ‫Security Health Analytics הוא כלי מנוהל לסריקת הערכת פגיעות. זו תכונה של Security Command Center שמזהה סיכוני אבטחה ונקודות חולשה בסביבתGoogle Cloud ומספקת המלצות לתיקון שלהם.

‫Mandiant Attack Surface Management for Google Cloud מאפשר לארגון שלכם לראות טוב יותר את הנכסים בסביבת מולטי-ענן או ענן היברידי. הוא מגלה באופן אוטומטי נכסים מכמה ספקי ענן, DNS ושטח התקפה חיצוני מורחב, כדי לספק לארגון שלכם הבנה מעמיקה יותר של המערכת האקולוגית שלו. אתם יכולים להשתמש במידע הזה כדי לתעדף את הטיפול בנקודות החולשה ובחשיפות שמציגות את הסיכון הגבוה ביותר.

  • פתרון לניהול אבטחת מידע ואירועים (SIEM) בענן: עוזר לאסוף ולנתח יומני אבטחה מסביבות היברידיות ומסביבות מרובות עננים כדי לזהות איומים ולהגיב להם. ‫Google Security Operations SIEM מבית Google Cloud עוזר לספק ניהול של אבטחת מידע ואירועים על ידי איסוף, ניתוח, זיהוי וחקר של כל נתוני האבטחה במקום אחד.

בניית ארכיטקטורות היברידיות ומרובות עננים (multi-cloud) באמצעות Google Cloud: מה השלב הבא