במסמך הזה מוגדרים יעדים עסקיים, גורמים מניעים ודרישות, ומוסבר איך הגורמים האלה יכולים להשפיע על החלטות העיצוב שלכם כשאתם בונים ארכיטקטורות היברידיות וארכיטקטורות מרובות עננים.
מטרות
ארגון יכול לאמץ ארכיטקטורה היברידית או מרובת עננים כפתרון קבוע כדי לעמוד ביעדים עסקיים ספציפיים, או כמצב זמני כדי לאפשר דרישות מסוימות, כמו מעבר לענן.
כדי להגדיר את הדרישות העסקיות ולקבוע ציפיות ספציפיות לגבי השגת חלק מהיעדים העסקיים או כולם, מומלץ לענות על השאלות הבאות לגבי העסק. השאלות האלה מתמקדות במה שנדרש לעסק שלכם, ולא איך להשיג את זה מבחינה טכנית.
- אילו יעדים עסקיים מובילים להחלטה לאמץ ארכיטקטורה היברידית או מרובת עננים?
- אילו יעדים עסקיים וטכניים אפשר להשיג באמצעות ארכיטקטורה היברידית או מרובת עננים?
- אילו גורמים עסקיים השפיעו על היעדים האלה?
- מהן הדרישות העסקיות הספציפיות?
בארכיטקטורות היברידיות ורב-ענניות, יעד עסקי אחד של לקוח ארגוני יכול להיות הרחבת פעולות מכירות אונליין או השווקים מאזור יחיד, כדי להפוך לאחד מהמובילים העולמיים בפלח השוק שלו. אחת מהמטרות העסקיות יכולה להיות להתחיל לקבל הזמנות רכש ממשתמשים בכל העולם (או מאזורים ספציפיים) תוך שישה חודשים.
כדי לתמוך בדרישות ובמטרות העסקיות שצוינו קודם, אחת מהמטרות הטכניות העיקריות האפשריות היא להרחיב את תשתית ה-IT ואת ארכיטקטורת האפליקציות של החברה ממודל מקומי בלבד לארכיטקטורה היברידית, באמצעות היכולות והשירותים הגלובליים של עננים ציבוריים. היעד הזה צריך להיות ספציפי ומדיד, ולהגדיר בבירור את היקף ההתרחבות מבחינת אזורי היעד ולוחות הזמנים.
באופן כללי, ארכיטקטורה היברידית או מרובת עננים היא בדרך כלל לא מטרה בפני עצמה, אלא אמצעי להשגת יעדים טכניים שנובעים מדרישות עסקיות מסוימות. לכן, כדי לבחור את הארכיטקטורה הנכונה של ענן היברידי או מרובה עננים, צריך קודם להבהיר את הדרישות האלה.
חשוב להבדיל בין היעדים העסקיים לבין היעדים הטכניים של פרויקט ה-IT. היעדים העסקיים צריכים להתמקד במטרה ובייעוד של הארגון. היעדים הטכניים צריכים להתמקד בבניית בסיס טכנולוגי שיאפשר לארגון לעמוד בדרישות וביעדים העסקיים שלו.
הגורמים העסקיים המשפיעים על השגת היעד והמטרות העסקיות. לכן, זיהוי ברור של הגורמים העסקיים יכול לעזור לעצב את היעדים או המטרות העסקיות כך שיהיו רלוונטיים יותר לצרכים ולמגמות בשוק.
בתרשים הזרימה הבא מוצגים הגורמים העסקיים, המטרות, היעדים והדרישות, וגם היעדים והדרישות הטכניים, ומוסבר איך כל הגורמים האלה קשורים זה לזה:
מניעים עסקיים וטכניים
כדאי לחשוב איך הגורמים שמניעים את העסק משפיעים על היעדים הטכניים. הנה כמה מניעים עסקיים נפוצים שמשפיעים על הבחירה בארכיטקטורה היברידית:
- הקפדה על חוקים ותקנות בנושא ריבונות נתונים.
- הפחתת הוצאות הון (CAPEX) או הוצאות כלליות על IT בעזרת ניהול פיננסי בענן ושיטות אופטימיזציה של עלויות כמו FinOps.
- המעבר לענן יכול להיות מונע על ידי תרחישים שעוזרים להפחית את הוצאות ההון, כמו בניית פתרון להתאוששות מאסון בארכיטקטורה היברידית או מרובת עננים.
- שיפור חוויית המשתמש.
- הגברת הגמישות והזריזות כדי להגיב לשינויים בביקוש בשוק.
- שיפור השקיפות לגבי עלויות וצריכת משאבים.
כדאי לעיין ברשימת הגורמים העסקיים שמובילים לאימוץ ארכיטקטורה היברידית או מרובת עננים. אל תתייחסו אליהם בנפרד. ההחלטה הסופית צריכה להתבסס על האיזון בין סדרי העדיפויות העסקיים.
אחרי שהארגון יבין את היתרונות של הענן, הוא עשוי להחליט לבצע מיגרציה מלאה, אם אין מגבלות – כמו עלויות או דרישות תאימות ספציפיות שמחייבות אירוח של נתונים מאובטחים מאוד בשרתים מקומיים – שמונעות ממנו לעשות זאת.
לשימוש בספק שירותי ענן יחיד יש כמה יתרונות, כמו מורכבות מופחתת, שילובים מובנים בין שירותים ואפשרויות לחיסכון בעלויות כמו הנחה תמורת התחייבות לשימוש (CUD). עם זאת, יש תרחישים שבהם ארכיטקטורת מרובה עננים (multi-cloud) יכולה להועיל לעסק. אלה הגורמים העסקיים הנפוצים שמובילים לאימוץ ארכיטקטורת מרובה עננים (multi-cloud), יחד עם השיקולים הרלוונטיים לכל גורם:
- הקפדה על חוקים ותקנות בנושא ריבונות הנתונים: התרחיש הנפוץ ביותר הוא כשארגון מרחיב את הפעילות העסקית שלו לאזור או למדינה חדשים, וצריך לעמוד בדרישות של תקנות חדשות בנושא אירוח נתונים.
- אם לספק שירותי הענן (CSP) שבו אתם משתמשים אין אזור ענן מקומי במדינה הזו, הפתרון המקובל לצורך עמידה בדרישות הוא להשתמש בספק אחר שיש לו אזור ענן מקומי במדינה הזו.
- הפחתת עלויות: הפחתת עלויות היא בדרך כלל המניע העסקי הנפוץ ביותר לאימוץ טכנולוגיה או ארכיטקטורה. עם זאת, כשמחליטים אם לאמץ ארכיטקטורה של ריבוי עננים, חשוב לקחת בחשבון לא רק את עלות השירותים ואת הנחות התמחור הפוטנציאליות. להביא בחשבון את העלות של בנייה והפעלה של פתרון בכמה עננים, ואת כל מגבלות הארכיטקטורה שעשויות לנבוע ממערכות קיימות.
לפעמים, האתגרים הפוטנציאליים שקשורים לאסטרטגיית מולטי-ענן עולים על היתרונות. יכול להיות שבהמשך תצטרכו לשלם עלויות נוספות במסגרת אסטרטגיית מרובה עננים (multi-cloud).
אתגרים נפוצים שקשורים לפיתוח אסטרטגיה של שימוש בכמה עננים:
- המורכבות של הניהול גדלה.
- שמירה על אבטחה עקבית.
- שילוב של סביבות תוכנה.
- השגת ביצועים ואמינות עקביים בענן.
- יכול להיות שיהיה יקר להקים צוות טכני עם מיומנויות בתחום ריבוי העננים, וייתכן שיהיה צורך להרחיב את הצוות, אלא אם חברת צד שלישי מנהלת אותו.
- ניהול התמחור של המוצרים והכלים לניהול מכל ספק CSP.
- ללא פתרון שיכול לספק נראות מאוחדת של עלויות ולוחות בקרה, יכול להיות קשה לנהל עלויות ביעילות בסביבות מרובות. במקרים כאלה, אפשר להשתמש בפתרון של Looker לניהול עלויות בענן, אם זה רלוונטי. מידע נוסף זמין במאמר האסטרטגיה לייעול יעיל של ניהול עלויות החיוב ב-Cloud.
- שימוש ביכולות הייחודיות של כל ספק שירותי ענן: ארכיטקטורת מרובה עננים מאפשרת לארגונים להשתמש בטכנולוגיות חדשות נוספות כדי לשפר את היכולות העסקיות שלהם, בלי להיות מוגבלים לאפשרויות שמציע ספק שירותי ענן יחיד.
- כדי להימנע מסיכונים או מורכבויות בלתי צפויים, מומלץ לבצע הערכה של האתגרים הפוטנציאליים באמצעות הערכת היתכנות ויעילות, כולל האתגרים הנפוצים שצוינו קודם.
- מניעת מצב של תלות בספק: לפעמים, ארגונים רוצים להימנע ממצב של תלות בספק שירותי ענן יחיד. גישה מרובת עננים מאפשרת להם לבחור את הפתרון הטוב ביותר לצרכים העסקיים שלהם. עם זאת, ההחלטה הזו תלויה בכמה גורמים, כמו:
- תלות טכנית
- שיקולים לגבי יכולת פעולה הדדית בין אפליקציות
- עלויות של בנייה מחדש או של ארגון הקוד מחדש של אפליקציות
- מערכי מיומנויות טכניות
- אבטחה וניהול עקביים
- שיפור רמת האמינות והזמינות של אפליקציות קריטיות לעסק: בתרחישים מסוימים, ארכיטקטורה מרובת עננים יכולה לספק חוסן להפסקות זמניות בשירות. לדוגמה, אם אזור אחד של ספק CSP מושבת, אפשר לנתב את התנועה לספק CSP אחר באותו אזור. בתרחיש הזה מניחים ששני ספקי הענן תומכים ביכולות או בשירותים הנדרשים באזור הזה.
כשחוקי שמירת נתונים במדינה או באזור מסוימים מחייבים אחסון של מידע אישי רגיש – כמו פרטים אישיים מזהים (PII) – במיקום הזה, גישה מרובת עננים יכולה לספק פתרון תואם. שימוש בשני ספקי CSP באזור אחד כדי לספק חוסן (resilience) להפסקות זמניות בשירות מאפשר לעמוד בהגבלות רגולטוריות וגם בדרישות הזמינות.
לפני שמאמצים ארכיטקטורה מרובת עננים, כדאי להעריך את השיקולים הבאים בנוגע לחוסן:
- העברת נתונים: באיזו תדירות יכולים נתונים לעבור בסביבת מולטי-ענן?
- האם העברת נתונים עלולה לגרום לחיובים משמעותיים על העברת נתונים?
- אבטחה וניהול: האם יש סיבוכים פוטנציאליים באבטחה או בניהול?
- שוויון ביכולות: האם שני ספקי ה-CSP באזור שנבחר מציעים את היכולות והשירותים הנדרשים?
- מערך הכישורים הטכניים: האם לצוות הטכני יש את הכישורים הנדרשים לניהול ארכיטקטורה מרובת עננים?
כדאי להביא בחשבון את כל הגורמים האלה כשבודקים את האפשרות להשתמש בארכיטקטורה מרובת עננים כדי לשפר את העמידות.
כשבודקים את ההיתכנות של ארכיטקטורה מרובת-עננים, חשוב לקחת בחשבון את היתרונות לטווח הארוך. לדוגמה, פריסת אפליקציות בכמה עננים לצורך תוכנית התאוששות מאסון (DR) או שיפור המהימנות עשויה להגדיל את העלויות בטווח הקצר, אבל יכולה למנוע הפסקות זמניות בשירות או תקלות. כשלים כאלה עלולים לגרום לנזק כספי ולנזק למוניטין בטווח הארוך. לכן חשוב לשקול את העלויות לטווח הקצר לעומת הערך הפוטנציאלי לטווח הארוך של אימוץ גישת מרובה עננים (multi-cloud). בנוסף, הערך הפוטנציאלי לטווח ארוך יכול להשתנות בהתאם לגודל הארגון, להיקף הטכנולוגיה, לחשיבות של פתרון הטכנולוגיה ולתחום הפעילות.
ארגונים שמתכננים ליצור בהצלחה סביבה היברידית או מרובת עננים (multi-cloud) צריכים לשקול הקמת מרכז המצוינות בענן (Cloud COE). צוות COE יכול להפוך לצינור להמרת האופן שבו צוותים פנימיים בארגון משרתים את העסק במהלך המעבר לענן. מרכז מצוינות הוא אחת הדרכים שבהן הארגון יכול לאמץ את הענן מהר יותר, להניע סטנדרטיזציה ולשמור על התאמה חזקה יותר בין האסטרטגיה העסקית לבין ההשקעות בענן.
אם המטרה של ארכיטקטורת הענן ההיברידי או מרובה העננים היא ליצור מצב זמני, הגורמים העסקיים הנפוצים כוללים:
- הצורך להקטין את הוצאות ה-CAPEX או את ההוצאות הכלליות על IT בפרויקטים לטווח קצר.
- היכולת להקצות תשתית כזו במהירות כדי לתמוך בתרחיש שימוש עסקי. לדוגמה:
- יכול להיות שתשתמשו בארכיטקטורה הזו לפרויקטים לזמן מוגבל. אפשר להשתמש בו כדי לתמוך בפרויקט שנדרשת בו תשתית מבוזרת בהיקף גדול למשך זמן מוגבל, ועדיין להשתמש בנתונים שנמצאים בשרתים מקומיים.
- הצורך בפרויקטים של טרנספורמציה דיגיטלית שנמשכים כמה שנים, שנדרשים לארגונים גדולים כדי להקים תשתית, ושמשתמשים בארכיטקטורה היברידית למשך תקופה מסוימת כדי לעזור להם להתאים את המודרניזציה של התשתית והאפליקציות שלהם לסדרי העדיפויות העסקיים שלהם.
- הצורך ליצור ארכיטקטורה זמנית היברידית, מרובת עננים או מעורבת אחרי מיזוג חברות. כך הארגון החדש יכול להגדיר אסטרטגיה למצב הסופי של ארכיטקטורת הענן החדשה שלו. בדרך כלל, שתי חברות שמתמזגות משתמשות בספקי ענן שונים, או שאחת מהן משתמשת במרכז נתונים פרטי מקומי והשנייה משתמשת בענן. בכל מקרה, השלב הראשון במיזוג וברכישה הוא כמעט תמיד שילוב של מערכות ה-IT.
מניעים טכניים
בקטע הקודם דנו במניעים עסקיים. כדי לקבל אישור, כמעט תמיד צריך את התמיכה של הגורמים האלה בהחלטות ארכיטקטוניות חשובות. עם זאת, גורמים טכניים, שיכולים להתבסס על יתרון טכני או על מגבלה, יכולים גם להשפיע על גורמים עסקיים. במקרים מסוימים, צריך לתרגם את הגורמים הטכניים לגורמים עסקיים ולהסביר איך הם יכולים להשפיע על העסק באופן חיובי או שלילי.
הרשימה הבאה היא רשימה חלקית של גורמים טכניים נפוצים שמובילים לאימוץ ארכיטקטורה היברידית או מרובת עננים:
- פיתוח יכולות טכנולוגיות, כמו שירותי ניתוח נתונים מתקדמים ו-AI, שאולי קשה להטמיע בסביבות קיימות.
- שיפור האיכות והביצועים של השירות.
- אוטומציה והאצה של השקת אפליקציות כדי להשיג זמן יציאה לשוק מהיר יותר ומחזורי זמן קצרים יותר.
- שימוש בממשקי API ובשירותים ברמה גבוהה כדי להאיץ את תהליך הפיתוח.
- האצת הקצאת משאבי מחשוב ואחסון.
- שימוש בשירותים בלי שרת (serverless) כדי לבנות שירותים ויכולות גמישים מהר יותר ובקנה מידה גדול.
- שימוש ביכולות של תשתית גלובלית כדי לבנות ארכיטקטורות גלובליות או רב-אזוריות בהתאם לדרישות טכניות מסוימות.
הסיבה הטכנית הנפוצה ביותר לארכיטקטורות היברידיות זמניות ולארכיטקטורות זמניות מרובות עננים היא להקל על מעבר משרתים מקומיים לענן או לענן נוסף. באופן כללי, מעבר לענן כמעט תמיד מוביל באופן טבעי להגדרת ענן היברידי. בארגונים גדולים, לעיתים קרובות צריך להעביר באופן שיטתי אפליקציות ונתונים על סמך סדר העדיפויות. באופן דומה, יכול להיות שהגדרה לטווח קצר נועדה להקל על הוכחת היתכנות באמצעות טכנולוגיות מתקדמות שזמינות בענן לתקופה מסוימת.
החלטות בנוגע לעיצוב הטכני
היעד הטכני שזוהה והגורמים שמשפיעים עליו הם המפתח לקבלת החלטה לגבי ארכיטקטורה שמבוססת על עסקים ולבחירה באחד מדפוסי הארכיטקטורה שמוסברים במדריך הזה. לדוגמה, כדי לתמוך ביעד עסקי ספציפי, חברה יכולה להגדיר יעד עסקי של בניית תהליך מחקר ופיתוח למשך שלושה עד שישה חודשים. הדרישה העסקית העיקרית לתמיכה ביעד הזה יכולה להיות בניית סביבת הטכנולוגיה הנדרשת למחקר ולעיצוב עם הוצאות הוניות נמוכות ככל האפשר.
המטרה הטכנית במקרה הזה היא להגדיר ענן היברידי זמני. המטרה הטכנית הזו נובעת מהרצון לנצל את מודל התמחור על פי דרישה של הענן כדי לעמוד בדרישה העסקית שצוינה קודם. גורם נוסף שמשפיע על ההחלטה הוא הדרישות הטכנולוגיות הספציפיות, שמחייבות פתרון מבוסס-ענן עם יכולת חישוב גבוהה והגדרה מהירה.
שימוש Google Cloud בארכיטקטורות היברידיות ומרובות עננים (multi-cloud)
שימוש בפתרונות קוד פתוח יכול להקל על אימוץ גישה היברידית וריבוי עננים, ולמזער את התלות בספק. עם זאת, כשמתכננים ארכיטקטורה, חשוב לקחת בחשבון את המורכבויות הפוטנציאליות הבאות:
- יכולת פעולה הדדית
- ניהול הענן
- עלות
- אבטחה
הסתמכות על פלטפורמת ענן שתורמת לקוד פתוח ותומכת בו יכולה לפשט את הדרך לאימוץ ארכיטקטורות היברידיות וארכיטקטורות מרובות עננים. ענן פתוח מאפשר לכם לבחור מתוך מגוון רחב של אפשרויות, ומפשט את המורכבות. בנוסף, Google Cloud מאפשרת גמישות במיגרציה, בבנייה ובאופטימיזציה של אפליקציות בסביבות היברידיות ובסביבות מרובות עננים (multi-cloud), תוך צמצום התלות בספק, שימוש בפתרונות הטובים ביותר ועמידה בדרישות הרגולטוריות.
Google היא גם אחת מהתורמות הגדולות ביותר לסביבה העסקית של קוד פתוח, והיא עובדת עם קהילת הקוד הפתוח כדי לפתח טכנולוגיות קוד פתוח מוכרות כמו Kubernetes. כשמשיקים את Kubernetes כשירות מנוהל, הוא יכול לעזור לצמצם את המורכבות של ניהול ואבטחה של עננים היברידיים ומרובי עננים.