הענן פה – אז מה עושים?

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

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

הטמעת תמידית של תהליכים עסקיים ומערכות המידע התומכות בהם

רובם המכריע של הפתרונות המוצעים בענן מבוססים על ארכיטקטורה של multi-tenant והמשמעות היא שכל המשתמשים בעולם נמצאים באותו בסיס של קוד ומסד נתונים ולכן כאשר מתבצע שדרוג – הוא מתבצע לכל המשתמשים בעולם באותו זמן ולא ניתן לדחות שדרוג זה. רוב יצרני הפתרונות בענן מבצעים שדרוג פעמיים בשנה והמשמעות היא שארגונים צריכים (תלוי בגודל השינוי של הגרסה החדשה לעומת הגרסה הישנה) לבצע הטמעה של הגרסה החדשה של המערכת, כולל שינוי של תהליכים עסקיים המתבקשים משינויי המערכת. זאת לעומת המצב הקודם שבו שינויים (אמנם גדולים יותר) היו מתרחשים רק פעם במספר שנים. לפיכך, מאמץ ההטמעה הארגוני אמור לגדול, כאשר הטמעת מערכות הופכת להיות פעולה שהיא יותר on going ולא פעולה שמתרחשת פעם במספר שנים. הגורמים העסקיים צריכים לקבל את העובדה שתהליכים העסקיים משתנים\מתפתחים כל הזמן.

מעבר מ- CAPEX ל- OPEX

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

סייבר ורגולציה בקצב מואץ

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

מבנה ארגוני חדש ושדרוג תהליכי תפעול ללא דריסת ה"ישן"

במאמר הקודם כבר דיברנו על כך שהענן מחייב התארגנות שונה ובניית תהליכים חדשים בין הגורמים הבאים: תפעול תשתיות, רגולציה, רכש ,מטה ה- IT (העוקב אחרי התקציבים ומתעדף משאבים) ואבטחת מידע\סייבר. במאמר גם הזכרנו כלים אשר באים לתת מענה לסוגיות אלו – תחום ה- cloud management platforms. הפעם נשים את הדגש על שילוב הישן עם החדש. לארגונים יש נטייה לבנות צוות ענן המופרד מהצוותים הקיימים בארגון. למרות היתרון במיקוד ובמקצועיות מדובר על מהלך שגוי, מכיוון שבניית צוות נפרד אשר מטפל בענן גורם ליצירת שני מחנות בארגון "ישן" מול "חדש", דבר שמהווה מתכון לכישלון בטווח הארוך. הדרך המומלצת היא לשלב את החדש בתוך הישן – במידת האפשר. כלומר, לדוגמא, צוות הסיסטם יטפל בשרתים בענן וגם בשרתים on prem. צוות ה- DBA יטפל בנתונים גם בענן וגם ב- on prem וכד'. רק האזורים שלא קיימים כלל בסביבת ה- on prem צריכים להיות מטופלים על ידי צוות הענן – דברים כמו ניהול הקשר מול ספק הענן בהקשר של תקציבים, מידת השימוש וכד'.

עד כאן להפעם.

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

מודעות פרסומת
הענן פה – אז מה עושים?

ענן: תמצות המגמות ומצב השוק בישראל

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

  1. Cloud First/ Cloud Only: ככל שעובר הזמן ישנה יותר ויותר פונקציונליות עסקית מתקדמת אשר קיימת אך ורק בענן. (כמעט) כל האפליקציות החדשניות העסקיות המפותחות כעת נמצאות בענן. לגבי אותם פתרונות להם קיימים גם גרסאות ענן וגם גרסאות on premise, על פי תמונת המצב שנמצאת בידינו כעת, החברות מפתחות ומקדמות את גרסאות הענן יותר ויותר לעומת גרסאות ה- on premise אשר "קופאות על שמריהם" ובמקרים הפחות טובים מפסיקות להיתמך. משמעות ניתוח זה היא שארגון אשר ירצה להמשיך ולהשתמש בפונקציונליות עסקית מתקדמת יהיה חייב לעבור לענן באותו האזור ולכן במובנים רבים, בגלל שיקול זה, הענן הוא לא אופציונלי אלא בגדר הכרח. כלל הארגונים המתקדמים יהיו, בדרך כזו או אחרת, בענן.
  2. הענן מספק גמישות ועדכניות טכנולוגית משופרת בעשרות מונים על הגמישות והעדכניות הקיימת בארגוני ה- IT ואף המתקדמים ביותר. כל היכולות הטכנולוגיות החדשניות נמצאות בענן וניתן להתחיל להשתמש בהן על ידי "לחיצה על קליק" (כמעט…). לעומת ארגון מסורתי אשר רוצה להשתמש ביכולות חדשניות: תחילה, עליו לרכוש את הטכנולוגיה החדשה, לאחר מכן להתקין אותה, להטמיע, לתפעל אותה (עדכוני גרסאות וכד'). ולכן ארגונים אשר שואפים להשתמש בטכנולוגיות החדשניות ביותר באופן מהיר עושים זאת באמצעות הענן. אגב, אלטרנטיבה מסוימת לזריזות הטכנולוגית המתקבלת בענן היא הקוד הפתוח שגם הוא מאפשר זריזות גבוהה עקב האפשרות להשתמש ולנסות בפונקציונליות חדשה באופן נוח (ללא רכישה). עם זאת, תפעול הקוד הפתוח (התקנה, קינפוג, עדכון גרסאות וכד') יותר מורכב בסביבת קוד פתוח ב- on prem מאשר בענן ועלול להיות גם יותר מורכב משימוש במוצרים מסחריים.
  3. עלויות באופן כללי ויכולת גידול\קיטון בפרט. ישנם מספר לא מבוטל של מקרים שבהם הענן יכול לספק שירותים זולים משמעותית מאשר הארגון המסורתי. עם זאת, יש גם מקרים שבהם הענן לא ייתן שירות זול יותר מאשר הארגון המסורתי.

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

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

המוביל ביניהם הוא Amazon – AWS. AWS היו הראשונים בתחום של IaaS ו- PaaS, הם הגדולים בתחום מבחינת הכנסות מספר שירותים ומבחינת היצירתיות בתחום. לדוגמה, AWS היו הראשונים שיצאו עם שירות serverless (בשם Lambda). מהות השירות (אשר כעת קיים גם ב- Azure וב- GCP) הוא קוד שמחכה ל- trigger כלשהו ומתבצע כאשר ה- trigger מתקיים. התשלום מתבצע לפי מספר הפעמים שהקוד רץ (ולא מחייב שימוש ותשלום לפי שרת). דוגמה נוספת למובילות של AWS היא העובדה שכל הפתרונות החיצוניים אשר מבצעים אופטימיזציה של עלויות ענן (כלומר מסתכלים על השימוש בענן וממליצים המלצות כגון "במקום 5 שרתים גדולים כדאי לעבור ל-20 שרתים קטנים") יודעים לעבוד מעל AWS אבל לא תמיד על שאר העננים. כלומר, AWS הוא המוביל.

Azure של מיקרוסופט גם הוא נחשב בין המובילים בתחום עקב ההשקעות הגדולות של מיקרוסופט בתחום (שאגב תומכת ביישום כל הטכנולוגיות בענן שלה כמו לינוקס ולא רק ב- windows) וגם עקב הנוחות של ארגונים להשתמש בסביבה המוכרת להם – לדוגמה שכפול של Active directory מתוך הארגון ל- Azure מתבצע באופן שהוא seamless. אגב, מיקרוסופט הוציאו לאחרונה פתרון חדשני AzureStack שהוא יישום חלק מיכולות הענן הציבורי Azure בתוך הארגון על ידי מכונה שמתנהגת כמו Azure הציבורי. פתרון זה יכול להקל מאוד על מעבר ארגונים לענן.

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

עננים בולטים נוספים מעבר לשלישייה הפותחת הנם הענן של אורקל והענן של IBM. אורקל משקיעה רבות בענן שלה, רוכשת חברות רבות, הן חברות SaaS והן חברות המספקות טכנולוגיות ענן אחרות (לדוגמה רכישת ravello הישראלית). מן הסתם לאורקל יתרון בהרצה של טכנולוגיות מסורתיות כמו oracle dbms , יתרון בהפעלת bare metal ועוד. IBM בצעו רכישה של softlayer אחד העננים המתקדמים שכלל יכולת ייחודית של bare metal (הקמה ושימוש בשרתים פיזיים ולא רק וירטואליים). וכמו אורקל גם היא מאפשרת חיבור מתקדם בין מה שרץ בתוך הארגון לבין מה שרץ בענן הציבורי.

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

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

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

כלומר הענן מחייב התארגנות שונה ובניית תהליכים חדשים בין הגורמים הבאים:

  1. תפעול תשתיות
  2. רגולציה
  3. רכש
  4. מטה (העוקב אחרי התקציבים)
  5. אבטחת מידע\סייבר

ישנם גם כלים אשר באים לתת מענה לסוגיות אלו. מדובר על תחום cloud management platforms עם יצרנים כמו rightscale scalr cliickR (cisco) cloudform redhat ועוד. אנחנו ממליצים לארגון ללמוד סוגיות אלו (וכמו כן, לא לבצע רכש של כלים כאלה כעת).

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

ענן: תמצות המגמות ומצב השוק בישראל

רשמים מכנס re:Invent של AWS

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

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

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

מגמה מרכזית שהודגשה בכנס היא תחום ה- AI – Artificial Intelligence.  AWS הרחיבו באופן מהותי את הצעת הפתרונות שלהם בתחום בעיקר סביב machine learning ותשתית לבנייה של Bots. שירות ראשון בתחום זה הנו AWS Polly אשר מתרגם טקסט לדיבור אנושי ב-24 שפות (עברית לא נמצאת בין שפות אלו). שירות שני הוא Amazon Recognition אשר מנתח תמונה וחוזר עם פרמטרים מובנים כגון "האם מרכיב משקפיים", "האם גבר או אישה" "האם שמח" וכד'. שירות מהותי נוסף הוא Amazon Lex  וזהו שירות ניתוח טקסט – ה"מוח" שמבין מה המשמעות (לפי קונוטציה) ומקבל החלטה. זהו הרכיב החכם שנמצא מאחורי Amazon Alexa המותקן ב- Amazon Echo הרמקול החכם שמקשיב ומבצע פקודות.

כחלק ממגמת ה- AI הכריזה AWS גם על שירותי מחשוב חדשים המאפשרים ביצועים משופרים הנדרשים במיוחד לשלב הראשוני של "לימוד" האלגוריתמים של machine learning. מדובר על שימוש במעבדים גרפיים (GPU) ואפילו על תכנות חומרה באמצעות תכנות מעבדי FPGA.

מגמה נוספת היא הרחבת יכולות בתחום ה- IoT. ב AWS הכריזו על רכיב תוכנה בשם AWS Greengrasse  אשר מותקן על התקן ה- IoT על ידי היצרן. רכיב תוכנה זה מתקשר באופן טבעי לשירות ה- AWS IoT platform ואפילו יכול לבצע חלק ממשימות החישוב בהתקן עצמו. בכך מצהירה AWS שהיא מקבלת את העובדה שלא כל החישובים יכולים להתבצע בענן המרכזי – חלקים צריכים להתרחש בסביבת ההתקן (ב- Edge).

המגמה השלישית שנזכיר כאן היא השקעה גדולה יותר של AWS לכיוון ארגוני ה- enterprise. סממן ראשון למגמה זו היא ההסכם האסטרטגי עם VMWARE. ארגון יוכל להעביר שרת בין סביבת ה- vSphere המותקנת אצלו לענן של VMWARE שנמצא ב- AWS. מדובר על הורדת מחסום גדול לצוותי התשתיות אשר יכולים לנצל את יכולות הענן ללא ביצוע שינוי בתשתית (שינוי טכנולוגיית hypervisor) וללא לימוד של טכנולוגיה חדשה  תוך ניצול מלא של ההשקעה הקיימת שלהם בהקשר של ידע ואף בהקשר של רישוי.

נדבך נוסף המצביע על השתדלות AWS לכיוון ה- enterprise הוא האפשרות להריץ את גרסת הלינוקס של AWS באתר הלקוח כך שבעתיד יוכל להעביר את המערכת לענן ללא צורך לבצע התאמות ובדיקות (בהקשר מערכת ההפעלה).

והדבר הכי משמעותי בהקשר זה הנם הפתרונות המאפשרים להעביר כמויות מידע גדולות מתוך ה- enterprise לענן. בכנס הוכרזה גרסה חדשה ובעלת קיבולת גדולה יותר של ה- AWS Snowball Edge – סוג של מזוודה שלתוכה מעתיקים מידע מתוך הארגון. ואז שולחים את המזוודה (המידע בה מוצפן) ל- AWS. פתרון שני בתחום זה הוא ה- AWS Snowmobile שהוא משאית ענקית המאפשרת העברה של 100 PETA  של מידע (בכדי לתת סדר גודל, אני מעריך שבישראל נמכר פחות שטח אחסון לארגוני enterprise בשנה!!).

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

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

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

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

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

– פיני כהן.

רשמים מכנס re:Invent של AWS

שינויים בכישורים, בהכשרות ובמבנה של מחלקת התפעול והתשתיות

 

  • כ"א בתחום התשתיות (אחסון, שרתים, תקשורת DC) יקטן בשיעור של 20%-25%
  • באופן יחסי צוות הסיסטם יגדל, צוות האחסון יקטן
  • על כל חברי הצוות להיות מנוסים בתכנות ולכן יש לגייס כ"א חדש ולהכשיר את כ"א קיים
  • צוות הענן יהיה חלק מצוות התשתיות הכללי

הדרישות העסקיות החדשות, המעבר לענן הציבורי והפרטי וההבשלה ההדרגתית של טכנולוגיות כגון ענן ציבורי, ענן פנימי, SDN, SDS, Containers-Docker ועוד, גורמות לשינוי מהותי בהתנהלות צוותי התשתיות והתפעול.

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

הפוטנציאל של שימוש בענן פנימי \ אוטומציה הוא גדול עד לפקטור של פי 10. לדוגמא, חברת אינטרנט ציינה שלפני 10 שנים (עוד לפני וירטואליזציה\DEVOPS, כאשר עבדו עוד על solaris) זמן ההפעלה/הקמה של 100 שרתים לקח בסביבות 3 חודשים. כעת מבצעים זאת ב- 3 שעות! עם זאת, מספר האנשים בצוות התשתיות\תפעול לא ירד כי כעת מבצעים פי 10 יותר פעולות, כלומר הם מהווים enabler עסקי באופן יותר משמעותי.

אולם על אף הפקטור של פי 10 שהוזכר כאן, כאשר מדברים על ארגוני enterprise, נראה שכאשר מיישמים ענן פנימי אמור להיות פקטור של חסכון של כ- 20%  – 25% ממספר האנשים, כאשר:

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

מבחינת מבנה ארגוני ישנן מספר גישות:

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

גישה אחרת מדברת על שמירת המבנה של אחסון-סיסטם-תקשורת אך מעלה את הצורך להוספת גוף מנחה-מקשר גם בין גורמי התשתיות וגם בין הפיתוח לתשתיות, שניתן לכנותו גוף Devops או "תשתיות Devops- ענן". בתוך כל צוות ספציפי (לדוגמה אחסון) יהיו אנשים אשר יטפלו באחסון "הישן" ואחרים באחסון "החדש" (כלומר ב- SDS). אנשי ה"ענן" מתוך כל הצוותים יוגדרו כ- COE – center of excellence  או "חוליית ענן" ויימדדו על פי הצלחתם.

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

לדוגמה:

  • לבנות "חוליית תקלות" משותפת לצוותים אשר מטפלת בתקלות באופן מאוחד. כלומר, כאשר יש תקלה ב- DC תמיד מתכנסת "חוליית התקלות" ומטפלת ביחד- לא מטפלים בנפרד האחסון, הסיסטם והתקשורת.
  • לבנות "חוליית התקנות" אשר אחראית באופן משותף על התקנה של פרוייקטים חדשים.
  • לבנות "חוליית design" אשר אחראית באופן משותף על design של מערכות חדשות (ביצוע sizing לפרויקטים, הכוונה בטכנולוגיות וכד').
  • לבנות "חוליית בדיקות" אשר אחראית באופן משותף על בדיקות של מערכות שנכנסות לייצור.
  • במידה ויש מערכת גדולה במיוחד, לבנות "חוליית מערכת" אשר תהיה אחראית באופן משותף על המערכת.
  • לבנות "חוליית DR" אשר אחראית באופן משותף על נושא ה- DR ב- DC.

וכד'. כלומר יש להתייחס לאחסון-תקשורת DC וסיסטם באופן מאוחד.

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

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

שינויים בכישורים, בהכשרות ובמבנה של מחלקת התפעול והתשתיות

Blockchain – מה למה ואיך?

Internet of value הנו שם למהפכת אינטרנט חדשה. היום ניתן לקחת כל טרנזקציה או כל ערך אחר ולהעבירו בין האנשים במהירות של העברת המידע.  בנוסף, Internet of value מקדם את תפיסת האקוסיסטם (ecosystem) בו מתנהלים העסקים בעולם הדיגיטלי. הכוונה לקהילה של אנשים ועסקים, הפועלים יחד, ומרוויחים משיתוף הפעולה הרבה יותר, אילולא היו פועלים לבדם ובנפרד.  טכנולוגיית הבלוקצ'יין (Blockchain) תאפשר לעסקים ליצור ecosystem לעסקים, שם יוכלו חברים להחליף פריטים בעלי ערך באמצעות ספר חשבונות (ledger), בעל תוכן זהה ומסונכרן בין כולם, ואשר נמצא בבעלות של כל חבר.

Bitcoin

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

סאטושי נקאמוטו (Satoshi Nakamoto), ממציא מטבע ביטקוין, פרסם ב-2009 מאמר בשם "מערכת שיתופית לכסף אלקטרוני " (Bitcoin: A Peer-to-Peer Electronic Cash System ), המדבר על מערכת מרכזית של תשלומים מאדם לאדם ללא גורם מרכזי. יחד עם המאמר פורסם קוד לתוכנה אשר מהווה בסיס לרשת הבלוקצ'יין של ביטקוין.

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

Block and blockchain

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

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

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

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

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

מהו בלוקצ'יין

  • ארכיטקטורה מבוזרת עם תחנות המורכבות מחברים באקוסיסטם.
  • Shared ledger (בסיס נתונים מבוזר) המהווה מקור אמת אחד לכל מי שעושה טרנזקציות blockchain.
  • Smart contract הכולל נכס דיגיטלי (מוחשי או לא) וסט של כללים להעברת הנכס לבעליו החדש. חוזה חכם הנו חוזה אוטומטי, אוטונומי שלא ניתן לשינוי. לדוגמא חוזה גידור, בו יש הימור בין שני אנשים על ערך שער הדולר בתאריך 1/1/2017. מגדירים את התנאים של חוזה גידור ומטמיעים אותם בבלוקצ'יין. בתאריך 1/1/2017 בלוקצ'יין באופן אוטומטי, ואוטונומי, על פי התנאים שקבענו מראש אותם לא ניתן לשנות, יפנה לגורם חיצוני (אורקל) – שירות חיצוני הקובע מה שער הדולר באותו היום, החוזה יבדוק מה שער הדולר ויחלק את הכספים שהופקדו מראש למי שניצח בהתערבות.
  • קונצנזוס מבטיח כי shared ledger אכן מקור אמת אחד, מדויק וזהה לכולם. קונצנזוס, בין אם הוא בנוי על שיטת Proof of Work ובין אם הוא בנוי על שיטה אחרת (proof of stake), מבטיח כי כל הטרנזקציות הנכנסות ל shared ledger (ספר חשבונות ראשי) הן מוסכמות ע"י כולם, זהות בהעתקים של כולם, ללא גורם מתווך מרכזי כלשהו.

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

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

דוגמא לבלוקצ'יין של רכישת רכב:

  1. נכס בעל ערך (רכב) אותו ניתן להפוך לנכס דיגיטלי ע"י הצגת תעודת בעלות וזיהוי חד ערכי של הנכס (מספר שלדה של הרכב)
  2. Ecosystem – קונה, בנק, משרד התחבורה, חברת ביטוח, דלקן
  3. Ledger – data base או ספר חשבונות שקוף לכולם עם היסטוריה כרונולוגית של הרכב מתי נקנה, ע"י מי, מתי אושרה ההלוואה, ממתי הביטוח
  4. חוזה חכם – ברגע שקיבלתי את הבעלות על הרכב – נפתח אוטומטית חוזה ביטוח ובקשה להתקנת דלקן

למה בלוקצ'יין?

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

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

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

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

בלוקצ'יין פרטי

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

דוגמאות לבלוקצ'יין אחרים, מעבר לביטקוין:

·        סחר בינלאומי. חברת WAVE יישמה את שטר המטען על בלוקצ'יין –Wave | Bill of Lading with the BlockChain

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

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

אם היה קיים בלוקצ'יין המחבר בין יצרני הרכב לבין מפעלי החלקים לבין המוסכים ניתן היה להגיע בזמן קצר למפעל המבוקש ולקבל את החלק החליפי. בנוסף בעולם של Internet of things היה ניתן לראות ישר, כי לחלקים הספציפיים הללו (אשר נוצרו בתאריך X במפעל Y) קיימת בעיה ביצור ופתרון לבעיה הוא Z.  קיים חיבור טבעי בין blockchain, לענן, ול Internet of things.

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

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

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

Blockchain as a Service

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

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

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

IBM  מציעה שירות של garage blockchain (בישראל garage נייד), שם ניתן לנתח use case מתאים, לתרגמו למושגים של בלוקצ'יין, לעשות design thinking יחד עם המומחים, ולהריץ גרסה ראשונה של אפליקציה או פתרון של בלוקצ'יין על הענן של IBM.

אתגרים:

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

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

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

ולסיכום

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

Blockchain – מה למה ואיך?

על LinuxONE

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

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

הפלטפורמה הנה שילוב של חומרה ותוכנה המוכנה מראש לעבודה – מה שנקרא בשוק כ- converged infrastructure במימדים גדולים (לעומת hyperconverged המדברת על שילוב של חומרה קטנה במימדים קטנים ואשר מתחברים אחד לשני).

נראה ש- IBM בצעה השקעה מהותית בפלטפורמה זו. בין הייתרונות הישירים ניתן להזכיר את כוח החישוב הגדול – מדובר על המעבדים המהירים ביותר בשוק (5 GHZ) , שימוש ב- 4 רמות של memory cache,  תמיכת חומרה יעודית הן ב- IO והן בביצוע משמימות קריפטוגרפיות.  מדובר על אחת מהמכונות החזקות בשוק, במיוחד למשימות שדורשות הצפנה והרצה של מסדי נתונים מהדור המתקדם. תכונות נוספות של הפלטפורמה היא מערכת אנליטית עצמית אשר מקבלת נתונים על ניצול המשאבים ובריאותם ויכולה לתת המלצות ואף לבצע פעולות הקשורות להרצת המשימות וזמינות המערכת (כאשר מתקבלת התראה המערכת מעבירה יישום מרכיב פיזי אחד לשניה – לפני שהתרחשה התקלה).

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

אכן נראה ש-יבמ מכוונת כאן לחברות מהדור החדש ולמערכות מתקדמות וזאת גם לפי הטכנולוגיות המתקדמות שנתמכות כאן (רשימה חלקית): nodejs scala erlang ruby tomcat ruby python  puppet chef docker chef Openstack vreliaze   mariadb mongodb postgresql Cassandra couchdb  oracle db2 mysql Hadoop infosphere  spark.

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

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

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

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

על LinuxONE

STKI MARKET PULSE – עדכונים מהירים על קצה המזלג:

הדבר הבא באנליטיקה: Machine intelligence

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

אך היכן נמצא השוק ביחס להתפתחויות טכנולוגיות אלה? טכנולוגיות Machine learning כבר די בשלות, ברמות שונות. ישנן טכנולוגיות בסיסיות אשר זמינות ופותחות החוצה את שירותיהן בתצורת APIs, יש מתקדמות יותר. וישנן גם אפליקציות – וכאן החלק המעניין באמת. במסגרת כנס ביג דאטה ו Machine Learning,Shivon Willis (החוקרת את התחום ב- Bloomberg), יצרה מפת טכנולוגיות מעניינת, אותה היא מחלקת לטכנולוגיות; אפליקציות המיועדות לשינוי חיי אנשים; תעשיות; Enterprises; כלים משלימים ועוד חלקים המרכיבים את ה Eco system הזה, שכמעט כולו מורכב מסטארטאפים. אבל לא רק, גם ספקים כדוגמת מיקרוסופט (יכולות ML ב Azure), אמאזון Machine Learning, היכולות הקוגניטיביות, ספקי אנליטיקה כדוגמת SAS ועוד.

שורה תחתונה: בקרוב כולנו נרגיש את ההשפעה של כלי Machine Learning בתחומים שונים, כאשר בתחומי ה-IT התחום הראשון בו ארגונים יוכלו להתחיל ליהנות מיכולות אלה יהיה תחום האנליטיקה, במיוחד פרויקטים חדשניים באנליטיקה ו – Big data analytics בהם לאנליסטים ו Data Scientists "מתחילים" אין תמיד מספיק ניסיון לדעת איזה מודל אנליטי מתאים לאיזו בעיה עסקית, טכנולוגיות אלה יוכלו לסייע בתהליך חשוב זה ולקצר את עקומת הלמידה, שהנה מאוד משמעותית כיום ומעכבת time to market. אנו ממליצים לחפש יכולות ML בכלי האנליטיקה שארגונים בוחנים כיום.

 Internet of Things

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

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

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

תיבות דואר בענן כמשל לענן – פוטנציאל גדול אך מציאות מורכבת

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

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

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

פידבק נוסף דיבר על מצבים שבהם מגיעים למגבלות בענן. תיבת דואר בענן מוגבלת למשלוח של 30 הודעות מייל בדקה או 10K הודעות ביום. אין אדם שמגיע או אפילו מתקרב למגבלות אלו אולם תיבת דואר מתוך אפליקציה (ERP\CRM) או תיבת דואר ארגונית המספקת הודעות ארגוניות (תקלות בארגון, אירועים חשובים וכד') מגיעה בקלות למגבלות אלו ולכן נדרשת התאמה מיוחדת ושינויים באפליקציה כאשר עוברים לענן.

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

The Israeli Privacy Data Dance – Opportunity or Difficulty?

Israel's Privacy Protection Law states that a citizen's personal data cannot be exported to a country with a lesser level of protection than that guaranteed by Israel. On October 6th, the European Court of Justice (ECJ) decided to invalidate the Safe Harbor Program between the EU and US.  The European Court of Justice held that the U.S.-EU Safe Harbor Program failed to provide adequate protection for EU citizens. Based on that decision, the Information and Technology Authority (ILITA), Israel's data protection authority revoked on October 19th its prior authorization for data transfers from Israel to the U.S. based on the U.S-EU Safe Harbor Program certification.

This may create an opportunity for Israeli companies, since the European Commission's 2011 decision remains in effect, the ECJ decision may create a competitive advantage to companies conducting processing or storage activities in Israel, as these companies can continue to receive data from Europe without the uncertainty now inherent in EU-US data transfers. Consequently, Israeli companies will need to find an alternative legal basis for transferring personal data to the U.S., and could experience an “uncomfortable transition period,” according to Limor Shmerling, ILITA's director of licensing and inspection.  “It's too early to tell how the market will be affected and how practices may need to be changed,” she said, adding that the authority is “considering the implications of the new legal status and will further address the subject accordingly.”

This may also create a challenge for local operators of multi-nationals including large local operations of multi-nationals such as IBM, Intel Corp., Microsoft Corp., Google Inc., Facebook Inc. and Hewlett-Packard Co., as well as Israeli “unicorns” such as Waze, Wix and IronSource., according to a statement by the U.S.-based International Association of Privacy Professionals (IAPP), “the decision could pose a significant barrier to data flow from Israel's surging technology sector,”

“Since the Safe Harbor arrangement is currently invalid under European law, and as long as there is no other valid arrangement or another formal decision of the European Union (EU) with respect to the transfer of data from Europe to destinations in the United States, database owners who wish to transfer personal data from Israel to entities in the United States are therefore required to assess whether they can base the data transfer on another of the derogations determined in the regulations,“ the ILITA said in its decision.

The EU's recognition of U.S. Safe Harbor certification, combined with its 2011 granting of “adequacy” status to Israel under the EU Data Protection Directive, allowed personal data to flow freely between the EU and Israel, and on to U.S. companies on the Safe Harbor certification list.

The Safe Harbor system has been widely used to legitimize the outsourcing of services by EU-based companies and their commercial partners to U.S.-based cloud or software-as-a service (SAAS) providers, and to facilitate intra-group data-sharing among entities with both U.S. and EU operations.  Although this has not had the desired effect in Israel and this new stance by ILITA goes hand in hand with the new Israeli Cloud Banking Regulation 357 stating that core data cannot be in the cloud.

It added, however, that current Israeli business models could be affected, including Israeli companies with European affiliates that previously relied on the Safe Harbor arrangement to transfer data to the U.S., as well as Israeli companies outsourcing storage or processing activities to U.S. service providers or affiliates that include information on European customers, in which case they may need to amend their customer agreements to include authorization for the transfers.

Bottom Line: Know your options and plan accordingly.

STKI MARKET PULSE – עדכונים מהירים על קצה המזלג: