מיני פוסט – EMC נותנים לסילק בראש?

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

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

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

הערה אחת שכן יש לי היא בנוגע לעלויות. הם מציגים ביצועים מאד מרשימים עם פוטנציאל להגיע למעל שלושים מליון IOPS זה פסיכי אבל בשביל להגיע לזה הם צריכים 140 שרתי i3en.12xlarge שזה מתורגם לכמה מליוני דולרים בשנה רק עלות תשתית לפני הנחות ובכסף הזה יותר כדי כבר לקנות EMC On-Prem.

בכל מקרה, חומר למחשבה. כל הכבוד לחברים ב Dell-EMC, תחרות עושה טוב לכולנו!

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

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

שלכם,

ניר מליק

אז מה זה NetApp BlueXP?

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

במהלך השנים האלו, בתהליך שהתחיל קצת לפני אותו פוסט שלי, נטאפ שינתה ומשנה את פניה. דבר ראשון, נטאפ הפכה באופן ברור מחברת מוצר לחברת פורטפוליו. דבר שני, מיצרנית פתרונות On-Prem הפכה החברה ליצרנית פתרונות Hybrid & Multi Cloud ודבר שלישי, זו כבר מזמן לא חברת אחסון, לא רק אחסון בכל אופן.

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

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

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

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

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

את שירותי הניטור:

ואיחדנו פנימה את שירות ה ActiveIQ המוכר והאהוב שלנו:

במסך ה Canvas, מסך הטופולוגיה הראשי אליו מאגדים את שירותי האחסון השונים, אפשר לראות שבאמת איחדנו את יכולת הניהול של ONTAP, E-Sereis ושל StorageGRID ביחד עם מערכות ה CVO ושירותי ה ANF (במיקרוסופט) וה FSxN (באמזון)

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

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

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

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

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

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

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

שלכם,

ניר מליק

למה הם עוזבים את הענן?

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

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

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

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

למי הענן כן מתאים לפי הניתוח שלהם? ללקוחות בתחילת דרכם או לקוחות מאד דינאמיים. אם אתם לקוח שרק מתחיל, שאולי עוד אין לכם אפילו לקוחות, הענן הוא הדרך הכי מהירה ולהתניע וגם אם זה יותר יקר לכל ג'יגה אחסון ופעימת מעבד, זה לא משנה, העיקר להתניע. אם אתם לקוח מאד דינאמי, למשל אתר מסחר שב Black Friday או Cyber Monday מכפיל בסדר גודל את היקף התנועה שלו, אין כמו הענן לאפשר את הדינאמיות הזו. אפילו עבור Hey עצמם הם אומרים, זה היה מהותי מאד בתחילת הדרך, כשהם ציפו לשלושים אלף משתמשים בשישה חודשים ובפועל הגיעו לשלוש מאות אלף משתמשים בשלושה שבועות אבל היום, כשהעומס והגידול צפויים, הענן הרבה יותר יקר ולא מספק יתרונות מספיק מהותיים.

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

טיעון משמעותי נוסף שהם טוענים הוא טיעון השרידות והגמישות. עם כל הכבוד לתשתיות הענן החסונות, הם אומרים, כאשר US-East-1 של אמזון נופל, חצי מהאינטרנט נופל איתו, זו לא הרשת המבוזרת אותה תכננו בDARPA הם טוענים ושוב הם קצת הולכים לאיבוד עם טיעונים רומנטיים שלא רק שהרשת צריכה להיות מבוזרת אלא גם שהם מעדיפים לשלם את הכסף שלהם לחברות קטנות כמוהם ושבחברה גדולה כמו אמזון או גוגל אפילו שהם משלמים מיליונים כל שנה אף אחד לא סופר אותם ולה עונה להם לטלפון. אם לך כלקוח שלנו ה Hey, הם אומרים, יש בעיה, כל החברה מתגייסת לעזור וזה יגיע מהר מאד גם לרמה שלנו המנהלים הכי בכירים. זו טענה מוזרה משני הכיוונים, ראשית כי אני מכיר את מערכי התמיכה של ספקיות הענן, אתה לא באמת לבד אם יש לך בעיה שם, ושנית כי זו לא חכמה להשוות חברה קטנה\בינונית וחברה ענקית, אם Hey יום אחד תגיע לקנה המידה של ג'ימייל, הרי גם אם דיויד וארון ירצו הם לא יהיו מסוגלים להתערב בכל קריאת שירות וכל תקלה ללקוח, גם אם הוא לקוח בינוני שמשלם להם מיליונים.

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

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

שלכם,

ניר מליק

אמסטרדמסקי, השקעות, תשואות, עננים וקשתות

אני מת על פודקאסטים וכבר המלצתי לכם בעבר על חלק מהפודקאסטים האהובים עלי כמו למשל הפודקאסט של presales collective או כמובן הפודקאסט שלנו, של נטאפ, Tech ONTAP אבל הפודקאסט הישראלי האהוב עלי הוא בלי שום ספק חיות כיס של כאן11.

בשבוע שעבר צייץ הכתב הכלכלי של כאן11 וחבר המערכת של חיות כיס, שאול אמסטרדמסקי, את סדרת הציוצים הבאה:

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

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

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

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

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

אבל לא לכל הלקוחות ולא לכל האתגרים, הענן הציבורי הוא הפתרון הנכון ועבור אתגרים אלו, נטאפ מציגה את נטאפ Keystone או "אבן הראשה". למיטב ידיעתי אין שום קשר בין בחירת השם ובין אופי השירות אבל היי, במבריק כבר אמר לנו שבמחשבים "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors."

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

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

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

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

שלכם,

ניר מליק

Bunch-O-Balloons & some hot air from Pure

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

היזם נתן כדוגמא את הסיפור על Bunch-O-Balloons, מכירים?

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

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

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

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

בכל מקרה, אתמול היה גם ה Analyst Day של Pure Storage שפומפם אצלנו בתעשיה יפה וכולנו חיכינו לשמוע מה יתחבא מאחורי הפרגוד.

ובכן, לא הרבה.

Pure Fusion

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

שירות ניהול מרכזי למערכות Pure תחת מעטה שיווקי ומטעה (רואים מה עשיתי כאן עם מעטה ומטעה?!), לא הרבה יותר מזה, זה נחמד שהם משתמשים בז'רגון ענני כמו availability zone ומוסיפים קצת אי דיוקים טכניים כמו scale out אבל בסופו של דבר זה ממשק ניהול של כמה מערכות שלא מייצר שום תוכן חדש מעבר למה שהמערכות המנוהלות כבר יודעות לייצר.

Portworks Data Services

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

סך הכל הכרזה קצת מאכזבת ואני מזכיר לכם שכשמגיע להם פירגון אני אכן מפרגן להם כמו כאן כשהם השיקו את תצורת ה Active/Active שלהם

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

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

ניר מליק

אמרתי לכם!

אמרתי לכם! הייתי הראשון לזהות!

הדבר הזה פשוט מטורף.

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

CPOC!

זה היה הדמו שעזר לנטו להפוך לכוכב בתוך החברה (CPOC!)

כמה דברים השתנו מאז, הרעיון של NPS היה רעיון חדשני, לשים מערכת אחסון פיזית ליד הענן, ומאז נטאפ כבר יודעת לספק במקום זה מערכת וירטואלית לחלוטין שרצה על הענן בתוך הסביבה הוירטואלית של לקוחות ובמקביל, ספקיות הענן עצמן מספקות את השירות של מערכת ליד הענן בעצמן, שירותים כמו Azure NetApp Files למשל שהם שירות של Azure לכל דבר ועניין רק שמאחוריו יש מערכת אחסון All Flash פיזית של NetApp.

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

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

היום אנחנו מכריזים על משהו חדש ביחד עם החברים מ AWS, FSxO או בשם המלא FSx for netApp ONTAP

FSxO הופך בפועל את נטאפ לספקית האחסון של AWS כלומר כל לקוח AWS, בין אם הוא לקוח נטאפ ותיק או לקוח שמעולם לא שמע על נטאפ, לקוח EC2 או EKS, VMware on cloud, זה לא משנה, יכול לצרוך את שירות האחסון שלנו בצורה שקופה לחלוטין מתוך שכבת הענן של AWS, כולל סנפשוטים, רפליקציה, יכולות דחיסה וביטול כפילויות, NFS, SMB, iSCSI, FabricPool  שאני אוהב, Flash Cache,  הכל כולל הכל!

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

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

עבור לקוחות קיימים של נטאפ, אפשר להסתכל על שלושה Use Case סופר מהירים וכדאיים והראשון הוא DR. זה סופר קל פשוט להגדיר Snap Mirror ולא לנהל שם דבר יותר, כל התשתית עבור FSxO היא מנוהלת על ידי AWS וכל מה שהלקוח צריך לעות זה להגדיר מדיניות רפליקציה ולשכוח מזה עד יום פקודה.

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

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

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

סוף שבוע נעים ושנה טובה לכולם!

שלכם,

ניר מליק

נישט אהין, נישט אהער

נישט אהין, נישט אהער ביידיש – לא פה ולא שם

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

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

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

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

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

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

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

מילה אישית

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

והנה, ככה נראית החצר הקדמית שלנו במהלך סגר 3.5:

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

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

ניר מליק

לייב בלוגינג – Strategic Cloud Migration – CMS, Microsoft & IsraelClouds

ממשיך ברצף הלייבים והפעם כנס של CMS ו IsraelClouds ביחד עם מיקרוסופט

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

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

מה זה Datacenter? חוות שרתים

מה זה region? אתר הבנוי לפחות משני datacenter או יותר נכון להגיד שני availability zones שמייצגים לפחות datacenter אחד

מיקרוסופט מקימה region כאן בארץ בקרוב והיא הראשונה מבין הספקיות הגדולות לעשות את זה

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

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

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

איך בכלל מתחילים מיגרציה לענן?

שלב ראשון לבצע הערכה ואפיון, assessment, כדי להבין מה יש לנו בכלל להעביר אל הענן

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

דמו של תהליך מיגרציה ולאחריו דמו של virtual desktop של מיקרוסופט

Azure migrate מאפשר לנו להוריד מ Azure כלי הגירה אל סביבת ה Hyper-V שלנו

הכלי מותקן בסביבה שלנו כשרת וירטואלי כלומר אנחנו מורידים VHD

לאחר ההתקנה והאוטנטיקציה אנחנו צריכים להוסיף את ה Hyepr-V Host שלנו ואז יבוצע הליך discovery אוטומטי להצגת המכונות הוירטואליות שיש לנו על ה Host

עכשיו ניתן לבצע תהליך Assessment אוטומטי כדי להקל עלינו בבחירה של סוג ה Cloud VM שלנו

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

הרפליקציה מוצפנת כדי להגן על המידע שלנו In Transit.

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

בשלב הזה עוברים להדגים virtual desktop אבל end user זה קצת פחות התחום שלי

סך הכל אירוע נחמד ברמת מבוא לענן, תודה רבה לכל המנחים!

ואפילו יש כיבוד כמו כנס אמיתי:-) מי שנשאר עד סוף האירוע מקבל שובר לפיצה או לוולט, טאצ' נחמד!

SalesForce Live Israel

מצטער אבל לא היה לי זמן להשתתף בצורה פעילה אבל ה Key Note היה מאד מקצועי ומעניין והמוצר של Bonobo שהוצג על ידי אפרת רפופורט נשמע סופר מגניב

כרגע אני מקשיב לסשן SMB שמונחה על ידי מורן שור (גילוי נאות מורן היא חברה טובה)

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

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

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

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

ניר מליק

לייב בלוגינג – Lift and shift an Apache Kafka cluster to Amazon MSK Floor28 Webinar

יאללה פעם שלישית אני צורח!

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

https://www.linkedin.com/posts/strati-georgopoulos_how-to-use-an-old-phone-as-a-home-security-ugcPost-6710808561468923904-M1dg

יאללה מתחילים

MSK הוא שירות לניהול קלאסטרים של קפקא

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

גרסאות נתמכות 1.1.1 2.2.1 2.3.1 2.4.1

השירות מספק תאימות מלאה לקפקא ולשירותים הסטנדרטיים באקו-סיסטם של קפקא כל עוד הם תומכים ב API של קפקא בעצמם

השירות מספק ברוקרים ו Zoo-קיפרים

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

השירות מספק הצפנה at rest ומתממשק לניהול מפתחות ההצפנה על ידי KMS

קיימת תמיכה גם בהצפנה ברמת TLS עבור data in transit

תאימות לרגולציות כמו HIPPA, PCI וכו'

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

הקלסטר תומך בזמינות של 99.9% ומוגדר על 2 או 3 AZ's בהתאם לדרישת הלקוח

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

אין תשלום על התעבורה בין הברוקרים והZOO-קיפרים

עכשיו למיגרציה עצמה –

למעשה כל כלי מיגרציה קיים שאתם מכירים יכול לעבוד עבורכם גם במעבר אל MSK

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

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

בדוגמא השניה יש צורך לשמר את המידע וכאן באה המלצה להשתמש ב Mirror Maker v2

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

kafka Connect משמשת אותנו להזרים מידע בין קלאסטרים ויכולה גם להזרים מידע מקלאסטרים מסוגים שונים כמו קסנדרה וכו'

בשלב הזה נפל לי החשמל בבית, נקווה שיחזור מהר ונוכל להמשיך בוובינר ובעדכון הלייב של הבלוג 🙂

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

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

יש אפילו אפשרות שנקראת Migration Incentives בה נותנים קרדיטים חינם כדי שתוכלו לתרגל ולבחון דברים לפני המיגרציה!

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

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

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

ניר מליק

לייב בלוגינג AWS Pricing Models Floor28 Webinar

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

https://floor28.co.il/

ההדרכה הפעם מתרכזת בשירותי סטורג', איזה כיף!

שירותי האחסון מחולקים ל3 קטגוריות עיקריות, Block, File ו Object, מוקד ההדרכה הפעם הוא שירות הבלוק, EBS וקצת על RDS.

שירותי File כוללים את EFS (שירות NFS) ואת FSX לשירותי קבצים של windows או luster. FSX משתמש ב S3 ב backed ככה שהוא מאד cost effective וכן highly available. ל EFS יש שני טירים של אחסון, סטנדרט (8 סנט לגיגה לחודש) וטיר של infriquent access בעלות של 2.5 סנט לגיגה לחודש. FSX עולה רק 1.3 סנט לחודש ל סינגל AZ או 2.5 לגיגה לחודש ל multi-AZ. אגב FSX תומך באינטגרציה ל Active Directory כיוון שהוא כאמור מכוון לסביבות windows. לא תאמינו אבל השירות הזה, FSX, כולל גם deduplication שאמור לחסוך כ 505 מעלות האחסון בשירות זה. זה די דהים כי זה נוגד את הקונספט של שירותי הענן בדרך כלל שמחייבים על נפח מוקצה בכלל, למה להם לחסוך לנו בנפחים?

עיצה ראשונה לחסכון בעלויות EBS היא למחוק volumes שאינם בשימוש, נשמע טרוויאלי אבל מסתבר שיש הרבה משתמשים שמוחקים את ה EC2 Instance שלהם אבל לא מוחקים את ה EBS שמחובר אליהם. ניתן למנוע טעויות כאלו אם בהקמת הEC2 אנחנו מגדירים גם delete on termination עבור ה EBS שהוגדרו עבורו, יש לישם לב שזה אכן מה שאנחנו רוצים כדי למנוע מצב הפוף של מחיקת מידע בטעות במחיקה של instance.

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

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

לגבי snapshots בגדול הם ממליצים שוב את אותה עיצה ראשונית של למחוק סנפשוטים ישנים שאין בהם צורך יותר ושכדאי ליישם את ה retention policy שלנו על ידי יכולת life cycle management.

עוברים עכשיו ל S3

S3 standard, S3 intelligent tiering, standard IA, One Zone IA, Glacier, Deep Archive, אם בוחרים את השירות הנכון ניתן לחסוך עשרות אחוזים בהאתם לגישה בפועל שלנו אל המידע, ככל שהמידע "קר" יותר ניתן לאחסון אותו על שכבה נמוכה יותר ולחסוך מלא כסף אבל צריך לזכור שיש עלויות למשיכת מידע בטירים הזולים באמת ויש גם מינימום של זמן שמירה ומינים יחידת נפח לחיוב.

יש לשים לב שלכל אובייקט יש 8Kb ועוד 32Kb של overhead לmetadata. ה 8Kb הראשונים מחוייבים לפי Tier יקר גם אם המידע נמצא ב Tier נמוך.

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

שירות storage analysis עולה גם הוא כסף, 10 בסנט למליון אובייקטים לחודש

שירות שמוצג בדמו הוא שירות trusted advisor שיודע להראות לנו under utilized EBS volumes. ניתן להשתמש בלמבדה להריץ בדיקה אוטומטית של ווליומים שאינם בשימוש מעל פרק זמן מוגדר מראש.

כשהדגימו כלים של S3 קצת איבדתי ריכוז אבל הכלים נראים יעילים סך הכל

זה הכל להיום, תודה למי שעקב כאן ותודה לצוות Floor 28

כמו תמיד אשמח לפידבק,

ניר מליק

לייב בלוגינג EC2 Image Builder Floor28 webinar

לייב בלוגינג? למה לא, מזמן לא עשינו את זה

הפעם אני בהדרכה של Floor28 על EC2 Image builder, שירות חדש לבניה של גולדן אימג'ז:

מה זה בכלל גולדן אימג'?

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

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

  1. אנחנו רואים שהרבה לקוחות מתקשים לבנות ולנהל אימג'ים טובים – חוסר בידע ומשאבים
  2. יש חברות שיש להן ידע אבל בוחורות שלא לתחזק מערכות אוטומציה לצרכים כאלו לצד מערכות Ci/CD שכבר יש להן
  3. קושי בבדיקת אימג'ים לפני עליה לאוויר
  4. השפעה קשה על פרודקשן אם מפספסים תקלות לפני שימוש באימג' חדש

מה הלקוחות ביקשו?

  1. לקוחות ביקשו מאמזון שירות אוטומטי לבניה של אימג'ים שלא יידרוש שימוש בקוד
  2. ביקשו להשתמש ביכולות של אמזון לבדיקות אוטומטיות של אימג'ים
  3. אימג'ים בטוחים לפי סטנדרטים מקובלים בתעשיה ויכולת להוסיף סטנדרטים ספיציים ללקוחות לפי תחום העיסוק שלהם
  4. הפצה של אימג'ים בין חשבונות ובין ריג'נים
  5. יכולת לבנות ולהתשמת באימג'ים האלו גם On-Prem

אז מה זה השירות החדש?

  1. שירות אוטומציה מבוסס GUI
  2. יכולת בדיקות
  3. שיפור זמני uptime

השירות תומך גם בווידוז 212R2 ומעלה וגם בלינוקס ובכל הפצה של לינוקס שנתמכת ב AWS

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

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

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

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

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

מן הסתם צריך לתת לשירות עצמו הרשאות IAM כדי שיוכל לרוץ בעצמו

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

צריך להגדיר דיפולט סאבנט וסקיוריטי גרופ (לא חובה)

תהליך בניית האימג' כולל כמובן לוגים כדי שנוכל לנתח במקרה של כשלון בבניה של אימג'

אפשר לקשר את שירות הפצת הרשיונות שלנו לתהליך בנית האימג' אם יש לנו צורך כזה ברקע מי שמבצע את התהליך זה SSM או Systems Manager ככה שאפשר לראות דרכו את תהליך הבניה עצמו

זהו, סיימנו, סה"כ די straight forward וברור

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

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