All Anything and Carpool lanes

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

אז בחודש שעבר, סיגייט סיפרה לנו באמצעות Block and Files, שבין היתר, באמצעות הטכנולוגיות האלו, דיסקים מסובבים יוכלו להישאר זולים יותר מדיסקי SSD גם במבט ל15 שנים קדימה שזה מעניין כי השבוע אותו אתר הציג לנו מאמר של היוברט סמית' שאומר לנו שדיסקים מבוססי NAND הם לא רק זולים יותר מדיסקים מסתובבים, הם אפילו אמינים יותר!

עכשיו, פעם היו לנו דיסקים 5,400 RPM, ואז שדרגנו ל 7,200 RPM  ואז מי שרצה דיסקים מהירים קנה דיסקי FC ואחריהם הוא קנה דיסקי SAS ואז אמרנו לכל הלקוחות שלנו להגדיל את כמות הדיסקים, הספינדלים, כדי לחלק על כמות דיסקים גדולה יותר את הפעולות שהם נדרשים לבצע, את ה IOPS ואז עלה עלינו מהמדבר הפולש המונגולי של מערכות ה All Flash ואמר ללקוחות שלנו שהם משוגעים כי הם קונים נפח שהם לא יכולים לנצל בשביל לקבל ביצועים וכדאי להם לעבור לדיסקי SSD ועכשיו מה מוכרים ללקוחות שלנו אותם כוהני SSD? שהם צריכים לקנות נפח שהם לא יכולים לנצל בשביל שרידות!

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

ועדיין, כולם מתעלמים מהעובדה ש DRAM  מהיר בסדרי גודל מכל מדיה אחרת! איך יצרני ה All Anything מעיזים למכור לכם מדיה איטית בסדרי גודל מהמדיה המהירה ביותר?!

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

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

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

ספרו לי מה חשבתם על הפוסט הפעם,

צום קל!

אני במשמרת מג"ב ביום כיפור אז תעשו טובה ותשמרו על עצמכם,

שלכם,

ניר מליק

מודעות פרסומת

Mini Post – VMware HCX

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

הכלי כולל בתוכו שלוש תכונות עיקריות:

  1. מיגרציה מסביבות שאינן סביבות ESXi – הכלי יאפשר להסב מכונות מסביבות KVM+ Hyper-V אל סביבות ESXi ובעתיד יאפשר גם להסב מכונות מסביבות נוספות
  2. ניהול של משימות vMotion תוך הוספה של האצה ומקביליות או מה שהם קוראים עכשיו replication assisted vMotion ככה שאפשר לבצע ניוד של מספר רב של מכונות על פני מרחקים גדולים יותר (תחשבו ESXi Over AWS)
  3. התממשקות אל VMware SRM כך ש HCX מהווה שכבת הטרנספורט עבור SRM ומוסיף יכולות של wan optimization, הצפנה וכו'

לקריאה נוספת יש כאן את ה FAQ ואם אתם בעניין אז בקישור מטה תמצאו גם את הפרק הרלוונטי של vSpeaking והפעם עם איימי לואיס הלא היא @CommsNinja

https://www.vspeakingpodcast.com/episodes/125

למתקדמים יש אפילו דמו עם hands On Lab

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

ניר מליק

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

שלשום דיברתי עם חבר, חקלאי שמדי פעם עוקץ אותי שנמאס לו מהחקלאות והוא רוצה לעבור לעבוד כמוני בהייטק. זה היה מיד אחרי שבתשע וחצי בערב, מוצאי שבת, הוא סיים שיחת צעקות עם אחד הסוחרים שעובדים איתו. בסופו של דבר, הסברתי לו, התהליך שונה, אני לובש חליפה וטס לפגישות והוא חורש, שותל, משקה מרסס אבל בקצה התהליך, 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 שאוסף מידע על מערכות האחסון של הלקוח ומסוגל לתת לו התראות בזמן אמת על נפחים, ביצועים, בריאות החומרה שלו, שדרוגי תוכנה מומלצים וכל מני דברים כאלו אבל הדבר המגניב באמת הוא התראות ממוקדות על שינויים בזמן אמת במצב המערכת שלו כמו למשל, אם אנחנו רואים ירידה חדה ומהירה ביחס הדחיסה על מערכת מסויימת, אנחנו מסוגלים להראות את זה ללקוח בזמן אמת, במקרה הטוב זה אומר שהלקוח שינה באופן יזום את סוג המידע שהוא מאחסן, נגיד עבר מקבצי טקסט לקבצי תמונה שכמובן נדחסים פחות, במקרה הרע זה אומר שהלקוח נמצא כרגע תחת מתקפת קריפטו כל שהוא שמצפינה לו את המידע וכדאי לפעול מהר לטפל בזה. לא רע הא?!

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

שלכם,

ניר מליק

Pure-in-the-middle attack, Vast data and tools for VMware admins

Pure-in-the-middle attack

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

לפני שבוע וקצת, חברת Pure הכריזה על פתרון חדש שהוצג כפתרון פורץ דרך ומאפשר ביצוע הצפנת נתונים מקצה לקצה ללא נטרול טכנולוגית ביטול הכפילויות המובנית במערכות היצרן.  האמת היא די רחוקה מזה, למעשה מה שמוצע כאן בפתרון הוא שילוב של שני כלים, הראשון הצפנה ברמת Host והשני הצפנה ברמת מערך האחסון, הבעיה היא שאלו שני כלים נפרדים והתהליך כולל פתיחה של ההצפנה והצפנה מחדש בעת כתיבה ושוב בעת קריאה, מתבצעת כאן החלפה של ההצפנה ובאמצע שלב של clear text כלומר, מי שיטמיע את הפתרון, יטמיע לעצמו מתקפה של men in the middle קלאסית.

image credit to blocksandfiles.com

Vast storage to the rescue?

במסגרת storage field day האחרון, נחשפה באופן מסודר חברת Vast storage. הם הציגו סוג חדש של טכנולוגית חסכון בנפח והיו לי ציפיות גדולות מהם ספציפית בעניין של חסכון בנפח עבור מידע מוצפן כי כריס מלור האהוב על כולנו כתב שהם מסוגלים לייצר חסכון של 1:5 גם על מידע שכבר עבר חסכון של 5:1 על ידי קומוולט. במקום לבצע דחיסה וביטול כפילויות, הם מציגים חישוב חדש שמתבסס על בלוקים לא זהים אלא דומים. כשהמערכת הכי קטנה שהם מתכוונים למכור היא פטה שלם של מידע ויכולה לגדול לפטות רבות, הסיכוי למצוא בלוקים דומים, עולה. הם מבצעים Hash על כל הבלוקים ולכל האש כזה נותנים מספר מזהה לפי אלגוריתם חיפוש הדמיון שלהם. אם יש בלוקים שחולקים את המספר המזהה, הם מקובצים ביחד ואז נשמר רק אחד מהם כבלוק ייחוס ונוצרות דלתות כדי לייצג את שאר הבלוקים במקבץ. נשמע ממש מגניב אבל כמו שרנן אומר, גם הם לא יכולים לספק חסכון משמעותי במידה והמידע מוצפן, אולי אם הצפנתם מידע דומה באלגוריתם הצפנה דומה עם מפתח הצפנה דומה.

אגב רנן חלק שמעביר כאן את ההדרכה, מייסד ומנכ"ל החברה ולשעבר VP R&D של ExtremeIO מדליק את הקבוצה בסביבות דקה 6:05 עם ההערה שלא צריך יותר לגבות, סנפשוטים זה מספיק. אני כמובן חולק עליו אבל אני לא איש R&D כמוהו ומה שעובד במחקר לא תמיד עובד בשטח.

תראו למשל את מה שקרה בשבוע שעבר לענקית הפלדה Norsk Hydro, חברה שמעסיקה 35,000 איש שעברה לעבוד עם דפים וכלי כתיבה אחרי שמערך המחשוב שלה הושבת כליל אחרי מתקפת Ransom והיום מודיע ש"מרבית" השירותים שלה חזרו לתפקוד, רק חלק ואחרי שבוע!

נקודה נוספת ששווה התייחסות בקליפ זה ה shout out של כריס אוונס עלינו, אינפינידט, תודה כריס! (דקה 7:35)


Renen Hallak, CEO introducing Vast at #SFD18

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

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

screenshot from the #SFD18 video above

כלים שימושיים בסביבות VMware

השנה התקבלתי שוב לתכנית vExpert לשמחתי הרבה והיה לי כיף לגלות שעדיין יש לי מה ללמוד גם ברמת הבסיס. באחד הפרקים האחרונים של Virtually speaking סקרו את עשרת הכלים הכי שימושיים לאדמינים של סביבות ESXi ואלו שלושה כלים שלא הכרתי ונראים לי מאד שימושיים:

ONYX – אוניקס הוא תוסף שמתרגם פעולות מהממשק הוובי של vCenter לקוד powercli. נראה לי כמו כלי סופר יעיל לגשר בין כלי GUI אינטואיטיבי ובין עולמות ה API בהם אנחנו אשכרה צריכים לדעת מה אנחנו רוצים לעשות. הפלט כמובן ניתן לעריכה והתאמה ולכן יכול לשמש אותנו כטמפלט מעכשיו הלאה

HCIBench – אם אתם זוכרים, כבר כתבתי כאן פעם על VDBench, הכלי המועדף עלינו לבדיקות ביצועים. מסתבר שיש פלינג נחמד שמבצע auto deployment לסביבה מבוססת VDBench להרצת בדיקות ביצועים של HCI, ממש מגניב!

שני הכלים האלו הם פלינגים, כלים ותוכנות שלא נתמכים רשמית על ידי VMware אבל כן מפותחים ונתמכים על ידי הקהילה ועובדי VMware, משהו כמו code.infinidat.com שלנו רק, מה לעשות, גדול עשיר ומרשים יותר.

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

As-Built-Report – יא וורדי איזה כלי, ממש התביישתי שלא הכרתי אותו עדיין, כלי קהילה, open source, שמאפשר לייצר דוחות מותאמים אישית על כלל סביבת ה IT הקיימת כולל vSphere, NSX, Cisco UCS, Nutanix, Pure, ממש שווה להעיף מבט על הכלי.

שויין, זה מה שיש לי להפעם,

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

אה, ואגב, אני מחפש חבר לצוות שלי לתפקיד Technical Advisor שדומה קצת לתפקידי TAM/TAC  בחברות אחרות או  תפקידי Success בסטארט-אפים מגניבים אז אם אתה מתאימים או מכירים מישהי\מישהו, תהיו חברים!

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

ניר מליק

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

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

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

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

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

ניר מליק