סיבוכיות: מקבלים את זה בחינם

אני רוצה לדבר על פשטות. פשטות של ארכיטקטורה ומוצר.כמה פשוט וקל לדבר על פשטות:

"בואו נעשה את זה פשוט"
Keep It Simple, Stupid
Less is More

כמה קל!!

אבל מה היא פשטות, ואיך משיגים אותה?

מה שמעון פרס היה אומר?

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

הקונצנזוס החיובי לגבי פשטות – הוא אוניברסלי.

כמו "שלום עולמי", לאף אחד אין באמת מושג אין משיגים אותה.

ובכן, לכל נהג מונית יש בערך 4 דרכים להשיג שלום עולמי "תיק-תק" – אבל הבודדים שכן מנסים להשיג שלום עולמי, מגלים שאין תורה ברורה איך עושים את זה.

…מתי אמרתם שיוצא הספר "World Peace for Dummies"?

ג'ונגל הסיבוכיות

למי שכתב אפליקציית "Hello World" בחייו ברור שזו אפליקציה פשוטה.

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

עיקרון #1: התבונה היא לא בייצור פשטות, התבונה היא ביציאה מסיבוכיות ברגע שהגענו אליה.

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

פה יש נקודה שקצת קשה למפתחים, אך יותר קלה למי שנמצא בדרגות גבוהות יותר: הדבר שאתם רוצים לשנות יכול להיות דרישות, עיצוב גרפי, צורת התקנה וכו'. אל תגבילו את הבדיקה רק לקוד שלכם ומה שאתם יכולים לעשות מבלי לערב אף-אחד מחוץ לפיתוח.

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

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

עיקרון #2: החכמה היא להאריך את הדרך אל הג'ונגל, עד כדי כך שאולי אפילו לא להגיע אליו…

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

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

"אנחנו מקבלים את זה בחינם", או חוסר ההבחנה בין ממשק public ל published.

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

אפילו יותר גרוע: תחשפו UI, WebService או Public API שלקוחות יוכלו להשתמש בו: הרי הקוד שם – וכך אתם יכולים בעלות נמוכה להשיג תועלת גבוהה – כלכלה פשוטה, "מקבלים את זה בחינם".

אז זהו – שלא.

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

שאלות הרות גורל (לנושא הפשטות) הן:

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

יש הרבה סיפוק בלספק פיצ'ר חדש.

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

"ריבית דריבית"

אם תכפילו 1.2 חמש פעמים תקבלו יותר מ 2. משהו כמו 2 וחצי. החצי הוא ה"ריבית דריבית".

אם תוסיפו פיצ'ר של חיפוש, ועליו יכולת Customization ועליה יכולת X ועליה יכולת Y – הפיצ'ר הבא (נקרא לו "Z"), יהיה יקר יותר מאשר המקרה בו הייתם נמנעים מלהוסיף את יכולות X ו Y. לעיתים – ההבדל בסיבוכיות המערכת הוא משמעותי למדי.

זכרו את הכלל הבא: העלות של יכולת חדשה n היא זמן הפיתוח של n + זמן התחזוקה של n + זמן גבוה יותר לפיתוח יכולת n+1 וזמן תחזוקה גבוה יותר ליכולת n+1. רקורסיבית (lim: n–>m).

עקרון שהתייחסתי אליו גם בפוסט על היעילות האמיתית שב SCRUM: הדרך הטובה ביותר לפריון גבוה יותר בפיתוח הוא לייצר פחות פ'יצרים – וכמעט תמיד יש מה להוריד. YFAGNI[ב]!

עקרון #3: פשטות לא תוצאה של מתכנן גאון – היא תוצאה של עבודה קשה.

הייתה לי פעם שיחה עם איש UX שאני מאוד מעריך. מדוע ה UI של המערכות שלנו הוא לא "כזה מגניב" – למרות שאנו באמת מנסים ומשקיעים.
"למה שיצא לנו UX מגניב?" – הוא שאל בתמימות.
"כי אתה ממש תותח…?!" – עניתי.
"האא… זה לא עובד ככה…" הוא החל להסביר. הוא הסביר שלא ניתן לקלוע ל UX מצוין בפעם ראשונה, אפילו איש UX מוצלח. הדרך להגיע לשם היא ע"י השקעה באיטרציות:

תכנון ה UX
בדיקת שימושיות (על משתמשים אמיתיים)
הפקת לקחים – ותכנון שיפורים
וחוזר חלילה

רק לאחר איטרציה ועוד איטרציה ועוד איטרציה – ה UX מתחיל להיות באמת אפקטיבי, "זורם", ומהנה. (רעיונות דומים אגב מתכנסים היום תחת התחום שנקרא כיום "LEAN UX", למשל לעשות usability tests מאוד קטנים, אבל כל ספרינט).פשטות בתוכנה – היא דומה. אם ניתן למתכנן הגאון עוד שבוע בחדר המובדד – התוצאה לא תהיה משמעותית. אם נקצה 10% מכל כח הפיתוח כל ספרינט ל Reafactoring ושיפור קוד – התוצאה תהיה משמעותית יותר. האם אין דרכי קיצור? האם אין את המתכנן הגאון שייצור את הפשטות במחי מכחול ב Visio? האם אין את המדינאי שיביא שלום עולמי לו רק יתנו לו איזו שנה אחת בשלטון?

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

—–

[א] הערה טכנית: כמובן ש Unit Tests ואוטומציית רגרסיה היא גיבוי רב-עצמה לביצוע שינויים כאלו בפועל.[ב] ! You Ain't Gonna Need It

הכר את המשתמש: איש ה-IT

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

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

על ליצור מוצר מצליח אנו צריכים לספק את צורכיהם ורצונתיהם של המשתמשים ו / או הלקוחות שלנו.

רגע… \"המשתמשים ו / או הלקוחות שלנו\"? מה ההבדל? האם זה לא בדיוק אותו הדבר?

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

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

המשתמשים / הלקוחות של עולם התוכנה

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

10 שנים הם לא מעט זמן…

אני יכול לומר שאני מבין שפות תכנות בצורה טובה, מבין בסיסי נתונים, מבין פרוטוקולי רשת, מבין בדפדפנים ו Web, מבין אפילו קצת בעיצוב ממשק-משתמש… אבל האם אני יכול לומר שאני באמת מבין את המשתמשים עבורם כתבתי כל-כך הרבה קוד?!

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

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

אבל מה עם אנשי IT? האם יש ספר שמתאר אותם? האם יש tutorials ופורומים שעוסקים בהם באינטרנט? – לא משהו רציני שאני מצאתי.

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

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

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

מחלקת ה IT

Disclaimer: למרות שהמידע מוצג בצורה מובנה, הוא מבוסס על התרשמויות אישיות ולא ידע ממוסד ומוסדר.

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

מחלקת רשת (Networking) – אחראים לעיתים קרובות גם על הטלפוניה.
מחלקת שרתים (או System).
מחלקת DB (אותם DBA מפורסמים) – לעיתים היא חלק ממחלקת ה System.
מחלקת תמיכה (או Help Desk, לעיתים גם נקרא PC).
מחלקת הדרכה – לעיתים היא חלק ממחלקת התמיכה.
מחלקת אבטחת המידע (Security).
מחלקת הפיתוח של מחלקת ה IT – מפתחים שכותבים כלים ותוכנות עבור הארגון עצמו.
מחלקת תוכן (אלו שמנהלים את אתר האינטרנט, הפורטל הארגוני וכו\') – לעיתים היא חלק ממחלקת הפיתוח.

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

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

בראש אירגון ה IT יושב ה CIO הרי הוא Chief Information Officer – סמנכ\"ל בחברה (או Board Member – באירגונים בהם סמנכ\"ל הוא דרג ביניים).
רגע של עברית: בישראל השם המקובל הוא מנמ\"ר – מנהל מערכות מידע ראשי. למרות שהשם נשמע כמו שם של רכב צבאי – הוא תפס והוא מקובל למדי.
ה CIO מנהל גם את המחלקות התפעוליות של ה IT – שמטפלות בשוטף (אלו שהזכרתי למעלה), אך גם יהיו תחתיו יחידות של תכנון אסטרטגי וניהול פרוייקטים חדשים. ה CIO – כך נראה, עסוק יותר בניהול הפרוייקטים הבאים מאשר מעורבות בשוטף. החלוקה דומה לחלוקה בצה\"ל בו הרמטכ\"ל עסוק בנושאים אסטרטגיים וסגן אחראי על הניהול השוטף של הצבא.

ה CIO הוא הבחור שיצטרף לישיבות פתיחה / סיכום של פרוייקטים – יגיד כמה מילים טובות ויחייך מאוזן-לאוזן. סוג של סימן \"אני בעד הפרוייקט הזה\" – אבל הוא לא יתעסק בפרטים.
הוא ייתעניין יותר בסיפורים של איש השיווק שלכם על מה שהמערכת שלכם ~~יכולה לעשות~~ אולי תעשה בעתיד (אם תוסיפו כמה שנות פיתוח ותתרחש פריצת דרך משמעותית בתחום הבינה המלאכותית).

את מחלקת האבטחה מנהל לרוב ה CISO הרי הוא ה Chief Information Security Office – שמדווח ישירות ל CIO. מחלקת האבטחה מדווחת ל CIO ואינה כפופה לגוף התפעולי ה IT. הקשר הזה כנראה אמור להבטיח את עצמאותה של מחלקת אבטחת המידע – עליו נדבר עוד קצת בהמשך.
גם מחלקת הפיתוח רחוקה יותר מהשוטף של ארגון ה IT וקרובה יותר לחלק של תכנון הפרוייקטים (איזור ה CIO).

מקומה של מחלקת ה IT באירגון

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

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

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

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

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

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

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

איש סיסטם בעבודה. מקור: eqslcc.blogspot.com

מבט קרוב על כמה ממחלקות ה IT השונות

מחלקת הרשת – כוללת לרוב אנשים טכניים למדי שיש להם את הזמן, היכולת והחובה להתעמק בציוד ופרוטוקולי הרשת לפרטי פרטים. הם רגילים לעבוד בסקריפטים וכלי Command Line ללא ממשק גרפי – זה הסטדרט בכלים שהם מתעסקים בהם. הם מרוכזים בנישה שלהם ולא נוטים להראות עניין בעולם החיצון.
התקשורת איתם היא לרוב \"תן לנו את הגדרות ה-[1]QOS של שירותי הרשת שאתה צריך (בשפה שאנחנו מכירים) – ואנחנו נספק אותם (ע\"פ הדרך שאנחנו רגילים למדוד)\".
הרושם הכללי שלי הוא שאנשי רשתות אינם נוטים לנסות ולהבין את הפרוייקט הכולל – ומתמקדים בעיקר בחלק שלהם.

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

אם אתם מפתחים ממשק ייחודי ולא סטנדרטי כדי להקסים ולגוון את חייהם של ה System Admin – כנראה שתשיגו את התוצאה ההפוכה.
אם החלטתם לחסוך פיתוח ולדרוש מה System Admin עוד כמה פעולות ידניות שעליו פשוט לזכור ולבצע – אחרת משהו לא יעבוד – כנראה שלא תזכו להיות הדמות שגורמת לו שמחה בלב. להיפך.
אם החלטתם שאיש סיסטם יכול להתמודד עם מסכים אולטא-מורכבים \"כי הוא טכנולוגי\", או אתם אותו להשתמש בכלי Command Line – אתם במסלול השגוי להגיע לליבו של איש הסיסטם.

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

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

יש כמה דרכי התמודדות מקובלות עם המורכביות האלו:
1. רכישת חוזרת של תוכנה מספקים קיימים – כך שכניסה למערכות החדשות תהיה קלה יותר והתמיכה תהיה מרכזית.
2. חיבור המערכות השונות, עד כמה שניתן, למערכת ניהול מרכזית ממנה יוכל איש הסיסטם לתפעל באופי מרכזי את כל המערכות. כנראה שהתשובה לשאלה \"איזה ממשק משתמש אתה רוצה?\" תהיה \"HP Open View. אני מעדיף מרגע ההתקנה לא להתחבר למערכת שלכם יותר איי פעם\".
3. Outsourcing של ניהול המערכות הפחות קריטיות לארגון. כמה מערכות פחות להתעסק איתן הם אוויר לנשימה עבור אנשי הסיסטם העמוסים במטלות. הצלחת הענן ושירותי On-Demand הם ביטוי ישיר למגמה זו. לעיתים ארגונים ישכרו יועץ חיצוני על מנת לבצע Configuration של מערכת מורכבת – הם יעדיפו לשלם על מנת לחסוך לאנשים שלהם את הצורך ללמוד לעומק עוד מערכת נוספת.
4. אוטומציה (בעזרת Scripting או ממשקים נוסח JMX) עד כמה שאפר למערכות השונות כך שלא יהיה צורך להתעסק איתן.

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

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

מחלקת ה Security
\"אם אנשי הרשת לא מסתכלים מעבר למשבצת שלהם, ואנשי הסיסטם מנסים לעזור, אבל מצלחים בקושי – אנשי האבטחה הם שם בכדי להפריע!!\"

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

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

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

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

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

—

[1] Quality Of Service – הגדרות מספריות לזמינות ומהירות הרשת בפרמטרים שונים. למרות שההגדרות אמורות להיות חד-חד ערכיות – הן ניתנות לפירושים שונים (\"אני דיברתי על Latency כשאין פעילות אחרת ברשת\").

[2] בציוד רשת יש משמעות רבה לרכישה מספק אחד – הציוד עובד ביחד בצורה משמעותית טובה יותר.

"זה נראה כמו סיפור הצלחה"

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

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

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

נושאים טכנולוגים (במיוחד חדשים) הם הרבה פחות מוכרים ואינטואטיביים: למשל Big Data. אם הייתי מספר לכם שיש לי אפליקציה שולחנית עם המון נתונים (אולי איזה 10GB!!) ואני רוצה להיכנס לעולם ה Big Data – ייתכן וזה היה נשמע יותר הגיוני. "למה לא?" הייתם עונים "זה תחום חם היום." – "פשוט מגניב!".

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

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

קרוב לוודאי שזה נשמע מצחיק (השתדלתי), אבל התיאור אינו שונה כ"כ ממאמצי אימוץ שונים שנתקלתי בהם: SCRUM, Object-Oriented ו test-automation – ואלו הן רק כמה דוגמאות ("to name the few").

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

הדגשים העיקריים מניסיוני הם אלו:

התמקדו בתוצאות – והזהרו מהתמקדות ב"חזות המקצוען"
ב SCRUM צוותים ממהרים להציג לוחות Burn-down Charts ולעשות Stand up meeting.
אם אח"כ, בישיבת ה Retrospective, רק ה Scrum Master מדבר ומחלק ציונים לכל האחרים – כנראה שמשהו התפספס (סיפור אמיתי). אם יש לכם שני ספרינטים של Design ואז שני ספרינטים של "מימוש" ואולי עוד ספירנט "בדיקות ו Stabilization" – כנראה שמשהו התפספס (המשך של אותו הסיפור).

פעם ראיתי ראש צוות שלמד Object-Oriented באמצע הקריירה (הוא בא מ Kernel C). הוא יצר מחלקה "פונקציות", מחלקה "קבועים" ומחלקה "משתנים" (והמשיך לפתח פרוצדורלית, כמובן). "הבנתי את הסיפור" הוא הכריז. "נחמד, קצת עושה סדר – אבל אני לא מבין למה עשו מ OO כזה רעש…"

אנו רוצים "להראות" כמו המקצועניים ו"להרגיש" כמו המקצוענים – ומהר, אבל בעצם יותר חשוב שנראה שיפור מדיד (ע"פ מדדים אובייקטיבים) ולבסוף נגיע לתוצאות טובות יותר מאשר השיטה הישנה. האם לחלק את הפונקציה ל class נפרד משפר את הקוד? אם לא – חשוב לשפר סגנון או לזנוח את ה OO. עדיף Waterfall מוצלח (אם יש דבר כזה…) על SCRUM רע ועדיף תכנות פרוצדורלי מסודר על פני תכנות OO מגוחך.

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

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

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

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

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

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

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

הניחו לצורך בהצלחה סובייקטיבית להתמלא ולחלוף – ושמרו כוחותיכם להצלחה האובייקטיבית הנדרשת הבאה.

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