תגית: GCP

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

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

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

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

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

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

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

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

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

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

שלכם,

ניר מליק

Got Silk?!

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

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

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

אפשר לראות שיש קשר ישיר בין גודל הדיסק ב GB וכמות ביצועי ה IOPS העומדת לרשותו. אפשר לראות בהערות גם שיש כמות ה CPU וכמות ה IOPS בגלל ששרתים עם יותר CPU יכולים לגבל הקצאת תקשורת נדיבה יותר, Network egress caps. משמעות הדברים היא שיתכנו מצבים בהם לקוחות צריכים לשלם על נפח דיסק ריק כדי לקבל יותר משאבי ביצועים ועל מעבדים מיותרים כדי לקבל יותר משאבי תקשורת אל הדיסקים.

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

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

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

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

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

כלי שימושי נוסף שאנחנו מאפשרים ללקוחות הוא סנפשוטים רזים. תהליך יצירת סנפשוט בענן הוא תהליך ארוך ויקר. ב AWS למשל, בתהליך יצירת הסנפשוט מועתק המידע אל S3 ובכל סנפשוט נוסף יש להעתיק מידע נוסף, את המידע החדש. אנחנו מאפשרים ליצור סנפשוטים מידיים, מבוססי הצבעות בלבד, כך שאין צורך להזיז מידע או לשלם על נפח מידע נוסף ולכל סנפשוט ניתן לייצר View כלומר להשתמש בסנפשוט כהעתק עצמאי של המידע לשרתים אחרים, test/dev או אנליטיקה וכו'.

אנחנו רואים בבמוצע חסכון של 3:1 בשימוש ביכולות חסכון בנפח ולפחות עוד 30% חסכון על ידי שימוש בThin Provisioning וזה אומר שרק על ידי זה שריכזנו את המידע של הלקוח והכלנו עליו את היכולות האלו, הלקוח צורך עכשיו פחות מרבע מהנפח שהוא צרך קודם ובגלל שאנחנו לא נסנכים על ביצועי הדיסקים של תשתית הענן הרבע הזה הוא בדיסקים זולים יותר מהדיסקים הקודמים!

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

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

עדכון לפוסט!

כמו מהשמים שלחו לי לינק לסרטון הזה היום, החל מדקה 16:54 בערך אפשר לראות בדיוק כמה מורכבות האופציות לבחירת דיסקים ב AWS והתאמת ה EC2 instance לבחירה שלכם.

כבונוס, יש שם הדגמה של יכולות של blktrace. ביחד עם blkparse, btt ועוד סקריפט פייטון קטן (כן כן הרבה חלקים זזים) אפשר ממש להציג באופן קריא ונוח עד כמה ה IO שהשרת שלכם עושה הוא Sequential או Random, נתון שהרבה פעמים חסר לנו כשאנחנו באים לעשות סייזינג מסודר למערכות סטורג', אם אתם מאלו שעוד עושים כאלו דברים 🙂

credit AWS: https://youtu.be/wsMWANWNoqQ
credit AWS: https://youtu.be/wsMWANWNoqQ

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

שלכם,

ניר מליק

מפריז הביתה

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

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

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

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

https://www.cloudshare.com/blog/the-big-share-a-qa-with-technical-sales-leader-and-remote-veteran-nir-malik

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

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

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

SAS זה בעצם ראשי תיבות של Serial Attached SCSI והפרוטוקול הזו הוא המקשר בקשר point to point בין יחידות המחשוב שלנו לדיסקים. אחד הדברים המתאפשרים לנו עם זה להציג את אותה המדיה לכמה יחידות מחשוב ובכך לנתק את הקשר הישיר ביניהם. עכשיו ניתן לנתק את הקשר הגורדי הזה ובכך לאפשר הרבה יותר גמישות במבנה מערכת האחסון, ניתן להגדיל את המערכת בנפח אחסון (scale up) או בכוח מחשוב (scale out) באופן הרבה יותר גמיש מאי פעם. אם מערכות scale out קלאסיות מחייבות להגדיל גם את נפח האחסון לצד כוח המחשוב ויחידות האחסון מקושרות פיזית ליחידות מחשוב ספציפיות, עכשיו אפשר נגיד לחבר שמונה יחידות מחשוב לאותה יחידת אחסון.

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

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

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

ניר מליק