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