שירותי MCS רלוונטיים

השנה מיקרוסופט תצא עם גירסא חדשה של מסד הנתונים  SQL Server 2008 R2 המיועדת למחסני נתונים ענקיים. המוצר החדש מבוסס על ידע שנרכש מחברה בשם DataAllegro שמיקרוסופט קנתה לפני כשנה וחצי.אז כמה דברים שכדאי לדעת:

 1.      יש כבר היום ל DataAllegro לקוחות עם 350TB - בגירסא של SQL Server היעדים יותר אגרסיבים

 2.      הארכיטקטורה דומה לזו של Teradata (שהיה לי בגלגולי הקודם הכבוד לנהל את ההתקנה הראשונה שלה בארץ)

 3.      המערכת היא Scale out, Share Nothing, High Availabale - הכל By Design

 4.      המערכת מיועדת אך ורק למחסני נתונים - לדוגמא - אין תמיכה ב Stored Procedures

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

לפני כשבוע נערך כנס 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, מתודולוגיות פיתוח וארכיטקטורת תוכנה.

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

"אצלנו לא עובדים על גרסאות במקביל..."

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

שאלות הכוונה:

האם אני צריך לתמוך בפיתוח מקבילי?

• פיתוח מס' גרסאות של המוצר
• טיפול בתקלות בגרסאות ששוחררו (Service Packs & Hot Fixes)

האם אני צריך סביבות פיתוח מבודדות?

• הוספת שינויים מהותיים – breaking changes
• Refactoring
• ייצוב

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

• גודל קבוצת הפיתוח, מבנה הצוותים ואופי העבודה
• הצורה בה משחררים גרסאות לייצור והאם יש צורך לתמוך ב- service packs ואולי אף hot fixes

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

בפוסט הבא נדבר על המודלים הבאים:

1. Basic Plan

2. Standard Plan

3. Advanced Plan

שירותי MCS רלוונטיים

שירותי MCS רלוונטיים

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

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

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

שאלה ראשונה: מענה לאיזה סוג של דרישות ?

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

את מידת המענה של הפתרון לדרישות פונקציונאליות קל (יחסית...) לבחון מבחינה טכנולוגית. "תופסים" את הדרישות האלו באמצעות תסריטים (scenarios) ו – use cases (או themes, epics ו – user stories , תלוי במתודולוגיית הפיתוח). האתגר בדרישות אלו הוא בדרך כלל אתגר של התנהלות ופוליטיקה ארגונית (השאלה "מהי הפונקציונליות הרצויה" תלויה לעתים קרובות באופי הארגון המפתח מאשר בצרכי המשתמש הסופי), בשיקולים של מאפייני המשתמשים (רקע וניסיון, ציפיות מוצהרות ולא-מוצהרות להתהגות המערכת, ציפיות סמנטיות, עומס קוגניטיבי סביר) ועוד.

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

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

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

שאלה שנייה: כיצד מצמצמים את האפשרויות ?

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

וכאן נכנסים לתמונה ה – Architecture Styles.

ההגדרה ה"רשמית" של architecture styles (עד כמה שניתן למצוא הגדרות רשמיות במקצוע עמו ארכיטקטורת תוכנה, שעדיין נמצא בתהליכי התגבשות), היא:

(מתוך המאמר המומלץ בחום "Introduction to Software Architecture" של David Garlan and Mary Shaw מ – 1994. מאמר שאפשר לשייך לו לא מעט השפעה בהיסטוריה של מקצוע ארכיטקטורת תוכנה).

ישנו דמיון רב בין Design Patterns לבין Architecture Styles (הכינוי הנפוץ "Architecture Patterns" מעיד על כך). עם זאת מדובר במשפחות שונות של תבניות (Patterns) שגם ממוקמות ברמות שונות בהיררכיה של ניתוח ואפיון מערכות תוכנה (רמת הארכיטקטורה לעומת רמת העיצוב – design – של המערכת). בגדול, אפשר לתאר את ה – architecture styles כתבניות בעלות נפח והשפעה מערכתית גדולים יותר (לעתים, הרבה יותר) מאשר Design Patterns.

במסגרת סדנת ארכיטקטורת התוכנה אנו דנים לא מעט על Architecture styles. על מנת לספק תיאור הולם של הנושא אני מצרף את המצגת שעסקה בנושא במהלך הסדנא, כמו כן (בסוף הפוסט) אני כולל רשימה של מקורות שבהם ניתן לקבל מידע נוסף על Architecture Styles.

שאלה שלישית: כיצד בוחרים את ה – Architecture Style המתאים ?

לכל Architecture Style יש מגוון מסוים וידוע מראש של מאפיינים אותם הוא מספק (במידה זו או אחרת). מאפיינים אלו ניתנים לניסוח כאותם Quality Attributes, הידועים כדרישות לא-פונקציונאליות. דוגמא אחת היא ה – Pipes and Filters architecture style (ה - style החביב עלי), שמאפשר לספק Quality Attributes כגון: Configurability, Composeability, Manageability, Reusability, Testability ועוד (הגדרת ה – Quality Attributes הנ"ל אינה ב – scope של הפוסט הנוכחי, אך ניתן ללמוד יותר בקישורים המצורפים).

וכאן אנו מגיעים לנקודה המרכזית –

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

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

מידת ההתאמה ל – quality attributes נובעת מהמאפיינים המובנים והידועים מראש של ה – Architecture Styles השונים (כאן בא לידי ביטוי הדמיון הרבה בינם לבין Patterns בכלל). הניסיון הרב שנצבר במימוש ה – Architecture Styles השונים מספק מידע רב לגבי יתרונותיהם וחסרונותיהם בהתייחס למגוון של תסריטים, וכן, עצם השימוש במונחים אחידים (vocabulary) מאפשר תקשורת יעילה מול ארכיטקטי תוכנה אחרים על מנת לאסוף המלצות, תובנות, הערות והארות בשלב מוקדם ככל האפשר בתהליך הניתוח האפיון.

כל זאת, בלי לזלזל או להתעלם מחשיבות הרבה שיש למימוש בפועל של ה – Architecture Style על היכולת לספק מענה לדרישות השונות.
לאחר צמצום האפשרויות ובחירת מספר Architecture styles שמועמדים לאימוץ במסגרת הפתרון הארכיטקטוני, מומלץ (מלשון "חובה" J), לבחון מאפיינים מעשיים, מדידים ומוחשיים של פתרונות אפשריים שמממשים Architecture Style שמועמד לשימוש. היות ורוב ה – Architecture Styles מומשו במסגרת Framework או מוצר זה או אחר, וזמינים לשימוש כ"קופסא שחורה", עולה השאלה של מידת ההתאמה של המוצר (או הרכיב, או התשתית וכו') לתסריט הספציפי עבורו מנסים לספק מענה. כמו תמיד – אלוהים נמצא בפרטים הקטנים (והשטן גם).

ולסיכום -

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

קישורים למקורות מידע נוספים בנושא -

• Introduction to Software Architecture - המאמר המייסד של התחום
• Microsoft Patterns & Prectices Application Architecture Guide 2.0 - Chapter 3 - Architectural Patterns and Styles - ספר מצוין של החבר'ה מ - Patterns & Practices
• Pattern-Oriented Software Architecture - A System of Patterns - החלק הראשון בסדרה (POSA1), ולטעמי הטוב שבהם. מכיל סקירה מצוינת של מגוון Architecture Styles.
• מצגת Architecture Styles מתוך סדנת ארכיטקטורת תוכנה.

HTH,

דני.

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

בשבוע הבא, במסגרת כנס P&P Summit, אני מנחה את ה – ask the experts" session", במהלכו יתאספו אנשי P&P ו – MCS לפאנל שיענה לשאלות המנחה והקהל.

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

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

וכאן אני מעוניין לבקש את עזרתכם:

מהן השאלות הקשות באמת שאתם מעוניינים לשאול את חברי הפאנל ?

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

אז זה הזמן לשאול את השאלות האלו.
בתגובות לפוסט הזה אתם מוזמנים לכתוב את השאלה\ות שאתם מעוניינים לשאול את הפאנל.

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

השאלות הטובות שיועלו, יועלו בפני הפאנל והקהל, בליווי קרדיט מלא לשואל\ת השאלה.
כמו כן, אני מבטיח כי אעשה כמיטב יכולתי על מנת לספק מענה מיטבי לכל שאלה שתעלה בתגובות לפוסט שיישלחו לפני ה – P&P Summit.

בקיצור - בואו נשאל שאלות שיגרמו לחבר'ה של P&P ו - MCS להזיע! J

 בתודה מראש,

דני.

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

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

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

אפשרי בערבון מוגבל. למה בערבון מוגבל? כי באבטחת מידע אין הבטחה מוחלטת – זה עניין של להעלות את הרף עוד ועוד.

תסריט מס’ 1 – הפעלת רכיב בצורה של Early Binding

כדי שרכיבים יזהו אחד את השני Net Fx כולל המצאה שנקראית Code Access Security או בקיצור CAS. מדובר על ניהול ואכיפת הרשאות שלא מבוססות משתמש [ל-CAS לא אכפת מי המשתמש]  אלא ניהול הרשאות על בסיס זהות של רכיב. ישנם הרבי מאפייני זהות של רכיב והכי חזק ביניהם הוא Strong Name. אז כדאי מאוד לחתום את הרכיבים ע”י SNK.

כמבון שיש את העניין של ניהול SNK בצורה מאובטחת – זה מכוסה ע”י Delayed Signing.

לא עניין גדול – חתמתי על הרכיב שלי ע”י SNK והוספתי Reference אליו מרכיב אחר ובנייתי את האפליקציה. תהליך הבנייה כלל גם הצמדה של מאפיני SNK בין הרכיבים. בזמן ריצה ה-CLR מזהה את הצימוד הזה ומוודא שהקשר לא נשבראיך אפשר לשבור אותו?למשל, ע”י כך שהרכיב שלי הוחלף ע”י רכיב אחר אך דומה וללא SNK שלי. במקרה של החלפה ה-CLR יעיף את הרכיב הזדוני ויחד איתו את האפליקציה שלי כולל רישום ל-Event Log.

אחלה! נראה פשוט – חותמים עם SNK והכול סבבה במקרה של Early Binding. מה קורה אם אני מרים את הרכיב ב-Reflection? הרי ישנם הרבה מקרים בהם ישנו שימוש מאוד מורחב ב-Reflection כמו במקרה של Provider Design Patterns או בשם אחר Abstract Factory Design Pattern.

תסריט מס’ 2– הפעלת רכיב ע”י Reflection ללא בדיקת חתימה

הקוד הבסיסי להרמת הרכיב בעזרת Reflection הוא דומה לזה:

Assembly asm = Assembly.LoadFrom("TrustedComponent.dll");
Type myType = asm.GetType("TrustedComponent.MyBusinessComponent");
IBusinessComponent myComponent = 

              (IBusinessComponent)Activator.CreateInstance(myType);
Console.WriteLine(myComponent.PerformBusinessAction(Guid.NewGuid().ToString()));
Console.ReadLine();

הקוד הזה יצליח בכל מקרה – עם SNK וללא SNK.  וזה מכיוון שהרכיב מורם בצורת Late Binding. לרכיב המרים אין שום ידע מוקדם לגבי הרכיב המורם.

מסקנה – מי שעובד עם Reflection להרמת רכיבים בצורת Late Binding חסוף לתקיפות של סוסים טרויניים. עם או בלי SNK.

ראה הוזהרת!

תסריט מס’ 3– הפעלת רכיב ע”י Reflection עם בדיקת חתימה

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

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

//GET STRONG NAME FOR THE LOADED ASSEMBLY
StrongName sn = GetStrongName(assembly);

StrongName myStrongName = null;

//GET CURRENT APPDOMAIN STRONG NAME
IEnumerator enumerator = (IEnumerator)AppDomain.CurrentDomain.Evidence.GetEnumerator();
enumerator.Reset();
while (enumerator.MoveNext())
{
    if (enumerator.Current.GetType().Equals(typeof(StrongName)))
        myStrongName = (StrongName)enumerator.Current;
}


if (!sn.PublicKey.Equals(myStrongName.PublicKey))
{
    throw new ApplicationException("SPOOFED!!");
}

static StrongName GetStrongName(Assembly assembly)
{
    if (assembly == null)
        throw new ArgumentNullException("assembly");

    AssemblyName assemblyName = assembly.GetName();
    // get the public key blob
    byte[] publicKey = assemblyName.GetPublicKey();
    if (publicKey == null || publicKey.Length == 0)
        throw new InvalidOperationException(String.Format("{0} is not strongly named", assembly));
    StrongNamePublicKeyBlob keyBlob = new StrongNamePublicKeyBlob(publicKey);

    // create the StrongName
    return new StrongName(keyBlob, assemblyName.Name, assemblyName.Version);
}

אחלה! עכשיו אפשר לנשום לרווחה, לא? :)

תסריט מס’ 4 – Link Demands

אני, הרכיב התמים, לא רוצה שיפעילו אותי כל מי שבא לו אז אני אסמן את עצמי עם SNIP – קיצור של StrongNameIdentityPermission. וואו, כתבתי את זה! שימוש ביכולת הזו מעלה רף הגנה מפני הפעלה לא מורשית של רכיבים שלי [התסריט ההפוך מאלה שדיברתי עליהם קודם]. הנה לך הסבר מצוין איך להשתמש בזה -

Using the StrongNameIdentityPermissionAttribute

חשוב לציין ש-SNIP הוא לא תרופה אולטימטיבית מפני תקיפה של סוסים. במיוחד בסביבה שהיא Full Trust – ה-SNIP לא מזיז ל-CLR במקרה הזה בכלל. Full Trust Means Full Trust…

חשבת פעם להגדיר Custom Trust Level? זה יכול לעזור לך עם SNIP.  דרך נוספת לכתוב קוד דומה לזה בתואר בתסריט 3.

איך אתה היית מונע תקיפה של סוסים טרויניים על הקוד .Net?

שירותי MCS שאני מדלוור

• שירות ניתוח פערי ארכיטקטורה (PDF)
• שירות ניתוח פערים ושיפור ביצועים (PDF)
• שירות תכנון וניתוח בדיקות ביצועים (PDF)
• סדנת פיתוח מערכות מונחה ביצועים (PDF)

חומר רלוונטי

שמי אליק לוין ואני מתרכז ב- Architecture, Security, and Performance באפליקציות Net.

בזמני הפנוי אני מפתח את עצמי בתחומים רבים אחרים.