סימני המהפכה (מובייל)

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

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

שינוי? אתם בטוחים?

הנה אחד הגרפים שעבורי הוא עוצמתי במיוחד:

במהלך שנות ה-80, Wintel (צימוד של Windows ו Intel) השתלטו לחלוטין על שוק המיחשוב – על חשבון כמעט כל השחקנים האחרים. הם שלטו בעוצמה במהלך שנות ה-90 ושנות ה-2000, כמעט 2 עשורים. לפתע פתאום, בשנים ספורות, המערכות שהם מייצרים ומוכרים הפכו להיות מיעוט של המערכות הנמכרות. בשנת 2012 רק כשליש ממערכות המחשוב האישי שנמכרו היו WinTel.
הנתונים בגרף הם דיי מדהימים וכנראה לא מבטאים את התחושה שיש לרבים מאיתנו: ה PC עדיין כאן, ומקומו יציב.
את התמונה משלים הגרף הבא:
ובכן, זה לא שמחשבי ה PC נזרקו לפח והפסיקו להימכר – פשוט יש מכשירים חדשים, סמארטפונים וטאבלטים, שנכרים בקצב גדול בהרבה.
כבר כמה שנים אנו יודעים על מגמה ברורה של צמיחת הלפטופים על חשבון המחשבים השולחניים, גם בבית וגם במקומות העבודה – אולם זו הייתה מגמה הדרגתית. הפריצה של מכשירי המובייל היא מהירה לאין-שיעור.
ב2012 יכולנו לראות צמצום לא רק במכירות המחשבים השולחניים, אלא גם במכירות הלפטופים שעד כה צמחו. ה Netbook (מחשב נייד קטן וזול) נעלם מהעולם ויצרנים גדולים כבר הפסיקו לייצר אותו (לינק1, לינק2). טאבלטים הם התחליף.
במקום Windows יש את Android ו iOS.
במקום מעבדי Intel ישנם מעבדי ARM.
ל Wintel יש סיבה טובה מאוד להיות מודאגים – והם כבר פועלים בשנה-שנתיים האחרונות במלוא המרץ, כולל קניבליזציה של מוצרים קיימים שלהם, על מנת להסתגל למציאות החדשה.
שאלה נפוצה היא: האם סמארטפונים הם באמת תחליף למחשב או שהם סתם עוד טלפון נייד? האמת היא, כנראה, איפשהו באמצע.

על אופניים ומשאיות

ההצלחה של מכשיר האייפון הפתיעה את כולם: אנליסטים, מומחים ומתחרים. יש שאומרים שזו הייתה הפתעה חד-פעמית שלא יכולה עוד לחזור על עצמה שוב בשנים הקרובות.
הסיבה הייתה כמובן נקודת הייחוס: האייפון היה הרבה יותר יקר ממכשירי טלפון אחרים. התאוריה הכלכלית גורסת שלמכשירים יקרים יש מעט קונים – אולם את האייפון קנו הרבה מאוד אנשים למרות מחירו הגבוה. הסתכלו מסביב: כמעט לכולם יש אייפון (או אנדרואיד) – גם אנשים שאינם עשירים או שאינם נוטים לקנות מוצרי יוקרה.
כיצד ניתן להסביר זאת?
חשבו לדוגמה על אופניים. אנשים רבים קונים ומשתמשים בהם. אופניים \"רגילים\" עולים 500, אולי 1000 ש\"ח. נאמר שמחר מופיעה חברה בשם \"אגס\" ומציעה אופניים מ-ד-ה-מ-י-ם במחיר 100,000 ש\"ח. כמה זוגות אופניים אתם חושבים שימכרו? בוודאי יש כמה טייקונים ובני עשירים שלא יתקשו להוציא סכום שכזה – אך הם עדיין מעטים.
מנכ\"ל \"אגס\", סתיו עובד, מסביר בתוקף שזו קטגוריה שונה של מוצר: באופניים שלו יכולה ליסוע ביחד משפחה שלמה. החוויה נעימה ונוחה הרבה יותר, שקטה ונעימה. לא נכון להשוות אותם ל\"אופניים סתם\".
אבל, 100,000 ש\"ח? השתכנעתם?
ובכן, מסתבר שה\"אופניים\" של חברת \"אגס\" הם בעצם רכב משפחתי, וכן – גם מי שאינו עשיר במיוחד או אינו נוטה לקנות מוצרי יוקרה עדיין מוציא סכום גבוה של 100,000 ש\"ח וקונה רכב. זו חוויה כ\"כ שונה ויותר טובה – שכולם רוצים אותה.
מהצד השני יש את המחשב האישי: ה PC. ה PC, כפי שתיאר אותו פעם סטיב ג\'ובס (לא לבלבל עם סתיו עובד), הוא כמו משאית: הוא כלי עבודה מקצועי, מאוד Capable – שאינו מותאם לצורכיהם של רוב המשתמשים. ה PC גדול, מסורבל, מסובך לשימוש ואיני אופטימלי לסט המשימות שאנו נוהגים לעשות הכי הרבה: לקרוא מייל או מסמך, לשמוע מוסיקה או לראות סרטון ביו-טיוב.
כמו משאיות, ה PC לא צפוי להיעלם – זהו כלי עבודה חשוב. ייתכן והוא יהפוך להיות נישה קטנה, שכוללת אולי 5% מהמחשבים בעולם. כפי שיש הרבה משאיות וכמה חברות מרוויחות מייצורן יפה, אך הן עדיין המיעוט.

עד כמה ההצלחה של אפל היא גדולה?

לכולם ברור שאפל הצליחה מאוד, שהמנייה שלה עלתה מאוד ושבעלי המניות כנראה מרוצים. בכל זאת, לסיום, הייתי רוצה להתבונן שוב במספרים המדהימים של אפל.
בעולם הגלובלי שלנו, כשאפשר לייצר מוצר חדשני ולשווק אותו בו-זמנית בכל העולם למיליוני אנשים – למוצר מהפכני אמיתי יש השפעה כספית מדהימה, מבהילה אולי.
בואו נשווה את הרווחים של אפל לאלו של חברות מקבילות.
אם נניח שאפל היא חברת תוכנה (תחום רווחי מאוד) – היא עדיין הרוויחה ב 2012 יותר מגוגל, מייקרוסופט, איביי, יאהו, פייסבוק ואמזון ביחד. כל אחת מהחברות הללו היא ענקית מעוררת קנאה, אבל אפל הרוויחה יותר מכולן ביחד. וואהו!
אפשר לומר שאפל היא חברת חומרה, כיצד אם כן היא משתווה לייצרני ה PC הגדולים? ובכן: אפל מרוויחה כפול מיבמ, לנובו, HP, אינטל, דל, אייסר ואסוס ביחד.
מה עם חברות המדיה? אפל הרי מוכרת תוכן (מוסיקה, ספרים, סרטים). אפל מרוויחה כפול מוולט דינסי, ניוז קורפ, טיים וורנר ועוד – ביחד. לא חברות קטנות או \"פראייריות\".
האם אפל היא יצרנית טלפונים? אם משווים את הרווחים שלה לרווחים המצרפיים של נוקיה, סמסונג (שכרגע מרוויחה הרבה מאוד), HTC ו RIM – היא עדיין משאירה להן אבק.
אפל, אגב, עושה את רוב רווחיה בעקבות מכירת חומרה: אייפונים ואייפדים. לא מתוכנה, לא מתוכן ולא מאפליקציות.
שיהיה בהצלחה בעולם החדש!

עננים ציבוריים ועננים פרטיים (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 אינסופיים – אך גם הם מוגבלים.

מה Amazon עושים נכון?

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

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

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

אני אקצר לכם, אבל הוא מדבר על SOA ואיך ארכיטקטורה שמחייבת אנשים לעבוד בממשקים מוגדרים היטב, ללא קיצורי דרך (זכרון משותף, למשל) גורמת לאנשים לצמצם תקשורת לאותם ממשקים. ואז – דברים מתפרקים: למשל מתרחשים (SDoS (Self Denial of Service כאשר שירות מהיר קורא לשירות איטי הרבה פעמים. לא היו מפתחים שמדברים אחד עם השני ויכלו למנוע זאת. 

וכך… כך מתפתח ה DNA* הארגוני: כל Service נבנה בצורה robust ו isolated לחלוטין. \"על המפתח להגן על הקוד בפני… עצמו\", אמר כבר פרדריך ברוקס בשנות השבעים.

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

שווה לקרוא בשפת מקור (context: נכתב ע\"י אדם שעובד כשש וחצי שנים בגוגל):

Google+ is a knee-jerk reaction, a study in short-term thinking, predicated on the incorrect notion that Facebook is successful because they built a great product. But that\'s not why they are successful. Facebook is successful because they built an entire constellation of products by allowing other people to do the work. So Facebook is different for everyone. Some people spend all their time on Mafia Wars. Some spend all their time on Farmville. There are hundreds or maybe thousands of different high-quality time sinks available, so there\'s something there for everyone.

Our Google+ team took a look at the aftermarket and said: \"Gosh, it looks like we need some games. Let\'s go contract someone to, um, write some games for us.\" Do you begin to see how incredibly wrong that thinking is now? The problem is that we are trying to predict what people want and deliver it for them.

You can\'t do that. Not really. Not reliably. There have been precious few people in the world, over the entire history of computing, who have been able to do it reliably. Steve Jobs was one of them. We don\'t have a Steve Jobs here. I\'m sorry, but we don\'t.


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


בקיצור, יפה.


אפשר למצוא את המקור כאן:

הרגישו חופשי להוסיף תובנות עקרונויות נוספות שפספסתי / לא ציינתי.

כמובן שדברים יכלו להתפתח אחרת.

בורסת הטכנולוגיה: איך מחליטים על השקעה בתחום לא מוכר?

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

כיצד אנו בוחרים ספריה/טכנולוגיה/מתודולוגיה?
אנשים טכנולוגיים נוטים להתבונן על הטכנולוגיה בפרטים:
  • איך ה Design או הארכיטקטורה של הספריה?
  • באיזו שפת תכנות היא כתובה? (חשוב!) \"מה, בBoo? כנראה שאלו חבר\'ה מביני עניין! אני כבר מחבב אותם\"
  • איך נראים ה API?
  • כמה קצר ומרשים ה tutorial שאיתו אוכל להתחיל ולהתשמש בה (טעות אנושית נפוצה היא להניח שאם אפשר להרים Hello World בפחות מדקה, אנו עתידים לשבוע נחת מהספרייה…)
  • לבדוק את ה Roadmap ופ\'יצרים עתידיים. 

    מתכנתים קצת יותר מנוסים יביטו על עוד כמה הבטים:
    • תיעוד ארכיטקטורה – כמה ברור מה קורה בפנים ואיך הספריה עובדת?
    • adoption וה community – האם נראה שהספריה תתמך עוד זמן רב או שהיא בנסיגה? כמה פעילות יש בפורומים?
    • בחינת רשימת הבאגים במערכת ניהול הבאגים (אם היא ציבורית) ולקבל מושג על רמת האיכות ואיזה סוג בעיות יש.
    • בחינת ה release notes האחרונים, כמה הם תכופים (כמה מהר נקבל עדכונים חשובים) וחיפוש אחר סימנים מעניינים. לדוגמא: ספריית client side שמדווחת על תמיכה ב windows 7 מעלה סימן שאלה על התלות ולמה רק עכשיו? דיווח על תיקון באג ב authentication ב SAML2 על Firefox יכול להיות סימן לבגרות. הכל כמובן תלוי ב context.
    מנהלים, אולי כי יש להם פחות זמן להשקיע ואולי בגלל שהם לא רוצים להכנס לפרטים, ישתמשו בכלים ניהוליים:
    • לשלוח מישהו שעליו סומכים עליו לעשות את הבדיקה (עדיף שזה יהיה אדם מנוסה)
    • שימוש בקשרים להשגת references חיים (כלומר מישהו שאפשר לתשאל אותו) – חשוב להתייחס לכל פידבק בהקשר הנכון.
    • Benchmarking – \"אתה אומר ש Haskell שפה נהדרת, אך אף אחת מהחברות בתחום שלנו לא עובדת בה. זה גם נכון לחברות בתחומים דומים\".
      \"היא שפה נהדרת\" יענה המתכנת הנבון והצעיר \"אתה יודע כמה בינוניות יש בתעשיה – זה שאחרים לא משתמשים בה לא אומר שומדבר\".
      \"לא נראה לי\" – סביר שתהיה החלטת המנהל, וכנראה בצדק [א]. הוא לא יודע כלום על Haskell, אבל מגמת התעשייה מכילה ידע שאלה האדם הבודד יכול להגיע רק לאחר חודשים ארוכים. אי הליכה בתלם משמעותה גם פחות Eco-System לעבוד איתו, כמובן (אפרט יותר בפוסט המשך).
    • חיפוש ובחינת נקודות מפתח מנחות – מה מאפיין את שפת Haskell? משולבת בעיקר באוניברסיטאות? (נאמר, אני לא יודע באמת). מה ניתן ללמוד מכך – מה מאפיין אוניברסיטאות?
    בחיינו היום-יומיים, יש נושאים שאנו מבינים בהם יותר (או יכולים להבין בהם), למשל –  קניית טלויזיה חדשה. אנו נוטים לפעול בנושאים אלו יותר כמו מפתחים. בנושאים שבהם אין לנו באמת סיכוי להבין בהם לעומק, למשל, השקעה בורסאית בחברות – אנו נוטים לפעול יותר כמו כמנהלים.
    בעיית חוסר היכולת להכנס לפרטים אינה חדשה. איזה פתרון יצר עולם ההשקעות לחוסר ההבנה של לקוחותיו? – אנליסטים! אותם מומחים שאומרים לנו \"לקנות לקנות\" או \"למכור למכור\" ואפילו קצת השתכללו עם השנים ועתה הם קובעים מחיר יעד למניה \"לאחר הכניסה לשוק הזימבבואי, על מנת לשקף את שווי השוק האמיתי, מניית נייס צריכה להגיע למחיר של 23 דולר ו 14 סנט בדיוק!\" [ב].
    אנליסטים של עולם התוכנה
    כמו שלשוק המניות יש אנליסטים שמסכמים כמות אדירה של נתונים להמלצה פשוטה, כך לשוק התוכנה יש את האנליסטים שלה. החברות המוכרות הן Gartner ו Forrester וקצת מאחור IDC ו Altimeter Group. תוצאות מחקרי השוק שלהן עולות אלפים רבים של דולרים למחקר ומכסים תחומים רבים, בעיקר ב IT. הרבה ביקורת קיימת על מחקרים אלו, אך רוב החברות בגודל בינוני-ומעלה עובדות לפחות עם אחד מהגופים הללו. אם תבדקו במחלקת ה PM רוב הסיכויים שתגלו שיש להם (או יש להם גישה) לחומר כתוב ויכולת לקבוע פגישת יעוץ עם אנליסטים מאחת מהחברות הנ\"ל.
     
    מצד שני יש את דו\"ח הטכנולוגיה של חברת ThoughtWorks שמחולק בחינם ומכסה מספר מצומצם של טכנולוגיות, אך מתוך הכרות אינטימית של מובילים טכנולוגיים שהשתמשו בטכנולוגיות אלו בפועל. דו\"ח זה נקרא Technology Radar והוא מיועד יותר למנהל הפיתוח / ארכיטקט / מנהל בכיר ופחות ל Marketing. תוכלו למצוא בדו\"ח זה סיכום על מצבן על טכנולוגיות, כלים ומתודולוגיות כגון OAuth, HAML, DevOps או ESB. הדו\"ח מדבר על מגמות ולא נכנס לפרטים. סקירת הדו\"ח יכולה להיות מקור טוב לקבלת החלטות (אם הטכנולוגיה עליה אתם חושבים מכוסה) או לעקוב אחר טכנולוגיות וטכניקות חדשות שצוברות תאוצה.

    [א] באותה לוגיקה (לכאורה) יכול מנהל להחליט לזנוח SCRUM ולעבור לפתח ב Waterfall \"כי שבעים אחוז מהתעשייה לא טועה\" או להסיק שאין סיבה לא לפתח בקובול, \"שפה מוכחת ורצופת הצלחות עסקיות\". גם Benchmarking צריך להעשות נכון, קרי – להביט על מגמות ולעשות השוואות רלוונטיות.
    [ב] האם האנליסט באמת יודע מה קורה בחברת נייס? הוא ניזון בעיקר ממסרים אופטימיים שמייצרת מחלקת יחסי הציבור של נייס. האם הוא מכיר את הלקוחות? טיפה. משוחח איתם פה ושם. וזימבבואה? הוא מצא אותה על המפה (אם הוא אנליסט טוב) וקרא כמה סקירות של… איך לא? אנליסטים אחרים שכתבו על השוק הזימבבואי. בערך2 כפול בערך3 = בערךבערך6, וככל שכמות המשתנים הלא מדוייקת גדל… כך התוצאה הסופית פחות מדוייקת.

    על המלכודת הפנימית של תעשיית ה IT ואיך נוצרים מוצרים פחות טובים (ספיישל יום כיפור)

    לאחרונה יוצא לי קצת להתעסק בהרמת הבלוג.

    אחת החוויות החיוביות והמפתיעות שהיו לי היא התקנה של הwidget של Outbrain. ה widget הוא תיבת ה \"בנוסף אולי תאהב/י את…\" שנמצא פה בבלוג בתחתית כל פוסט (הוא זקוק לעוד זמן תוכן ותעבורה כדי לעבוד כמו שצריך פה בבלוג).

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

    הממ… עסוק באמצע העבודה כדי לפרט? טיפים? אומר לעצמו \"הוא טכנולוג, הוא כבר יסתדר\"?

    לא ציפיתי לכיף חיים. הוספתי גוגל אנליטיקס ממש לפני זה ונאלצתי לחפש tutorial בגוגל, לערוך את ה HTML View של הבלוג ולשתול javascript שנתנו לי. ואז עוד עשר דקות בפורומים של גוגל להבין ש \"invalid connection\" בסוף ההתקנה הוא נורמאלי וייקח לו עד חצי שעה להתרפרש.
    גוגל אנליטיקס ובלוגר הם שני מוצרים של גוגל – חברת ענק עם גוף פיתוח שידוע באיכותו הגבוהה. ואאוטבריין? סטארט-אפ ישראלי?

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

    פתאום הייתי בבלוגר – מאשר להוסיף? מאשר.
    נגמר.

    מה???
    בדקתי כמה פעם לא מאמין – הכל עובד.

    אני לא יודע אם החוויה שלי היא המייצגת, אבל היא בהחלט הייתה טובה. הדהדו לי קולות של מנהלי מוצר שעבדתי איתם בעברי: \"המשתמש הוא administrator – הוא יסתדר גם עם להקליד regex במקום להקליק על checkbox\". \"זה משתמש טכנולוגי, אז שימחק הכל וייצר את הרשימה מחדש, הוא ימצא עזרה בגוגל\".

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

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

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

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

    מה עושים?
    מנהל בכיר שהכרתי הציע ברגע של יאוש לשלוח מאמר בנושא ל all-customers@worldwide.com, המייל חזר.

    הייתי שמח מאוד לראות חרם צרכנים של אנשי IT: \"לא Wizard – לא קונה\". מהפכת צרכנים כמו שקרתה בעולם המערבי בשנות החמישים.*

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

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

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

    יש תקווה של אבולוציה, כיוון שהשוק מתבגר לאט לאט (לאט) – ודורש עלות תפעול משפורת.

    ויש את המציאות הקיימת שנדרש להמשיך להתמודד איתה.

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

    בקיצור, גמר חתימה טובה וצום קל.

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


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