ארכיטקטורה מונחית-שירותים (SOA): על מה המהומה?

הרכינו ראשיכם והחרישו צעדיכם!
בפוסט זה אדבר על נושאי דת.

לא מדובר ביהדות או בנצרות, אם כי בדת לא פחות אדוקה - ושמה: Service Oriented Architecture - SOA.

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

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

ישנן גישות שונות ל SOA, רובן כוללות אלמנטים בירוקרטיים של ארגון גדול:

• יש כאלו שחושבים שסט תקני ה WS-* הם הבסיס לכל פתרון, גם לאינטגרציה בין ארגונים וגם פנימית בתוך הארגון. כיום, זהו קומץ קטן וסהרורי, דיברתי על האלטרנטיבות כאן.
• יש כאלו שמאמינים ש SOA היא לא רק טכנולוגיה, אלא כמעט דרך-חיים. SOA חוצה את הצד הטכנולוגי וממפה את תהליכי העבודה הקיימים באירגון. כשרוצים להוסיף תהליך עסקי / אירגוני חדש יש ללכת ולמדל אותו ב SOA. סוג של איחוד שמיימי בין אדם ומכונה - שהגבולות הולכים ומטשטשים. כדי לתאר כמעט-כל תהליך בארגון יש לנהל אלפי שירותים. מי ששולט בשירותים שולט בארגון ויש לשים Governance מרכזי על השירותים והשימוש בהם. אלו הם האורתודוקסים של SOA. הם לוקחים את התורה רחוק, רחוק. לפעמים נדמה שעבורם SOA היא כמעט-מטרה ולא "עוד כלי". האמונה שלהם ב SOA - גדולה.
• יש כאלו שמנסים להעמיק בלמידת  הצדדים הטכנולוגיים של SOA. הם מתמודדים עם בעיות שונות ומשונות בעזרת כל מיני משחקים (Patterns) ברמת השירותים והרשת. הם משתמשים ב REST, אך גם ב WS-*. מנסים למצוא איזון בין השניים ולחתור במאמץ לא קטן ל"ארכיטקטורת SOA נכונה". הם מאמינים. אלו הם ה"כיפות הסרוגות" של SOA, הם הכי קרובים בתפיסה לחילונים, להם אין כל רגשות ל SOA, אבל לעיתים נדמה שאנשי ה"כיפות הסרוגות" מתאמצים קצת יותר מדי בכדי לפתור בעיות דווקא בעזרת SOA.

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

בראשית

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

לפני עשור (וקצת) דובר הרבה על Component-Based Development. הרעיון היה להחיל את עקרונות ה OO על "קוביות גדולות יותר". "אם תכנון מונחה אובייקטים הוא טוב, למה לא לעשות אותו גם ב High Level?" שאלו.

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

...ואז באה SOA. מאיפה היא באה? השגחה עליונה? בתולה קדושה? זינוק אבלוציוני בתובנה של האנושות? - אף אחד לא יודע.
מדי פעם נאמרים דברי כפירה כגון "הא - חזרנו לתכנון פרוצדורלי של שנות ה 60" או "זוהי פשוט התפחות צפויה נוסח 'הברירה הטבעית' של עקרונות ארכיטקטונים בסיסיים, למשל הגדרת ממשקים מוגדרים-היטב". כדאי לשקול דיבורים שכאלו בשיחה עם אנשים מאמינים!

אמנם החשיבה של שירותים סותרת לכאורה את סגנון התכנון ה Object Oriented הנפוץ כיום, אך יש לה שני יתרונות:

היא פשוטה והיא עובדת. אין מניעה, ואולי אפילו מומלץ, שכל שירות יהיה בנוי בעצמו בצורה Object Oriented.

"כל מה שעשינו עד היום - רע, ומהיום הכל יהיה טוב" רומזת כרזה שיווקית של SUN, אחת המשקיעות הגדולות ב SOA.
נדמה לי שאני זוכר את השקף השמאלי מככב בצד ימין לפני עשור כשדובר על ארכיטקטורת N-Tier :)  מקור sun.com

שמות
ואלו שמות ומושגים בעולם ה SOA:
WS-*, ESB, EAI, SOAP, MOM, WSDL, UDDI, REST, SLA, DDS, JBI, CEA, E-SOA, Event-Driven SOA, Middleware, Business Process, BPM, BPMN, BPEL, SOMA ועוד ועוד...

סתם, לספוג קצת אווירה.


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

לא כל מערכת עם כמה שירותים נפרדים היא SOA. הנה מספר עקרונות מרכזיים ההופכים את הארכיטקטורה שלכם ל SOA:

הכמסה של שירותים
על השירות לכמוס (= לא לשתף) את פרטי המימוש שלו. האם הוא בנוי Object Oriented או Data Oriented? האם הוא משתמש בבסיס נתונים או בזיכרון? האם הוא משתמש ב Cache או לא? - כל אלה פרטים שכדאי למנוע ממשתמשי השירות כך שלא ייקשרו אליהם ויפגעו משינויים במימוש.

Service Contract
לכל שירות יש חוזה פעולה ברור. החוזה של השירות הוא לרוב ה API.
עד כמה ששפות התכנות מפותחות - הן עדיין מוגבלות ביכולת הביטוי. חשוב להבין שה API הוא רק חלק מהחוזה הכולל. כלומר, בעזרת Interface בשפת #C או Java אני יכול לומר מהן המתודות והמשתנים שהשירות מצפה לקבל, אך אני לא יכול לבטא דברים כמו:

• האם קריאה לשירות היא יקרה או זולה (Performance)
• לאיזה התנהגויות הוא תוכנן ולאיזה לא (הנחות יסוד). באיזה מקרים הוא לא תומך או לא נכון להשתמש בו.
• התנהגות במקרי קיצון
• וכו'

כל אלה מרכיבים את החוזה של השירות. כדאי מאוד שהחוזה יהיה מפורש וברור: גם למי שמפתח את השירות (נשמע ברור, אך לא תמיד זה כך) וגם למי שצורך אותו.
הכלים לתיאור החוזה הם:

• אכיפה ברמת השפה  (למשל טיפוסים) / פרוטוקול (למשל MIME TYPE).
• שמות נכונים של השירות, המתודות והמשתנים.
• מטאפורה, חלוקה לשירותי משנה בצורה שמכוונת את המשתמש נכונה.
• תיעוד, תיעוד תיעוד.

באופן תאורטי היה נחמד אם היה אפשר להחליף את שירות אחד בשירות עם מימוש אחר שעונה לאותו contract, מבלי שאף אחד מהלקוחות שלו ישים לב.

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

Service Policy

ברגע שהמערכת היא מבוזרת (מערכות גדולות לרוב מבוזרות בצורה כזו או אחרת), עלינו לפתור עוד מספר עניינים:
איך מוצאים את כתובת השירות? אבטחה (Authentication, Audit) של השירות? התנהגות השירות בעת עומס / תקלות ועוד.
במקום לפתור את הבעיה כל פעם מחדש - אני יכול לפתור אותה פעם אחת בצורה מרוכזת ע"י הגדרת מדיניות לכל השירותים במערכת / ארגון. מצד שני לשירותים שונים יש צרכים שונים. חלקם מכילים מיידע חסוי - חלקם לא. חלקם קריטיים לפעילות עסקית, ונרצה שתמיד יהיו למעלה גם במחיר גבוה, - וחלקם לא.

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

אין הגדרה חד משמעית מה אמור להכיל ה Policy - יש גישות שונות. יש כאלו שיכילו אלמנטים של אבטחה וגישה - יש כאלו שיכללו בהם SLA או צורת ההתקשרות (messaging, request-response). העניין המעניין הוא שזהו חלק בחוזה שמשותף להרבה שירותים ואין טעם להגדירו כל פעם מחדש, יהיה החלק מה שיהיה.


ומחשבה קצרה בצד: אם נחשוב בצורה יותר מופשטת, אין קשר חזק בין איך עובד השירות לאיך מוצאים אותו, מבצעים Authentication אליו, היכן השירות ממוקם גיאורפית וכו'. יש decoupling אמיתי בין מה שהשירות מספק לאופן הצריכה של השירות. על בסיס זה ניתן לעשות הרבה משחקים ווריאציות. זו יכולה להיות הזדמנות לכמה פתרונות ארכיטקטוניים מעניינים ולא מעט דיונים ופילפולים הנגמרים בהסתבכויות בלתי-רצויות. ל SOA יש על כך גם "גמרה" וגם "משנה" - יש היסטוריה של אנשים שהלכו רחוק מדי עם SOA אל חזון שנשמע מתוחכם אך לא היה מעשי - כדאי להזהר.

תכננו לעצמאות מירבית
כפי שציינו, השירותים לרוב יהיו חלק ממערכת מבוזרת. במערכת מבוזרת יש לעיתים Latency (אם היא מבוזרת על פני Data Centers) אבל גם ייתכנו כשלים: שירות לא זמין, נתק ברשת וכו'.
כשאתם מתכננים שירות עליכם לדאוג שהוא ימשיך לעבוד טוב ככל האפשר כאשר שירותים אחרים שהוא מסתמך עליהם אינם זמינים. טעות דבילית למדי (סליחה, היסטוריה אישית) היא לבצע קריאה סינכרונית שנכנסת לBlocking לשירות אחר. אם השירות האחר חי אבל תקוע - גם השירות שלכם ייתקע במהרה.
כאשר שירות אחר שאתם תלויים בו כושל - תרצו להחזיר תשובות פחות-טובות או להחזיר הודעות שגיאה. לא תרצו לא-להגיב או להתקע (ואולי לתקוע שירותים אחרים שאינם זהירים).


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

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

סכנה שנייה היא יצירה של המון שירותים. שמעתי כבר את המשפט "מעולם לא הצטערנו על שירות שחילקנו ל 2" מפי אנשים שאני מעריך, אבל בעיה נפוצה היא להפוך כל 3 פונקציות בסיסיות לשירות - ה overhead הפוטנציאלי הוא אדיר. שירות צריך להיות coarse-grained ולתאר פונקציה גדולה ומשמעותית מספיק.

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

סכנה אחרונה שאציין היא התעסקות עם תקני WS-*. אלו תקנים סבירים לחיבור בין מערכות שונות מאוד (שפה שונה, אירגון שונה, מערכות Legacy) - אבל דיי overkill לרוב השימושים האחרים. התחילו בקטן עם שירותים מבוססי HTTP Messages או REST.


דברים
כמה דברי סיכום:

SOA קושרה בצדק או לא (תלוי את מי שואלים) ל Web Services ו WS-* עם הבעיות הרבות שלהם. SOA יכולה להיות מוצלחת למדי - אם מצליחים לעשות אותה במידה ובמקומות המתאימים.

ל SOA יש כמה ייתרונות ברורים:

• צורה פשוטה יחסית לבניית מערכת מבוזרת - מערכות שקל מאוד להסתבך איתן.
• פוטנציאל טוב לשימוש חוזר בקוד (רעיון נשגב, שפעמים רחוקות יוצא אל הפועל). שירות הוא רמה מצויינת לשימוש חוזר: בעל משמעות, אך לא נקודתי מדי.
• פרדיגמה פשוטה שקל להבין.
• בניה של שירותים עצמאיים עם תלות נמוכה תקל על ה Upgrade ותפחית את ה down-time של המערכת: ניתן לעשות upgrade לשירות אחד בלבד - ושאר השירותים יתמודדו עם ה down time בצורה טובה. יכולת זו תקל על יישום של Continuous Delivery.
• הגדרה של שירותים הפועלים ע"פ חוזים תקל על מתכנני המערכת לבקר את נכונות הארכיטקטורה של המערכת: ניתן להתמקד בחוזה של השירותים והתלויות בין השירותים - ללא הצורך להכיר כל פינה במערכת.

שמים לב לקשר בין הנקודות?
מערכות מבוזרות...? שימוש-חוזר בקוד...? Continuous Delivery ו Availability...?

SOA והענן. מקור: http://webtechnologiesarticle.blogspot.com/

צודקים לגמרי! SOA פורחת מחדש בעולם הענן. היא מתאימה למדי ואכן היא זוכה לשימוש נפוץ. ציינתי אותה כתכונה עשירית ב 10 המאפיינים של שירותי ענן.


בהצלחה והמשיכו בזהירות. נתראה בחגים!

עננים ציבוריים ועננים פרטיים (Cloud Computing)

זהו פוסט המשך לפוסט שדיבר על PaaS, SaaS ו IaaS, ולפוסט 10 תכונות של שירותי ענן.

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

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

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

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

כשאמזון הציגו את פתרון הענן שלהם הם עשו תצוגת תכלית של אבטחה: קירות בטון, מצלמות אבטחה, שומרים מגודלים וכלבים רעים. משהו נוסח חומת ברלין בזמן המלחמה הקרה[1]. "בוודאי יותר אבטחה ממה שיש לכם היום" הם הצהירו. מה קרה מאז? עד כמה מנגנון האבטחה החזיק מעמד? אף עובד שכפוף אליכם לא יכול "לקפוץ לביקור פתע". מנהלים מכירים היטב את הפער ברמת המחויבות של עובדים שכפופים אליהם וכאלו שלא.
במידה רבה אלו הם שיקולים פסיכולוגיים, קרוב לוודאי שגם אמאזון דואגים לאבטחה - יש להם הרבה מה להפסיד. בכל זאת אלו דאגות מוחשיות המקשות על ארגונים לעבור לענן ציבורי.

אינטרנט פרטי?
באופן דומה להפליא, ארגונים רבים התקנאו בעבר באינטרנט וכל היכולות שהוא הציע. בתחילת שנות התשעים רוב הארגונים עוד עבדו עם רשתות של נובל או מייקרוסופט שתוכננו במקור לקנה מידה קטו בהרבה: עשרות עד מאות מחשבים. טכנולוגיות כמו Token Ring ו NetBIOS (או גרסה יותר מתקדמת שנקראה NBF) איפשרו יכולות די בסיסיות והיוו את הסטנדרט הארגוני. "רשת" לא הייתה יכולת מובנית במערכת ההפעלה. על המשתמש היה להתקין מערכת הפעלה, "חומרה יעודית לרשתות" (כרטיס רשת) ותוכנה (נובל או מייקורוספט) להרצת הרשת. לנובל, אם אני זוכר נכון, היה נדרש שרת ש"ינהל את הרשת". חשבו באיזה קלות אתם מתחברים היום עם ה iPad לרשת הביתית.
האינטרנט נחשב לאיטי (הגישה לרוב הייתה דרך קווי טלפון), חסר תמיכה בצרכים ארגוניים (לדוגמא הדפסה) ובלתי-ניתן לשליטה. בכלל - הוא תוכנן כאילו יש בעולם רק אינטרנט אחד(!). למרות זאת, טכנולוגיות האינטרנט היו יעילות בהרבה וככל שלארגונים נוספו עוד ועוד מחשבים, "הרשתות הארגוניות" התקשו לעמוד במשימה.

בתחילת שנות ה-90 אוניברסיטאות, וכמה שנים אח"כ גם ארגונים עסקיים, התחילו להטמיע "טכנולוגיות אינטרנט" ברשת הארגונית. על מגבלת המחסור ברשתות התמודדו עם subnet masking ואת שירותי ההדפסה העבירו על גבי TCP. בהדרגה, פחת החלק של הטכנולוגיות של מייקרוסופט ונובל והוחלף ע"י טכנולוגיות אינטרנט סטנדרטיות: HTTP, אתרי אינטרנט ("פורטל ארגוני"), Firewalls, דואר אלקטרוני ועוד.
הסיפור אינו אמור להפליא, הוא מתרחש שוב ושוב במהלך ההיסטוריה: טכנולוגיה עם ייתרון מובנה (scale במקרה שלנו) מתחילה בעמדת נחיתות, המתחרים מזלזלים וצוחקים עליה אך הבעיות בה נפתרות אחת אחת עד שהיא הופכת להיות מתמודדת ראויה. בשלב זה הייתרון המובנה של הטכנולוגיה החדשה אינו ניתן לחיקוי ע"י המתחרים המסורתיים - והמערכה מוכרעת לטובתה. כך היה עם הטלפון שבגרסאות הראשונות היה מוגבל לטווח של 10 ק"מ ודרש חיווט ידני. מנהלי המוצר של חברות הטלגרף, חברות בעלות אמצעים אדירים, צחקו על הטלפון והסבירו ש"בשביל 10 ק''מ תלך ותפגש עם האדם פנים-מול-פנים. כל הבלאגן כדי לדבר איתו בטלפון הוא פשוט use-case מגוחך". בל ניסה למכור ל Western Union את הפטנט ב 100,000 דולר - אך הם ויתרו. התוצאה כיום ידועה. הרכבים הראשונים היו ללא בלמים, על הנהג היה ללחוץ על הקלאץ' כל הדרך לעצירה. חברות הרכבת, תאגידים עצומי-מימדים, גיחכו והתעלמו. התוצאה ידועה. כך גם עם המחשב הפרטי (PC) ועוד ועוד... [3]

ע"פ סקר עכשיווי (מקור, עמ' 5) שתי הדאגות העקריות של ארגונים מאפליקציות ענן הן אבטחה וביצועים (זמני תגובה, איכות הרשת וזמינות). את שתי הבעיות הללו ניתן לפתור ע"י הטמעת "טכנולוגיות ענן" בתשתית הארגונית: להתקין כמה עשרות שרתים עם טכנולוגיות Virtualization, אלסטיות וניהול אוטומטי - ולהריץ ענן קטן.

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

• ענן פרטי (Private Cloud)
• ענן מנוהל (Hosted Cloud)
• ענן משותף (Community Cloud)

ענן פרטי
מגמה שתופסת תאוצה היא ארגונים שרוצים להריץ את אפליקציות הענן - In House. "שלחו לנו את ה Appliances" הם מבקשים מאיש המכירות של אפליקציית ה SaaS - "ה IT שלנו יתקין ויתחזק אותם, מקסימום עם קצת תמיכה מכם". ספקי הענן לרוב מופתעים בהתחלה - אך יש כסף בצד השני והמעבר הוא לא כ"כ קשה:

• אפליקצית הענן לרוב נכתבה עבור חומרה לא ידועה. ניתן לבחון שרתים סטנדרטיים של חברות כמו IBM או HP ולמכור אותם כ "Appliance".
• נוהלים וכלי אוטומציה לניהול הענן - כבר יש. לבנות גוף תמיכה על בסיס ידע קיים - לא כ"כ קשה.
• "טכנולוגיות הענן" אינן נחלתן הבלעדית של אמזון או מייקרוסופט, ישנן ספריות קוד-פתוח כגון OpenStack או vCloud שמספקות יכולות דומות.

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

שאלה לגיטימית היא למה פתרון שכזה הוא "ענן פרטי" ולא "Data Center מנוהל מרכזית"?
השוני הוא, במידה רבה, בשימוש בוירטואליציה. וירטואליזציה שמאפשרת לאפליקציות לרוץ על מספר שונה של שרתים - ע"פ הצורך. אמנם הארגון צריך להחזיק מספיק מכונות לתמוך ברגעי שיא של צריכה, אך הוא יכול לווסת בין האפליקציות השונות שרצות על אותה חומרה. הסבירות ל Peak בשימוש בכל האפליקציות בו-זמנית הוא קטן[4]. עוד יכולת מעניינת היא היכולת של ה IT לחייב את היחידות הארגוניות השונות ע"פ שימוש בשירותי המחשוב בפועל.
לרוב הענן הפרטי יהיה קצת יותר יקר מענן ציבורי - יש פחות ייתרון לגודל והנצילות של החומרה נמוכה יותר, אך יתרונות האבטחה והרשת המהירה מצדיקים את מחיר הפרמיום עבור ארגונים רבים.

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

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

ענן מנוהל
זהו שלב-ביניים בין ענן פרטי לציבורי: ארגון הרוצה אבטחה גבוהה ורשת יציבה ממה שמספקים ספקי ענן ציבוריים, אך לא רוצה לנהל את הענן בעצמו. חברות כמו HP, GoGrid ו IBM ישמחו לעשות זאת עבורו עבור תשלום (לא-)צנוע. חברות אלה מספקות שירותים של Hosting ל Data Centers של ארגונים כבר במשך שנים והן צברו מיומנות לא מבוטלת. אמנם ספק ה Hosting יושב באתר מרוחק (עם כל המגבלות שבכך), אך עבור התשלום המתאים הוא ישמח לפתוח VPN על גבי קו אינטרנט מהיר שישפר בהרבה את ביצועי הרשת והאבטחה שלכם.

ענן משותף
סוג ענן זה הוא עדיין בחיתוליו - אך נראה שיש לו הרבה פוטנציאל. חשבו על הענן הפרטי שמקימה רשת בתי חולים גדולה, למשל (Hospital Corporation of America (HCA - רשת אמריקאית של 150 בתי חולים ב 270 אתרים. HCA הוא ארגון-העל המשרת בתי-חולים רבים. כאשר ארגון מנהל מידע רפואי של חולים, יש עליו דרישות מחמירות בתחום אבטחת הפרטיות של של חולה. רופא שיחשוף פרטים חסויים של מטופל - עלול להשלל רשיונו. מה יקרה לאיש-IT רשלן? לצורך כך הגדירו בארה"ב תקן מחמיר בשם HIPPA המחייב ארגונים המחזיקים במידע רפואי של חולים לנהוג ע"פ סדרה מסוימת של נוהלים. אני לא מקנא בקבוצת הפיתוח שתאלץ להתמודד עם התקן בפיתוח תוכנה בענן,  אך לאחר שתאימות ה-HIPPA הושגה, תוכל HCA להציע את השירות לכל בתי-החולים ברשת.
ומה עם שותפי-מחקר? אוניברסיטאות, חברות תרופות ועוד? גם הם מחזיקים במידע רגיש הנכלל בתקן ה HIPPA. מלבד הייתרון של "לא להמציא את הגלגל מחדש", יש עוד ייתרון לאותו שותף עסקי שיצטרף לענן של HCA: הוא יוכל להציע את השירותים שלו לבתי-החולים השונים עם Latency נמוך (הרי השירותים יושבים באותו Data Center) ואבטחה גבוהה (התקשורת לא עוברת באינטרנט הפתוח)!

אם אתם זוכרים את הפוסטים הקודמים, ציינו שאחת המגמות הפחות מפורשות של שימוש בענן הוא אימוץ SOA ובניית המערכת בעזרת שירותים אחרים בענן. מצד אחד - זהו שיפור משמעותי ביכולת לפתח אפליקציה בקלות. מצד שני - לא ברור היכן השירותים הללו יושבים. אולי הם מפוזרים אצל ספקי IaaS/PaaS ברחבי העולים? ה Latency לפעולה הדורשת קריאה למספר שירותים, הקוראים לשירותים אחרים יכולה להצטבר לזמן משמעותי.
עוד אלמנט מורגש, למי שפיתח מערכת התלויה בשירותים שונים בפיזור גאוגרפי, היא בעיית הזמינות. ככל שהמערכת שלי תלויה ביותר שירותים חיצוניים כך גדל הסבירות שאחד מהם לא זמין ברגע מסוים. האם זו בעייה של ספק השירות, ספק הענן הציבורי או בעיית תקשורת - זה לא משנה בכלל. השירות לא זמין והפונקציונליות (או יותר גרוע - הזמינות) של האפליקציה שלי - נפגעת.

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

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

בהצלחה.


הערות שוליים

[1]  מערך ההגנה של חומת ברלין הוא סיפור מעניין בפני עצמו:

• 302 מגדלי שמירה עם שומרים חמושים.
• קיר בטון חלק בגובה 4 מטר עם גדרות תייל בראשו
• שדה של ברזנטים מחודדים (שנקרא "העשב של סטאלין") שמקשה מאוד על ריצה והופך נפילה למסוכנת.
• 20 בונקרים עם שומרים בקו ההיקף של השדה
• מאות שומרים חמושים מלווים בכלבים תוקפניים
• שביל גישוש ברוחב 6 עד 15 מ' עם פטרול לגילוי חדירות למרחב
• תעלה למניעת מעבר של רכבים
• גדר חשמלית וגלאי תנועה
• מרחב גדול שהושטח על מנת להסיר מקומות מחבוא אפשריים (שנקרא "רצועת המוות")

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

[2] מנכל אינטל, אנדי גרוב, ניסה ללמוד את הלקח וגרס "רק הפרנואידים שורדים". עד היום אינטל הפליאה להיות קשובה לשינויים: קו מעבדי הסלרון, מעבדים חסכניים באנרגיה ועכשיו מעבדים למחשבי tablet ואבטחה בחומרה. כל אלו תגובות של אינטל למגמות שלא הומצאו אצלה אך היא נותרה קשובה. האם מודעות מספיקה? האם ארגון רגיש-לשוק יצליח להיות מספיק גמיש כדי לשרוד את שינויי המגמה בעולם? האם התרבות הארגונית וההשקעות הקיימות לא יכבלו אותו, מתישהו, להשאר בפינה "נוחה"? שאלה טובה - אין לי תשובה.

[3] המעבר מ Appliances לענן הוא לרוב קשה בהרבה!

[4] אמזון וספקי IaaS אחרים אוהבים ליצור את הרושם שיש להם Data Centers אינסופיים - אך גם הם מוגבלים.

על Domain Driven Design

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

הקדמה
הקשר בין גודל התוכנה לסיבוכיות שבה הוא קשר ברור וידוע.

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

בסופו של דבר (בשאיפה), התוכנה פוגשת לקוח, הלקוח מרים גבה, הדרישות משתנות, והשינויים במערכת גדולה ומורכבת - הם קשים.

כיצד ניתן לשנות זאת?

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

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

הרבה יודעים לתת הנחיות וטיפים, אך מלבד בודדים (כמו תנועת האג'ייל שהציגה שיטות ישימות), הרוב סתם מדברים. פעם עבדתי בחברה בה הביאו מרצה אורח שדיבר על פשטות ובסופה חילקו לכל העובדים ספר משעמם עד גרוע על פשטות. המרצה סיפר בהתלהבות כמה פשטות היא טובה בכל תחומי החיים, אך מלבד העצה "לחשוב פשוט על פשטות" - הוא לא עזר בכלל להגיע לשם :(

ובכן, היכונו! אוונס וה DDD (כלומר [Domain Driven Design [1) הולכים ללמד אתכם כיצד לקבל דרישות איכותיות יותר וכיצד לבנות מערכת שתהיה גמישה יותר לקבלת דרישות עתידיות. הדרך להתמקצעות היא לא פשוטה, אך כל מי שיש לו גישה לדרישות של לקוחות וקצת חשיבה מופשטת יכול די מהר להגיע לתוצאות ראשונות.

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

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

על התהליך הנפוץ לתכנון תוכנה
לא משנה אם אתם עובדים Waterfall או Agile, קרוב לוודאי שהמתכנתים לא אוספים את הדרישות מהלקוח בעצמם. יתרה מכך, גם שמדברים עם הלקוח לא תמיד יהיה זה המומחה העסקי. ייתכן ואתם מדברים עם מנהל התפעול בבנק ("לקוח") שרוצה מערכת לניהול משכנתאות, אבל אתם לא מדברים עם מי שמתעסק עם זה בפועל (Domain Expert). על מנת לפשט לכם את הנושא, מנהל התפעול משתמש במושגים שיותר קלים להבנה. ה PM לוקח צעד אחד הלאה ומשתמש במושגים יותר מקובלים מהעולם-הלא-מקצועי כי "מפתחים יאבדו כיוון אם נציף אותם בכל המידע הזה". זהו הרי תפקידו.
הארכיטקט או המומחה הטכנולוגי מפשט את הדברים קצת יותר להתאים לתשתית הקיימת , זה תפקידו, והופ - המפתחים מבינים בקלות על מה מדובר וניגשים מייד לעבודה.

הנה דוגמא ויזואלית של הסיפור עבור מערכת מעקב חיובים. אמנם פיתחתי כזו לפני 10 שנים ויותר, ובוודאי שכחתי את הרוב. סליחה על אי-דיוקים או חוסר שלמות במודל. הדוגמא למטה אינה מבוססת על מספיק ידע בכדי לפתח מערכת חיובים ע"פ ה DDD, אבל אני מקווה שהיא מספיקה לצורך הדגמת התהליך (יש לקרוא משמאל לימין):

מקור: softwarearchiblog

כפי שסיפרנו ה Domain Expert (אשתמש ב DE מעכשיו) משתמש בטרמינולוגיה משלו וכל שאר הגורמים בדרך מתרגמים, שלב אחר שלב, כך שלמפתחים יהיה ברור מה "עליהם לעשות". הכל טוב, לזמן מה - עד אשר מגיע שינוי לא-צפוי בדרישות:

מקור: softwarearchiblog

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

בואו נעצור לרגע: אנו מדברים במושגים ("חשבונית") ובתסריטים (Use-Cases) אך מאחורי כל אלה יש לנו מודל תפיסתי (Conceptual Model) שמתאר איך הדברים מתרחשים. בני-אדם, כמונו, נוטים להרגיש אי-נוחות בעת שהם עוסקים בנושא לא מוכר. כתרופה, מנגנוני החשיבה שלנו גורמים לנו להשלים, באופן כמעט מיידי, את סט העובדות שניתנו לנו למודל תפיסתי הגיוני (מבחינתנו). איכות העובדות שהועברה לנו, כשרון ומזל יכתיבו עד כמה נכון המודל שבנינו. לא מעט ריבים / חוסרי-הבנה נוצרים בגלל הפער שבין המודל של אדם א' לאדם ב', שניהם ניזונו מאותן עובדות.

הפתרון "הרשמי"
אז מה עושים? אחד העקרונות המרכזיים של DDD הוא שפה-רוחבית (ubiquitous language). על מישהו, ה business analyst, לחפור ללמוד ולהגדיר עם ה DEs שפה אחידה ומוסכמת על פיה כולם יעבדו, שפה שבעצם תגזר מתוך Conceptual Model ברור ומלוטש (במידת האפשר).

מקור: softwarearchiblog

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

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

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

אז מה יותר יציב מרשימת use-cases ומסכי UI? היכן אנו יכולים להשקיע בלמידה של המקור ממנו באות הדרישות? ידע יציב שאינו נוטה להשתנות בקלות?
ובכן - זהו ה Domain, תחום העיסוק, הביזנס, הידע שמי שעוסק בתחום חייב לדעת על מנת לעסוק בו. הביזנס אינו משתנה במהירות.

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

ע"פ DDD, יש להשקיע זמן לא דווקא בשמיעת עוד דרישות וציור עוד מסכים - דבר שאנו מתפתים לעשות, אלא בלמידה לעומק של הדומיין. הדומיין יתואר במודל (להלן Conceptual Model) שהשימוש בו יהיה חוצה גבולות: לקוחות, מחלקת מוצר/שיווק ומחלקות הפיתוח השונות. כל דרישה עתידית תעבור דרך אותו מודל ותעדכן אותו ע"פ הצורך, אך סביר שהשינויים יהיו קטנים והגיוניים.
אם הקוד יהיה שיקוף של המודל - גם השינויים בו יהיו קלים יותר.

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

מודל קונספטואלי המתאר פעולה בנקאית. האם המפתחים, מנהלי המוצר והלקוחות שותפים לאותה תמונה (או הבנה)? מקור: martinfowler.com

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

אילוסטרציה: domain experts.
כמעט ושמתי תמונה אומנותית של מנהל חשבונות זקן משנות ה-50, אך כנראה שבישראל בשנות ה-10, תתקלו יותר ב domain experts שדומים לאלו, שני מנהלים ב-888.
מקור: כתבה ב"אנשים ומחשבים".

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

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

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

הקשיבו לשפה
כלל #1: אם בשיחה עם הלקוח (DE), הלקוח משתמש הרבה במושג (למשל, "חשבונית") ואין לכם אובייקט מרכזי בשם "חשבונית" - זהו סימן לפער במודל. תקנו את המודל שייתן משקל מתאים למושגים החשובים בהם משתמש הלקוח בשיחה היום-יומית.

כלל #2: אם אינכם יכולים לבטא רעיון מרכזי או דרישה (למשל: "יש בסוף כל שנה להוציא דו"ח של החשבוניות שלא זוכו ממס") מבלי להתבסס על המושגים הבסיסיים במודל - עליכם לחזור ולהבין למה. לרוב זה יהיה אי-דיוק, בהירות או שלמות של המודל.

זכרו: "(You can run, but you cannot hide (a bad conceptual model". אם "תשקרו" את המערכת ותעבדו עם מודל לא מדוייק, זה יחזור אליכם בדמות תחזוקה קשה ודרישות עתידיות הקשות ליישום.
לדוגמא: תיאור של מחשב עם 2 כתובות IP כשני מחשבים עם אותו השם, כל אחד עם כתובת IP אחת - אולי יקצר את הפיתוח בשלב הראשון, אך יחזור אליכם כמוברנג כחלק מדרישות עתידיות. ניסיתם "לשקר" במודל.

סיכום
למי שהתנסה בהצלחה במידול בכלל או DDD בפרט, מידול נראה חלק הכרחי בבנייה של כל מערכת. תורת המידול אינה נפוצה ואינה קלה - אך היא מביאה תוצאות ממשיות. המקור הטוב ביותר שאני נתקלתי בו עד היום הוא הספר Analysis Patterns של Martin Fowler, ספר קצת לא-מסודר אך בעל תובנות עמוקות.

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

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

[1] בעברית: תכנון מונחה-תחום, תרגום לא כל-כך מוצלח לדעתי - אך לא מצאתי טוב יותר.

כיוונים חדשים-ישנים במתודולוגיות פיתוח תוכנה (Data-Oriented Programming)

תשאלו אנשים הכותבים מערכות ב #C או Java מהי מתודולוגית הפיתוח הנפוצה ביותר כיום וקרוב לוודאי שתשמעו "תכנות מונחה-עצמים, ברור!".

הייתי מקשה ושואל: "איך עובד לכם תכנות מונחה-עצמים, טוב? עומד בציפיות?" והתשובה היא לרוב "האמת, ביננו? קצת חטאנו ויש מה לשפר - אבל בגרסה הבאה קצת נשפר / במערכת הבאה נכתוב הכל 'כמו שצריך' והכל יהיה טוב..."

ובכן, לצערי רוב המערכות שראיתי (וראיתי) היו לא-מוצלחות בהיבטי ה Object-Oriented. כינויים נפוצים למערכות אלו הן:

• Anemic Object Model - מצב שבו האובייקטים הם דלילים ולרוב מחזיקים רק נתונים או רק פונקציות.
• או Big Ball Of Mud - "גוש גדול של בוץ" (שהאמת, מתייחס למגוון רחב יותר של בעיות).

רבים מאיתנו רוצים ליצור תוכנת Object-Oriented הבנויות לתפארת עם Domain Model עשיר, אך אנו נכשלים לעשות זאת שוב-ושוב. האם רוב המתכנתים בעולם גרועים? או שאולי מתודולוגית ה Object-Oriented אינה טובה? (השם ירחם - דברי כפירה)

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

אז אם לא תכנות מונחה-עצמים, אז מהי האלטרנטיבה? תכנות פרוצדורלי? תכנות פונציונאלי? או אולי לכתוב את כל המערכת בפונקציה אחת גדולה? (הכי קל - בהתחלה)

פיתוח מונחה-נתונים (Data Oriented Programming)
בתכנות מונחה-עצמים, האובייקטים הם במרכז ובתכנות פרוצדורלי - הפונקציה היא במרכז. בתכנות מונחה-נתונים (DOP מותר לבטא כ Dope) תשומת הלב נעה מן הקוד לכיוון הנתונים: מהו הקלט, איזה טרנספורמציות (עיבוד) המידע עובר וכיצד הוא נראה בסוף.

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

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

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

על האנומליה של הזכרון
בוודאי למדתם באוניברסיטה קורס "מבני נתונים" - קורס חשוב המכסה חומר לא טריוויאלי.
למדתם שיש רשימה משורשרת עם הכנסה של (O(1 ו"טיול" (traversal) של (O(n, ויש וקטור (נקרא ArrayList ב #C וג'אווה) עם מחיר הכנסה של (O(1 או (O(n (עבור הכנסה באמצע או מילוי המחסנית שהוקצה) ו"טיול" (traversal) של (O(n.

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

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

פיזור מקובל של תפוסת-זכרון של רשימה משורשרת (באדום). מקור: תוכנת ה disk defrag שלי ;-)

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

• אנו יודעים שמערכת ההפעלה עובדת עם Virtual Memory. אם בלוקים של זכרון בהם שמור אלמנט אחד לפחות מהרשימה שלנו הם paged out (כלומר נשמרו לדיסק על מנת לשחרר זכרון פיסי), מערכת ההפעלה תקבל Page Fault שיגרור Context Switch וטעינת הדף / כתיבת דפים אחרים לדיסק - פעולה יקרה!
• זכרון המטמון (בעיקר L2 ו L3) במעבד נוטים לעשות prefetch ואחזקה של בלוקים של זכרון - לא תאי זכרון בודדים. כאשר אנו משתמשים בזכרון רציף גישה זו תהיה מועילה, אך עבור רשימה משורשרת היא יכולה אפילו להזיק ולבצע prefetch לזכרון לא רלוונטי [1].

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

במשך 30 השנים האחרונות - המעבדים הלכו והפכו מהירים עוד ועוד , משמעותית מהר יותר מהקצב בו התפתח הזכרון. אם ב 1980 המעבד המתין Cycle אחד לקריאה מהזכרון, היום הוא ממתין בערך 400 Cycles. הבעיה מחמירה כאשר הזכרון הזמין גדל (המעבר לעבדי 64 ביט פרץ את גבולות 4GB זכרון) ואנו רוצים להשתמש בזכרון על מנת לעבד כמות רבה יותר של נתונים - בעיה הידועה כ"צוואר הבקבוק של פון-ניומן". מעבדים מודרניים יודעים לעבוד עם Bus רחב בהרבה לזכרון, כלומר קריאה של יותר ביטים במקביל שמושגת ע"י קריאה (וכתיבה) במקביל מ 2 עד 4 יחידות זכרון (עקרון שדומה מאוד ל RAID 0 בכוננים קשיחים).

שיפורים בביצועי המעבד מול הזכרון ב30 בשנים האחרונות. מקור: Computer architecture: a quantitative approach

כיצד מתכנתים ב Data Oriented Programming
אלו שפות הן שפות "Data Oriented"? ובכן, השפה היחידה שאני יכול לחשוב עליה ככזו היא SQL: אנו מודעים לטבלאות וחושבים בפעולות על הנתונים. לטבלה B יש Foreign Key המצביע על טבלה A? אנו יכולים לבצע Select על טבלה B ולמצוא את כל ההצבעות - אין צורך (או משמעות גדולה) בהצבעה כפולה (כמו באובייקטים). ב #C יש את LINQ שהיא אמנם שפה לטיפול בנתונים, אך טבעית מאוד גם לנתונים במודל אובייקטלי - לכן אני לא בטוח שהיא דוגמא טובה.

העקרון של תכנות מונחה נתונים Per-Se הוא להחזיק נתונים (כאשר יש רבים מהם) בזכרון בצמידות. ממש כמו שמירה של טבלאות של בסיס נתונים רלציוני. כך יהיו לנו הרבה Collections גלובאליים של "אובייקטים", כאשר האובייקטים הם רזים (יותר דומים ל struct של נתונים ופחות אובייקטים קטנים ועשירים). מצד שני יהיה ניתן להפעיל כל פעם פונקציה אחרת על אותו struct - מעבר שהוא "זול" מבחינת עלות זכרון (מכיוון שיש יחסית מעט פונקציות נפוצות שיכולות להשמר ב Cache).
בעוד תכנות מונחה-עצמים יוצר מבנה דומה ל LinkedList - אובייקטים הפזורים לכל עבר בזכרון, כאשר קריאות getX.GetY.GeyZ המפורסמות של ג'אווה מדלגות בזכרון לא-רציף, תכנון מונחה-נתונים הוא דומה יותר לוקטור (ArrayList) רציף בזכרון המאפשר להשתמש ב Cache בצורה יעילה ופונציות שונות שפועלות בצורה ממוקדת על הנתונים ללא "קפיצה" תכופה לאובייקטים אחרים.

השימוש בData-Oriented Programming כמתודולוגיה מקובלת חזר בשניים האחרונות בעקבות אפליקציות ה Mobile (כלומר Android, iPad, iPhone) - אפליקציות קטנות הנכתבות עבור מכשירים בעלי כח עיבוד חלש.
מתכנתים מדווחים על ביצועים גבוהים פי 2 עד 4 בהמרה של אפליקציות Object Oriented להיות אפליקציות Data Oriented ובקלות פיתוח גבוהה יותר.

האם DOP מתאים למערכות Enterprise ארגוניות? האם לא נכון לדחות ביצועים ולטפל בהם רק בסוף? ובכן - נכון.
לא הייתי עובר ל DOP רק עבור הביצועים, אך זהו ייתרון שכדאי להכיר. בעוד מפתחי אפליקציות המובייל מאמצים DOP בשביל ביצועים ואולי מעט פשטות, אני חושב על DOP עבור מערכות ארגוניות בעיקר בגלל הפשטות. לעיתים, אני מאמין, עדיך DOP טוב (כי קל ללמוד את המתודולוגיה) על פני OOP בינוני או רע.

כמו שאנשים חששו להשתמש ב"אובייקט פשוט של ג'אווה" (והשתמשו ב EJB) עד שניתן לו השם המכובד POJO, כך גם אין לחשוש בתכנות מונחה נתונים ולהתייסר שאנו לא כותבים OOP, הנה עכשיו יש לו שם מכובד: DOP.
בסופו של דבר כל אלו הם כלים, עם יתרונות וחסרונות, ומקצוען אמיתי ידע לבחור בניהם בחוכמה ולא ייקלע למלכודת של "חייבים לעבוד ב EJB או OOP או <כלי אחר> - כי כולם עובדים כך".
דוגמא קרובה נוספת היא ההצלחה של REST - מודל פשוט וממוקד נתונים / פרוטוקול רשת, שהצליח יותר בשטח ממודלים מונחי אובייקטים או שירותים, ארכיטקטורות נבונות מגובות בהמון תאוריה.

אני חושב שאפשר בהחלט לכתוב מודולים במערכת שהיו מונחי נתונים, ועדיף שזה יהיה מהלך מודע. תכנות מונחה-עצמים הוא בהחלט לא קדוש.
גישה אחת ל DOP היא הגישה הקלאסית[2] (מערכיים של structs) וגישה אחרת היא עבודה עם בסיס נתונים רלציוני בזכרון (כגון H2, HSQLDB או SQLite), עם היכולת לשמור את הנתונים לדיסק בקלות ובכל רגע.

היתרונות של DOP על OOP
אני מניח שהיתרונות של OOP (הכמסה, מידול, ריבוי-צורות ועוד) מוכרים לכולם, בואו נסקור כמה יתרונות של ה DOP:

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

Unit Testing
מי שעובד עם unit tests יודע שהכי קל לכתוב בדיקות לפונקציות המרה פשוטות של נתונים, כמו פעולות parsing, למשל. שימוש ב DOP יהפוך גם את ה unit tests לפשוט וטבעי יותר מכיוון שיהיו הרבה יותר פונקציות ש"רק מעבדות נתונים" ויפחית משמעותית את הצורך ב mocks, stubs וחברים. אימוץ Unit Tests הוא לא דבר קל, ושימוש ב DOP יכול להיות סיוע משמעותי.

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

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

מאגר אדיר של בסיסי נתונים (רלציוניים) התואמים למודל כמו כפפה.
מודל ה OOP לא רק הקשה על החשיבה הלוגית שלנו ועל ארגון התוכנה לאובייקטים, הוא גם הקשה מאוד על שימוש בבסיסי הנתונים הרלציוניים, אשר בטבעם הם מונחי-נתונים.
במשך שנים ניסו לבנות כלי (ORM (Object-Relational Mapping עם הצלחה חלקית בלבד. אפילו Hibernate/NHibernate - ה framework הפופולארי ביותר, הוא נחמד לשמירת קונפיגורציה אך כושל כאשר אנו זקוקים לביצועים טובים על הרבה נתונים. גם אני האמנתי למצגות שמספרות שברוב המקרים Hibernate יבנה סכמה יעילה יותר מהמתכנת ויספק Cache שישפר את הביצועים אפילו יותר. הנסיון שלי הוא שכאשר יש דרישה לביצועים טובים, ישנו מאבק ארוך עם Hibernate שבסופו Hibernate מוצא את עצמו מחוץ למשחק.
אמנם אם היינו יוצרים באופן ידני את אותה הסכמה ש Hibernate מייצר - הוא יכול היה להיות מהיר יותר, אך ההבנה שלנו בנתונים מובילה אותנו לסכמות שונות לחלוטין ממה ש Hibernate ייצר.
אחד המניעים של תנועת ה NoSQL היא השתחררות ממיפוי אובייקטים למודל רלציוני ועבודה ישירות מקוד OO למודל שמירת נתונים OO (כגון בסיסי נתונים KV). על אותו מטבע אם הקוד שלנו הוא מונחה-נתונים, כך גם בסיסי נתונים רלציונים ישרתו אותנו היטב ובקלות - ויש המון כאלה.

העליונות של Object Oriented Design
בעוד יש ספקות על העליונות של תכנות מונחה-עצמים, לי אישית יש מעט מאוד ספקות על העליונות של תכנון מונחה-עצמים (Object-Oriented Design).
תכנון מערכת מונחה-נתונים, סביר לדעתי, שיסתיים באסון (כלומר אי הצלחת הפרוייקט - לא משהו מעבר לזה).

היתרונות של חלוקה של מערכת למודולים עם אחריויות ברורות, הכמסה נוקשה (encapsulation) של כל מודול ותיאור המערכת כשיקוף של העולם האמיתי / הבעיה העסקית (מה שנקרא גם DDD - Domain Driven Design) - הם יתרונות ברורים שעובדים היטב בשטח.

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

לסיכום - תכנון מונחה אובייקטים הוא טכניקה מוצלחת שעובדת בשטח. אינני יכול לחשוב על אלטרנטיביות ראויות.
התכנות בתוך המודול (module) הוא פחות שחור ולבן, ואם התייסרנו בכל פעם שגילינו שלא עבדנו OOP - ייתכן והתייסרנו לשווא. ישנן היום הרבה פרדיגמות מוכחות (בעיקר תכנות מונחה-עצמים, תוכנות פונציונאלי, תכנות מונחה-נתונים) וכדאי להתייחס לבחירה בניהן כמו בחירה בין ספריית קוד: יתרונות מול חסרונות והתאמה למוצר / בעייה / ארגון, תחת ההבנה שזו לא בחירה עם פתרון יחיד.

בהצלחה.


[1] בשקפים 31 עד 101 של מצגת זו - ניתן למצוא הסבר מפורט של התופעה.

[2] יש לזכור שמערך בג'אווה הוא רשימה רציפה של מצביעים. האובייקטים עצמם (אליהם אנו מצביעים מה ArrayList) עדיין מפוזרים באופן שרירותי בחלק הזכרון הנקרא Heap. ב #C המצב נוח יותר - יש structs שיכולים להיות מוגדר באופן רציף. בכל מקרה אני רוצה להדגיש ולחזור שאופטימזציית performance היא לא עצם העניין, עצם העניין הוא מודל שקל יותר לשימוש המפתח - אופטימזציות הביצועים בדיון זה היא משנית.

הקרב בתעשיית התוכנה: Development vs. Marketing

הקרב בין מחלקת השיווק ([1]Marketing) למחלקת הפיתוח מתנהל כבר שנים, במשך דורות, אבות ובנים. אלה רוצים "עוד פיצ'רים ומהר" אלו רוצים "איכות, דיוק ושיטתיות" (ע"פ המפתחים. אנשי שיווק יספרו את הסיפור קצת אחרת). נקודת ההכרעה אינה נראית באופק.

האם זה קרב מחוייב המציאות? האם לא ברור שהפעם "אנחנו" צודקים?

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

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

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

Best Practices: פיתוח כנגד שיווק

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

• DRY - אל תחזור על עצמך
• Bake Quality In - איכות צריכה להיות בכל שלב בתהליך
• Abstraction / Loose Coupling - צמצם תלויות בקוד כך ששינוי באזור אחד לא יזעזע אזורים אחרים.
• Naming / Clean Code - קוד "ספרותי" שמתאר את עצמו.
• וכו'

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

רגל בדלת
בניגוד לקונוטציה האגרסיבית של "לדחוף את הרגל" כדי לחסום דלת נסגרת (שמתאימה לתיאור של איש מכירות אגרסיבי במיוחד), "רגל בדלת" לרוב מתייחס לצורה המנומסת (האמריקאית אולי) של נקודת הכניסה לבית הלקוח. במקום לשאול: "האם אתם רוצים לקנות שואב אבק חדש?" יפתח איש המכירות בשאלה "האם גם לכם האובך האחרון לכלך את הבית?" - שאלה תמימה ולא מחייבת. "כן בוודאי - פשוט נורא" המשכתם, פתחתם את הדלת לרווחה ואפשרתם לאיש המכירות לחצות פיסית את קו הדלת ולהניח שם רגל. הקרבה המעטה הזו (והכניסה בהסכמה למרחב האישי שלנו) היא כבר נקודת פתיחה טובה בהרבה להצעה עסקית.
באופן דומה אנשי שיווק ירצו שתספקו להם פיצ'ר, אולי חלקי ולא עובד, שאיתו יוכלו לגשת ללקוח ולומר "גם לך יש בעיות ABC"? "יש לנו דווקא משהו מעניין לדבר עליו" - יפתחו דיון עם לקוח שזקוק לפ'יצר אך ירגיש הרבה יותר נוח לדבר עם מישהו שיש לו משהו ולא רק רעיון באוויר. עד שיגיע הזמן למסור את הפתרון ללקוח, הפיתוח יוכל כבר לפתח את הפי'צר כמו שצריך [2].

Feature Superiority
הרבה יותר קל למכור מוצר שיש לו רשימה גדולה יותר של פ'יצרים. ללקוח זו מרגישה קנייה בטוחה יותר ומי שמוכר אותה נתפס מנוסה יותר. ב SAP שמעתי את האמרה הבאה (שנכונה גם לחברות אחרות): "The Suite Always Wins". כלומר ל SAP לא חייב להיות מוצר לניהול משאבי אנוש הכי טוב או כלי לניהול פרוייקטים הכי טוב, אך כשהיא מוכרת חבילה שמחליפה 10 מוצרים שונים ויותר - יש לה ייתרון אדיר. עקרון זה נכון כאשר מדובר במוצרים נפרדים תחת אותה קורת גג ("One Stop Shop") ואפילו קצת יותר כאשר מדובר במוצרים שמדברים אחד עם השני ("Suite").

ייתכן והרצון להגיע ל Feature Superiority דוחף לבקש עוד פ'יצרים על חשבון סגירת ושיפור הקיימים. למי שמכיר את תאוריית האוקיינוס הכחול[3] (או בכלל את פורטר) - זו נראית לעיתים קרובה טעות נפוצה של אנשי שיווק ולא Best Practice, אך נראה שאנשי שיווק לא מעטים פספסו את השיעור הזה ב MBA שלהם. אציין שאנשים נבונים שעבדתי איתם עשו, למיטב הבנתי, את הטעות הזו. נראה שתחת לחץ ותחרות (אנשי מכירות שמכפישים את שמכם בחברה כי הפסידו עסקה בגלל המחסור בפ'יצר X) - קל מאוד להגיע לשם. באופן אירוני, מתחרה שלו יש עדיפות במספר הפ'יצרים ואולי הגיע לשם בעקבות לחץ, עלול לגרור את החברה שלכם לריצה אחר רשימת פ'יצרים במקום להתבונן על התמונה השלמה.

Check-box Feature
לעיתים קרובות, תהליך מכירה של תוכנה ארגונית עובד כך: הלקוח שולח RFP - Request For Proposal לכמה ספקי תוכנה שנשמע שיש להם תוכנה שמתאימה לצורכיו. ה-RFP הוא מסמך עם רשימה ארוכה של דרישות "יש"/"אין" שעל הספק למלא. מי שעומד בדרישת הסף עובר לשלב הבא בו משוחחים על הפתרון, עושים פיילוט וממשיכים למכירה. אם חסר לכם ברשימת הדרישות פ'יצר שמוגדר כקריטי - יסננו אתכם עוד בשלב ה RFP, לעיתים ללא הבנה מה אתם במקום לאותה הבעיה, ללא ודאות שזה באמת מה שנחוץ וכו'. על מנת לעבור את התהליך יש לסמן כמה שיותר סימני V.
זה תהליך דומה מאוד לשילחת קורות חיים. מתכנת עם 10 שנות ניסיון ב Web יציין ידע ב JQuery, Comet, Ajax ו Cross-Browser DOM אבל אולי ידלג על HTML ו CSS. הוא עלול לגלות שאשת כח-האדם שעושה Pattern-matching על קורות החיים שלו פשוט מסננת אותו "אין לו מספיק ידע" כי "צריך ידע ב CSS" או CSS3 או XHTML (מול HTML - הבדל סמנטי) וכו'.
מה הפתרון? על מנת לעבור את הסינון הזה אותו מתכנת יכתוב אינסוף מושגים הקשורים לווב, שחלקם אולי לא כ"כ נכונים על מנת להגיע למראיין המקצועי (כלומר - טכנולוגי) הראשון שיוכל להתרשם באמת מכישוריו.

באופן דומה מנהלי מוצר רוצים להציג רשימה ארוכה של יכולות במוצר. לעיתים הם יאתרו פ'יצרים שאותם לקוחות מבקשים אבל אף פעם לא משתמשים בהם. כיצד ייתכן שלקוח דורש פ'יצר שהוא לא מתכוון להשתמש בו?

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

פי'צר כזה מסומן כ Check-box Feature - תחמושת חשובה שאיש השיווק רוצה לספק לאנשי המכירות שלו. הם יוכלו לטעון "בטח - גם לנו יש Mobile Cloud EAI Service Integration 2.0 ואולי יוכלו לעבור איזה Demo של כמה דקות. אבל הפ'יצר עצמו לא באמת צריך לעבוד על מנת למכור או אפילו ליצור לקוח מרוצה - חבל לבזבז עליו זמן פיתוח.
מה עדיף? לחנך את הלקוחות/שוק (והגרורות שלהם) שזה פ'יצר מיותר (קשה מאוד) או לבקש מהמפתחים פ'יצר חלקי ונבוב בהשקעה מינימלית (יחסית קל)? האופצייה השנייה ישימה יותר ועובדת טוב יותר (לצערנו, המפתחים).

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

למכור סיפור
מנהלים בכירים הם לרוב אינם אנשי-פרטים. כבר מזמן הפסיקו לעסוק בפרטי התפעול של החברה - הם אנשי חזון. ואם הם המנהלים בחברת הלקוח - יש סיכוי טוב שהם אלו ש"יחתכו" בעסקאות גדולות. במקום להגיע לליבם עם פ'יצר כזה או אחר - קל יותר להגיע לליבם בעזרת חזון. סיפור. "החברה שלנו תחבר את כל מערכות המחשוב ותיצור תמונה אחידה" הוא סיפור טוב. מנהל טוב מבין את הייתרון ביכולת כזו. לעיתים קרובות מאוד הסיפור איננו התיאור הטוב ביותר של המציאות, אלא הרחבה רעיונית משמעותית של עובדה קיימת (קרי - הגזמה פרועה).
לדוגמא, ייתכן והסיפור הנ"ל מסופר על מערכת שאוספת סטטוסים ב SNMP ממגוון מערכות, כ"א בשפה שלה, הנתונים לעיתים לא מסופקים ע"י המערכות, וכדי להגיע לתובנה איש ה IT צריך לחפור לא מעט בנתונים שנאספו. בכל זאת, אם המתחרים מוכרים סיפור - לא תרצו לשלוח את אנשי המכירות שלכם עם "פ'יצר": "לא באים עם סכין לקרב אקדחים", אומרים באמריקאית.

אנחנו בפיתוח מעדיפים לדייק בפרטים ולא "לנפח". אנו נעדיף לקרוא לאובייקט "SnmpMessage" ולא "SystemWellBeingReport" (קצת מוגזם - לא?). אנו נעדיף "XmlParser" ולא "Cross-SystemTranslator". לכן כשאנחנו רואים את החומר השיווק של המוצר שפיתחנו, בעוד אנו יודעים מה הוא באמת עושה, אנו עלולים להיות מופתעים. "הם חיים בעננים" אנו מספרים על אנשי השיווק, "רואים סרטים בעננים", מוסיפים. קרוב לודאי שהסבר כמו "הלקוחות שמחים לקנות את הסיפור, זה נותן להם אמון שאנחנו מבינים אותם ויודעים על מה אנחנו מדברים" רק מעצים את תחושת הניכור.


סיכום
טעות נפוצה היא לחשוב ש"המוצר מוכר את עצמו" או ש"מספיק מוצר טוב". אמנם יש מעט מוצרים שנמכרים ללא שיווק (למשל מנוע החיפוש של גוגל) ולמשתמש ישירות, אך את רוב המוצרים עדיין מוכרים בעזרת אנשי מכירות, שיווק וחומר פרסומי ועל המוצר למלא חלק במערכה. הלקוחות שלנו אינם תמיד מבקשים את מה שהם צריכים [4], השוק לעיתים קרובות "טיפש" (או "לא רציונלי") וזו הטייה שחשוב להבין להתמודד איתה על מנת להצליח בעסקים. לא מעט סטראט-אפים נופלים על הטעות הזו. אם לא שמתם לב - ברוב חברות ההייטק, לפיתוח מוקצים כ 10-15% מהתקציב ולשיווק - כ 40-60% מהתקציב. לא סתם.

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

בתחומים שבהם איכות היא חיונית להצלחה עסקית (למשל מכשור רפואי, ניהול כספים) - תהיה איכות גבוהה ובתחומים בהם הדרישה פחות מחמירה (למשל תוכנה שהמצאותה נדרשת על מנת לעמוד בתקן [5], מה שנקרא Compliance)  - תהיה איכות נמוכה יותר [6].
הלקוחות יאמרו לנו מה רמת האיכות הנכונה בעבורם, והם יאמרו זו בצורה עקיפה. לרוב אלו יהיו מעשים (אי קנייה / קנייה ממתחרה) ולא דיבורים (הרי, מי לא רוצה איכות?).

אפרופו, המנהלים בארגון שלכם כמעט ותמיד יכריזו שהם רוצים איכות - אך המעשים בשטח הם אלו שקובעים. על מה מקדמים אנשים? על יותר פ'יצרים או על יותר איכות? לא מזמן שוחחתי עם VP R&D של חברה קטנה שהפסידו עסקת ענק (עבורם) בגלל באגים שצצו בתהליך בחינת המוצר ע"י הלקוח. "המוצר שלכם נחמד, אבל יש בו יותר מדי תקלות" הסביר הלקוח מדוע הוא דוחה את העסקה. לא נראה שיש מוטיבציה טובה מזו להשקיע באיכות. האם הלקוחות שלכם דוחים מוצר על איכות או רק על מחסור פ'יצרים?

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

תודה לניר דרמר על ההערות המועילות על הפוסט.


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

[2] או שלא. יש פה סיכון מסוים. אנחנו בפיתוח נוטים לזכור היטב את המקרים שבהם זה לא עבד - אבל הרבה פעמים זה עובד יפה. בכל זאת זהו Best Practice ולא Flawless practice.

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

[4] ב XP נוהגים לומר: תן ללקוח מה שהוא צריך, לא מה שהוא מבקש.

[5] לדוגמא, כשאתם עושים ביטוח לרכב ומבקשים מכם לבדוק את האזעקה, אתם רק רוצים לקבל את האישור. האזעקה רק עצבנה והטרידה וכבר שמעתם סיפורים שהיא לא כ"כ יעילה. מבחינת רבים מאיתנו עדיף שיתנו לנו אישור ושהאזעקה לא תפעל יותר לעולם. כמה הקפדה אתם צופים מיצרן האזעקות שנזרק מלקוחות כי המוצר שלו פעל מספר רב מדי של פעמים? בעיקר הקפדה שהאזעקה לא תפעל לשווא - אני מאמין.

[6] מדידה של איכות תוכנה הוא דבר מורכב ובעייתי, במיוחד מכיוון שאין מדדים מוסכמים ל"מהי איכות". לכן לכל מחקר או נתון על איכות תוכנה יש להתייחס בזהירות.

10 התכונות של שירותי ענן (Cloud Computing)

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

זהו פוסט המשך לפוסט המבוא בו תיארתי את ההבדל בין PaaS, SaaS ו IaaS.

אפליקציות ענן הן שונות ומשונות. לעתים אלו אפליקציות עסקיות שלמות (כמו NetSuite) ו Salesforce, לעתים זהו שירות ממוקד (כגון Geo Location). ישנם עננים ציבוריים (Amazon), שיתופיים (למשל - ממשל) ועננים פרטיים (פנים-ארגוניים), ישנם ספקי תשתית (Amazon) וספקי Hosting שאינם בהכרח ספקי-ענן. מה הופך אפליקציה להיות אפליקצית ענן או שירות להיות שירות ענן?
התשובה כמובן היא לא מוחלטת ויש וריאציות שונות ומשונות של ספקים ושירותים. בכל זאת אספתי את עשרת המאפיינים העקריים של אפליקציות ושירותים בענן.

קודם כל כמה הגדרות שאשתמש בהן בפוסט זה:

• ספק שירותי הענן - Amazon, Salesforce, Microsoft או Google. החברה אשר מבצעת Hosting ומספקת לי תשתיות ושירותים עליהם אבנה את אפליקציית הענן שלי.
• שירות ענן - תשתיות כגון EC2 של Amazon או Azure של מייקרוסופט בעזרתם אני אבנה את האפליקציה שלי.
• אפליקציית ענן - האפליקציה הסופית למשתמש הקצה אותה אני מפתח, תוך כדי שימוש בשירותי ענן המסופקים על ידי ספקי שירותי ענן.

1.Hosting או Off-Premises - בניגוד לשירותים On-Premises שמנוהלות בחוות השרתים של הארגון, אפליקציות ענן לרוב יותקנו על מחשבים של ספק שירות הענן ומחוץ לגבולות הארגון. לעובדה זו יש שתי השלכות חשובות: אחת - המידע בין משתמש הקצה לשירות מועבר על גבי האינטרנט (ולא ברשת הפנימית של הארגון או VPN). שנייה - המידע נשמר ומעובד מחוץ ל Firewall של הארגון. התקשורת בין המשתמש לשירות חוצה גם את הגבולות הפיסיים וגם גבולות האבטחה של הארגון.

2. אלסטיות לגדול ולהצטמצם ע"פ הצורך. עקרון שהולך יד-ביד עם שירותי הענן הוא עיקרון של On-Demand: שימוש על פי הצורך. לדוגמה: אנו אתר מכירות ויש לנו Sale מטורף? אנו צופים תעבורה כפולה מהרגיל בשבוע הקרוב? ספקי Hosting יאפשרו לנו להכפיל את מספר השרתים בשימוש תוך דקות ולהפסיק להשתמש אחרי שבוע. באתרי מכירות מקוונים לקהל האמריקאי, שבהן חלק נכבד מהמכירות השנתיות מתבצע בתקופת חג-המולד, זהו ההבדל בין החזקת חומרה כפולה ומשולשת כל השנה (מי יודע כמה תעבורה תהיה בסוף השנה? - פספוס מכירות הוא דבר בלתי נסבל) על מנת להשתמש בה למשך חודש בודד בשנה [1].

3. Virtualization - אפליקציות ענן לרוב אינן מותקנות ישירות על מערכת ההפעלה. על מנת לספק אלסטיות גבוהה, קרי - להגדיל ולהקטין את נפח השירות בצורה מהירה, ספק השירות חייב להיות מסוגל להקצות עוד מכונות (חומרה) ללקוח בזמן קצר ביותר. אם על כל ביקוש לעוד כח חישוב / אחסון לשירות מסוים היה צורך באיש Operations שמבצע התקנה פיסית של שרת - התגובה תהיה איטית למדי.

הפתרון בעולם ה IaaS הוא להתקין מערכת הפעלה (Host OS) עליה תוכנת וירטואליזציה (Hypervisor). ה Hypervisor יריץ (ע"פ דרישה) מערכת הפעלה (אחת או יותר), הנקראות Guest OS, שעליה יותקן ה Image של הלקוח. ה Image הוא העתק של מערכת הפעלה המותקנת עם התוכנה שלכם ומקונפגת בהתאם - מוכנה לפעולה. בסביבות שונות (לדוגמה, Amazon) ספק השירות מציע מבחר של Images מוכנים של מערכות הפעלה והסדרי רישיונות עם היצרן (מייקרוסופט) על מנת להקל את התהליך למשתמש. פשוט בקשו "מכונה גדולה עם Windows Server 2008 64bit" ותוך חצי דקה יש לכם שרת online מוכן לפעולה.

מצד הספק, על מנת לספק את השירות הנ"ל, הוא פשוט בוחר שרת פיסי שאינו בשימוש (או שבדיוק הוחזר ל pool ע"י לקוח אחר), סוגר את התהליך של Guest OS אחד ומפעיל Guest OS אחר על סמך ה Image שסיפקתם לו (שלרוב שמור ברשת, אמאזון משתמשת ב S3 - שירות האחסון המבוזר שלה לשמור גם את ה Images). לא צריך לגשת פיסית למחשב, לא צריך מעורבות של איש Operations ואפילו לא צריך Restart. נהדר!

בתחום הוירטואליזציה יש 4 שחקניות מרכזיות:

• VMWare (שנרכשה ע"י EMC) - מסחרית, ותיקה ובעלת סט עשיר של יכולות. [עדכון 2014: למרבה ההפתעה, היא עדיין פתרון הוירטואליזציה הנפוץ ביותר].
• KVM (קיצור של Kernel-Based-Virtual Machine) - פתרון חינמי, ופופולארי, ללינוקס.
• XEN - במקור חינמית, אך נפוצים שימושים בגרסאות מסחריות, כמו XenServer של Citrix.
• VirtualBox של אורקל (במקור: של Sun), דומה בהיבטים רבים ל VMWare.

ישנה גישה לוירטואליזציה הנקראת Full Virtualization (למשל VMWare) - שזו הגישה הנפוצה ובעלת תאימות טובה למערכות ישנות, וגישה אחרת בשם Paravirtualization (המספקת שכבה דומה יותר לחומרה המקורית וכך חוסכת עבודה מה Guest OS) - אשר בכדי להשתמש בה יש צורך בתמיכה ספציפית ממערכת ההפעלה. דוגמה נפוצה ל Paravirtualization בימנו היא XEN. עוד גישה נפוצה מאוד לאחרונה, אותה מאמצים ענקי המחשוב (כמו גוגל, או נטפליקס) היא גישת ה Containers. כתבתי פוסט העוסק בוירטואליזציה.


4. חיוב ע"פ שימוש בפועל - כפי שהוזכר בנקודה מס' 2, השאיפה היא לחייב ע"פ שימוש בפועל. מכיוון ויתכן שעל אותו המחשב רצים כמה שירותים של לקוחות שונים (בעקבות וירטואליזציה בעיקר), לכל ספק שירותי ענן שיטה משלו לחייב ע"פ כמות שימוש: כמות שימוש ב CPU, דיסק, רשת וכו' [2]. לעיתים הספק מעודד שימוש בשעות המתות ע"י מתן תעריפים נמוכים יותר, כך שהוא יכול לנצל את החומרה שברשותו בצורה עדיפה. התשלום לספק הענן לרוב אפשרי בעזרת כרטיס אשראי, עובדה שהופכת את ההצטרפות לפשוטה.

5. חומרה זולה (Commodity hardware) אחת הסיבות העקריות לשימוש במחשוב ענן הוא הפחתת עלויות. ברוב סביבות הענן איננו יכולים לדעת על אילו חומרה בדיוק תרוץ האפליקציה שלנו בפועל, ולרוב האפליקציה שלנו תכתב מראש בצורה Scalabale כך שהיא יכולה לגדול אם מוסיפים לה עוד שרתים (חומרה). ניתן לנצל עובדה זו ולהשתמש בחומרה זולה למדי - בעלת מקסימום CPU Cycles ליחידת תצרוכת חשמל. תצרוכת החשמל מכתיבה לא רק את מחיר החשמל (מחיר ישיר), אלא גם את מחיר הקירור / מיזוג (מחיר עקיף) וכיוון שיש מגבלה של יכולת קרור לנפח נתון - את עלות הנדל"ן בו יושב ב Data Center. הכל בכדי להפחית בעלויות.

6. (SLA (Service Level Agreement - ספקי שירות ענן מוכרים לא רק את הזכות להשתמש בחומרה ושירותים, אלא גם מחויבות לזמינות החומרה והשירותים שאותם הם מספקים, זמני תגובה ועוד. סט התחייבויות אלו נקרא (SLA (Service Level Agreement והוא חלק מכל שירות. יש ספקי ענן שמתחייבים רק לזמינות נמוכה, ויש כאלו שמתחייבים לזמינות גבוהה יותר. זמינות מקובלת היא 99.95% up-time (מה שנקרא three and a half nines). זמינות של five nines (כלומר 99.999%) - היא נדירה וגבוהה במיוחד. המבקרים יאמרו שלא משנות ההבטחות - ספקי הענן עד היום לא עמדו בהן ולא פיצו את הלקוחות. מצד שני נראה שהספקים משקיעים מאמצים אמיתיים לעמוד ב SLAs.
בכל מקרה, פיתוח נכון של אפליקציות לענן מניח שיהיו תקלות וכולל את המנגנונים להתמודד איתן.

7. High Availability - רוב שירותי הענן מסופקים במספר אתרים בעולם המפוזרים גיאוגרפית. לעיתים אתר מחולק לכמה יחידות (מה שנקרא באמאזון Availability Zones) שאמורות להיות בלתי תלויות - גנרטורים אחרים, רשת נפרדת וכו' על מנת לאפשר המשך פעילות כאשר יחידה מסויימת נפגעת (שריפה, ניתוק ברשת האינטרנט וכו'). אם האיזור בו שרתים שהוקצו לכם נפגעו - תוכלו להתאושש ללא פגיעה חמורה בזמינות - בהנחה שחילקתם את השרתים שלכם לכמה יחידות זמינות. אני אומר לא-חמורה מכיוון שבכל זאת, ייקח קצת זמן להבין שהייתה תקלה, להקצות שרתים חדשים לפצות על היחידה שנפגעה, לטעון עליהם את ה images - וכנראה שאם הייתה שריפה ביחידת זמינות - אתם לא היחידים שמבצעים פעולות התאוששות באותו הרגע [3].
ספקי Infrastructure מניחים שעל מפתח האפליקציה לנהל את הנוכחות שלו באיזורים שונים בעצמו, בעוד ספקי Platform נוטים יותר לבצע את הפיזור עבור הלקוח. עוד שירות נפוץ הוא [4]CDN המאפשר למשתמש-קצה של האפליקציה אשר הוא מרוחק גיאוגרפית מספק הענן לקבל שירות דומה ללקוח שקרוב גיאוגרפית אליו.

8. Mutli-tenancy - זוהי נקודה שמטעה לא מעט כותבי אפליקציות ענן. Multi-tenancy היא היכולת של שירות לספק לקוחות שונים באופן בלתי תלוי. Multi-Tenancy מתייחס לאחד או יותר מהבאים:

1. חציצה בנתונים ובקונפיגורציה (לקוח אחר לא יכול בשום אופן לגשת לנתונים שלי)
2. אי-תלות גירסה (אני יכול לבחור בגרסת התוכנה, ללא תלות בלקוח אחר שרץ איתי על אותו השרת).
3. אי-תלות של תוספים Plug-ins (אני יכול להריץ תוספים שלי או של ספק אחר, ללא תלות בלקוח אחר שרץ איתי על אותו השרת).

כמה שניות לחשוב... מה המשמעות... 

כן. Multi-tenancy הוא לא דבר פשוט. הוא מהדברים שאם לא תכננתם מראש - יהיה מאוד קשה להוסיף בהמשך.

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

בפועל יותר סביר שיהיו לכם המון לקוחות קטנים שלא יצליחו לנצל אפילו שרת אחד פשוט. כל לקוח גם יצפה שהנתונים, הקונפיגורציה והתוספים (Plug-ins) בהם הוא משתמש יהיו פרטיים לחלוטין. אם תקצו לכל לקוח קטן שרת פיסי משלו (על מנת לספק את ההפרדה) - קרוב לוודאי שהתפעול יהיה יקר ואולי אפילו תפסידו על חלק גדול מהלקוחות כסף. אפילו אם הלקוחות שלכן הן חברות ענק, נוסח חברות Fortune 500, תגלו שלהם יש משרדים, מחלקות, שותפים וסניפים שונים שעלולים לדרוש אוטונומיה. אם לא תתכננו את המערכת שלכם בהתאם ומהתחלה, התפעול שלכם יהיה יקר במיוחד ותאלצו לעבוד שנים על מנת להוסיף יכולת Multi-tenancy למערכת קיימת [5].

9. הפעלה ב API - למרות שיש לרוב גם UI חלקי להפעלת שירותי הענן, רוב התקשורת והעבודה מול ספק שירות הענן יתבצע ב API. זאת על מנת שנוכל לתפעל את כל הפעולות מול ספק הענן (שינוי הקצאת החומרה לשירות שלנו, עדכון תוכנה וכו') בצורה אוטמטית ועם מינימום התערבות ידנית.

10. ארכיטקטורה מבוססת שירותים (SOA)
זוהי נקודה פחות מפורשת ומדוברת מהנקודות האחרות, אך ארכיטקטורה מבוססת שירותים (Service Oriented Architecture), או לאחרונה Micro-Services Architecture (בקיצור: MSA) - נפוצות מאוד בענן. אני מתכוון לחלוקת המערכת לשירותים בלתי-תלויים ועצמאיים, לא לשימוש ב Web Services או ESB - Enterprise Service Bus (השם ירחם). אם נבחן את SOA - נראה שהיא מתאימה לענן: היא מאפשרת ביזור, חוסר תלות, Scalability ואולי הכי חשוב: בנייה של מערכת מודולרית משירותים (services) שונים. מצב נפוץ הוא שמערכת בענן מתבססת ומשתמשת בשירותי ענן אחרים, יש לכך 2 סיבות משמעותיות:

1. חסם נמוך יותר לשימוש בשירותים אחרים: אם רציתם להשתמש בשירות חיצוני במערכת On-Premises הייתם צריכים לדרוש גישה לאינטרנט, לנהל מעקב אחר השימוש של הלקוחות על מנת לחייב אותם - או לדרוש מהם לרכוש את השירות בעצמם, להתלות במערכת אחרת שפחות יציבה משלכם (בשל המרחק הגדול ברשת ו (Commodity Hardware) ועוד. כאשר אתם מפתחים אפליקציית ענן - קרוב לוודאי שהתמודדתם כבר עם רוב הקשיים האלו, ולכן אימוץ של שירות ענן אחר הופך לטבעי וקל הרבה יותר.
2. כיום, ישנה תחרות גדולה מי יציע בתחום שירותי ענן מוקדם יותר, ושימוש חוזר בשירותים היא דרך טובה להאיץ את הפיתוח ולצאת מוקדם יותר עם פתרון מתפקד.

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


---

[1] נשאלת השאלה מדוע אמזון (ספקית IaaS מובילה) אינה נתקלת באותה בעיה: דרישה אדירה לשרתים בחג-המולד ו"תקופה מתה" בשאר השנה (או לסרוגין צריכה אדירה בשעות היום בארה"ב מול שעות מתות בשעות הלילה)? אמזון מסבירה שהיא מאזנת את מגמת השימוש הנוצרית / אמריקאית עם שאר העולם (בעיקר המזרח הרחוק) וגופי מחקר - שישמחו לשכור כח מחשוב במחיר מוזל בשעות המתות. בכל זאת, כנראה שזו בעיה קיימת שאמזון ממעיטה בערכה בפומבי. עובדה שהיא מציעה השכרה של שרתים "בתנאי חוסר-שימוש" - שרתים במחיר זול במיוחד, שברגע שלקוח שמשלם מחיר מלא מבקש אותם - אתם נזרקים מהם ללא התראה (והחיוב בהתאם, כמובן). מעניין עד כמה הענות יש לסידור הזה.

[2] Google Apps לדוגמא חייבה בצורה בה היה משתלם יותר להתפרש על מכונות פיסיות רבות, וברגע ששינתה את שיטת החיוב יצרה מהומה לא קטנה. לינק נוסף.

[3] למרות שבכמה מקרים נפל Availability Zone יחיד של אמזון, השמועות שרצו הם שכולם נפלו. מייד אחרי הנפילה נוצר עומס גדול כ"כ על היחידות השכנות כך שזה נראה כמו חוסר זמינות שלהן.
לזכותם של אמאזון יאמר שהם מפרסמים תחקירי אירוע כנים ויסודיים - כזה שאינו ברור מאליו שכל ארגון היה מפיק לעצמו. אין מה לעשות: אמון הצרכנים בענן הוא נכס (או נטל) בעל משמעות אדירה לעסקים - ולא נראה שלאמזון יש ברירה אחרת.

[4] Content Delivery Network.

[5] חברת SAP השקיעה מיליארד דולר בפיתוח אפליקציה עסקית בענן ללא יכולת multi-tenancy, רק כדי לגלות שלקוחות הענק שלה רוצים הרבה חבילות קטנות של רישיונות (לכל משרד, מחלקה, שותף וכו') ולא חבילה אחת גדולה. SAP עיכבה את שחרור המוצר ונדרשו 3 שנים עד ש SAP הצליחה לספק פתרון Multi-tenant.

מבוא ראשוני ובסיסי בהחלט ל Cloud Computing

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

כשעבדתי בחברת SAP הציגו לנו פעם את הטבלאות הבאות: צמיחה של ספקים לתוכנות עסקיות (המגזר בו משחקת SAP), הספקים המסורתיים המובילים (נקרא כאן On-Premise) מול הספקים המובילים בענן (נקרא כאן SaaS):

מקור SoftwareInsiderPOV blog

כפי שניתן לראות, בערך כל הספקים המסורתיים מצטמקים - וכל ספקי הענן צומחים. בעוד SAP בעלת נתח השוק הגדול בתחום (בצורה בולטת), אבל היא איננה בין 20 ספקי התוכנות העסקיות הצומחות - כמעט כל אלו היו ספקי ענן [1].

ובכן, המסקנה ברורה: שים גז על מוצרי הענן, ג'וני!

אז למה לי מחשוב-ענן עכשיו?
מטפורה אהובה בתחום מחשוב הענן הוא של "רשת החשמל". לפני שנים רבות, מסתבר, כל משק בית (בעל תקציב מספיק) היה מייצר ומנהל את החשמל בעצמו: הוא היה קונה גנרטור, דלק, חלפים ומייצר חשמל. ייצור החשמל לא היה כ"כ יעיל ואיכותי - אך לא הייתה רשת חשמל ארצית. הדרישה הייתה לגנרטור פשוט, זול וקל לתפעול. בנוסף, ההשקעה בחומרה (גנרטור) הייתה ע"פ צריכת המקסימום: ליידי שושנה מבשלת צ'ונט וזקוקה לחשמל רב ביום שישי בצהריים? - עבור אותם שעתיים בשבוע יש להחזיק גנרטור נוסף. מסייה שמעון מדליק דוד-חימום בחודשי החורפים הקרים - כל יום ב 9 בערב? - שיקנה גנרטור נוסף משלו על מנת לעמוד בהספק. האופציה לבצע Sharing של גנרטורים בין משקי בית הייתה תאורטית ולא מעשית.

לספק של רשת חשמל מרכזית (חברת חשמל) יש כמה יתרונות ברורים:

1. חברי משק הבית לא צריכים לדעת לתפעל, ולא צריכים השקיע זמן בהפקת חשמל - יש להם זמן לטפל בדברים אחרים [2]
2. איכות השירות (למשל זמינות) תהיה כנראה טובה יותר עבור הרוב הגדול של הצרכנים, כי עובדי רשת החשמל יכולים להתמקצע טוב יותר. 
3. מחיר - ייתרון לגודל.
4. אין צורך לבצע השקעה גדולה מראש (רכישת גנרטור), אלא משלמים באופן שוטף (עניין של תזרים מזומנים).
5. "צרוך ע"פ השימוש", מה שידוע כ On-Demand (מושג שנקשר רבות למערכות ענן אך מבטא היבט עצמו שמיושם גם מחוץ לענן[3]). המשפחה נסעה לבקר חברים בקנזס (סיבוב של חודש) ולא השתמשו בחשמל בכלל? - אין צורך לשלם. אתם זקוקים לתצרוכת חשמל גדולה בהרבה למשך שבוע בודד בשנה - רשת החשמל יכולה לעמוד בכל צריכה של לקוח בסדר גודל סביר [4].

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

בכל זאת - זוהי מטאפורה מועילה לתיאור כמה עקרונות חשובים.

באופן דומה ניתן לקנות כח מחשוב מספק מרכזי: לא להתעסק בתחזוקה, לצרוך בכל רגע רק כמה שצריך ולשלם בד"כ פחות. הארגון החליט להעביר את הטיפול ב Exchange Server לענן? התוצאה היא פחות התעסקות למחלקת ה IT (שלא צריכים ללמוד על נבכי ה Exchange Server בכדי לתחזק שרת בודד - המומחים של מייקרוסופט יעשו זאת) ולרוב במחיר נמוך יותר. עוד ועוד ארגונים רוצים כיום להעביר שירותים שפחות קריטיים לארגון - לניהול מרכזי. כך מחלקת ה IT תתמחה באותן מערכות שהתעמקות בהן קריטיות לארגון או בתמיכה פיסית במשתמשי קצה ("לא הדלקת את המסך, אדוני").
עוד תסריט אטרקטיבי הוא אימוץ אפליקציה חדשה: אם מחלקה קטנה בארגון רוצה להשתמש בתוכנה ייעודית, במערכת המסורתית היא צריכה לתאם עם גוף ה IT - לרכוש חומרה, על ה IT ללמוד את תפעול השרת. בקיצור - סיפור שלם שעלול לקחת חודשים. אם מדובר באפליקציית ענן, ראש המחלקה יכול להשתמש בתקציב הפנימי שלו לרכוש כמה רישיונות בכרטיס האשראי וברגע זה - לא צריך לדבר עם ה IT. אם המערכת לא מוצלחת - חודשיים אח"כ מסיימים ומנסים מערכת חדשה.

מי-נגד-מי בענן

בתור התחלה אציג חלוקה קלאסית ל 3 סוגי ספקים של יכולות ענן:

מקור silverlighthack.com

אפליקציות מסורתיות נקראות בהיבט הענן לרוב אפליקציות On-Premise (לעתים כותבים On-Prem), שם שמשמעותו On-Location - מותקנות אצל הלקוח.
אפליקציות ענן, שהן לרוב גם אפליקציות On-Demand נקראות לעתים גם SaaS או Off-Premise = רחוקות.

SaaS - ספקי אפליקציות.
דוגמה טובה לאפליקציות הן GMail או Google Docs:

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

אפליקציות SaaS קיימות כבר יותר מעשרו (למשל Hotmail), אולם בשנים האחרונות הן נהיות נפוצות יותר ויותר. מדוע? האם אלו הדפדפנים שנעשו מהירים יותר? בשלות של טכנולוגיות אינטרנט? אולי קצב התעבורה ברשת שגדל לבלי-היכר? (מי חלם על קצב של 1Mbps ויותר מטלפון נייד לפני עשור?!) או אולי אלו החלוצות כמו Salesforce, ספקית אפליקציית ענן לניהול לקוחות (CRM - Customer Relationship Management), ששכנעה את לקוחותיה להעביר אליה, ולנהל באמצעותה, את המידע אחד הרגישים ביותר בארגון: מאגר פרטי הלקוחות?
אני לא יכול לומר, אך נראה שלכל אחד מהגורמים למעלה קשר מסוים למגמה.


PaaS - ספקי פלטפורמה.
ברוב המקרים, פיתוח של אפליקציות בענן איננו נעשה מאפס (Scratch). כמו שישנן מערכת הפעלה ובסיס נתונים שאנו יכולים לרכוש רישיונות ולחסוך הרבה מאוד עבודה בפיתוח מערכות מסורתיות - כך ישנן גם תשתיות לענן.
Google Apps היא ספקית PaaS קלאסית: הכנס לאתר ורכוש רישיון שימוש. לאחר מכן הורד את ה SDK ותתחיל לפתח. לכל תוצר רלוונטי אתה יכול לעשות Upload. אתה יכול לחשוף את האפליקציה באינטרנט ולדרוש הרשמה / הרשאות. בסוף כל חודש תקבל מגוגל חשבון ע"פ מספר פרמטרים כגון זמן המעבד (CPU Type), תעבורת הרשת והשימוש בדיסק של האפליקציה שלך.
היכן היא רצה? על כמה שרתים? מתי ואיך מתחזקים את השרתים? תיקוני באגים בתשתית ה PaaS? שריפה ב Data Center? המהרת תוכן (CDN) עבור משתמשים מאוסטרליה? - אין לך מושג!

עשית Deploy לאפליקציה בענן ושם היא רצה. בנוסף אתה מקבל גישה לתשתיות ייחודיות (דרך ה SDK) החשובות לפיתוח בענן: [5]Multi-tenancy, תקשורת וסנכרון בין השרתים השונים, Middleware וחיבוריות ועוד.

עוד ספקים חשובים של PaaS הם force.com - התשתית של חברת Salesforce שמוצעת כפלטפורמה בפני עצמה ו Azure של מייקרוסופט.


IaaS - ספקי תשתית
עוד קטגוריה חשובה היא ספקי התשתית. ספקי PaaS מספקים קלות שימוש אך גם מציבים מגבלות. פחות שליטה על הביצועים, חיבוריות, יכולת לבצע debug ב production ועוד. מכיוון שעל אותו שרת פיסי יכולות לרוץ גם אפליקציות של משתמש אחר - מגבלות האבטחה עלולות להיות משמעותיות. ספק IaaS יספק לכם את השירות הבסיסי ביותר: חומרה. היחידה הקטנה ביותר - היא לרוב שרת בודד.
הוא יקצה לכם שרתים ע"פ דרישה, יתחזק את החומרה, יספק תקשורת ופתרונות Storage (כגון NAS) אבל את המערכת תצטרכו לתפעל לבד: גיבויים, עדכוני תוכנה, ניטור השרתים (עומס, תקלות) ושינויים בהקצאת השרתים הנובעים מכך (הכל בעזרת API כמובן).

אם בעבודה עם ספק PaaS אתם מתמקדים בתוכנה בלבד, בעבודה עם ספק IaaS תזדקקו לאיש/צוות/מחלקת Operations משלכם. הם לא יתעסקו עם תקשורת וחומרה - אך יתעסקו בכל היבטי התוכנה של המערכת.

הבחירה בין PaaS ו IaaS היא trade off בין גמישות לנוחות. יותר גמישות = עבודה קשה יותר.
הספק הקלאסי של IaaS הוא Rackspace, שיתיר לכם לבחור את החומרה שאתם זקוקים לה ויאפשר לכם להתקין חומרה ייחודית על השרתים, אולם השחקן הגדול היא חברת Amazon - חברה המתפרנסת ממכירת ספרים ותשתיות ענן [6]. השימוש ב Amazon הוא הרבה יותר סטנדרטי והבחירה שלכם לרוב תסתכם בשרת "גדול", "קטן" או "בינוני".
שחקנים בולטים אחרים הם GoGrid, IBM SmartCloud ו Citrix עם Could.com.

כוכב עולה בתחום ה IaaS הוא פרויקט OpenStack - פרויקט Open Source שיזמו חברת Rackspace ו NASA אך כיום מלווה על ידי עשרות חברות חשובות בשוק (HP, Cisco, Intel, SUSE Linux ועוד רבות אחרות) שמטרתו לייצר API אחיד לפלטפורמות IaaS (אותו API לבקש עוד שרת, פרטים על מצב השרתים, שירותי Storage ועוד) כך שלא יהיה יותר Lock-in לספק ספציפי (בגלל ה API) והתחרות בין הספקים תהיה על בסיס איכות התשתית שהם מספקים - כלומר תהיה יכולת קלה לעבור בין ספק לספק.

כמובן ש Lock-In ניתן ליצור גם למרות API אחיד בבסיס (ראה ערך ANSI-SQL) - אך זוהי בהחלט יזמה מבורכת. נחיה ונראה כיצד היא תצליח במשימה הקשה [7].

מקור silverlighthack.com

אל העולם האמיתי

טוב, עכשיו אחרי שהבנתם את ההבדלים בין SaaS, PaaS ו IaaS, תשכחו את כל מה שלמדתם - זה לא עובד ככה.
וברצינות: החלוקה לשלושת הקטגוריה הייתה יותר נכונה בעבר, אבל הגבולות הולכים ומטשטשים. לדוגמא Amazon מספקת הרבה מאוד שירותים שהופכים אותה לסוג של PaaS בסיסי. ספקי PaaS מתירים לשכור גם שירות יותר בסיסי. ההבחנה שלמדתם כאן היא חשובה בעיקר כשפה וסדר בראש - אל תצפו שהמציאות בשטח תתאים בדיוק, By the book, לתיאוריה.

מקור: Yankee Group

כמו שניתן לראות בתרשים זה או בדוחות של [Deloitte[8, כיום הכסף הגדול הוא צרכני (SaaS) - כצפוי. באופן קצת מפתיע יש יותר שימוש ב IaaS מאשר ב PaaS. הסיבה לדעתי היא שהפלטפורמות השונות (PaaS) עדיין לא טובות מספיק ועדיין לא החל תהליך של Commoditization. הבחירה של חברות SaaS רבות הוא לשכור תשתית (IaaS) ולפתח פלטפורמה בעצמן. נשמע שזה ישתנה בעתיד ו IaaS יהפוך ליותר נישתי - עבור אפליקציות בעלות דרישות מיוחדות.

[עדכון יוני 2014]: מה היה קודם?

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

שלום ליאור. אני תמיד נהנה לקרוא בבלוג שלך. היום כשבונים אפלקיציה מאחסנים אותה בענן - מסיבות של עלויות וסקאלביליות. אני מדבר בעיקר על אתרים על בסיס ג'אווה ונוד. 
יש לי בעיה למפות את כל האפשרויות - כלומר אם אני לא קונה ענן שיש לי package של ג'אווה לדוגמא אז זה אומר שהואפציה הישנה היא אתר shared שבו אני מתקין (לא נשמע הגיוני שיתנו לי להתקין משהו על משותף) ג'אווה. 
אני אשמח אם תפקח לי את העיניים - של מה היו הפתרונות של פעם לעומת הפתרונות של היום. ואיך זה מסתדר עם העלויות. 
אז אם אתה יכול לעשות סדר בבלגן... 


והנה התשובה שלי:

היי xxx,

ה"אופציה הישנה" היא בד"כ אחת מ2:

• לנהל את השרתים אצלך בחברה
• לשכור שירות hosting

שירותי hosting ברמת "האפליקציה" ניתנו בעיקר לאתרים סטאטיים / PHP או ל frameworks מוכרים כגון wordpress, jumla וכו'.

אם הייתה לך אפליקציה ייחודית (ג'אווה למשל) היית שוכר בד"כ מקום. שירות שכזה מאפשר לך לשים מחשב שלך ב Data Center של מישהו ולקבל שירות בסיסי לטיפול בחומרה (force restart למחשב, החלפת דיסק קשיח / ספק כח וכו', טלפון בלילה אם המחשב השתגע ע"פ monitoring מאוד בסיסי).

שירותים יותר מפנקים גם סיפקו לך את החומרה - למשל כמו Rackspace ואולי נתנו שירתים בסיסיים של רשת (Firewall, אולי Load Balancer וכו') או גיבוי. יש כנראה אלפי או עשרות-אלפי נותני שירותים כאלו בעולם, ועם מהפכת הענן הם נותנים יותר ויותר שירותים ו/או פושטים רגל.

עדיין יש לא מעט שרתים מנוהלים באחת מ2 הדרכים הללו - אך זה הופך פחות ופחות נפוץ.

העלויות היו גבוהות משמעותית. הסיבות העיקריות:

• היית צריך להחזיק / לשכור חומר ל peak load שלך. אם בשיא הצהריים אתה זקוק ל3 שרתים ובלילה - רק לאחד (ב 20% CPU), היית משלם על שלושה שרתים כל הזמן - והם היו יושבים "מובטלים" חלק גדול מהזמן.
• היכולת שלך או של ספק לקנות חומרה בזול ו/או לתחזק אותה ביעילות.

מקווה שעזרתי,

ליאור

סיכום

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



---

[1] http://blog.softwareinsider.org/2010/03/18/software-insider-index%E2%84%A2-sii-2009-sii-top-35-enterprise-business-apps-vendors%E2%84%A2/. המגמה מאז קצת התאזנה - המשבר של 2008 משך הרבה לקוחות לפתרון זול, מיידי וללא השקעה גדולה מראש - יתרונות ברורים של מחשוב הענן.

[2] אלמט זה נקרא Annoyance. "ההתעסקות במטלות שאינן ב core business של החברה מפריעים לה להתמקד בעיקר - ואם ניתן עדיף להוציא אותם מחוץ לארגון" - היא טענה מקובלת.

[3] מכונות צילום לארגונים, ואפילו מכונות קפה - מסופקות כיום כשירות On-Demand: הארגון משלם על חוזה שירות ואינו דואג מעבר לכך לדבר. טכנאים של ספק-השירות יבואו לאתר הלקוח לצורכי תחזוקה ותפעול שוטף. התשלום - ע"פ מידת השימוש. אם יש משבר כלכלי - בסוף החודש המכונות חוזרות לספק - והלקוח מפסיק לשלם עד הודעה חדשה.

[4] אם אצלכם בבית אתם לא יכולים להפעיל כמה מכשירים במקביל זו בעיה של התשתית בדירה - הרחיבו את התשתית בהשקעה של כמה אלפי שקלים ותוכלו לצרוך פי 2, פי 10, פי 100 - כמה שתרצו.

[5] היכולת של האפליקציה לבודד בין המשתמשים (או בעצם הלקוחות) השונים. כשאני משתמש ל Gmail אני רוצה שאף אחד לא יוכל להגיע בטעות או בזדון למיילים שלי, אני רוצה שהקומפיגורציה שלי תהיה אישית ואם החלטתי לדחות את המעבר למראה החדש - החלטה זו תהיה בלתי תלויה במשמשים אחרים שמתחברים לאותו שרת פיסי.

[6] אם תהיתם כיצד Amazon הגיעה לשירותי ענן הסיפור הוא כזה: בשלב מסוים של חייה, אמאזון הבחינה שהמחסנים (הפיסיים) שלה אינם מגיעים לתפוסה מלאה חלק גדול מהשנה. היו לה יכולות לוגיסטיות יוצאות-דופן שפיתחה במשך השנים - אותן החליטה להשכיר כאחסון (Storage) במחסנים שלה במודל Leasing. כמה שנים אח"כ חזר אותו הסיפור עם אחסון דיגיטלי ו S3 - שירות האחסון המבוזר של אמאזון. יש לציין שאמאזון, כאחת מהספקיות המקוונות הגדולות, הייתה מובילה טכנולוית כבר לפני שנים. ההמשך מכאן היה דיי טבעי.

[7] לספק מוביל כמו Amazon יש מעט מאוד סיבות לאפשר ללקוח לעזוב בקלות. קרוב לודאי שהיא מעסיקה אנשים שימצאו דרכים לעשות בדיוק את ההיפך.

[8] https://www.deloitte.com/assets/Dcom-Global/Local%20Assets/Documents/TMT/cloud_-_market_overview_and_perspective.pdf