המסמך הזה מתמקד בהסבר איך להשתמש בשיקולים עסקיים מוגדרים מראש כשמתכננים אסטרטגיה היברידית ומרובת עננים. המאמר הזה מרחיב את ההנחיות שבמאמר גורמים, שיקולים, אסטרטגיה וגישות. במאמר הזה מוגדרים ומנותחים השיקולים העסקיים שארגונים צריכים לקחת בחשבון כשהם מתכננים אסטרטגיה כזו.
הבהרה והסכמה לגבי החזון והיעדים
בסופו של דבר, המטרה העיקרית של אסטרטגיה היברידית או מרובת עננים היא להשיג את הדרישות העסקיות שזוהו ואת היעדים הטכניים המשויכים לכל תרחיש שימוש עסקי, בהתאם ליעדים עסקיים ספציפיים. כדי להשיג את היעד הזה, צריך ליצור תוכנית מובנית היטב שכוללת את ההיבטים הבאים:
- אילו עומסי עבודה יפעלו בכל סביבת מחשוב.
- אילו דפוסי ארכיטקטורה של אפליקציות להחיל על כמה עומסי עבודה.
- באיזו טכנולוגיה ותבנית של ארכיטקטורת רשת להשתמש.
חשוב לדעת שקשה מאוד להגדיר תוכנית שמתייחסת לכל עומסי העבודה ולכל הדרישות, במיוחד בסביבת IT מורכבת. בנוסף, תהליך התכנון לוקח זמן ויכול להוביל לחזונות שונים של בעלי עניין.
כדי להימנע ממצבים כאלה, כדאי לגבש הצהרת חזון שעונה על השאלות הבאות (לפחות):
- מהו תרחיש השימוש העסקי המטורגט להשגת יעדים עסקיים ספציפיים?
- למה הגישה הנוכחית וסביבת המחשוב לא מספיקות כדי להשיג את היעדים העסקיים?
- מהם ההיבטים הטכנולוגיים העיקריים שצריך לבצע להם אופטימיזציה באמצעות הענן הציבורי?
- למה ואיך הגישה החדשה תבצע אופטימיזציה ותעזור לכם להשיג את היעדים העסקיים?
- כמה זמן אתם מתכננים להשתמש בהגדרה היברידית או מרובת עננים?
הסכמה על היעדים העסקיים והטכניים העיקריים ועל הגורמים המניעים, ולאחר מכן קבלת אישור מהגורמים הרלוונטיים, יכולים לספק בסיס לשלבים הבאים בתהליך התכנון. כדי להתאים את הפתרון המוצע לחזון הארכיטקטוני הכולל של הארגון, חשוב לתאם עם הצוות ועם הגורמים הרלוונטיים שאחראים על הובלת היוזמה הזו ועל המימון שלה.
לזהות ולחדד שיקולים אחרים
כשמתכננים ארכיטקטורה היברידית או מרובת עננים, חשוב לזהות את המגבלות הארכיטקטוניות והתפעוליות של הפרויקט ולהסכים עליהן.
בצד התפעול, הרשימה החלקית הבאה כוללת כמה דרישות שעשויות ליצור מגבלות שכדאי לקחת בחשבון כשמתכננים את הארכיטקטורה:
- ניהול והגדרה של כמה עננים בנפרד לעומת בניית מודל הוליסטי לניהול ולאבטחה של סביבות ענן שונות.
- הבטחת עקביות באימות, בהרשאה, בביקורת ובמדיניות בכל הסביבות.
- שימוש בכלים ותהליכים עקביים בכל הסביבות כדי לספק תמונה הוליסטית של האבטחה, העלויות וההזדמנויות לאופטימיזציה.
- שימוש בתקנים עקביים של תאימות ואבטחה כדי להחיל ניהול מאוחד.
בצד של תכנון הארכיטקטורה, המגבלות הגדולות ביותר נובעות לרוב ממערכות קיימות, ויכולות לכלול את הדברים הבאים:
- תלות בין אפליקציות
- דרישות הביצועים וזמן האחזור לתקשורת בין מערכות
- הסתמכות על חומרה או מערכות הפעלה שאולי לא זמינות בענן הציבורי
- הגבלות רישוי
- תלות בזמינות של יכולות נדרשות באזורים שנבחרו בארכיטקטורה של כמה עננים
מידע נוסף על שיקולים אחרים שקשורים לניוד עומסי עבודה, להעברת נתונים ולשיקולי אבטחה זמין במאמר שיקולים נוספים.
תכנון אסטרטגיה של ארכיטקטורה היברידית ומרובת עננים (multi-cloud)
אחרי שתבהירו את הפרטים הספציפיים של היעדים העסקיים והטכניים עם הדרישות העסקיות המשויכות (ובאופן אידיאלי, אחרי שתבהירו ותסכימו על הצהרת חזון), תוכלו לבנות את האסטרטגיה שלכם ליצירת ארכיטקטורה היברידית או מרובת עננים.
בתרשים הזרימה הבא מפורטים השלבים הלוגיים ליצירת אסטרטגיה כזו.
כדי לעזור לכם לקבוע את היעדים והצרכים הטכניים של הארכיטקטורה ההיברידית או מרובת העננים, השלבים בתרשים הזרימה הקודם מתחילים בדרישות וביעדים העסקיים. אופן היישום של האסטרטגיה יכול להשתנות בהתאם ליעדים, לגורמים המניעים ולנתיב המעבר הטכנולוגי של כל תרחיש לדוגמה בעסק.
חשוב לזכור שהמיגרציה היא תהליך. בתרשים הבא מוצגים השלבים בתהליך הזה, כפי שמתואר במאמר מעבר אל Google Cloud.
בקטע הזה מוסבר על השלבים 'הערכה', 'תכנון', 'פריסה' ו'אופטימיזציה' שמוצגים בתרשים שלמעלה. המידע הזה מוצג בהקשר של העברה היברידית או העברה לריבוי עננים. מומלץ להתאים כל העברה להנחיות ולשיטות המומלצות שמופיעות בקטע על נתיב ההעברה במדריך בנושא העברה אל Google Cloud . יכול להיות שהשלבים האלה יחולו על כל עומס עבודה בנפרד, ולא על כל עומסי העבודה בבת אחת. בכל נקודת זמן, יכול להיות שעומסי עבודה שונים יהיו בשלבים שונים:
שלב ההערכה
בשלב הערכה, מבצעים הערכה ראשונית של עומסי העבודה. במהלך השלב הזה, כדאי להתייחס ליעדים שמפורטים במסמכי התכנון של החזון והאסטרטגיה. מחליטים על תוכנית העברה על ידי זיהוי רשימה של עומסי עבודה שיכולים להפיק תועלת מפריסה או מהעברה לענן הציבורי.
כדי להתחיל, בוחרים עומס עבודה שלא קריטי לעסק או שלא קשה מדי להעברה (עם תלות מינימלית או ללא תלות בעומס עבודה בסביבות אחרות), אבל מספיק אופייני כדי לשמש כתוכנית פעולה לפריסות או להעברות עתידיות.
מומלץ שהעומס או האפליקציה שתבחרו יהיו חלק מתרחיש שימוש או פונקציה עסקיים ממוקדים, שיש להם השפעה מדידה על העסק אחרי שהם מסתיימים.
כדי להעריך ולצמצם את הסיכונים הפוטנציאליים של המיגרציה, מומלץ לבצע הערכת סיכוני מיגרציה. חשוב להעריך את עומס העבודה המועמד כדי לקבוע אם הוא מתאים למיגרציה לסביבת מולטי-ענן. ההערכה הזו כוללת בחינה של היבטים שונים של האפליקציות והתשתית, כולל:
- דרישות התאימות של האפליקציה לספקי הענן שבחרתם
- מודלים של תמחור
- תכונות האבטחה שמוצעות על ידי ספקי שירותי הענן שבחרתם
- דרישות ליכולת פעולה הדדית של אפליקציות
הפעלת הערכה עוזרת גם לזהות דרישות לשמירה על פרטיות הנתונים, דרישות תאימות, דרישות עקביות ופתרונות בסביבות ענן מרובות. הסיכונים שתזהו יכולים להשפיע על עומסי העבודה שתבחרו להעביר או להפעיל.
יש כמה סוגים של כלים, כמו Google Cloud Migration Center, שיעזרו לכם להעריך את עומסי העבודה הקיימים. מידע נוסף זמין במאמר מעבר אל Google Cloud: בחירה של כלי להערכה.
מבחינת מודרניזציה של עומסי עבודה, כלי הערכת ההתאמה עוזר להעריך עומס עבודה של מכונה וירטואלית כדי לקבוע אם עומס העבודה מתאים למודרניזציה לקונטיינר או להעברה ל-Compute Engine.
שלב בתוכנית
בשלב התכנון, מתחילים עם האפליקציות שזוהו ועומסי העבודה הנדרשים בענן ומבצעים את המשימות הבאות:
- פיתוח אסטרטגיית העברה עם סדר עדיפויות שמגדירה גלי העברה של אפליקציות ונתיבים.
- מזהים את דפוס הארכיטקטורה של אפליקציה היברידית או מרובת עננים ברמה גבוהה שרלוונטיים.
- בוחרים תבנית ארכיטקטורת רשת שתומכת בתבנית ארכיטקטורת האפליקציה שנבחרה.
מומלץ לשלב את דפוס הרשת בענן עם העיצוב של אזור הנחיתה. העיצוב של אזור הנחיתה הוא רכיב בסיסי חשוב בארכיטקטורות היברידיות ורב-ענניות. העיצוב צריך להשתלב בצורה חלקה עם הדפוסים האלה. אל תעצבו את אזור הנחיתה בנפרד. דפוסי הרשת האלה הם קבוצת משנה של העיצוב של אזור הנחיתה.
אזור נחיתה יכול לכלול אפליקציות שונות, שלכל אחת מהן יש תבנית ארכיטקטורת רשת שונה. בנוסף, בשלב הזה חשוב להחליט על העיצוב של Google Cloud הארגון, הפרויקטים והיררכיית המשאבים כדי להכין את אזור הנחיתה של סביבת הענן לשילוב ולפריסה היברידיים או מרובי עננים.
בשלב הזה, חשוב לקחת בחשבון את הדברים הבאים:
- מגדירים את הגישה להעברה ולמודרניזציה. בהמשך המדריך הזה יש מידע נוסף על גישות להעברה. מידע נוסף זמין גם בקטע סוגי העברות במאמר מעבר אל Google Cloud.
- משתמשים בממצאים משלב ההערכה והגילוי. מתאימים אותם לעומס העבודה המועמד שמתכננים להעביר. לאחר מכן מפתחים תוכנית לגלי העברה של אפליקציות. התוכנית צריכה לכלול את הדרישות המשוערות לגודל המשאבים שנקבעו במהלך שלב ההערכה.
- הגדרת מודל התקשורת שנדרש בין האפליקציות המבוזרות ובין רכיבי האפליקציה עבור הארכיטקטורה ההיברידית או מרובת העננים המיועדת.
- בוחרים ארכיטיפ פריסה מתאים לפריסת עומס העבודה, כמו אזורי, אזורי, רב-אזורי או גלובלי, עבור דפוס הארכיטקטורה שנבחר. הארכיטיפ שתבחרו יהווה את הבסיס לבניית ארכיטקטורות פריסה ספציפיות לאפליקציה, שמותאמות לצרכים העסקיים והטכניים שלכם.
- קובעים קריטריונים למדידת הצלחת המיגרציה, עם אבני דרך ברורות לכל שלב או גל של המיגרציה. חשוב לבחור קריטריונים, גם אם המטרה הטכנית היא להגדיר את הארכיטקטורה ההיברידית כהגדרה לטווח קצר.
- הגדרת הסכמי רמת שירות (SLA) ומדדי ביצועים מרכזיים (KPI) לאפליקציות כשמפעילים אותן בהגדרה היברידית, במיוחד לאפליקציות שיש להן רכיבים מבוזרים בכמה סביבות.
מידע נוסף זמין במאמר מידע על תכנון העברה, שיעזור לכם לתכנן העברה מוצלחת ולמזער את הסיכונים הכרוכים בה.
שלב הפריסה
בשלב הפריסה, אתם מוכנים להתחיל להוציא לפועל את אסטרטגיית ההעברה. בהתחשב במספר הדרישות הפוטנציאלי, מומלץ להשתמש בגישה איטרטיבית.
נותנים עדיפות לעומסי העבודה על סמך גלי ההעברה והאפליקציות שפיתחתם בשלב התכנון. בארכיטקטורות היברידיות ומרובות עננים (multi-cloud), מתחילים את הפריסה ביצירת הקישוריות הנדרשת בין Google Cloud לבין סביבות המחשוב האחרות. כדי להקל על מודל התקשורת הנדרש לארכיטקטורה היברידית או מרובת עננים, צריך לבסס את הפריסה על העיצוב שנבחר ועל סוג הקישוריות לרשת, וגם על דפוס הרשת הרלוונטי. מומלץ להשתמש בגישה הזו כדי לקבל החלטות לגבי העיצוב הכולל של אזור הנחיתה.
בנוסף, צריך לבדוק ולאמת את האפליקציה או השירות על סמך הקריטריונים להצלחה של האפליקציה שמוגדרים. מומלץ שהקריטריונים האלה יכללו דרישות של בדיקות פונקציונליות ושל בדיקות עומס (לא פונקציונליות) לפני המעבר לסביבת הייצור.
שלב האופטימיזציה
בשלב האופטימיזציה, בודקים את הפריסה: אחרי שמסיימים את הבדיקות, והאפליקציה או השירות עומדים בדרישות הפונקציונליות והביצועים, אפשר להעביר אותם לסביבת הייצור. כלים לניטור ולשקיפות בענן, כמו Cloud Monitoring, יכולים לספק תובנות לגבי הביצועים, הזמינות והתקינות של האפליקציות והתשתית שלכם, ולעזור לכם לבצע אופטימיזציה במקומות שנדרשת בהם אופטימיזציה.
מידע נוסף זמין במאמר מעבר אל Google Cloud: אופטימיזציה של הסביבה. מידע נוסף על תכנון כלים כאלה לארכיטקטורה היברידית או מרובת עננים זמין במאמר תבניות של מעקב ורישום ביומן בענן היברידי ובענן מרובה.
הערכת עומסי עבודה של מועמדים
הבחירה של סביבות מחשוב עבור עומסי עבודה שונים משפיעה באופן משמעותי על ההצלחה של אסטרטגיה היברידית ורב-עננית. החלטות לגבי מיקום עומסי העבודה צריכות להתאים ליעדים עסקיים ספציפיים. לכן, ההחלטות האלה צריכות להתבסס על תרחישי שימוש עסקיים ממוקדים שמאפשרים מדידה של ההשפעות העסקיות. עם זאת, לא תמיד צריך להתחיל עם עומס העבודה או האפליקציה שהכי קריטיים לעסק, ולא מומלץ לעשות זאת. מידע נוסף זמין במאמר בחירת האפליקציות להעברה ראשונה במדריך בנושא מעבר אל Google Cloud .
כפי שצוין בקטע גורמים עסקיים וטכניים, יש סוגים שונים של גורמים ושיקולים לארכיטקטורות היברידיות וארכיטקטורות מרובות עננים.
רשימת הגורמים הבאה יכולה לעזור לכם להעריך את תרחיש השימוש בהעברה בהקשר של ארכיטקטורה היברידית או מרובת עננים, עם הזדמנויות להשפעה עסקית מדידה:
- הפוטנציאל לבידול בשוק או לחדשנות שמתאפשרים באמצעות שימוש בשירותי ענן כדי להפעיל פונקציות או יכולות עסקיות מסוימות, כמו יכולות בינה מלאכותית שמשתמשות בנתונים קיימים מקומיים כדי לאמן מודלים של למידת מכונה.
- חיסכון פוטנציאלי בעלות הבעלות הכוללת (TCO) של אפליקציה.
- שיפורים פוטנציאליים בזמינות, בעמידות, באבטחה או בביצועים – לדוגמה, הוספת אתר לשחזור נתונים (DR) בענן.
- קיצור תהליכי הפיתוח וההפצה – לדוגמה, בניית סביבות הפיתוח והבדיקה בענן.
הגורמים הבאים יכולים לעזור לכם להעריך את סיכוני ההעברה:
- ההשפעה הפוטנציאלית של הפסקות שירות שנגרמות כתוצאה מהעברה.
- הניסיון של הצוות שלכם בפריסות בענן ציבורי, או בפריסות של ספק שירותי ענן חדש או שני.
- הצורך לעמוד בהגבלות משפטיות או רגולטוריות קיימות.
הגורמים הבאים יכולים לעזור לכם להעריך את הקשיים הטכניים של מעבר:
- הגודל, המורכבות והגיל של האפליקציה.
- מספר התלות באפליקציות ובשירותים אחרים בסביבות מחשוב שונות.
- הגבלות כלשהן שמוטלות על ידי רישיונות צד שלישי.
- תלויות בגרסאות ספציפיות של מערכות הפעלה, מסדי נתונים או הגדרות סביבה אחרות.
אחרי שמעריכים את עומסי העבודה הראשוניים, אפשר להתחיל לתעדף אותם ולהגדיר את קבוצות ההעברה ואת הגישות. לאחר מכן, תוכלו לזהות דפוסי ארכיטקטורה רלוונטיים ודפוסי רשת תומכים. יכול להיות שיהיה צורך לבצע את השלב הזה כמה פעמים, כי ההערכה שלכם עשויה להשתנות עם הזמן. לכן, כדאי להעריך מחדש את עומסי העבודה אחרי שמבצעים את הפריסות הראשונות בענן.