לפני כשבוע נערך כנס P&P Summit, שבמהלכו הרצה יוחניו פצ'ה (Eugenio Pace), אחד מהמובילים בנושא מחשוב ענן ו - S+S, מספר הרצאות בנושא Azure בפרט, ומחשוב בענן בכלל.
במהלך הכנס הבחנתי בחוסר הנוחות (או הסבלנות) שבו מגיבים אנשי פיתוח רבים לשיקולי עלות ותמחור. ספציפית, חוסר עניין בולט בהיבטים הכספיים של פיתוח אפליקציות בענן אשר נתפסים ע"י רבים כנושא לא מעניין, שיווקי, שמקומו אינו בהרצאה שנושאה ארכיטקטורת אפליקציות בענן, לא כל שכן כאשר ההרצאה עוסקת בהיבטים הטכנולוגיים של פיתוח אפליקציות בענן (ציטוט: "תראו לי קוד… לא מעניין אותי המודל הכספי – זה הקטע של מנהל הכספים, לא שלי…").
קל להבין מדוע כך הדבר: נדיר למצוא אנשי פיתוח שיכולים לספק אומדן מדויק של העלות הכוללת (TCO) של האפליקציה אותה הם מפתחים. איש הפיתוח המצוי (וכאן אני מתייחס גם לתוכניתן זוטר, לראש צוות, ולעתים קרובות גם לארכיטקט) מתמקד בהיבטים הטכנולוגיים, העיצוביים, ולעתים (לא קרובות מספיק, לטעמי) גם בהיבטים הארכיטקטוניים. אך השיקולים הכספיים של המערכת ? במקרים רבים מדי מדובר על מידע שאינו נמצא כלל ברשותו של איש הפיתוח. לרוב מדובר על בורות מבחירה, ולכל הפחות הסכמה שבשתיקה.
מחשוב בענן ישנה מצב זה באופן מהותי ומשמעותי, ויוביל את המודעות להיבטי עלויות ישירות אל שולחנם (ובסופו של דבר גם אל ה – IDE) של אנשי הפיתוח.
מדוע ?
על מנת להסביר מדוע, הרשו לי לספר סיפור קצר על פרבר הולנדי בתחילת שנות השבעים.
אחד מפרברי אמסטרדם בנוי באופן אחיד: כל הבתים בנויים על בסיס אותו מודל ארכיטקטוני, באותו גודל, מאותם חומרים, באותו עיצוב, מסודרים בשורות אחידות, עם גינות בגודל זהה, מחירי הבתים דומים זה לזה, וגם האוכלוסייה מאוד אחידה ומורכבת ממשפחות מהמעמד הבינוני עם ילדים צעירים.
במהלך משבר הנפט שפרץ בתחילת שנות ה – 70, ממשלת הולנד האיצה בתושבים לחסוך בחשמל. וההולנדים, מתוקף היותם הולנדים, נענו במידה רבה ואכן צריכת החשמל הכוללת ירדה. עם זאת, בפרבר הספציפי הזה התגלתה מגמה מוזרה: בחלק מהבתים הייתה ירידה דרמטית של כשליש בצריכת החשמל, ובחלק האחר הייתה ירידה מועטה, אם בכלל.
מה מקור הפער הדרמטי בירידה בצריכת החשמל בין בתים דומים בעלי מבנה ואוכלוסיה דומים ?
הניסיון לענות על שאלה זו העלה תשובה מפתיעה: מסיבה לא ידועה, בחלק מהבתים בפרבר מוקמו מוני החשמל בכניסה לבית. בחלק אחר מהבתים, מוקמו מוני החשמל במרתפי הבתים. מדובר על מוני החשמל הזכורים לוותיקים שבינינו: עם דיסק שמסתובב במהירות משתנה: מהירות גבוהה מציינת צריכה גבוהה של חשמל, ומהירות נמוכה מציינת צריכה נמוכה של חשמל.
בדיקה קצרה העלתה כי קיימת תאימות מלאה בין מיקום מונה החשמל, לבין הירידה הדרמטית בצריכת החשמל. קל להבין מדוע: כאשר מונה החשמל ממוקם בכניסה לבית, מקום בולט ונגיש, ניתן לראות באופן מיידי ותכוף את הדיסק המסתובב במהירות ומציין את צריכה החשמל הגבוהה. בבתים אלו, נקיפות המצפון ההולנדיות עשו את שלהן, וצריכת החשמל הביתית ירדה בשליש בממוצע. לעומת זאת, בבתים בהם מוקמו מוני החשמל במרתף, מיקום הרבה פחות בולט, נחשפו התושבים הרבה פחות למהירות הדיסק המסתובב במונה החשמלי. כתוצאה, המודעות לרמת צריכת החשמל הייתה נמוכה, ואכן צריכת החשמל הממוצעת ירדה במידה מועטה מאוד.
במקרה זה, די ברור שמה שהביא לירידה בצריכת החשמל הייתה מידת המודעות שהתקיימה כתוצאה מהיזון חוזר (feedback) שקיבל כל תושב ממונה החשמל שלו: מי שראה את המונה לנגד עיניו מספר פעמים ביום, בכניסה לביתו ובמיקום בולט, קיבל היזון חוזר תכוף ופיתח מודעות גבוהה לצריכת החשמל, ומי שראה את מונה החשמל רק לעתים רחוקות, כאשר נאלץ לרדת למרתף, לא פיתח מודעות כזו, וכתוצאה – צריכת החשמל שלו כמעט לא השתנתה.
ומה הקשר למחשוב בענן ?
מחשוב בענן אינו מהווה מהפכה טכנולוגית: אין כאן פריצת דרך טכנולוגית, ובעצם מדובר באוסף של יכולות טכנולוגיות קיימות (בדגש על וירטואליזציה וחיבור אינטרנט ברוחב פס גבוה) אשר מאפשרות לספק את היכולות הכלולות תחת הכינוי הכולל "מחשוב בענן".
השינוי המשמעותי הוא במודל העסקי והכספי, אשר הופך את המחשוב בענן למודל כספי הרבה יותר משתלם, בחלק מסוים מהמקרים (אך לא תמיד). ישנם מקורות מצוינים לתיאור המודלים הכספיים של סוגים שונים של מחשוב עננים, ולכן לא ארחיב על כך בפוסט זה.
וכאן נכנס לתמונה איש הפיתוח המצוי, אשר אינו מביע עניין רב בהיבטים הפיננסיים של המערכת אותה הוא מפתח.
השפעתו של איש הפיתוח על העלות הכוללות של האפליקציה (TCO) הינה השפעה משמעותית בכל סביבת פיתוח, בין אם היא מקומית (on-premise) או ע"ג פלטפורמת ענן כלשהי. שורות הקוד ורכיבי התוכנה משפיעים במידה רבה על מבנה המערכת, מורכבותה, כמויות ונפחי החומרה הנדרשים, דרישות ואינטנסיביות פעילות התחזוקה וכדומה.
אך בסביבת פיתוח מקומית (on-premise), ניתן לעמעם מעט את העלויות הנובעות כתוצאה מרכיבי תוכנה שפותחו in-house, בזכות קיומם של מספר רב של סעיפי הוצאה (מעבר להוצאות הישירות על פעילויות פיתוח בלבד, ישנן הוצאות בולטות על רכישת החומרה, והוצאות שוטפות רבות ומשמעותיות על עלויות אחסון, כ"א מתחזק, חשמל ואנרגיה, ועוד ועוד). כתוצאה מכך, קשה יותר לזהות את ההשפעה הישירה שיש למבנה התוכנה שפותחה ע"י איש הפיתוח על העלויות הכוללות של המערכת. יש יותר מדי "רעש רקע" מכדי לאפשר למנהל הממוצע לבצע ניתוח סיבה-תוצאה יעיל בין שורות הקוד של איש הפיתוח שהעסיק, לבין עלויות המערכת בכללותה.
לעומת זאת, במחשוב בענן מסוג Platform as a Service, רכיבי החומרה, התקשורת, אחסון המידע ותשתיות התוכנה נכללות במסגרת שירותים עליהם משלמים על בסיס צריכה ("pay as you go"). המרכיב המשמעותי היחיד שעל ארגון הלקוח לספק הוא רכיבי התוכנה המהווים את האפליקציה עצמה. כלומר: את שורות הקוד שנכתבו ע"י איש הפיתוח. משמעות הדבר, היא שבמחשוב בענן, ישנה האפשרות לזהות את הקשר הישיר שיש לשורות קוד על העלות הכוללת של המערכת. במצב כזה, ברור שיופעל לחץ הולך וגובר על אנשי הפיתוח להוריד את עלויות התוכנה אותה הם מפתחים.
אך כיצד יכולים אנשי הפיתוח להוריד את עלויות השימוש במחשוב בענן ?
במשפט אחד: מודעות להיבטים הכספיים של התוכנה אותה הם מפתחים.
איש הפיתוח הכותב שורות קוד אשר יפעילו אפליקציה אשר תתארח בשירות ענן כלשהו, חייב להיות מודע למודל התמחור של שירות הענן המארח, ולקבל החלטות אשר יצמצמו את עלויות צריכת שירותי הענן ע"י המערכת. החלטות אלו אינן רק ואינן בעיקר החלטות ברמה הארכיטקטונית, או ברמה העסקית, אלא הן יכולות לבוא לידי ביטוי בשורות קוד בודדות אשר יכולות להשפיע באופן דרמטי על היקפי צריכת שירותי הענן ע"י המערכת.
לדוגמא:
הבה נניח שאנו מפתחים אפליקציית ליצירת וניהול אתרים, אשר תעשה שימוש בשירותי ענן. אפליקציה זו רוצה לספק ללקוחותיה מידע על התנהגות המבקרים באתרים, והיא עושה זאת ע"י שמירת Log של פעילות המבקרים. במקביל, תתבצע קריאה של המידע ותצוגה למנהל המערכת, אשר מעוניין לראות את המידע העדכני ביותר, מהר ככל האפשר (הבה נניח שייעשה שימוש בעדכון שוטף של המידע המוצג למנהל המערכת, מדי מספר שניות). נראה כי השירות המתאים ביותר לשמירת Log כזה הוא מאגר מידע כגן ה – Windows Azure Storage, אשר מספק מרחב אחסון בלתי מוגבל בהיקפו.
איש הפיתוח יכול לכתוב מספר שורות קוד המבצעות פעולה פשוטה: שמירת תיעוד של כל פעולת משתמש למרחב האחסון, ובדיקה תכופה של המאגר על מנת לאפשר עדכון מהיר ככל האפשר של המידע המוצג למנהל המערכת. פשוט וקל, ללא בעיות מיוחדות. מחשוב בענן במיטבו.
אך מהו ההיבט הכספי של מספר שורות קוד אלו ?
שירותים כגון ה – Windows Azure Storage מחייבים על בסיס נפחי שימוש, נפחים אלו נמדדים לרוב ע"פ כמויות החומרה (VM's) בה ייעשה שימוש, נפחי מידע (GB אחסון בחודש), תעבורת מידע (GB מידע נכנס או יוצא ברשת התקשורת החיצונית) וכן טרנזאקציות מידע (כמות פעולות הכתיבה והקריאה שמתבצעות מול מאגר המידע), וכאן חבויה יכולתו של איש הפיתוח להשפיע באופן משמעותי – לטוב ולרע – על עלויות המערכת.
איש הפיתוח יכול להחליט לשמור את המידע באופן מהיר וממוקד, ולבצע טרנזאקציית שמירה לכל פעולה של כל משתמש. זה בהחלט נראה הגיוני ויעיל: באופן זה מצומצם הסיכון לאובדן מידע, מדובר על best-practice בסביבה שהיא stateless, נדרשות פחות שורות קוד והאפליקציה תהיה פשוטה יותר, והמערכת בכללותה תראה יכולות מרשימות יותר כתוצאה מכך (לדוגמא, החלטה כזו יכולה לאפשר רמת עדכניות גבוהה של דוחות ניהול המראים את פעילות המשתמשים).
הבעיה הסמויה בהחלטה לבצע שמירה ממוקדת ומיידית של כל פריט מידע כזה, היא היבטי העלות. אם מדובר בכמות גדולה של טרנזאקציות (קריאה וכתיבה), המספרים מתחילים להצטבר, וההשפעה הכספית יכולה להיות משמעותית, למרות שבמבט ראשון העלויות נראות שוליות.
הבה נניח, למטרת ההשוואה, שבמקום לבצע שמירה עבור כל טרנזאקצייה, איש הפיתוח יבחר לאגור את הטרנזאקציות, ולשמור אותם למאגר המידע כ – bulk update של 1,000 רשומות בכל פעולת שמירה. זוהי פעולה מעט יותר מורכבת, אך הפער בנפחי הטרנזאקציות הוא פי 1,000, וכתוצאה, גם העלות בצריכת שירותי הטרנזאקציות גדלה פי 1000, ולרוב ההשפעה חורגת גם להיבטי עלויות שירותים נוספים.
לדוגמא, בצילום המסך שלעיל, חישוב פשוט (באמצעות מחשבון ה – TCO של Windows Azure, ניתן לראות ששימוש לא מבוקר בטרנזאקציות שמירה וכתיבה ל – Windows Azure Storage יכול להוביל לעלויות גבוהות מאוד באופן יחסי (בדוגמא שלעיל: 12,000$ לשנה, ובערך שני שליש מעלות אחסון המערכת ב – Windows Azure). אם יחליט התוכניתן לעשות שימוש מושכל בטרנזאקציות, ניתן לצמצם את העלויות הללו באופן משמעותי ביותר.
אלוהים והשטן נמצאים בפרטים הקטנים. ניתן ומומלץ לעיין במידע על אופן התמחור של שירותי ענן, וכל ספק שירות ענן מספק גם מחשבון לסיוע בחישובי TCO. ניתן לדוגמא לראות את אופן התמחור של Windows Azure ולעיין במחשבון ה – TCO של Windows Azure (יש לציין כי בעת כתיבת שורות אלו, Windows Azure אינו זמין עדיין לשימוש במדינת ישראל, ונתונים אלו יכולים להשתנות בעתיד).
משמעויות:
ההשפעה של אנשי הפיתוח על עלות המערכת המתארחת בשירותי ענן הינה השפעה משמעותית ביותר. שינוי המודל הפיננסי של אירוח שירותים בענן יביא להדגשה של עלות המערכת הנובעת כתוצאה מאופן פיתוח התוכנה ע"י איש הפיתוח, וכתוצאה בלתי נמנעת מכך, תופנה דרישה כלפי אנשי הפיתוח להוריד את עלויות התוכנה, ע"י פיתוח אפליקציות וכתיבת קוד באופן מודע להיבטים כספיים.
ניתוח ההיבטים הכספיים של אפליקציה המתארחת בענן, בין אם ברמת ארכיטקטורה, עיצוב או אפילו ברמת שורת קוד בודדת, תיהפך להיות משימה שעל איש הפיתוח לבצע כחלק שוטף מפעילותו, בשל היותו הגורם בעל ההשפעה הרבה ביותר על כך, וכן היותו הגורם שבידיו המידע והיכולת לאמוד את המשמעויות הנגזרות מאופן פעילות רכיבי התוכנה אותם הוא מפתח.
על מנת לעמוד במשימה זו, נדרש איש הפיתוח להכיר את המודל הפיננסי של עלויות שירותי הענן, וחשוב מכך – לפתח מודעות לעלויות אלו, ולהיות מסוגל לנתח כיצד החלטות עיצוב בפיתוח תוכנה (הבאות לידי ביטוי בשורות קוד בודדות, ויכולות להיראות לעתים כשוליות) משפיעות על העלות הכוללת של המערכת.
אני מאמין שהלקח ההולנדי לחסכון בחשמל יהיה תקף במיוחד עבור מפתחי אפליקציות העושים שימוש בשירותי ענן: מי שישמור על מודעות גבוהה להיבטי עלויות שירותי הענן בהם הוא משתמש, יוכל לספק אפליקציות בעלות TCO נמוך יותר, לעתים באופן משמעותי ביותר, וע"י כך לספק החזר על השקעה (ROI) גדול ומהיר יותר למעסיקיו.
ייתכן ובעתיד נראה יישומים המוטבעים ב – IDE של מפתח התוכנה, אשר מסייעים לו לחשב את עלות השימוש בשירותי ענן באמצעות ניתוח של הקוד אותו הוא כותב (והנה רעיון לסטארט-אפ!).
באותה מידע של תכיפות שבה ארכיטקטים ואנשי פיתוח דנים כיום בדרישות פונקציונאליות ולא-פונקציונאליות של המערכת, ישנו גם מקום לדון בהיבטי TCO של המערכת, וכיצד ניתן לאזן ביניהם (הדבר נעשה כיום באופן חלקי ביותר ולא באופן המוטבע בפעילות העיצוב והפיתוח, וכתוצאה, תוך שמירה על מודעות נמוכה של אנשי הפיתוח להיבטי עלות המערכת).
ולסיכום:
כיום, ניתן להשוות את המודעות של אנשי הפיתוח להיבטים הכספיים של פיתוח המערכת, למיקום מונה החשמל ההולנדי במרתף הבית: מודעות נמוכה, המביאה לעלויות גבוהות יותר.
עם השינוי במודל התמחור של מחשוב בענן, והדגשת ההשפעה הישירה שיש למודעות אנשי הפיתוח להיבטים הכספיים על עלויות המערכת, נראה כיצד המודעות גדלה, ונראה גם את המקבילה של עולם פיתוח התוכנה בענן למיקום מונה החשמל בכניסה לבית - במקום שבו תהיה למידע ולמודעות השפעה מירבית, אשר תביא גם לירידה המירבית בעלויות אירוח אפליקציות בענן..
| |
שמי דני כהן ואני ארכיטקט ויועץ בצוות MCS Israel, ומתמחה במערכות מבוזרות, Cloud Computing, מתודולוגיות פיתוח וארכיטקטורת תוכנה. |