במסמך הזה מודגשים שיקולי העיצוב העיקריים שמשפיעים באופן משמעותי על הארכיטקטורה הכוללת של סביבות היברידיות ומרובות עננים. חשוב לנתח ולהעריך את השיקולים האלה באופן הוליסטי בכל ארכיטקטורת הפתרון, כולל כל עומסי העבודה ולא רק עומסי עבודה ספציפיים.
Refactor
במיגרציה של שינוי מבנה, אתם משנים את עומסי העבודה כדי לנצל את היכולות של הענן, ולא רק כדי שהם יפעלו בסביבה החדשה. אתם יכולים לשפר כל עומס עבודה מבחינת ביצועים, תכונות, עלות וחוויית משתמש. כפי שצוין במאמר Refactor: move and improve, בתרחישי refactoring מסוימים אפשר לשנות עומסי עבודה לפני העברתם לענן. גישת הרפקטורינג הזו מציעה את היתרונות הבאים, במיוחד אם המטרה שלכם היא לבנות ארכיטקטורה היברידית כארכיטקטורה ממוקדת לטווח ארוך:
- אפשר לשפר את תהליך הפריסה.
- כדי להאיץ את קצב הפרסום ולקצר את מחזורי המשוב, כדאי להשקיע בתשתית ובכלים של אינטגרציה רציפה (CI) ופריסה רציפה (CD).
- אתם יכולים להשתמש בשינוי מבנה הקוד כבסיס לבנייה ולניהול של ארכיטקטורה היברידית עם ניידות של אפליקציות.
כדי שהגישה הזו תפעל בצורה טובה, בדרך כלל צריך להשקיע בתשתית ובכלים מקומיים. שילוב של Google Kubernetes Engine (GKE) עם Google Distributed Cloud יכול להיות שימושי בגישה הזו לסביבות היברידיות. מידע נוסף על GKE מופיע בקטע הבא. לפרטים נוספים, אפשר לעיין גם בארכיטקטורת העזר של סביבת GKE Hybrid.
ניידות של עומסי עבודה
באמצעות ארכיטקטורות היברידיות וארכיטקטורות מרובות עננים, יכול להיות שתרצו להעביר עומסי עבודה בין סביבות המחשוב שמארחות את הנתונים שלכם. כדי לאפשר העברה חלקה של עומסי עבודה בין סביבות, כדאי לקחת בחשבון את הגורמים הבאים:
- אתם יכולים להעביר אפליקציה מסביבת מחשוב אחת לאחרת
בלי לשנות באופן משמעותי את האפליקציה ואת המודל התפעולי שלה:
- פריסת האפליקציות והניהול שלהן עקביים בסביבות מחשוב שונות.
- הנראות, ההגדרה והאבטחה עקביות בסביבות מחשוב שונות.
- היכולת להעביר עומס עבודה לא צריכה להתנגש עם העובדה שעומס העבודה הוא בעדיפות לענן.
אוטומציה של תשתית
אוטומציה של תשתית היא חיונית לניידות בארכיטקטורות היברידיות ומרובות עננים (multi-cloud). אחת הגישות הנפוצות לאוטומציה של יצירת תשתית היא באמצעות תשתית כקוד (IaC). תשתית כקוד (IaC) כוללת ניהול של התשתית בקבצים במקום הגדרה ידנית של משאבים – כמו מכונת VM, קבוצת אבטחה או איזון עומסים – בממשק משתמש. Terraform הוא כלי פופולרי של IaC שמאפשר להגדיר משאבי תשתית בקובץ. בנוסף, Terraform מאפשרת לבצע אוטומציה של יצירת המשאבים האלה בסביבות הטרוגניות.
למידע נוסף על פונקציות הליבה של Terraform שיכולות לעזור לכם להקצות ולנהל משאבים באופן אוטומטי, אפשר לעיין במאמר תוכניות ומודולים של Terraform ל- Google Cloud. 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 מאפשר לכם להפעיל אפליקציות מרובות אשכולות כציים.
GKE עוזר עם אפשרויות התכנון הבאות לתמיכה בארכיטקטורות היברידיות ורב-ענניות:
עיצוב ופיתוח של חוויות דומות לענן במערכות מקומיות או פתרונות מאוחדים למעבר של אפליקציות לסביבת GKE Hybrid. מידע נוסף זמין במאמר ארכיטקטורת עזר של סביבה היברידית ב-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 Cloudולצמצם את סיכוני האבטחה. Google Cloud
יעדי התאימות יכולים להיות שונים, כי הם מושפעים גם מתקנות ספציפיות לתעשייה וגם מדרישות רגולטוריות שונות באזורים ובמדינות שונים. מידע נוסף זמין ב Google Cloud מרכז המשאבים בנושא תאימות. אלה כמה מהגישות העיקריות המומלצות לתכנון ארכיטקטורה מאובטחת של ענן היברידי ושל multi-cloud:
פיתוח אסטרטגיה וארכיטקטורה מאוחדות ומותאמות אישית לאבטחת הענן. אסטרטגיות אבטחה היברידיות ורב-ענניות צריכות להיות מותאמות לצרכים ולמטרות הספציפיים של הארגון.
חשוב להבין את הארכיטקטורה והסביבה המטורגטות לפני שמטמיעים אמצעי בקרה לאבטחה, כי כל סביבה יכולה להשתמש בתכונות, בהגדרות ובשירותים שונים.
כדאי לשקול ארכיטקטורת אבטחה מאוחדת בסביבות היברידיות ומרובות עננים.
ליצור סטנדרטיזציה של תכנון ופריסות בענן, במיוחד של תכנון ויכולות אבטחה. הפעולה הזו יכולה לשפר את היעילות ולאפשר ניהול מאוחד של המדיניות ושל כלי הניהול.
שימוש במספר אמצעי אבטחה.
בדרך כלל, אף אמצעי בקרה יחיד לא יכול לתת מענה הולם לכל דרישות ההגנה על האבטחה. לכן, ארגונים צריכים להשתמש בשילוב של אמצעי בקרה לאבטחה במסגרת גישה של הגנה בשכבות, שנקראת גם הגנה לעומק.
מעקב ושיפור מתמשך של מצבי האבטחה: הארגון צריך לעקוב אחרי הסביבות השונות שלו כדי לזהות איומי אבטחה ונקודות חולשה. הארגון צריך גם לשאוף לשפר באופן מתמיד את אמצעי האבטחה שלו.
כדאי להשתמש ב-Cloud Security Posture Management (CSPM) כדי לזהות ולתקן בעיות בהגדרות האבטחה ואיומים על אבטחת הסייבר. בנוסף, CSPM מספק הערכות של נקודות חולשה בסביבות היברידיות ומרובות עננים (multi-cloud).
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 עוזר לספק ניהול של אבטחת מידע ואירועים על ידי איסוף, ניתוח, זיהוי וחקר של כל נתוני האבטחה במקום אחד.