רשמים מכנס AWS

השתתפתי בכנס AWS וברצוני לשתף ברשמים מחוויה זו.

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

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

בענן הציבורי חשופים לתקלות ול- downtime אולם מציאות של תקלות (חמורות יותר או חמורות פחות) מתרחשות גם בארגונים פנימה.

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

לגבי הכיוונים והמיצוב של AWS, אכן נראה של- AWS יש וותק ומובילות בשוק, לטענת לקוחות שהופיע בכנס, של לפחות 4 שנים. אולם מכיוון ששוק זה מתחיל להיות צפוף וישנם מספר חברות אשר מאיימות על ההגמוניה של AWS  בתחום ובמקרים מסוימים אפילו קונות נתח שוק (נזכיר כאן את מיקרוסופט, גוגל, IBM ) הרי שאחת הפעולות ש- AWS מבצעת היא הצעה של שירותים מתקדמים הדומים לשירותים שקיימים בשוק אבל עם ניחוח ייעודי, לדוגמה אחד השירותים החדשים שהשקו הוא AWS CodeDeploy או AWS CodePipeline  שירותים המתממשקים עם פתרונות ידועים כמו puppet, chef ו- GIT אבל אינם זהים להם לגמרי.

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

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

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

יבמ מוכרת את עסקי שרתי האינטל שלה –ניתוח המהלך עם זווית ישראלית

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

ישנן מספר סיבות שחברו למהלך דרמטי זה. תחום שרתי האינטל הפך להיות עם השנים תחום בעל בידול נמוך יחסית. ישנם הבדלים בין המוצרים השונים בהקשר של חיבור להתקנים חיצוניים, קלות ניהול ותכונות חשובות נוספות אולם ברמה ה"בסיסית" מדובר אצל כולם באותם מעבדים של אינטל ש"עושים את העבודה" מעל מערכת הפעלה windows או linux שמנוהלות בסביבה וירטואלית בדרך כלל על ידי VMWARE.  לאחרונה רואים התגברות הנפיצות של יצרני שרתים שמוגדרים כ- white boxes (לדוגמה supermicro).

סיבה נוספת (מבחינת חשיבות אולי אפילו קודמת) השימוש בענן הציבורי שעדיין לא נכנס לשימוש שוטף בחברות מסורתיות הפך להיות סטנדרט דה פקטו אצל חברות חדשות וגם חברות מסורתיות מבצעות מהלכים ראשונים בענן הציבורי כאשר ספקי השירות משתמשות בדרך כלל בחומרה מתוצרת white boxes או אפילו מיצרות חומרה ייעודית שלעיתים גם מוצעת לשימוש באופן כללי (opencompute project).

סיבה אחרונה שנזכיר היא טכנולוגיית ה- big data (בעיקר מדובר על Hadoop ו- NoSQL DBMS) אשר באופן בסיסי משתמשים בשרתים שהם stand alone (להבדיל מ- blades ) וגם הם משתמשים בחומרה זולה.

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

לצעד זה יש השלכות חשובות על שוק המחשוב.

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

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

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

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

ההכרזות החדשות של מיקרוסופט – הכל אפשרי!

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

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

לראשונה מדובר במערכות הפעלה אשר ירוצו לא רק על מעבדי אינטל אלא גם על מעבדי ARM. מעבדי ARM הנם מעבדים חלשים יותר ממעבדי אינטל אולם צורכים משמעותית פחות חשמל (פחות מתחממים, זמן העבודה למול אותה סוללה ארוך יותר). גרסת Windows 8 שתרוץ על אינטל נקראת Win 8 pro. גרסת Windows 8 שתרוץ על ARM נקראת Win 8 RT. מיקרוסופט יוצאת לא רק במערכת הפעלה שתעבוד על מעבדי ARM אלא גם בתוכנות מותאמות כשבראשן Office. במרץ אמורה לצאת תוכנת Office שתפעל שתפעל גם על טבלטים של אפל-IPAD וטבלטים של גוגל, מכשירים שגם הם מבוססים על מעבדי ARM.

לראשונה מדובר בשני אופני עבודה מול מערכת ההפעלה. הממשק הותיק והמוכר "Desktop" שמתאים יותר לעבודה עם עכבר\מקלדת וממשק חדש שמתאים לעבודה במכשירים המבוססים על "מגע" ופחות לעבודה עם מקלדת\עכבר – ממשק ה- Metro. יש לציין שהממשק הותיק "desktop" אומנים יופעל במכשירים המבוססים על מעבדי ARM אך מצד שני רק אפליקציות מותאמות מראש יוכלו לפעול בתצורה זו (תיקון טעות מהגרסה המקורית - תודה לניר שגיא!)

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

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

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

תסריט 1: מכשירי ה- tablet יחדרו לארגונים רק כנישה – ולא יצליחו לחדור לשימוש כללי של המשתמשים הארגוניים.

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

תסריט 2: מיקרוסופט לא תצליח לחדור כלל לתחום הטבלט ולתחום הטלפוניה.

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

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

STKI: זהו תסריט אידאלי למיקרוסופט. מצד אחד אפשר יהיה חויית טבלט עדכנית מהמכשירים מצד שני אפשר יהיה להשתמש במידת הצורך בתוכנות הקיימות (מתוך ממשק ה- metro ניתן לעבור לממשק ה- desktop במכשירים שמבוססים על מעבד אינטל). עם זאת, מדובר על תסריט שאינו ודאי וזאת מכיוון שעוד אין ברשותנו מידע על מעבדי אינטל שנותנים חווית שימוש מבחינת צריכת חשמל, סוללה, משקל, חימום המכשיר וכד' –כפי שמתקבלים במכשירי ARM. אחת הסיבות לכך היא שלאינטל מחוייבות לקוד קיים (לעומת ARM שבו יש פחות פקודות) ולכן לבנות מעבד אינטל שצורך מהותית פחות חשמל הנה משימה קשה ביותר.

תסריט 4 – טבלטים מבוססים Windows 8 RT – כלומר רצים על מעבד ARM – יצליחו בשוק הביתי והן בשוק הארגונים.

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

תסריט 5 – לקוחות ירצו לרכוש רק חומרות שיצרני התוכנה סיפקו כלומר טבלטים וטלפונים של מיקרוסופט, אפל וגוגל (ולא של השותפות הנוכחיות HP DELL LENOVO HTC SAMSUNG וכד').

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

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

עבודה או כסת"ח?!

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

בשעת מעבר - רגל אחת או שתיים? One foot or two

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

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

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

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

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

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

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

כאשר בכל זאת דיברו על הסתמכות על אתר DR בלבד דובר על:

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

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

• ארגון נוסף המליץ שלא להעביר את כל המערכות במשאית אחת ולחלק מערכות האחסון במספר רכבים או מספר העברות.
• פידבק נוסף - לגבי עבודת אתר ה-DR - זה צריך לראות עד כמה הוא מוכן? האם הם עושים תרגילי DRP? האם הם מנטרים כשירות DRP? האם יש מספיק capacity וקו תקשורת קיימים ומספקים לעבודה מאתר ה-DR? האם יש דברים שמראש ידוע שלא יעבדו מה-DR? הכי חשוב לעשות תרגילים אמיתיים של DR, כך ידעו הכי טוב מה עובד ומה לא.
• לגבי העברת מדפים במשאית (tender-processing) - עשינו את זה כמה וכמה פעמים, בהצלחה רבה. וגם עדיף לבקש מהספק לשנע את החומרה שלו, כך שגם יקחו אחריות. אבל אני לא הייתי חושש מזה יותר מידי.

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

כלוב הזהב של אפל -טוב או רע? Apple's golden cage

חויית השימוש בטכנולוגיות הניידות של אפל - כלומר iPhone ו- iPad היא חוויה שונה מחויית השימוש במכשירים ניידים - laptops פיסי או מכשירי אנדרואיד. החוייה מושקעת יותר מחד אך מצד שני סגורה יותר והדבר זכה לכינוי "כלוב זהב".
לאחרונה נתקל ארגון מוסדי במגבלה של שימוש בסביבה הטכולוגית של אפל. מדובר על ארגון אשר פיתח אפליקציה ללקוחותיו ב-iPhone. האפליקציה היא אפליקציה פשוטה יחסית - לקוח ניגש חשבון שלו מבקש לראות סוג מסוייים של נתונים ומקבל אותם בצורה טבלאית. ביצוע פעולות בתחום זה בעייתי בגלל מגבלות רגולציה ולכן עיקר הפונקציונליות של האפליקציה היא בתצוגת מידע רלוונטי במספר מימדים הקשורה לחשבון הלקוח. הארגון פיתוח את האפליקציה בטכנולוגיה הידועה בשם טכנולוגיית פיתוח היברידית למכשירים ניידם (hybrid mobile application). בטכנולוגיה זו משתמשים ביכולת ההיברידית של המכשיר הנייד לפתוח דפדפן ללא שורת הכתובת ולבצע באמצעות הדפדפן את רוב הפעולות הנדרשות - הצגת והזנת טקסט, הצגת תמונות וכד'. ספציפית בטכנולוגיית אפל מדובר על שימוש במוד של דפדפן הספאריי שנקרא UIWebView. ישנן פעולות אשר לא ניתנות לביצוע דרך הדפדפן והן מתבצעות על ידי החלק הבסיסי של האפליקציה (ידוע בכינוייו כחלק ה- native). במקרה זה פותחה יכולת של עדכון הלקוח בצורה יזומה (push notification), כאשר יש עדכון חשוב (לדוגמה מעבר למצב של חריגה באשראי) מקבל המשתמש הודעה במכשיר שמציעה לו לפתוח את האפליקציה.
הייתרון בשימוש בטכנולוגיית הפיתוח ההיברידית למכשירים ניידים חכמים היא האפשרות להשתמש בחלק מקוד האפליקציה בכל המכשירים הניידים. זאת מן הטעם שקטע הקוד שנמצא בדפדפן כתוב ב- html5 הזהה בין כל הפלטפורמות - אפל, אנדרואיד, מיקרוסופט וכד'. זאת לעומת פיתוח native אשר מחייב כתיבה מחדש של כל האפליקציה בנפרד לכל טכנולוגיה של מכשיר חכם.
ובכן, הלקוח כתב את האפליקציה והעביר אותה ל-appstore בכדי שיוכל להפיץ את האפליקציה ללקוחותיו. השקת האפליקציה לסביבה הניידת היתה אמורה להיות מלווה בקמפיין שיווקי מהותי. אולם הסתבר ששלטונות אפל דחו את האפליקציה בטענה שמדובר על אפליקציה שאינה מספיק עשירה. לייתר דיוק האפליקציה לא הועלתה בגלל סיבה 12.3 שעיקרה:

the experience it provides does not differ significantly from the
general experience of using Safari, as required by the App Store Review Guidelines

מאז ועד היום מנסה הארגון לשפר את האפליקציה ולהוסיף תכונות בסביבה הטבעית (כלומר בסביבת ה- native) אך עדיין לא הצליח להבין מה הדרישות המינימליות שאליהן חייבים להגיע בכדי שאפל יאשרו את האפליקציה לשימוש כאשר כל התהליך מתבצע מול שלטונות אפל בחול באמצעות המייל כמעט ללא מגע אישי (המגע האישי היחידי היה באמצעות מוקד שהקימו אפל לתחום זה בהודו). מדובר מבחינת מפתחי האפליקציה בארגון בסיטואציה מתסכלת בלשון המעטה. זאת כאשר במקביל האפליקציה באנדרואיד כבר עובדת אצל לקוחות הארגון כאשר הארגון כבר וויתר על ההשקה השיווקית המהתית.
אין ספק שאפל יצטרכו לשפר את תהליכי אישור האפליקציות הן במימד השירותי והן במימד הטכנולוגי תוך מתן הנחיות מפורטות יותר למפתחים.
עם זאת נשאלת שאלה עקרונית יותר - האם לאפל יש זכות להעלאת דרישות מסוג זה?
איזה זכות יש לאפל להחליט שאפליקציה מסויימת אינה טובה מספיק לשימוש? האם משימה זו אינה מוטלת על לקוחות הארגון אשר יחליטו לפי רוח השוק החופשי בעצמם אם הם רוצים להשתמש באפליקציה או לא? כאמור מדובר על החלטה של אפל שלא לאשר אפליקציות בגלל שחוויית השימוש אינה טובה מספיק ולא בגלל סיבות טכנולוגיות כלשהן (סיכונים באבטחת מידע, העמסת הרשת, העמסת המכשיר הנייד וכד').
הדבר דומה לחברת שילוח יוקרתית אשר אינה מוכנה לשלוח חבילות אשר אינן יפות מספיק או שתוכנן אינן חיובי מספיק! או לחילופין יצרן צבעים שלא מסכים למכור צבע לאומן אשר יצירותיו אינן מספיק אסטטיות לטעמו! על פניו נראה הדבר מקומם ביותר. מצד שני התנהגות מסוג זה מקובלת בשוק בכל מיני תחומים. לדוגמה חנות כלבו יוקרתית אשר משכירה שטח מסחר ליצרן מסויים מבקשת ממנו להסיר מוצרים מהמדף כי אופיים אינו תואם לאופי חנות הכלבו ולסטנדרטים הקבועים בה. זה נראה כבר פחות מקומם למרות שאת היצרן שצריך להסיר את המוצרים מהמדפים הדבר לא ישמח...
הסוגייה מצטצמת לתהייה הבאה- האם כאשר צורכים תכנים או אפליקציות במכשיר סלולרי - האם מדובר על פעילות שהיא מול יצרן התכנים או פעילות מול יצרן המכשיר הסלולרי (או הרשת הסלולרית)? עד כה היה מקובל שפעילות כזו היא שייכת ליצרן התכנים אולם אפל הגדירו שפעילות היא גם בבעלותה. מדובר על התנהגות שונה ממה שהיה מקובל עד כה. ובכל מקרה התוצאות מדברות בעד עצמן - אפליקציות בסביבת אפל (iPhone או iPad) הנן טובות יותר מאפליקציות מקבילות לאנדרואיד. במבחן ה-"תן לילד בן השנתיים לבחור בין iPad או לבין טבלט של אנדרואיד או לבין מחשב pc נייד" אפל מנצחים בגדול (כך מוסרת קולגה שהבן שלה מסרב להתקרב לטבלט שאינו iPad). עם תוצאות כאלה קשה להתווכח.
מצד שני נתח השוק של אנדרואיד ממשיך לעלות בעיקר על חשבון אפל כאשר לקוחות מודעים גם לתכונות הפחות טובות של אפל - לא ניתן להעביר למכשרים אלו קבצים בצורה ישירה אלא רק באמצעות תוכנת ה-itunes ,לא ניתן לשלוח קבצים מסוגים שונים באותה הודעת דוואר (כי לא ניתן לגשת לקבצים ישירות), לא נתן להתקין אפליקציות שלא דרך Appstore וכד'.
לסיכום אפל יצטרכו לשפר את תהליך אישור האפליקציות שלהם ולגבי הגישה ה"מתערבת" בתכנים ובאפליקציות- ימים יגידו אם מדובר על אסטרטגיה מנצחת לטווח ארוך.