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

שירותים הקשורים לנושא

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

השוואה

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

לא מתחילים מהמיקום, אלא מדרישות עומס העבודה

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

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

תשתית מקומית: שליטה גבוהה ואחריות מלאה

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

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

מתקן אירוח: ציוד בבעלות הארגון, מעטפת מקצועית

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

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

ענן ציבורי: גמישות אינה פוטרת מתכנון

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

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

העלות הנכונה להשוואה היא עלות כוללת

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

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

זמינות והתאוששות מאסון

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

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

אבטחה, רגולציה וריבונות מידע

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

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

גם גמישות ויכולת יציאה הן חלק מההחלטה

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

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

ברוב הארגונים התשובה תהיה מודל משולב

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

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

תהליך החלטה מומלץ

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

לסיכום

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

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