על תקשורת יעילה ושאלת שאלות

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

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

וזה אגב הפוסט המקורי אליו הוא מתייחס:

https://www.linkedin.com/feed/update/urn:li:activity:6559503027663888384

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

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

  1. אם למשימה יש דד-ליין אז כותבים את הדד-ליין באופן ברור בראש המייל כי הרבה החלטות אחרות נגזרות מהדד-ליין
  2. לא שולחים מייל עם נושא כללי כמו "שאלה" או "הצעת מחיר"
  3. לא שולחים מייל עם מיליון אנשים בשורת ה To:, אל מי המייל מיועד? מי לדעתכם צריך להגיב\לפעול?
  4. גם מיליון אנשים בשורת ה Cc: זה לא תמיד חכם, האם באמת כל המכותבים צריכים להיות מכותבים?
  5. בדרך כלל התגובה הנכונה היא לא Reply All
  6. היה כבר פינג-פונג-פינג-פונג? תרימו את הטלפון במקום לענות למייל שוב
  7. אם המיל מכיל יותר מנושא אחד צריך לוודא שההפרדה בין הנושאים ברורה ואולי כדאי מראש לפצל מיילים עם שורת נושא ברורה (בהתאם הערה מספר 1)
  8. אין לצאת מנקודת הנחה שמקבל המייל יהיה סקרן מספיק בשביל לגלול למטה בשרשור
  9. אם נעשה שינוי בתוכנית אז מפיצים תוכנית חדשה כדי שלכולם יהיה את אותו הדבר מול העיניים

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

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

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

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

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

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

שלכם תמיד,

ניר מליק

רברסים – לא הכרתי אותם קודם ושווה להכיר

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

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

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

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

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

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

מצאתי גם מקומות ביקורתיים כלפי השיטה, מקומות שטוענים שאכן מדובר באגדה אורבנית ושאין דבר כזה בעצם. פוסט הביקורת הזה מציג עקרונות מקבילים וקורא לזה blame aware כלומר מכיר בזה שזה טבעי לבני האדם לחפש אשמים וקורא לנו להיות מודעים לזה ולקבוע מעין קוד התנהגות לאיך אנחנו מתקשרים ודנים בזה בצורה פרודוקטיבית יותר. אהבתי במיוחד את הקריאה שלו לתת ל post mortem מקום ראוי, הוא קורא לזה to be deliberate, וזאת בניגוד לנורמות נפוצות בהם תחקירי אירוע נדחקים הצידה לטובת כמעט כל דבר אחר שקורה בארגון, הוא קורה לתת לזה עדיפות ולקיים את התחקיר בסמוך למועד האירוע, ככל שחולף הזמן הטעם לבצע תחקיר בכלל יורד.

ההרצאה האחרונה שאני רוצה לספר לכם עליה היא ההרצאה של  שחר קידר מהכנס של 2018 בכלל

שהיא הרצאת תגובה להרצאה של יפתח בר מהכנס של 2017.

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

זה הכל לפעם,

אשמח לשמוע מה דעתכם,

שלכם,

ניר מליק

נגמר לי המוג'ו, מזל שאינפינידט מחפה עלי!

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

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

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

https://www.crowdchat.net/chat/c3BvdF9vYmpfMjk3Mg==

אחד הדברים המגניבים שכלולים בהכרזה הנוכחית הוא פתרון Active/Active אמיתי שמאפשר להתקין שתי מערכות אחסון בשני מיקומים גיאוגרפיים שונים ולבצע קריאה וכתיבה של מידע באותו ה Volume בשני האתרים בו זמנית. כמו כל דבר באינפינידט, לא צריך לרכוש רישוי נוסף עבור הפיצ'ר הזה והיות ומדובר ברפליקציה מובססת IP לא צריך לרכוש חומרה נוספת על מנת ליישם את הפתרון, רק שתי מערכות אחסון וקו IP  ביניהן. אם קו התקשורת שלכם בין המערכות מהיר מספיק, ושני האתרים קרובים מספיק בשביל לא לייצר Latency נוסף, נניח שתי קומות של אותו בניין או שני בניינים באותו הקמפוס, אפשר לבצע Sub ms IOps על גבי פתרון Active/Active אמיתי, הרפליקציה עצמה לא מוסיפה Latency מורגש!

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

בנוסף, לטווח הארוך יותר, הכרזנו על תפיסת ה Elastic Data Fabric שלנו שתאפשר לכל לקוח לנהל ולשלוט במידע שלו על פני מערכת אחסון אחת או יותר, בחדר השרתים שלו, באתר אירוח חיצוני ועל גבי שירותי הענן הציבוריים הגדולים. כתבתי כאן הרבה על יכולות ה Hybrid של נטאפ ופיור מצד יצרניות האחסון ושל אמזון מצד ספקיות הענן על מנת לגשר על הפערים בין מערכות On Prem ופתרונות ענן וההכרזה הזו שלנו היא חלק מהמענה שלנו לאתגר הזה. סיפרתי לכם בעבר על פתרון ה Neutrix שלנו כאן וכאן שהיה בעצם הצעד הראשון שלנו בתחום, צפו לעוד בקרוב!

בנוסף לאקטיב-אקטיב ול Elastic Data Fabric הכרזנו גם על שיפור ביצועים משמעותי מאד, אנחנו מסוגלים היום לספק 2M IOps בזמני תגובה של sub ms, קפיצה גדולה מאד מ 1.4M רק בסוף השנה הקודמת ובנוסף הגדלנו את ה Throughput שלנו מ 15GB ל 25GB וכאילו כל זה לא מספיק, השקנו גם שירות חדש שנקרא InfiniVerse שהוא שירות ניטור וניתוח מבוסס AI שאוסף מידע על מערכות האחסון של הלקוח ומסוגל לתת לו התראות בזמן אמת על נפחים, ביצועים, בריאות החומרה שלו, שדרוגי תוכנה מומלצים וכל מני דברים כאלו אבל הדבר המגניב באמת הוא התראות ממוקדות על שינויים בזמן אמת במצב המערכת שלו כמו למשל, אם אנחנו רואים ירידה חדה ומהירה ביחס הדחיסה על מערכת מסויימת, אנחנו מסוגלים להראות את זה ללקוח בזמן אמת, במקרה הטוב זה אומר שהלקוח שינה באופן יזום את סוג המידע שהוא מאחסן, נגיד עבר מקבצי טקסט לקבצי תמונה שכמובן נדחסים פחות, במקרה הרע זה אומר שהלקוח נמצא כרגע תחת מתקפת קריפטו כל שהוא שמצפינה לו את המידע וכדאי לפעול מהר לטפל בזה. לא רע הא?!

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

שלכם,

ניר מליק

bikeshedding , ESXi on ARM and keeping the momentum

bikeshedding

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

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

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

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

ESXi on ARM

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

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

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

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

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

Momentum

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

וג'סי פראזל ענתה:

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

שלכם כמו תמיד,

ניר מליק

חדר השרתים לא ימות בקרוב

זוכרים שבפוסט הקודם שלי הזכרתי את ה Snowball Edge החדש? אם כן אז אתם בטח זוכרים גם שאמרתי שזו דוגמא לאפשרות לגשר על הפער בין חדר השרתים והענן, בין המחשוב המקומי ומחשוב הציבורי המבוזר. מסתבר שמאוחר יותר באותו היום ממש שפרסמתי את הפוסט, אמזון הכריזו גם על מוצר חדש בעל השם המלחיץ AWS Outposts. אמזון נכנסת חזק אל המחשוב המקומי ומאפשרת שתי חלופות, הראשונה למי שרוצה להשתמש בשכבת הניהול של VMware והשניה מיועדת למי שרוצה חווית ניהול זהה לניהול AWS בענן הציבורי.   ההכרזה הזו היא תזכורת לכמה דברים, הראשון הוא שהמחשוב המקומי לא מת, יש עדיין סיבות טובות להחזיק חדרי שרתים והשניה היא שהענן הוא לא רק "להיפטר מהברזלים" אלא גם מודל תפעול ותמחור, הטמעה של פתרון ענן פרטי מנוהל מאפשרת ללקוחות לצרוך שירותי מחשוב במודל ענן וזה אמור להיות החלק המעניין, לא איפה הCPU רץ אלא איך צורכים את משאבי ה CPU, איך משלמים עליהם, איך מתחזקים אותם ואיך מקבלים עוד מהם אם צריך.

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

שימו לב להגדרה של Amazon ל serverless

" Serverless is the native architecture of the cloud that enables you to shift more of your operational responsibilities to AWS"

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

וורדלי מביא כאן הגדרה רחבה יותר:

an event driven, utility based, stateless, code execution environment

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

utility based – אנחנו משלמים רק על מה שאנחנו צורכים

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

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

גרטנר, עננים, פלטפורמות ולמות

דילמה מוסרית

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

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

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

תקראו עד הסוף היום, על תעצרו במונטי פייטון בסדר?

גרטנר

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

gartner

Pure מכריזים על פתרון חדש לעולם ה hybrid cloud

לאחרונה קצת ניגחתי את Pure והנה שוב הזדמנות לפרגן במקום. בשבוע שעבר הם הכריזו על פתרון חדש  שמאפשר להריץ את מערכת ההפעלה שלהם גם על גבי תשתיות AWS וככה לספק חוויה דומה (אותם API) באתר הלקוח או בענן. יכולת זו מצטרפת ליכולת הקיימת לבצע טירינג של סנפשוטים לענן (יכולת שנקראת אצלם CloudSnap) שדומה ליכולת של NetApp שנקראתFabric Pool.

כתבתי כבר על החשיבות של hybrid cloud ושל data mobility כמו גם data governance. הסיפור של פיור מצטרף כאן לסיפור ה Data Fabric של NetApp וכמובן לסיפור ה Neutrix שלנו באינפינידט. הפער בין חדר השרתים והענן הוא האתגר הגדול של עולם ה IT כי לפחות בעתיד הנראה לעין גם פתרונות On Premises וגם פתרונות Cloud יחיו זה לצד זה ולכל אופציה יהיו היתרונות והחסרונות שלה.

אמזון סנובול אדג' חדש

גם באמזון, שיצרו למעשה את עולם ה Public Cloud ומובילים אותו בבטחה גם מבחינת הגודל וגם מבחינת החדשנות, רואים את הפער ומספקים פתרונות שונים כדי לצמצם אותו. כתבתי בעבר על שירותי המיגרציה של גוגל והזכרתי שם את ה Snowmobile של אמזון והשבוע במסגרת RE:Invent הם הכריזו על מוצר חדש באותה סדרה או למעשה בסדרה הקטנה יותר שנקראת Snowball Edge. המוצר החדש כולל יכולות מחשוב חזקות יותר ותמיכה בכרטיסי האצה גרפיים GPU. הסדרה הזו למעשה תוקפת את הפער מהכיוון ההפוך ומאפשרת לפתח כלים בענן ואז "להביא" אותם, פיזית, בתוך מארז מוגן ומוקשח, אל חדר השרתים או איפה שצריך אותם כדי שירוצו בפועל.

פלטפורמות ובהמות משא דרום אמריקאיות

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

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

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

יש כאן למשל כלי שכל חברה, או מחלקה בתוך החברה, יכולה לאמץ לעצמה גם בלי לזעזע את כלל המבנה הארגוני או להוציא תקציבים גדולים, הכלי נקרא 5 הלמות. סתם הוא נקראה 5 הלמה, the 5 whys, ובדוגמא שלפנינו, אמזון משתמשת בכלי הזה כדי לבצע תחקיר למציאת שורש הבעיה, Root cause Analysis. מספרים לנו שעובד אחד פצע את האצבע על מסוע.

למה הוא פצע את האצבע? כי היא נתפסה במסוע

למה האצבע נתפסה במסוע? כי העובד ניסה לתפוס את התיק שלו

למה הוא ניסה לתפוס את התיק שלו? כי התיק היה מונח על המסוע והמסוע פתאום התחיל לפעול

למה התיק היה על המסוע? כי העובד השתמש במסוע כשולחן

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

פתרון לבעיה – לוודא שיהיו שולחנות במיקומים נחוצים או לפחות שולחנות מתקפלים ניידים זמינים למי שצריך אותם

הגירה של שירותי קבצים בשרת חלונות 2019 החדש

בתחילת הפוסט הזכרתי שהייתי בקוריאה בשבוע שעבר ואחד הדברים שדיברנו עליהם הרבה היה מיגרציות. לקוחות בכל העולם רגילים שפרויקט מיגרציה של סטורג' זה פרויקט גדול מסובל ויקר והרבה פעמים גם מסוכן. עבור רובם זה לא נכון עבור ככה הם רגילים ובשוק מסורתי כמו קוריאה זה נכון כפליים. דיברנו הרבה על העובדה שעם כלים כמו VMware vSphere Storage vMotion או Live Migration המקביל ב Hyper-V, לקוחות בכלל לא צריכים עזרה בשביל להעביר באופן קל וחלק את מרבית חדר השרתים שלהם ממערכת אחסון אחת לשנייה.

כמו מהשמיים גיליתי שאפילו מיגרציה של קבצים משרתי Windows זה לא מה שהיה פעם. מיקרוסופט תומכת היום במיגרציה של קבצים משרתי Windows ישנים, אפילו שרתי 2003 שכבר לא נתמכים רשמית, אל שרתי Windows 2019 פיזיים או וירטואליים או לשירותי הקבצים של Azure באמצעות כלי מובנה שנקרא Storage Migration Service או SMS וכן, השירות הזה מובנה בשרתי 2019 ושרתי WAC (Windows Admin Center).

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

טוב, יצא פוסט עמוס מכל טוב,

שלכם כמו תמיד,

ניר מליק

סופרמן, אנגלית, דקדקנות מיותרת והצפנות

אני מדבר שתי השפות

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

מחר אני מתחפש לסופרמן

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

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

 

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

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

גדילה זה לא תמיד חיובי

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

takethemoneyandrun

זמינות חלפים ושאלות מיותרות

היום שאל אותי לקוח קוריאני מה ה MTBF של הדיסקים שלכם? זה הזכיר מקרה מלפני כמעט שמונה שנים כשהייתי יחסית חדש בחברת אנקור, לקוח מכפר נטר גרם למנהל המכירות של אנקור להתקשר אלי באחת עשרה וחצי בלילה, אתם מבינים EMC השתמשו אז בדיסקים מסוג eMLC אבל NetApp שאנחנו ייצגנו השתמשו רק ב MLC ובגלל זה אנחנו עומדים להפסיד את העיסקה. נו בחיאת. מצד אחד, יש ערך לירידה לפרטים ומצד שני יש חובה לדעת את ההבדל בין עיקר לתפל. אנחנו באינפינידט היחידים שמתחייבים בכתב לשבע תשיעיות של זמינות על המערכות שלנו, ואנחנו עושים את זה דווקא עם רכיבי החומרה הכי פשוטים שיש בעולם האנטרפרייז, אנחנו מספקים סדר גודל שלם מעל המתחרים הקרובים שמציגים שש תשיעיות בלי לזרוק כסף על חומרה יקרה ומורכבת מדי, שני סדרי גודל מעל הסטנדרט המקובל בתעשייה של חמש תשיעיות ושלושה סדרי גודל מעל ספקיות הענן הגדולות בלי להיגרר לטרנדים הכי חמים בתעשייה סתם ככה לשם הטרנדיות ועדיין מישהו רוצה לדעת שהדיסק הבודד שאמכור לו בתוך המערכת יכול להחזיק 2,000,000 שעות עבודה רציפות בממוצע. לך תבין. ואם הממוצע הוא רק 1,800,000 שעות עבודה רציפות לדיסק בודד איזה השלכה יש לזה על הביזנס שלך אדוני הלקוח?

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

המשמעות של תלות בחומרה והדרישה להצפנה לגבי מודלים עסקיים

השבוע נחשפה חולשה מובנית בהצפנה החומרתית של דיסקי SSD וכתוצאה מכך חולשה מובנית במנגנון ההצפנה BitLocker שמשתמש בהצפנה חומרתית כברירת מחדל. פועל יוצא מחולשות כאלו ולצדן חוקי הרגולציה  המחייבים הצפנת מידע, הוא הכורח להצפין ברמת האפליקציה ולא ברמת התשתית. נשאלת השאלה מה יקרה למודל הכלכלי של יצרניות ה All Flash כולו? עד לא מזמן, יצרניות כמו NetApp סיפקו יכולות Deduplication ככלי טכנולוגי, הלקוח שילם על נפח דיסק ואם בזכות ביטול כפילויות הצליח לכתוב על הנפח הזה יותר מידע, הוא הרוויח. היום המודל הפוך, בגלל העלויות הגבוהות של מערכות מבוססות פלאש, הלקוח משלם על נפח דיסק ולמעשה מקבל שליש, רבע או לפעמים אפילו חמישית מהנפח שקנה. היצרניות השונות מתחייבות לספק את כלל הנפח הנרכש באמצעות ביטול כפילויות ודחיסה וכך הכלי הטכנולוגי הפך להיות כורח כלכלי אבל מה יקרה אם המידע יוצפן במקור? הרי היכולת לדחוס מידע מוצפן או למצוא כפילויות בו יורדת לאפס?

כמו תמיד שמח לשמוע פידבק על מה שכתבתי אז אל תהיו ביישנים!

שלכם,

ניר מליק