זה כמובן עניין של מספרים. לדוגמא - באמזון יש כ- 165 שירותים וכחמישה מחוללי עלויות. זה בעצם מייצר חשבונית פוטנציאלית ובה 825 פריטים שונים לחיוב, אלא שכאן הסיפור רק מתחיל. לאמזון יש 23 אזורים (regions) שונים כאשר בכל אזור העלויות שונות, אז תכפילו ב- 23. אמנם לא כל השירותים זמינים בכל אזור, אבל אתם מבינים את הרעיון.
ואז נכנס העניין של שיטות התשלום. התחייבתם מראש - שילמתם פחות, ואם שילמת מראש הסכום עוד יורד. ואז מגיע הענין של התמחור לפי זמינות (Spot). התמחור לפי זמינות משתנה למעשה גם בתוך האזורים ברמת אזורי זמינות (AZ), יש 69 כאלו, וגם במהלך הזמן לפי היצע וביקוש בכל AZ.
בקיצור אם תסתכלו בקטלוג המחירים של AWS תגלו שכרגע יש 1,134,202 SKUs (מספרי מוצר) שונים. כל אחד מהם יכול להופיע לכם בחשבונית, ולכן בכל אחד מהם נדרש לשלוט.
הדבר השני שמסבך את ניהול עלויות הענן הוא מספר הקניינים. למעשה יש כמות עצומה של קניינים. כל מפתח שמעלה מכונה מחייב ישירות את חשבון הבנק של הארגון. לקוח שמעלה תמונה לאתר, מחייב את החשבון בנק של הארגון. האקר שתוקף את האתר וגורם למכונות לעלות באופן אוטומטי מחייב את חשבון הבנק של החשבון. במילים אחרות, השימוש בענן מחבר באופן ישיר את השימוש במחשוב לחשבון הבנק של הארגון.
חשוב לומר, שזה לא אומר שהענן יותר יקר מאשר דאטה סנטר. ברוב המקרים ההיפך הוא הנכון. אם ניקח את הדוגמה האחרונה, הוספת מכונות בהתקפה אומר שהיו פחות מכונות בד"כ, מה שאומר שהשתמשתם בפחות כח מחשוב מאשר הייתם משתמשים בחוץ. ולכן, חסכתם הרבה ביום יום מבלי לפגוע בביצועים, או אפילו לקבל ביצועים טובים יותר בשעות עומס.
אז איך בכל זאת מנהלים את העלויות? עובדים בכמה מישורים:
כלכלי
ראשית חשוב להבין היטב את הכלכלה של הענן. זה אינו נושא פשוט והוא משתנה כל הזמן. חשוב להבין את צורת חישוב העלויות, ומחוללי העלויות השונים. לאחר מכן מסתכלים על ההיבטים הכלכליים או במילים אחרות, כיצד אני יכול לחסוך כסף מבלי לשנות דבר בצורת הפעולה של הענן. למשל, ריכוז חשבונות, מנויים וקניות של הארגון בענן. כמובן שכדאי לקנות/להתחייב מראש ולבקש הנחות, ויש הרבה סוגים ורמות של הנחות. תכנון והבנה של הצריכה הצפויה הם פקטורים משמעותיים בניהול כלכלי נכון ויעיל של הענן.
אופרטיבי
התחום האופרטיבי הוא הקשה והמורכב מבין כל התחומים אבל בו טמון פוטנציאל החיסכון הגדול ביותר. מומלץ להתחיל עם הדברים שאין להם השפעה מהותית או שאין להם השפעה כלל על תפעול ענן. לא תאמינו כמה כאלה יש. זה פשוט כסף ששוכב על הרצפה. למחוק חשבונות וסביבות שאינן בשימוש ולכבות מכונות שאינן נדרשות, לגבות אחסון יקר לאחסון זול ולמחוק את המקור.
בהמשך, נדרש לעלות בסולם הערך והסיבוכיות. כדי לחסוך נדרש לפעמים לעבור לטכנולוגיות חדשות, או באופן מפתיע, לחזור לטכנולוגיות ישנות. זה משתנה משימוש לשימוש אבל המשותף לכולם הוא שאנחנו משקיעים רק כשה- ROI חיובי ומיידי, או מאוד קצר. הרמה הגבוהה ביותר היא הרמה שבה אנחנו מטמיעים אוטומציה ושיקולי עלות לתוך תהליכי התכנון והפריסה של המערכות שלנו בענן. עוד על נושא זה בהמשך.
הקניית ידע
פן חשוב מאוד הוא העשרת הידע של האנשים הנוגעים בדבר בארגון בנושא עלויות הענן והדרכים למצות את יתרונות הענן, כולל היכולת לעמוד בדרישות עסקיות בעלויות נמוכות. זהו תהליך לא קצר ולא זול אבל הוא הכרחי. העלאת המודעות הארגונית לעלויות הענן ולהשפעה שיכולה להיות להם בשורה התחתונה של הארגון כולו היא חלק חשוב בניהול העלויות.
הדברים הבסיסיים שצריך לעשות:
ניטור
הקלישאה המתבקשת של ידע הוא כוח רלוונטית מאוד לניהול עלויות בענן. ללא ניטור אנחנו עיוורים ונראה את הבעיות רק שכבר יהיה מאוחר מידי, כלומר כשקיבלנו את החשבון. זה אמנם נחמד לדעת על מה הוצאתי כסף בחודש שעבר, אבל זה בהחלט מאוחר מדי. הניטור תפקידו לתת תמונת מצב עדכנית עם אקסטרפולציה אל העתיד כדי לאפשר לנו להגיב בזמן ולהימנע מעלויות מיותרות.
אוטומציה
אוטומציה הינה מרכיב מהותי בתהליכי finops. בדיוק כמו שבונים אוטומציה שמטרתה להתמודד עם כשלים במערכות מחשוב, נדרשת בניית אוטומציה שמטרתה להתמודד עם כשלים כספיים. לצורך העניין, כשל כספי הינו כל מצב שבו משלמים על משאבי ענן שאינם מנוצלים. זה כולל את הנושא של שימוש במשאבים גדולים ויקרים ביחס לנדרש לביצוע המשימות.
שליטה
אין כמובן דרך לשלוט במעל מיליון "מוצרים" בלי אוטומציה. בהינתן אוטומציה, בהחלט ניתן לבנות מערכת שליטה (Gouvernance) שמאפשרת שיוך עלויות לפעילויות ותקציבים. תפקיד חשוב של המערכת הוא לוודא שאנחנו לא במסלול חריגה מהתקציבים המאושרים. בלי מערכת שליטה, חריגות תקציב בלתי-נמנעות.
חוזר חלילה
תהליכי אופטימיזציה של הענן הם תהליכים מחזורים ונדרש לבצע אותם באופן רציף ומחזורי כדי להתמודד עם השינויים הדחופים בשימושי הענן של הארגון.
אבטחת מידע
קיים פקטור, נדיר יחסית אך משמעותי, של עלויות שנוצרות כתוצאה מנושאי אבטחת מידע. חלק מניהול פיננסי של ענן צריך לכלול גם תוכניות אופרטיביות לטיפול מהיר באירועי אבטחת מידע וכן גידור של העלויות הנובעות מאירועים אלו.
כמה דרכים לשליטה בעלויות הענן:
לא אוכל לכסות כאן את כל הדרכים לשלוט בעלויות הענן. נכתבו על זה ספרים שלמים. בחרתי להביא כמה מהדרכים שלדעתי חשוב להכיר.
שיטת הקופסאות - בשיטה זו אנחנו משיגים שליטה על עלויות הענן על ידי הגבלה של שירותי הענן שבהם ניתן להשתמש. למעשה בונים קופסא שמגדירה את כל המשאבים לכל פרויקט. הפרויקט עולה לייצור בתוך הקופסה. הקופסה מנוטרת ומוגדרת היטב מראש והעלויות ברורות וידועות מראש נשמרות לאורך חיי המערכת. השיטה הזאת מאפשרת צפי מצויין של העלויות לאורך זמן ותכנון פיננסי של הצריכה. החיסרון כמובן הוא חוסר הגמישות. כן ניתן לבנות קופסאות חדשות עם טכנולוגיות חדשות בזריזות, וכך להתקדם טכנולוגית בשליטה תקציבית.
לא מתוייג לא קיים - בשיטה הזו אנחנו מורידים/מוחקים כל משאב שעולה ללא סט מוגדר מראש של טאגים. אנחנו משתמשים בתגים כדי לשייך את המשאב מבחינה תקציבית ומבחינה ארגונית. ניתן לבדוק שהטאגים מכילים ערכים תקינים בהתאם לערכים שהגדרנו מראש. משאב שעולה לא מתוייג יכובה/ימחק לאלתר. זו שיטה אגרסיבית ולא תמיד מתאימה לכל ארגון וגם ארגונים שמשתמשים בה לפעמים נמנעים מלהשתמש בה בייצור. אך היא אפקטיבית מאוד.
האצלת סמכויות ואחריות - בשיטה הזאת משקפים את העלויות לבעלי התקציב ומעבירים עליהם את הסמכות, היכולת (כלים, ניטור ותהליכים) והאחריות על התקציב. זה כולל הכנסה של יעדי עלויות ענן לתוך יעדי הרווח של היחידות העסקיות הקטנות ביותר שאפשר למדוד. הקושי הוא בשליטה המבוזרת על התקציב. היתרון הוא בגמישות בהתגייסות של בעלי העניין בארגון למשימה.
צנטרליזם - ארגונים רבים נוקטים בגישה צנטרליסטית לניהול עלויות. צוות אחד בודד מאשר ובונה את המשאבים בענן. זו שיטה שמתאימה מאוד לארגונים שאינם קלאוד נייטיב ורגילים לעבוד כך גם ב- on-prem. זו שיטה שמאבדת חלק מהגמישות שענן מאפשר אבל היא אפקטיבית מאוד בניהול העלויות וגם בהיבטים אחרים כמו אבטחת מידע. חשוב לשים לב שבדרך כלל כשעובדים בשיטה הזאת, במקביל לענן " המרכזי" נוצר שימוש בעננים פרטיים קטנים ובעלויות קטנות על תקציבי הוצאה אישית (expenses) כדי לשמר את הגמישות של הענן.
אוטומציה - לסיום אני רוצה לחזור שוב לנושא החשוב של אוטומציה. האוטומציה בנויה בכל הרבדים של הענן. יש המון יכולות שהענן עצמו נותן כחלק משירותים רבים, כמו Auto-scaling. מעל ובנוסף לשירותים האלו, נדרש לכתוב אוטומציה המשקפת את הפעילות של המערכת שלכם. העלאת משאבים, הורדת משאבים, מחיקת משאבים שאינם בשימוש, ניהול מחזור חיים של מידע, הקמה וסגירה של סביבות ועוד. האוטומציה היא חלק מרכזי בניהול עלויות הענן ובלעדיה הענן הופך מכלי שימושי וכלכלי מאוד ללא כלכלי בעליל.
מאת: סאם באב"ד, המייסד של CloudHawk.net המפתחת תוכנה לניהול אופרטיבי אפקטיבי של הענן המובילה לחיסכון משמעותי בעלויות.
זה כמובן עניין של מספרים. לדוגמא - באמזון יש כ- 165 שירותים וכחמישה מחוללי עלויות. זה בעצם מייצר חשבונית פוטנציאלית ובה 825 פריטים שונים לחיוב, אלא שכאן הסיפור רק מתחיל. לאמזון יש 23 אזורים (regions) שונים כאשר בכל אזור העלויות שונות, אז תכפילו ב- 23. אמנם לא כל השירותים זמינים בכל אזור, אבל אתם מבינים את הרעיון.
ואז נכנס העניין של שיטות התשלום. התחייבתם מראש - שילמתם פחות, ואם שילמת מראש הסכום עוד יורד. ואז מגיע הענין של התמחור לפי זמינות (Spot). התמחור לפי זמינות משתנה למעשה גם בתוך האזורים ברמת אזורי זמינות (AZ), יש 69 כאלו, וגם במהלך הזמן לפי היצע וביקוש בכל AZ.
בקיצור אם תסתכלו בקטלוג המחירים של AWS תגלו שכרגע יש 1,134,202 SKUs (מספרי מוצר) שונים. כל אחד מהם יכול להופיע לכם בחשבונית, ולכן בכל אחד מהם נדרש לשלוט.
הדבר השני שמסבך את ניהול עלויות הענן הוא מספר הקניינים. למעשה יש כמות עצומה של קניינים. כל מפתח שמעלה מכונה מחייב ישירות את חשבון הבנק של הארגון. לקוח שמעלה תמונה לאתר, מחייב את החשבון בנק של הארגון. האקר שתוקף את האתר וגורם למכונות לעלות באופן אוטומטי מחייב את חשבון הבנק של החשבון. במילים אחרות, השימוש בענן מחבר באופן ישיר את השימוש במחשוב לחשבון הבנק של הארגון.
חשוב לומר, שזה לא אומר שהענן יותר יקר מאשר דאטה סנטר. ברוב המקרים ההיפך הוא הנכון. אם ניקח את הדוגמה האחרונה, הוספת מכונות בהתקפה אומר שהיו פחות מכונות בד"כ, מה שאומר שהשתמשתם בפחות כח מחשוב מאשר הייתם משתמשים בחוץ. ולכן, חסכתם הרבה ביום יום מבלי לפגוע בביצועים, או אפילו לקבל ביצועים טובים יותר בשעות עומס.
אז איך בכל זאת מנהלים את העלויות? עובדים בכמה מישורים:
כלכלי
ראשית חשוב להבין היטב את הכלכלה של הענן. זה אינו נושא פשוט והוא משתנה כל הזמן. חשוב להבין את צורת חישוב העלויות, ומחוללי העלויות השונים. לאחר מכן מסתכלים על ההיבטים הכלכליים או במילים אחרות, כיצד אני יכול לחסוך כסף מבלי לשנות דבר בצורת הפעולה של הענן. למשל, ריכוז חשבונות, מנויים וקניות של הארגון בענן. כמובן שכדאי לקנות/להתחייב מראש ולבקש הנחות, ויש הרבה סוגים ורמות של הנחות. תכנון והבנה של הצריכה הצפויה הם פקטורים משמעותיים בניהול כלכלי נכון ויעיל של הענן.
אופרטיבי
התחום האופרטיבי הוא הקשה והמורכב מבין כל התחומים אבל בו טמון פוטנציאל החיסכון הגדול ביותר. מומלץ להתחיל עם הדברים שאין להם השפעה מהותית או שאין להם השפעה כלל על תפעול ענן. לא תאמינו כמה כאלה יש. זה פשוט כסף ששוכב על הרצפה. למחוק חשבונות וסביבות שאינן בשימוש ולכבות מכונות שאינן נדרשות, לגבות אחסון יקר לאחסון זול ולמחוק את המקור.
בהמשך, נדרש לעלות בסולם הערך והסיבוכיות. כדי לחסוך נדרש לפעמים לעבור לטכנולוגיות חדשות, או באופן מפתיע, לחזור לטכנולוגיות ישנות. זה משתנה משימוש לשימוש אבל המשותף לכולם הוא שאנחנו משקיעים רק כשה- ROI חיובי ומיידי, או מאוד קצר. הרמה הגבוהה ביותר היא הרמה שבה אנחנו מטמיעים אוטומציה ושיקולי עלות לתוך תהליכי התכנון והפריסה של המערכות שלנו בענן. עוד על נושא זה בהמשך.
הקניית ידע
פן חשוב מאוד הוא העשרת הידע של האנשים הנוגעים בדבר בארגון בנושא עלויות הענן והדרכים למצות את יתרונות הענן, כולל היכולת לעמוד בדרישות עסקיות בעלויות נמוכות. זהו תהליך לא קצר ולא זול אבל הוא הכרחי. העלאת המודעות הארגונית לעלויות הענן ולהשפעה שיכולה להיות להם בשורה התחתונה של הארגון כולו היא חלק חשוב בניהול העלויות.
הדברים הבסיסיים שצריך לעשות:
ניטור
הקלישאה המתבקשת של ידע הוא כוח רלוונטית מאוד לניהול עלויות בענן. ללא ניטור אנחנו עיוורים ונראה את הבעיות רק שכבר יהיה מאוחר מידי, כלומר כשקיבלנו את החשבון. זה אמנם נחמד לדעת על מה הוצאתי כסף בחודש שעבר, אבל זה בהחלט מאוחר מדי. הניטור תפקידו לתת תמונת מצב עדכנית עם אקסטרפולציה אל העתיד כדי לאפשר לנו להגיב בזמן ולהימנע מעלויות מיותרות.
אוטומציה
אוטומציה הינה מרכיב מהותי בתהליכי finops. בדיוק כמו שבונים אוטומציה שמטרתה להתמודד עם כשלים במערכות מחשוב, נדרשת בניית אוטומציה שמטרתה להתמודד עם כשלים כספיים. לצורך העניין, כשל כספי הינו כל מצב שבו משלמים על משאבי ענן שאינם מנוצלים. זה כולל את הנושא של שימוש במשאבים גדולים ויקרים ביחס לנדרש לביצוע המשימות.
שליטה
אין כמובן דרך לשלוט במעל מיליון "מוצרים" בלי אוטומציה. בהינתן אוטומציה, בהחלט ניתן לבנות מערכת שליטה (Gouvernance) שמאפשרת שיוך עלויות לפעילויות ותקציבים. תפקיד חשוב של המערכת הוא לוודא שאנחנו לא במסלול חריגה מהתקציבים המאושרים. בלי מערכת שליטה, חריגות תקציב בלתי-נמנעות.
חוזר חלילה
תהליכי אופטימיזציה של הענן הם תהליכים מחזורים ונדרש לבצע אותם באופן רציף ומחזורי כדי להתמודד עם השינויים הדחופים בשימושי הענן של הארגון.
אבטחת מידע
קיים פקטור, נדיר יחסית אך משמעותי, של עלויות שנוצרות כתוצאה מנושאי אבטחת מידע. חלק מניהול פיננסי של ענן צריך לכלול גם תוכניות אופרטיביות לטיפול מהיר באירועי אבטחת מידע וכן גידור של העלויות הנובעות מאירועים אלו.
כמה דרכים לשליטה בעלויות הענן:
לא אוכל לכסות כאן את כל הדרכים לשלוט בעלויות הענן. נכתבו על זה ספרים שלמים. בחרתי להביא כמה מהדרכים שלדעתי חשוב להכיר.
שיטת הקופסאות - בשיטה זו אנחנו משיגים שליטה על עלויות הענן על ידי הגבלה של שירותי הענן שבהם ניתן להשתמש. למעשה בונים קופסא שמגדירה את כל המשאבים לכל פרויקט. הפרויקט עולה לייצור בתוך הקופסה. הקופסה מנוטרת ומוגדרת היטב מראש והעלויות ברורות וידועות מראש נשמרות לאורך חיי המערכת. השיטה הזאת מאפשרת צפי מצויין של העלויות לאורך זמן ותכנון פיננסי של הצריכה. החיסרון כמובן הוא חוסר הגמישות. כן ניתן לבנות קופסאות חדשות עם טכנולוגיות חדשות בזריזות, וכך להתקדם טכנולוגית בשליטה תקציבית.
לא מתוייג לא קיים - בשיטה הזו אנחנו מורידים/מוחקים כל משאב שעולה ללא סט מוגדר מראש של טאגים. אנחנו משתמשים בתגים כדי לשייך את המשאב מבחינה תקציבית ומבחינה ארגונית. ניתן לבדוק שהטאגים מכילים ערכים תקינים בהתאם לערכים שהגדרנו מראש. משאב שעולה לא מתוייג יכובה/ימחק לאלתר. זו שיטה אגרסיבית ולא תמיד מתאימה לכל ארגון וגם ארגונים שמשתמשים בה לפעמים נמנעים מלהשתמש בה בייצור. אך היא אפקטיבית מאוד.
האצלת סמכויות ואחריות - בשיטה הזאת משקפים את העלויות לבעלי התקציב ומעבירים עליהם את הסמכות, היכולת (כלים, ניטור ותהליכים) והאחריות על התקציב. זה כולל הכנסה של יעדי עלויות ענן לתוך יעדי הרווח של היחידות העסקיות הקטנות ביותר שאפשר למדוד. הקושי הוא בשליטה המבוזרת על התקציב. היתרון הוא בגמישות בהתגייסות של בעלי העניין בארגון למשימה.
צנטרליזם - ארגונים רבים נוקטים בגישה צנטרליסטית לניהול עלויות. צוות אחד בודד מאשר ובונה את המשאבים בענן. זו שיטה שמתאימה מאוד לארגונים שאינם קלאוד נייטיב ורגילים לעבוד כך גם ב- on-prem. זו שיטה שמאבדת חלק מהגמישות שענן מאפשר אבל היא אפקטיבית מאוד בניהול העלויות וגם בהיבטים אחרים כמו אבטחת מידע. חשוב לשים לב שבדרך כלל כשעובדים בשיטה הזאת, במקביל לענן " המרכזי" נוצר שימוש בעננים פרטיים קטנים ובעלויות קטנות על תקציבי הוצאה אישית (expenses) כדי לשמר את הגמישות של הענן.
אוטומציה - לסיום אני רוצה לחזור שוב לנושא החשוב של אוטומציה. האוטומציה בנויה בכל הרבדים של הענן. יש המון יכולות שהענן עצמו נותן כחלק משירותים רבים, כמו Auto-scaling. מעל ובנוסף לשירותים האלו, נדרש לכתוב אוטומציה המשקפת את הפעילות של המערכת שלכם. העלאת משאבים, הורדת משאבים, מחיקת משאבים שאינם בשימוש, ניהול מחזור חיים של מידע, הקמה וסגירה של סביבות ועוד. האוטומציה היא חלק מרכזי בניהול עלויות הענן ובלעדיה הענן הופך מכלי שימושי וכלכלי מאוד ללא כלכלי בעליל.
מאת: סאם באב"ד, המייסד של CloudHawk.net המפתחת תוכנה לניהול אופרטיבי אפקטיבי של הענן המובילה לחיסכון משמעותי בעלויות.
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר