התאריך היום הוא ה-17 באוגוסט 2021 ואנחנו בכרכור באולפן הבייתי שלנו בבית של אורי . . . הי אורי! (אורי) אהלן . . . רן, אתה מחזיק את המיקרופון ביד בהחזקה אופיינית לתבורי . . . (רן) בבקשה, הרמתי את האצבע . . . החלטתי להישען בפודקאסט הזה, היה לי יום ארוך של נסיעות . . . אז אנחנו בקרבורטור - ובקרבורטור, כמיטב המסורת, אנחנו מארחים את נתי שלום, אז הנה - שלום לנתי שלום!
(נתי) שלום לכם! כמה זמן כבר שלא נפגשנו? כבר איזה חודשיים בערך?
(נתי) האמת שזה די מדהים שכל פעם אנחנו מוצאים איזה נושא מעניין כזה שמדליק פתאום את החושים - כל פעם אתה זורק איזה WhatsApp על משהו ושולח אותי לשבועות של מחקר . . .
(אורי) בנושא טעון . . . כמו ענן שחור כבד שעולה במערב . . .
(רן) זה הפרק שבו אורי יגיד לנו “אמרתי לכם!” . . . אז בואו נראה מה הולך לקרות פה היום . . .
(אורי) אמרתי לכם! . . .
(רן) לגמרי.
אז לפני מספר שבועות, או אפילו כמה חודשים [May 27, 2021], התפרסם מאמר מעניין בבלוג של Andreessen Horowitz שנקרא The Cost of Cloud, a Trillion Dollar Paradox - שבו, למעשה, הם מתארים, שני המחברים - Sarah Wang ו-Martin Casado את מה שהם קוראים לו “פרדוקס” בתחום של עלויות ענן, או אם נתמצת את זה - מתי “נכון” להיות בענן ומתי “לא נכון” להיות בענן.
התשובה לא איחרה לבוא, מפי Corey Quinn, שאמנם לא עובד ב-AWS אבל הוא בדרך כלל בעדם, והוא בא ושובר את כל הטיעונים שלהם לחלקים . . .
אז פשוט שלחתי את שני המאמרים האלה ב-WhatsApp לנתי - ופה נקודת ההתחלה שלנו . . .
לא נקריא אותם פה בשידור ואתם כמובן מוזמנים ונוסיף רפרנסים [יש] - ובגדול, השאלה היא “האם Cloud נכון לחברה בשלבי ה-Growth השונים? מה העלות האמיתית שלו? האם יש פה אכן פרדוקס?”.
(רן) אז בוא, קודם, נכנס ככה למאמר - ולפרדוקס, לכאורה, שהם מתארים. . .
- (נתי) אז בוא נדבר באמת קודם על מה זה הפרדוקס - הפרדוקס בא ואומר שחברות . . . חברות נמדדות על Velocity, והיום יש Incentive שונה בין Velocity ל-Efficiency
- זאת אומרת שרוב החברות משקיעות ב-Velocity, וכשאני אומר ש”יש Incentive” זאת אומרת שהן מתוגמלות בשוק, בבורסה, בצורה שבה החברות נמדדות ב-Valuation
- ומכאן בעצם יש בעצם שרשרת של התנהלות שאומרת “אוקיי, אני צריך להוציא כמה שיותר מוצרים, כמה יותר פיצ’רים כמה שיותר מהר” - וה-Cloud זו פלטפורמה אידיאלית לדבר הזה.
- בדרך, שוכחים את הצד של העלות של ה-Cloud . . . ואז, כשמסתכלים פתאום על זה התוכן של החברות האלה ועל ה-Portfolio וה-Breakdown של ה-Revenue שלהן, מוצאים נתון די מדהים, לדעתי, שאיכשהו, כשמישהו שם אותו על הלוח, זה הפך להיות משהו מדהים -
- הרבה מאוד חברות SaaS שהן ב-Scale - אם זה Asana וכמובן Elastic ואחרים - נמצאות במצב שבו אחוז גדול מסך כל ה-revenue שלהן הולך ל-Infrastructure של Cloud . . .
- ויותר מזה - האחוז הזה הולך וגדל . . .
- זאת אומרת - ופה נכנס הפרדוקס - מצד אחד, הם גדלים, ומצד שני הריווחיות שלהן הולכת ונשחקת, במגמה כזאת, שהיא לא יכולה להדביק את הריווחיות שלהן . . .
- זאת אומרת שיש פה איזושהי מגמה שבה אני לא יכול לגבות עבור המוצר שלי בקצב שבו אני מוציא כסף . . .
(רן) למה זה נשחק?
- (נתי) זה נשחק כי אני לא יכול לגבות . . . יש לי מוצר נתון בענן, וכל פעם יש לי דרישה להוסיף לו פיצ’רים ולהגדיל אותו
- המשמעות של זה היא יותר ויותר Infrastructure
- עכשיו, יש הרבה “איים של Inefficiency” [בזרם?] שעוד מעט נדבר עליהם - ומה שקורה לאורך זמן זה שהעלות שלי הוא די קבועה, זאת אומרת שהיא גדלה באופן די קבוע - אבל ההכנסה שלי היא הרבה פעמים Flat, זאת אומרת, מבחינת מבנה ההכנסות . . .
- אז יש פה שחיקה - בעבור אותו מוצר, אני מתחיל להוציא יותר ויותר . . .
(רן) ההכנסה פר-לקוח . . .
(אורי) זה סוג של Inefficiency of Scale . . . אנחנו רגילים להגיד שצריך להיות לנו Efficiency of Scale מבחינת עלויות . . .
- (נתי) אנחנו כמעט ולא נמדדים עליו . . . כל המאמר מתמקד בנקודה הזאת, שאתה מודד את כל החברות על עד כמה מהר הם מביאים עוד לקוחות וכמה מהר הם גדלים, כמה פיצ’רים הם מוציאים . . .
- אז ברור שהצד השני - כמעט ואף אחד לא יסתכל עליו . . .
- הרבה פעמים אני זוכר בשיחות שהייתי הולך ו . . . זה בעיני הערך הכי גדול של המאמר הזה . . . הייתי הולך ומדבר עם מנהלי פיתוח ומדבר איתם על כל מיני דברים של איך כן לעשות דברים של Efficiency, והיו אומרים לי “אין לי זמן” . . .
- “אין לי זמן, אני עסוק כרגע, יש לי מיליון דברים לעשות - זה איפשהו ב-Back-Burner . . .”
- וכמעט תמיד זאת התשובה שהייתי שומע . . .
(אורי) אני רוצה להגיד משהו עם . . . בוא נשים שנייה את הבורסה בצד, בסדר, ונחזור ל-Basics של הכנסות-הוצאות: היכולת לייצר Efficiency of Scale מאפשרת לך, בגדול, To Scale the business more -
- כי, אם נסתכל על זה בצורה מאוד בסיסית, יש לך “דלי של כסף”, ואתה יכול, בגדול, להוציא אותו על שלושה דברים עיקריים - על Sales & Marketing, על פיתוח ועל Infrastructure . . .
- זה, נגיד, שלושת הדברים . . . ההוצאות הכבדות שיש.
- ב-Sales & Marketing ובפיתוח אתה משקיע באנשים - וזה הכוח שלך קדימה, בסדר?
- ה-Infrastructure הוא מקום ש - עד כדי הפגיעה בהתקדמות של אחרים, של האנשים - איפה שאתה יכול לאפטם (Optimize), תאפטם . . .
- כי כל השקעה ב-Human Capital . . . לא ה-Human Capital עצמו אלא ב . . . Human Capital יביא מכפילים על הכסף, בסדר?
- ו-Infrastructure, ברוב המקרים, לא יביא יותר מ-1:1 . . . זאת אומרת: שרת שמשרת X בקשות ביום - היום הוא ישרת X בקשות ומחר הוא ישרת X בקשות.
- איש מכירות עשה מכירה - מחר המכירה הזו ממשיכה לעבוד ולהביא Revenue, והמכירה שהוא יעשה מחר מביאה עוד Revenue
- זאת אומרת שיש עליו Revenue אינקרמנטלי . . .
- אנשי פיתוח, ואני חושב שגם Marketing, הם באותו מקום, ומוצר וכו’ - הם הופכים את איש המכירות ליותר יעיל, הם נותנים לו עוד כלים למכור והם גם לפעמים משקיעים ב-Infrastructure והופכים אותו ליותר יעיל . . . אז יש להם, אני חושב, תרומה אקספוננציאלית ל-Business.
- עכשיו - יש לך את הדלי הזה של הכסף, ותחשוב איפה אתה ועל מה אתה שם אותו:
- ב-Economy of Scale, תשים אותו על מה שמגדיל את ה-Business, ולא על מה שמביא תרומה יחסית קטנה או קבועה.
ואת ה-Basics הזה אנשים שכחו . . .
- (נתי) נכון . . . ואני אומר, וזה למשל משהו ש-Corey Quinn דיבר על הנקודה הזאת באמת - הוא טוען שהטיעון של Martin Casado מופרך, מכמה סיבות -
- 1 - מי שקרא את המאמר היה רואה שהוא מתבסס מאוד על המודל של Dropbox . . . מה Dropbox עשו? באמת עשו Repatriation, מהמילה “Patriot” - “לקחת את ה-Cloud הבייתה”.
(רן) בוא נזכיר רק . . . לא נקרא פה את כל המאמר, אבל בגדול - הוא מתאר סיפור של Dropbox לפני ההנפקה, שעשו, כמו שאמרת Repatriation, שזו מילה ממש קשה . . .
(נתי) . . .נכון, אני עשיתי חזרות לפני כן . . . .
(רן) . . . שזה בגדול אומר “לרדת מההענן וללכת ל-Datacenter משלהם” - לחלק מהשירותים שלהם - בוא נגיד שלא לכולם, בעיקר לשכבת ה-Storage, שהיא כנראה יחסית גם מאוד יקרה בענן וגם מאוד סטטית מבחינת . . .
(אורי) לא רק . . .זה עד כמה שהיא בשלה . . .
(רן) בדיוק - בשלה, תודה אורי.
אז הוא בא ואמר שכשהם עשו את הצעד הזה לפני ההנפקה, זה העלה מאוד את הערך של Dropbox בזמן ההנפקה, והם הגיעו שם למספרים די אסטרונומיים - משהו כמו פי-25, אני לא זוכר בדיוק מה המספרים, אבל בצורה מאוד משמעותית, לא ב-30 אחוז . . . גם אם, לצורך העניין, הם הצליחו להשיג הוזלה של 30%, השיפור במכפיל שלהם, או ב-Value או במה שאני לא זוכר . . .
(נתי) זה היה X24 . . .
(רן) . . . זהו, זה לא היה 30%, אלא זה היה פי-24 . . . ויש להם איזשהו הסבר ללמה זה?
(נתי) בדיוק . . .
(אורי) כי גם משקיעים מבינים את הדבר הזה שנקרא Economy of Scale . . . זה פינה ל-Dropbox הרבה מאוד כסף כדי להשקיע בחזרה בהגדלה של ה-Business . . .
- (נתי) נכון, אבל שווה רגע להתעכב על זה טיפה, כי אני חושב שזה הטוויסט הכי גדול בעלילה, במאמר הזה . . .
- עד היום, בכל השיחות של Efficiency, מה עשינו ומדדנו? אמרנו אוקיי, כמה עולה עכשיו . . . ניקח סתם “להרים VM”?
- אז עולה לך X$ בשעה וולצורך העניין, בענן פרטי אתה יכול להראות שאולי זה פחות.
- ואז אתה מגיע למיליונים.
- אבל ברגע שאתה מזיז את המדד הזה מ”כמה עולה ב-Datacenter שלך לעומת שרת בענן?” ל-”איך זה משפיע על הווליואציה (Valuation) של החברה?”, אתה מגיע פתאום למיליונים, ל”טריליון דולר” הזה שהוא מדבר עליו, ה”Trillion Dollar Paradox”.
- כי אתה כבר לא מודד את ההבדלים ב-Cost של ה-Infrastructure . . . .
(אורי) . . . כי הוא הכפיל את זה במספר החברות ש . . .
- (נתי) . . . לא רק מספר החברות - אלא איך החברות, איך כל דולר שאתה חוסך משפיע על הווליואציה.
- וברור שהווליואציה הרבה יותר רגישה למספר הזה - היא לא לינארית, היא לא אומרת “אה, חסכת דולר? אז המנייה שלך תעלה בדולר” אלא “חסכת דולר? אז כמובן במכפילים של כמות העסקאות שיש לך והלקוחות שיש לך זה שווה הרבה יותר”
- וזה הפך את זה ל”Trillion Dollar Paradox” ולא ל”Million Dollar Paradox” . . .
(רן) אגב, שווה לציין שזה טיעון שונה מהטיעון שלך, אורי - אתה אומר “חסכת דולר? תשתמש בו להשקעה ב-Human Capital או במשהו אחר”, והוא לא בא ואומר את זה . . .
(אורי) לא, אני חושב שזה פשוט . . . אתה יודע, אנחנו מדברים פה על מכפילים לווליואציות (Valuation), אז מכפיל לווליואציות - המשקיעים בוחרים על מה הם שמים את המכפיל . . .
- [כאן יש הסבר אפשרי מעניין]
- אז לפעמים הם שמים את זה על הגדילה, לפעמים הם שמים את זה על ה-Gross Revenue - והרבה פעמים הם שמים את זה על ה-EBITA, אז . . .
- (נתי) אז פה הוא מדבר על זה שהרבה פעמים מודדים ARR, בלי בהכרח למדוד את הדברים האחרים . . .
- (אורי) נכון . . .
- (נתי) . . ואם אתה מראה גדילה משמעותית ב-ARR, הווליואציה שלך בהכרח גדלה, גם אם אתה עושה את זה על חשבון זה שאתה מקטין את הרווחיות שלך . . .
- (אורי) . . . אני אומר שיש שווקים מסויימים ויש סגמנטים של שוק, שבהם דווקא מסתכלים על ה-EBITA ועל הגדילה ב-EBITA - וזה מדד לריווחיות ול”בריאות החברה”.
(אורי) תכל’ס - זה הרווח הנקי . . .
(רן) הרווח הגולמי?
(אורי) לא - הרווח הנקי . . . Earnings before interest, taxes, and amortization (EBITA) וכל הקללות האלה ש . . .
(אורי) כן . . . אז ה-EBITA הזאת היא מדד ל”בריאות ה-Business Model” של החברה, והרבה פעמים מקבלים על זה את המכפילים - ויש לא מעט חברות שאם הן תעבירנה את . . . אתה יודע מה, אני לא יודע . . . אבל ההבדל בין לרוץ ב-Cloud או לרוץ On-Premise הוא בין EBITA בריאה לבין אפס EBITA . . .
- (נתי) כן - אבל אם אתה מסתכל, אז רוב השוק של ה-Unicorns, שעכשיו זה השם הנפוץ ביותר במדינה, פחות או יותר, כשאתה מסתובב היום בהרצליה ובתל אביב . . .
- (רן) עוד חודשיים, כשנקליט את זה, זה יהיה כבר יהיה תטא-קורן . . .
- (נתי) כן . . . אז בסוף יש לך חברות, בסופו של דבר, כמו Uber, שאם הייתה מודד אותה על EBITA, לא היית נותן להם את הווליואציה שיש להם היום, אתה מסכים איתי, נכון?
- כי המודל הוצאות והכנסות שלהם לא היה, לפחות עד לא מזמן, לא כזה הגיוני . . . [ה-understatement הגדול בהיסטוריה?]
- מן הסתם, רוב החברות שהן יוניקורן, לפחות עד השלב שהן מגיעות לזה שהן יוניקורן ומתחילות להימדד על זה, הן נמדדות על ARR ועל גידול ובשלב הזה הן אפילו, חלקית [חלקית?] הפסדיות . . .
- (נתי) נכון . . . אז אנחנו בבועה, לצורך העניין, וזה איזשהו מדד מסויים, כנראה, גם של בועה - אבל היא לא אומרת שהיא הולכת להתפוצץ מהר . . . [לא אומרים משפטים כאלה . . . לא קראת קומיקס אף פעם?]
- יש איפשהו איזה כסף אינסופי שאני לא מצליח להבין אותו - טפו-טפו, כן - אבל אני חושב שזה היה, כשאני ככה “מקזז את זה”, זה היכולת להסתכל לא על “כמה עולה לי שרת ב-Datacenter שלי וכמה עולה לי שרת בענן” ולמדוד את זה שם ו”להישאר במגרש של הגרושים”, לצורך העניין - אלא להביא את זה פתאום לחברה . . . זה הפך את זה ל-”Trillion Dollar Paradox” מ-”Million Dollar Paradox”.
- וזה, פתאום, שם איזושהי מראה של “אוקיי, מה קורה פה? . . . “ יש פה משהו לא הגיוני.
(רן) אז נסכם, רק שנייה, את המאמר הזה של Andreessen Horowitz, שאני ממליץ, אגב, לקרוא, למי שמתעניין - אנחנו ממש נסכם אותו בקצרה -
- הוא בא ואומר “חבר’ה, מאיזשהו גודל מסויים, אתם לא צריכים להיות בענן - אתם צריכים לעשות Repatriation ל-Service-ים שלכם, זאת אומרת - לקחת את ה-Service-ים, להוריד אותם מהענן ולבנות אותם ב-Datacenter שלכם”.
- הוא בא ואומר “תראו חבר’ה, זה לא נכון, כל הסיפור הזה - זה אולי נכון במקרה של Dropbox”
- “למה זה נכון במקרה של Dropbox?” אז . . .
- (נתי) במקרה של Dropbox הוא אומר ש”מדדתם לא נכון כי הסתרתם חלק מהמידע” . . .
- (רן) יכול להיות - אבל הוא אומר למה זה: אולי זה נכון במקרה של Dropbox - אני אזהר פה - כי אומר ש”Dropbox סיימו לחדש” . . . .
- זאת אומרת, אין להם כבר פיצ’רים חדשים להוציא, הם הגיעו פחות או יותר לתקרת הזכוכית מבחינת איפה שהם יכולים לגדול ולחדש - אז כל מה שנשאר להם זה להיות יותר Efficient . . .
- אז אם אתם חברה כזאת, שכבר אין לה לאן לגדול - “סבבה, תלכו להיות Efficient”
- [זה מגיע עם תנועת יד ספציפית?]
- אבל לרוב החברות בעולם - יש להן עוד הרבה מאוד לאן לגדול, אז יותר נכון לגדול, גם אם זה על חשבון ה . . . EBITA? איך אמרנו?
- (נתי) כן . . .
- (אורי) אה . . .
- (רן) זה הטיעון שלו . . .
(אורי) כן, אתה יודע - ואז בא נתי שלום ואומר, בצדק אני חושב - תקן אותי אם אני טועה . . . Dropbox לא גמרה לחדש, בסדר? אין חברה חפצת-חיים שגומרת לחדש, כולם מחדשים.
וה-Sweat-spot הוא לדעת לתמוך בתשתית שנותנת את האג’ליות בחידושים - ולדעת לעשות אופטימיזציה ל-Core Business, על המקום שבו ה-Economy of Scale הוא מאוד מאוד חשוב.
- (נתי) אז א’ - במקרה של Dropbox, יש שם איזושהי אנומליה שהוא מתאר, שבעצם כשאתה מסתכל על הספרים וכשאתה מסתכל על ההוצאות שלהם על Infrastructure אז לכאורה זה נראה נמוך, אבל מאחורי זה מה שמסתתר זה סעיף אחר - של הוצאות על אנשים והוצאות על Datacenters ,שלא נכללו בסעיף ההוא, והם מופיעים פשוט בסעיף אחר . . .
- ואז הוא אומר שיש פה משהו שבסך הכל המספרים הם לא כמו שהם מתארים.
- זה עדיין יותר זול, אבל . . .
(אורי) נתי - בתור אחד שמכיר את המספרים מהחברה שלו וזה . . . - ההוצאות על האנשים שתומכים ב-Infrastructure הזה הן Fraction of a fraction ממה שעולה . . . עליות של Cloud. זה טיעון של מישהו שלא בדיוק יודע איך עובדים ב-Cloud . . .
- (נתי) אז זה לא סותר את התיאוריה, זה רק אומר שהמספרים הם לא “כצעקתם”, מה שנקרא.
- לכן אני שם את זה שנייה בצד ואומר - יש כאן טיעונים, צריך להכיר אותם, וכנראה ש-Dropbox, מה שנקרא, “מינפו את הפוזיציה” הרבה יותר ממה שהיא באמת, אבל הגרעין של הטיעון - הוא עדיין עומד עליו . . .
- זה הניתוח שלי לפחות - שלמרות כל הרעש על זה והביקורת שלעשות Repatriation זה דבר שהוא גם מאוד יקר ופוגע באג’יליות - בסופו של דבר, אני חושב שהטיעון המרכזי זה Efficiency vs. Velocity
- היום חברות נדרשות ל-Tradeoff הזה, וזה הגורם העיקרי.
- עכשיו - יש הרבה מאוד דרכים, ואולי נדבר גם על זה, לעשות Efficiency בתוך הענן - לפני שאתה עושה Repatriation,
- בעצם, Repatriation הוא אחד האמצעים לעשות אופטימיזציה - מאוד קיצוני יחסית, ויש הרבה יחסית שאיחרו את הרכבת, או שלחילופין המהלך הזה יהיה להם מאוד מאוד יקר וכואב, למי שלא בנה את זה מראש, כמוך [אורי], או למי שלא תכנן את זה - זה לא יהיה לו טריויאלי.
- אבל הטיעון המרכזי הוא Efficiency - אני צריך לייעל את הצורה שבה אני צורך משאבים ואני צריך להסתכל על איך אני צורך משאבים בצורה מאוד נכונה.
- עכשיו - למה זה מורכב? כי אם אתה מסתכל היום מה הן האפשרויות שלי להגדיל את ה-Efficiency בענן, אז בוא נסתכל על הפתרונות שיש לי . . .
- יש לי פתרון אחד, שזה כל מיני כלים שנותנים לי Cost . . . מה הבעיה עם זה?
- א’ - זה בדרך כלל After the fact
- ב’ - ההמלצות שאתם תראו אם תשתמשו בכלים שנותנים לכם Cost מקסימום יגידו לכם “הנה Alert על איזה מישהו טיפש שהשאיר את המכונה שלו ולא סגר את זה!”
- אוקיי, סבבה, מתישהו אתם לומדים גם לנהל את ה-Policy הזה - אבל . . . .
- לפעמים הוא גם יגיד לך אם אתה מחזיק מכונות גדולות ואתה יכול להקטין אותן וכל מיני דברים כאלה
- אבל אתה תמצה את המהלך הזה יחסית מהר, ה-Value של האינפורמציה הזו הוא די יגיע למיצוי בתוך כמה חודשים, וכבר הגעת למיצוי של מה שאתה תקבל
- ואז אתה תתחיל לקבל הרבה מאוד “רעש” כזה, כמו בחברות Security - המון רעש על Alert-ים, וזה בעצם יהיה רעש ואתה לא תקשיב לזה בכלל, וזה יכנס לך ויצא מהאוזן השנייה.
- אז זה כל החברות Cost . . .
- הדבר השני שיש לנו זה כל החברות אוטומציה - מה הבעיה עם אוטומציה? נתתי דוגמא דווקא מ[יובל] נח-הררי, שמאוד אהבתי את ה . . . מאמר אחר לגמרי, לא קשור בכלל לנושא הזה . .
(רן) “מאזיננו יובל” . . .
- (נתי) כן, יובל נח-הררי, חבר שלי מהמסטינ”ג . . . לא, סתם
- יש לו אגב פודקאסט מאוד מעניין עם [מארק] צוקרברג, גם נושא לשיחה אחרת . . .
- אז הוא בא ואמר משפט שאני עכשיו נוהג לצטט אותו הרבה - “כלי בסוף תלוי במה שאתה עושה איתו” . . .
- והוא נתן את הדוגמא של הסכין - שזה כלי שאתה יכול לחתוך איתו סלט ולהכין אוכל מצויין, אבל אתה גם יכול להרוג איתו . . . זה אותו הכלי.
- אותו הדבר לגבי כלי האוטומציה - אנחנו הרבה פעמים אומרים “אוקיי, איך אני אחסוך? אני אעבוד ל-Spot!” או “איך אני אחסוך? אני אעבור ל-Kubernetes!” או “איך אני אחסוך? אני אעבור ל-Terraform!”
- מה קורה בדרך כלל לחברות אחרי שהן עושות את המהלך ל-Kubernetes? אתה שואל אותן “איך היה המעבר? עד כמה זה באמת היה Efficient יותר?”
- אז הם אומרים לך “אג’ילי! אג’ילי! אג’ילי! - אבל ב-Cost זה Sky-rocketing . . . “
- למה? כי נוצרה גם, עם המעבר לכלי האוטומציה הזה, איזושהי אבסטרקציה עוד יותר גדולה ל-Cost, כי עכשיו אתה לא באמת יודע מה רץ ואיפה
- וגם עניין של קלות - פתאום עכשיו להרים סביבות ו-Containers ניהיה נורא קל, אז מעיפים Container-ים על ימין ועל שמאל, והרבה מאוד סביבות . . . אתה מכיר את זה גם, אני חושב . . .
- הרבה יותר ממה שהיית צורך קודם, אפילו ב-Monolith . . . אם תשווה את ה-Monolith שהיה לך קודם לעומת ה-microServices שיש לך היום, ואת כל הסביבות Development שאתה מריץ לצד זה, וכל ה-Overhead-ים שיש לזה . . .
- פתאום רואים שהעלות שלהם גדלה וגדלה וגדלה - בקצב מאוד גבוה.
- והסיבה היא שכלי האוטומציה באמת נותנים Efficiency - הם מביאים אותך ל-Efficiency, אבל הם גם, באותה מידה, מורידים את ה-Efficiency מעצם זה שהם עושים אבסטרקציה ו”מחביאים” את ה . . .
- (רן) מייצרים שכבת Overhead משמעותית, לא זניחה . . .
- (נתי) והיום, אין את היכולת באמת לתווך בצורה טובה בין המשתמש ל-Infrastructure - וכך אנחנו מגיעים לנקודה הזאת, ואז יש . . .
(אורי) אני חושב שמהניסיון שלי, אין תחליף למישהו שמדי פעם מסתכל על ה-Cost ואומר “חבר’ה, ברחנו פה . . . בואו, תעשו סיבוב ותראו איך אתם מאפטמים . . . “
- [ובינתיים, ב-Pinterest . . . ]
- (נתי) נכון - ואני אגיד לך שגם זה בעייתי, ותיכף גם נגיע לאיזשהו, הייתי אומר “Pattern של פתרון” או כיוון מסויים של פתרון, שקיים בכמה תעשיות כבר . . .
(רן) זה מה שהזכרת כ”חברות ה-Cost” - חברות שמציפות את ה-Cost הבעייתי . . .
- (נתי) זה כמו חברות Security, באיזשהו שלב . . . כי מה הבעיה? בוא, אני אראה לך ואפרוש לך עכשיו את כל הכלים של אופטימיזציה, ואז תבין איפה הבעיה - יש לך בעצם ארבע קטיגוריות של אופטימיזציה:
- יש לך קטיגוריה אחת שזה ברמת ה-VM, ה-Compute וה-Storage - אז אתה יכול ללכת מ-Spot ל-Reserved ל-VM יותר גדול . . . עם GPU, בלי GPU, כל מיני - אופטימיזציות ברמה הזאת, של ה-Infrastructure.
- יש ברמת Policy - שזה בעצם להגיד “אוקיי, מכונה שלא השתמשת בה, אתה יכול להרוג”, “אם זה ב-Development תעשה ככה” - ויש כל מיני נושאים של מדיניות.
- ויש ארכיטקטורה - Kubernetes ו-Containers, אם זה Fargate או לא Fargate, או שזה Serverless או לא Serverless - כל מיני היבטים כאלה.
- [עוד קטיגוריה?]
- ועכשיו, כשתסתכל על כל הדבר הזה, ותגיד “אוקיי, אני רוצה לעבור, למשל, מ-VM ל-Spot” - אז זה, לכאורה, פשוט: אתה לא צריך לעשות כלום . . .
- איפה אתה נופל? אם האפליקציה שלך היא Stateful, אז לא בדיוק בדיוק יעבוד, זה דורש שינוי ארכיטקטוני . . .
- זה כמעט כמו לעבור ל-microServices - השינוי הארכיטקטוני הזה הוא כבר שינוי קוד, ושינוי קוד זה כבר לא דבר פשוט
- זה לא שמישהו יצעק לך “אתה מאוד לא Efficient פה!” - ומחר אתה יכול להיות 30% יותר Efficient . . .
(אורי) מה שאתה אומר זה שזה לא משנה אם אתה תעבור מ . . . לא יודע, מ-Cloud ל-On Premise או מ-Monolith ל-microService - עצם זה ששינית State of Mind ואתה מתחיל להיות Mindful, למודעות - זה יצריך ממש השקעה . .
- (נתי) בדיוק - הרבה השקעה ולאורך לא מעט זמן, כי בוא ניקח את הדוגמא הכי טובה לחברות שיודעות לעשות Scale - אלו חברות ה-Cloud עצמן . . .
- מה קורה בחברות האלה? הן . . .
(אורי) אגב - הם ידעו כל כך טוב לעשות Scale שהן הרימו את ה-Cloud . . .
- (נתי) נכון . . . אבל אני אומר “איך הם עושים את זה?” אפשר ללמוד מהן, זאת אומרת - יש להם על כל צוות, על כל מוצר, כשהם עושים S3, הצוות הזה לא עובר רק לפתח את הפיצ’ר הבא אלא הוא עובד מאוד מאוד חזק בלמצוא פתרונות שמורידים את ה-Cost עבורם
- ולצורך העניין מגדילים את ה-Margin ואת כל האופטימיזציות שיש אחרי זה, לאורך זמן - משקיעים בזה המון.
- זה לא שזה קורה “כדרך אגב”, זה לא שמישהו אומר להם “אה, ה-Cost שלך יקר, בוא תוריד אותו” - ופתאום משקיעים בזה, עושים שינוי של Priorities ומשקיעים בזה.
- זה חלק מאוד מאוד משמעותי בהתנהלות שלהם, זה חלק חלק מאוד משמעותי ב-Incentives שלהם
- זה יכול להיות חלק מאוד משמעותי באיך שהם מתכננים את ה-Roadmap-ים שלהם - וזה פיצ’ר לכל דבר ועניין, והוא מקבל את אותה עדיפות כמו פיצ’ר שהוא Customer-facing . . .
- אז זה, קודם כל, משהו בצורת ההתנהלות שצריך להיות מאוד שונה - ולהבין שזה On-going, זה קשה, אין פתרונות קסם פה ולא יבוא איזה “פתרון מהצד” ויפתור לכם את הבעיות. זה כל הזמן צריך להיות . . .
(רן) זאת אומרת, אתה אומר ש”Cost צריך להיות פיצ’ר”, לצורך העניין? . . .
- (נתי) כן . .
(רן) “אל תייצר לי פיצ’ר שנותן ל-User לעשות File Upload - תייצר לי פיצ’ר שנותן ל-User לעשות File Upload בפחות מ-5 מילי-סנט . . .”
- (נתי) בדיוק - ותמדוד את זה, ותתגמל על זה . . . כמו שאתה מתגמל על דברים אחרים.
- ואז זה הופך להיות, ברמת ההתנהלות, זה הופך להיות משהו חשוב שה-Business מודע אליו - ואז אתה מייצר את התרבות הזאת, שאתה נותן לזה Attention . . . - וזה, לכשלעצמו, עדיין לא מספיק.
(רן) אבל אז, זאת אומרת, אנחנו חוזרים ל-Tradeoff שהצגת בהתחלה - האג’ליות מול ה . . . סליחה - ה-Velocity מול ה-Efficiency: ברגע שאתה עובד על ה-Efficiency, אתה באותה רגע פוגע ב-Velocity . . .
- (נתי) אז נתתי את הדוגמא של חברות ה-Cloud - הם מצאו פתרון לזה . . . אז הם באו ואמרו - ובואו נלמד מהם, כי אני חושב שיש כאן איזה בית ספר שאפשר ללמוד ממנו.
- אז עובדה שהם משקיעים בזה הרבה, וכן - זה בא על חשבון Velocity, לכאורה.
- אבל זה לא באמת בא רק על חשבון Velocity, כי זה פיצ’ר - ושוב פעם זו הסתכלות מאוד לא נכונה על Efficiency . . .
(רן) לא, אני הייתי אומר שזה בא על החשבון - וזה בסדר: ברור שזה בא על חשבון זה, כי את זה הבנו, וזה Tradeoff ואי אפשר להתחמק מזה . . .
- (נתי) כשאומרים ש”זה בא על חשבון”, אני אומר . . . הרי מה המטרה שלך בפיצ’ר? בסופו של דבר, אתה מביא פיצ’ר כדי להגדיל ערך - אבל פה גם הגדלת ערך! רק במימד אחר . . . [איפה אסימוב כשצריך אותו?]
- שפחות רואים אותו ופחות יודעים עליו - רואה אותו רק מי שמסתכל בסוף על המספרים . . .
- אתה פחות רואה את זה . . . אתה לא יכול לשים איזה PR ולהוציא על זה Announcement . . .
(רן) דרך אגב, מכל הסיפור הזה של מדידת עלות בענן, של אוטומציה של עלות וכו’ - יש לזה כבר שם, אז בואו ניתן לזה אתה השם: היום קוראים לזה FinOps [!], לא יודע אם כבר ראיתם או לא . . . ויש כמה חברות בתחום הזה וגם כמה חברות ישראליות . . .
- אז אם נתקלתם בשם הזה שנקרא FinOps - אז זה כל התחום של עלויות בענן ו”ייעול בענן”.
(אורי) אני רציתי להגיד עוד משהו על האג’ליות של המוצרים החדשים וזה . . . אתם יודעים, זה סוד כזה שאולי קצת לא מדברים עליו, אבל נתקלתי לפחות בחברה אחת שאומרת “רגע! אני באתי, ייצרתי מוצר שהוא SaaS בענן, ובעצם אני עשיתי את ה-Trail & Error, אני בניתי . . . וברגע שהוכחתי שזה עובד וזה הצליח לי - באו AWS והעתיקו אותי ו . . . “
(רן) הקלטנו על זה פרק [קוסמי! 365 Carburetor 26 - open source politics], אבל . . . זה נכון, וזה נושא כאוב ומעניין . . .
(אורי) אז אתה אומר, כאילו - באיזה Innovation בדיוק הם משקיעים, אם הם . . . וואלה, יש חברות אחרות שלוקחות את ה-Cost של ה-Trail & Error, ואז הם פשוט באים, עושים את אותו הדבר ו . . .
- (נתי) מיקרוסופט המציאו את הדבר הזה, כשעוד הייתה להם את מערכת ההפעלה והם עשו את הדבר הזה . . .
- וכן, זו מציאות שאני חושב שלא תשתנה, כנראה, ועל זה יש לנו פחות שליטה, אז אני פחות מתעסק בזה.
- כולם חווים את הכאב הזה - וזה כואב וזה מעצבן, ואני לא רואה את זה משתנה בדינמיקה הזאת יותר מדי . . .
(אורי) אני רוצה לומר שרוב ה-Cost שיש ביצירת Innovation היא בטעויות . . .
- (נתי) נכון, אז אתה אומר שבהגדרה השלב הזה הוא עוד לא Efficient כי אתה לומד מטעויות . . .
(אורי) כן . . .
- (נתי) אז זה סבבה - אבל בוא נלך שנייה על איפה אני חושב שכן יכולה להיות הקפיצה הבאה, ויש פה, לדעתי, איזושהי בשורה שאפשר כן לצאת ממנה בשיחה הזאת, ולפחות . . . חשבתי על זה הרבה והגעתי לאיזושהי תובנה בהקשר הזה ואני אחלוק אותה איתכם:
- התובנה באה ואומרת כזה דבר - אם אנחנו מסתכלים על הנקודות Scale בעולם ה-Cloud, אז יש כל מיני נקודות, שראינו את הקפיצה פתאום -
- נקודה אחת זה כשיצאו ה-VM-ים והפכנו מכונות פיזיות לווירטואליות, ובנקודה הזאת בכלל נוצר הענן - בלי זה בכלל לא היה לנו היום ענן ולא היינו מדברים בכלל.
- הנקודה השנייה הייתה המעבר ל-Containers ואחר כך ל-Kubernetes, שבעצם הביאו לנו את היכולת לנהל מערכות מאוד מורכבות וגדולות
- יצאנו מ-VM-ים ל-Container-ים וזה היה, דרך אגב, גם נקודה סינגולרית מאוד מאוד משמעותית.
- אחרי זה יש את ה-Infrastructure-as-a-Code
- והיום, אחת הבעיות לאופטימיזציה - ואני בא קצת מעולם של Databases אז אני מכיר את זה טוב - זה מאוד קשה לעשות אופטימיזציה כשהעולם שלך הוא Security Group וכשהעולם שלך זה VPC, וכשהעולם שלך הוא כל מיני נקודות כאלה ב-Infrastructure . . .
- כי ככל שאתה מסתכל על “הפסיפס” ואתה מנסה לעשות אופטימיזציה, מאוד מאוד קשה לך לראות את התמונה הגדולה ולראות איפה “ה-Pocket הכי גדול שלך” ולעשות את האופטימיזציה שם . .
- ואנחנו קצת תקועים פה . . .
- עכשיו, לדעתי צריך להיות . . .
(אורי) “תקועים בפרטים”, אתה אומר . . .
- (נתי) תקועים בפרטים, בדיוק - ולכן ה-Complexity הוא זה שמייצר את המורכבות, שלא מאפשרת לעשות את ה . . .
- תיארתי כל מיני שיטות לאופטימיזציה - זה יכול להיות Policy זה יכול להיות לעשות Scaling או שזה Spot, שזה היכולת לשלוט ב-VM-ים - אבל היכולת ליישם את זה היא מאוד מאוד קשה.
- ואז, אם אני לוקח את זה הלאה, אני אומר “אוקיי, חייב להיות פה משהו נוסף שמשנה את המשחק בעוצמה של המעבר מ-VM-ים ל-Container-ים, בעוצמה של המעבר מ-Container-ים ל-microServices ול-Infrastructure-as-a-Code”
- והדבר הבא שאני מסתכל עליו זה היחידת בניין - “Templatized Environments” . . .
- היום, אני כבר לא מסתכל על Container, או אפילו על microService - יש לי Template לכל דבר.
- היום אני אמצא Template ל-Machine Learning ו-Template ל”איך אני עושה Monitoring?” ו-Template . . .
- יש לי המון Tamplte-ים מסוגים שונים וחלקם כתובים ב-Terraform וחלקם ב-CloudFormation וחלקם ב-Azure Hub, חלקם בשפה אחרת - אבל אני כבר יכול להסתכל על Building Blocks יותר crossgrade - מערכות . .
- נגיד “RDS כמערכת” - לא מעניין אותי איך ה-RDS הזה בנוי, אני מקבל אותו כיחידה
- ועכשיו, כשאני מסתכל עליו כיחידה, אני מנסה לאפטם (Optimize) אותו כיחידה ולא את כל ה-Bits וה-Bytes - את זה כבר מישהו אחר עשה.
- וזה מאפשר לי, פתאום, להסתכל על אופטימיזציה של מערכות
- ולאן זה מביא אותי? זה . . .
(רן) רגע, אני לא בטוח שאני איתך . . . בוא, אני אגיד את זה בשפה שלי ואתה תגיד לי איפה אני טועה:
- אתה אומר שיש כל מיני סוגים של Workloads - נגיד Database רלציוני זה סוג אחד של Workload ו- Web Service זה סוג אחר של Workload
- (נתי) Kubernetes Cluster זה גם . . .
- (רן) אוקיי, נגיד Spark או Big Data Processing זה גם סוג אחר של Workload . . .
- (נתי) נכון . . .
- (רן) אז בוא נשים כל אחד מה-Workloads האלה “בתוך קופסא” - נגיד שניתן להם APIs וניתן להם שם - ועכשיו, את כל אחת מהקופסאות האלה אנחנו נוכל לאפטם, בצורה שהיא לא שקופה החוצה, זאת אומרת - ה-API אליהן לא ישתנה.
- לצורך העניין, אם אני שולח בקשה ל-Database אני תמיד אקבל תשובה - ולא חשוב איך הוא בנוי, בין אם זה ממומש ב-SQL או שזה ממומש ב . . .
- (נתי) בוודאי . . .
- (אורי) אבל הקופסא היא Optimized . . .
- (נתי) הקופסא Optimized - אבל כשאנחנו אומרים “Optimized”, זו אף פעם לא אותה האופטימיזציה - ועכשיו תיכף נגיע לשלב הבא . . .
- אז השלב הראשון היה להגיד, כדי בכלל להגיע לרמה הבאה, אנחנו צריכים לעלות קומה - כמו שעשינו עד עכשיו, אנחנו צריכים לעלות קומה בגרנולריות (Granularity) וביכולת שלנו
- האבן-בניין צריכה להשתנות - מפסיפס ללבנים ומלבנים לבלוקים ומבלוקים לאיטונג, או לא יודע איך נקרא לזה . . .
- אז כשהאבן-בניין גדלה, אז אני יכול להסתכל על גורדי-שחקים -
- כשאני עובד עם פסיפס, אני לא אבנה גורד-שחקים, מקסימום אני אבנה קומה אחת . . .
- אז האבן-בניין היא נקודה מאוד קריטית פה.
- השלב השני זה באמת מה שהתחלת לגעת בו - זה היכולת לעשות Decoupling בין ה-Workload ל-Infrastructure.
- כי ברגע שאני יכול לעשות את ה-Decoupling הזה, אני יכול באמת להגיד עכשיו על כל יחידה שהיא אופטימלית - ועכשיו אני יכול להדביק את ה-Workload ליחידה הכי אופטימלית לצורך הזה . . .
- ואם אני עושה את זה סטטית, אז אני אהיה Semi-optimal, כי קיבלתי את ההחלטה בנקודת זמן מסויימת ולא בטוח שהיא תמיד תיהיה נכונה לאורך זמן
- כי המשפט הזאת של “אופטימלית” הוא דבר דינאמי - כי ה-Load משתנה.
(אורי) אני זוכר שהקלטנו פעם פרק עם חברה . . . אני לא זוכר איך קראו לה, היא ישבה פעם ביקנעם [עדיין], זה היה שם משהו עם ”ז’ באדר ב’” או משהו כזה [א’] . . .
(אורי) אבל הם נותנים פתרון Storage לכל העננים, לכל ה-API-ים של העננים למיניהם - ושאלנו אותו איפה הוא בתכל’ס מאחסן - והוא ענה ש”אנחנו לא מאחסנים בענן - אנחנו יושבים ליד העננים וכו’, אבל האופטימיזציה שלנו ל-Cost היא בזה שיצאנו החוצה, ואנחנו נותנים, לצורך העניין, Building Blocks הרבה יותר גנריים של ‘הנה - Storage!’, פתרון Storage אופטימלי” . . .
- (נתי) נכון . . .
- (נתי) אני אומר שאפילו אם זה בענן, אפילו אם זה בענן - ושוב פעם פרשנו “מיליון אופציות” על להריץ את אותו הדבר בענן, יש לך רק על Kubernetes את Fargate ויש לך את . . .
- יש להם גם Services מסוגים אחרים - יש להם User Interface, יש להם . . .
- (אורי) יש להם Docs! . . . [הפנייה מעגלית ל-Paper]
- (רן) יש להם Docs . . . יש להם הרבה סוגים של Services, והם לקחו את אחד מהם - רק את ה-Storage - בודדו אותו, ורק אותו הוציאו מחוץ לענן . . .
- (נתי) אז אני אומר . . .
(אורי) אני חושב שבתור חברה אתה רוצה לאפטם את החלקים הגדולים של ה-Cost model שלך - גם Netflix, עם כל הסיפור של “אנחנו בענן . . . “ - את ה-CDN הם הוציאו החוצה.
- (נתי) אז אני מסתכל על זה קצת יותר רחב - אני אומר שזו אחת האופטימיזציות, כנראה המשמעותית יותר, אבל לא לכל דבר היא מתאימה ואני חושב שזה די ברור
- אבל יש עוד הרבה אופטימיזציות, הרבה דברים שלא דורשים בהכרח דברים כאלה קיצוניים או דרמטיים - ופרשנו פה כמה מהדברים האלה.
- אבל היכולת שלי להשתמש בהם - זה החלק המורכב: אם אני אהפוך את היכולת שלי להשתמש בהם ליותר פשוטה, אז אני אוכל להגיע לנקודה הזאת.
- ופה אני אומר - אם אני יכול להגיע לאופטימום, שזה The right infrastructure for the job, ואני אגיד עכשיו איזה משפט שאני חושב שכל אחד יסתכל על העולם שלו ויבין על מה אני מדבר:
- היום, כמה פעמים אנחנו בעצם מריצים את ה-Workload שלנו מסיבה שהיא "Least-Common-Denominator”?
- זאת אומרת שאת ה-Production system שלנו, למשל, אנחנו נריץ הרבה מאוד Dev ו-Test ועוד כל מיני דברים על אותה Production Environment.
- עכשיו - אני לא צריך ל-Dev ו-Test את ה-SLA של RDS - אני יכול סתם להשתמש ב-Database לצורך העניין . . . אני לא צריך Network מורכב, אני לא צריך עוד המון דברים, ברמת ה-SLA, שיש לי היום בסביבת Production . . .
- אבל מסובך לי לייצר עכשיו סביבה שהיא ייעודית ל-Development אז אני לא אעשה את זה - ואז אני נשאר במכנה המשותף הזה שצריך לשרת הרבה מאוד Workloads.
- אז בהגדרה, אני לא Optimized . . .
- (נתי) תסביר לי את המשפט הזה, איך זה יכול להיות? . . .
(רן) כשזה גם ככה לא עולה כלום . . .
(אורי) לא - כשזה שקוף לך איפה זה רץ . . .
- (נתי) לא - אז השקוף זה תנאי, אתה צודק . . . השקוף זה תנאי, אבל אני צריך בסוף להגיד, וניתן את הדוגמא של Dev-Production כי זו הדוגמא שהכי קל לאנשים להבין אותה -
- אם אני יכול, לצורך העניין - אני רוצה עכשיו רק לבנות פיצ’ר ולבדוק אותו
- אני לא צריך עכשיו שתריץ לי EKS בשביל הדבר הזה . . . אם תיתן לי Kubernetes שרץ לי על VM, או minikube או K3S או Whatever - את אותו API של ה-RDS, שזה בעצם Postgres, את אותו Storage של S3, שזה יכול להיות MinIO, בסביבה שהיא Sandbox - סבבה לי.
- אני יודע לעשות את זה . . . תמיד יהיו לי את ”החיצים החוצה”, כי אני לא אריץ את הכל באותו VM - אבל אני מקבל פה מה שנקרא היום, ה-Buzzword החדש בעולם של ה-DevOps - זה “הדמוקרטיזציה של ה-Development”.
- היכולת שלי באמת לא להיות תלוי ב-Shared Environment, להגיע ל-Agility, להגדיל את כמות הטסטים וכל מיני דברים מהסוג הזה.
- אבל אני יכול ממש לבנות Stack, די בקלות, במיוחד כשיש לי Building blocks שחוזרים על עצמם, שזה בדרך כלל Kubernetes ו-Terraform ו-Ansible - כל מיני יחידות כאלה שהן . . . אני יודע כבר למדל אותן בתוך כאלה “קופסאות קטנות” - לקופסא גדולה.
- אני יכול להגיד עכשיו שאני מריץ את זה ב-Dev - אני לא צריך GPU, אני יכול להריץ את זה בלי GPU
- וזה, דרך אגב, ירוץ יותר לאט - אבל אני לא חייב את המכונה עם ה-GPU ה-High-end כדי לבדוק את הפיצ’ר עצמו ברמת הפונקציונאליות.
- עכשיו, אני זורק כל מיני דברים - ברור שזה לא יתאים להכל, אבל העיקרון הוא שאם אני יכול כן להגיע למקום שבו אני יכול להצמיד את The right infrastructure for the workload, אני אגיע למקסימום אופטימיזציה
- ועכשיו יש את המציאות - אני אף פעם לא אגיע ל-100% של זה, כי זה תמיד מסובך, אבל אני יכול להגיע קרוב לזה.
- וככל שאני אגיע קרוב לזה, אני אהיה קרוב לאופטימום.
- [על פניו, נראה שבאינטל עכשיו טוענים שהם יכולים לעשות משהו דומה ברמת ה-Hardware . . .]
- וחלק מה-right infrastructure for the workload זה גם ה-Repatriation - להריץ בזה . . . כי ל-Workload הזה, למשל, של Storage או של CDN, המשמעות של “The right infrastructure” זה On-Prem . . .
- ולמשהו אחר, שזה Dev Environment, זה דווקא לא On-Prem, כי זה משאב שהוא מאוד מתאים ל-Production use-case ולא מתאים ל-Dev Use case.
(אורי) אז מה שאתה אומר זה שב-Dev אני משתמש בפחות Load - אני צורך פחות משאבים . . .
- (נתי) . . זה גם לא ה-SLA שלי, שזה העיקר - ה-SLA שלי הוא בכלל . . . אני לא צריך SLA של Production . . .
(אורי) נכון - ואני יכול לנסות את זה גם בסביבה “יקרה”, כי אין כאן Economy of Scale, להיפך - יש פה Economy of Velocity . . .
- (נתי) נכון . . . וכמה עושים את זה?
(אורי) אני חושב שזה הפתרון, נגיד . . . לא יודע אם זה הפתרון, אבל זה השימוש הנכון בעולם כזה - שאנשים מבינים שאין דרך אחת: יש כמה דרכים, יש כמה פתרונות, וצריך To use the right tool for the problem.
- וצריך להבין - Cloud זה Optimized ל-Velocity . . .
- (נתי) על חשבון Cost אפילו . . .
- (אורי) על חשבון Cost - כי Cost לא מעניין אותנו בשלב הזה, הוא . . . ה-Velocity מעניין אותנו ולא ה . . .
- ו-On-Prem, לצורך העניין, או סביבות יותר אופטימליות - זה במקום שאתה צריך Economy of Scale.
- (נתי) אז אני מתמצת את זה בזה שאני אגיד ש-The right infrastructure for the Job הוא האופטימום . . . עכשיו שכל אחד יעשה את החושבים אצלו ויגיד “כמה באמת אני קרוב לאופטימום הזה?”
- אני חושב שהרוב יסתכלו ויגידו “וואו, אני רחוק שנות אור מהדבר הזה - אבל יש לי פה מקום אחד שאני יכול להגיע לזה . . .”
- שזה, למשל, Dev-Test, שזה משהו שאני מתחיל לראות כאיזשהו Pattern שמתחילים להתמודד איתו . . .
- (אורי) אבל Dev-Test זה לא אצל מי שעושה Repatriation . . .
- (נתי) לא לא לא . . .
- (אורי) ה-Repatriation . . .
- (נתי) אמרתי - ה-Repatriation, למי שלא עשה את זה כמוך, בהתחלה - זו עצה מצויינת, מאוד קשה ליישום . . .
- יהיו כאלה שבאמת יש להם Workload שהם יודעים כבר לאפיין אותו טוב וה-Benefit הוא כל כך גדול שהם יהיו מוכנים ללכת את ה-Journey הזה והם יעשו אותו,
- אבל זה יהיה במקרים מאוד מאוד ספציפיים - וב-Scale מאוד מאוד גבוה . . .
(רן) אבל בואו נזכור שזה לא צריך להיות All-or-Nothing . . .
- (נתי) נכון - זה אחד הבילבולים . . . זו אחת הטעויות, לדעתי, גם בכתיבה של המאמר - שהוא שם את כל ה-Bucket על Dropbox, אז כאילו אנשים יצאו על זה ואמרו “רגע! אבל אני לא Dropbox, מה זה אומר?”
- ואני חושב שהעיקרון שלו היה Efficiency ולאו דווקא Repatriation . . .
(אורי) אני חושב שיש פה כמה מפתחות, ואתה יודע - אני עכשיו מחליף רכב להיברידי-נטען, וכשאני מסתכל על כל הרכבים החדשים בשוק - אין כבר מנועי בנזין “נטו” . . . יש היברידי והיברידי-נטען, וכבר מתחילות להיכנס חשמליות ובעוד 10 שנים - זהו.
אני חושב, והמאמר הזה היה פוקח עיניים, למי שלא נפקחו לו העיניים עד עכשיו . . .
(נתי) לא אמרת “אמרתי לך” . . .
(אורי) נכון . . .
(נתי) הייתה לך פה הרמה להנחתה עכשיו . . .
(אורי) . . . ואנחנו נתחיל לראות, כמו שיש את כל החברות ש”מעבירות ל-Cloud”, אנחנו נתחיל לראות חברות שעוזרות לעשות Repatriation - והמפתח פה הוא ידע.
זה מסוג האומנויות שנשכחו, והמפתח פה הוא ידע, ועם הידע הזה מגיעה גם הקלות - כמו שניהיו מלא מוצרים שהופכים לך את המעבר ל-Cloud לקל, אז יהיה גם ההיפך.
ואני יכול להגיד שגם, אתה יודע - ב-Outbrain הגענו למצב שזה לא משנה למפתח איפה זה רץ, חוץ מזה שאנחנו יכולים לדאוג לעניין של העלות - הוא פשוט את ה-Deployment יעשה ל-Datacenter X או ל-Datacenter Y וכן - Datacenter X נמצא ב-Cloud, וזה אותו Deployment . . .
- (נתי) ואני אומר שאפשר להגיע למקום עוד יותר גבוה מזה, במרחק נגיעה ממה שאתה אומר עכשיו - שהוא גם לא יצטרך לדעת באיזה Datacenter זה רץ - הוא פשוט יגיד “אני רוצה Dev Environment”, ואתה תדע להגיד לו מה ה-Environment המתאים
- “אני רוצה Production Environment ואני רוצה Machine Learning” - ואני אגדיר לו את ה-Environment הנכון עבורו . . . הרבה פעמים זה סוג של . . .
- (אורי) . . . סביבה זה . . . יש לנו ב-Datacenter אחד סביבה כזו וסביבה כזו . . .
- (נתי) אפשר, בגישה הזאת, כשהולכים איתה, אפשר ממש לגדול ברמת Efficiency - בשנייה שאתה מצליח לעשות את ה-Decoupling הזה, אז על הציר הזה, שבין ה-Workload ל-Infrastructure יש המון המון מקום לחוכמה.
- יש משפט, שהרוב לא יגיעו אליו כי הוא ממש בסוף המסמך, ממש למטה, שהוא מסכם את זה ככה: The biggest potential זה חברות שיצליחו לפצח את הממשק בין ה-inefficient code ל-Infrastructure - ושם טמון הפוטנציאל הגדול ביותר.
- למה שם טמון הפוטנציאל הגדול? כי שוב פעם - אנחנו היום מסתכלים על Security פה ו-Infrastructure פה ו-VM פה - ו-Kubernetes worker node כזה או Kubernetes worker node אחר - וזה העולם שלנו.
- ושם גם פחות או יותר, כשאנחנו מדברים על אופטימיזציות, אנחנו מגיעים עד לתקרה הזאת.
- אבל כשאנחנו מסתכלים על ה-End-to-End Service, אנחנו אומרים “עכשיו בוא נסתכל על כל ה-End-to-End Service, ונראה איפה הטרנזקציה של ה-User עוברת ואיזה תחנות היא עוברת בדרך ואיפה באמת התחנה שהכי יקרה לי” - אני יכול לגלות “Pocket-ים” אחרים לגמרי.
- ואז אני יכול להסתכל על זה ברמה של, לפעמים , ארכיטקטורה, שזו דרך להגיע לאופטימום הרבה יותר גבוה
- לפעמים זה יכול להיות Policy
- לפעמים זה יכול להיות באמת ה-Dev-Production
- אפשר להסתכל על זה מהזוית הזאת, ואז לתקוף את זה מזוית אחרת לגמרי מאשר “תביא לי את ה-Cost Report ותגיד לי ,וואי, היה לך איזה User שהעלה לך איזו מכונה ועכשיו היא רצה הרבה יותר זמן מאשר הייתה צריכה להיות’” . . .
(רן) בסדר, אז בוא, ככה, נתקדם לסיכום - קודם כל, הייתי חייב להגיד, נתי, שבעצם מה שאתה אומר זה ש”אם יש לך Bug ב-Design אז ז*ן ב-Debug” . . . תעשו Design כמו שצריך, או במילים אחרות - אתה בא ואומר שאם נעשה חלוקה הגיונית בין ה-Workload-ים השונים, נוכל את כל אחד מהם בנפרד לאפטם, ואם נעשה חלוקה הגיונית בין ה-Workload עצמו לבין ה-Infrastructure, אז נהיה גם אגנוסטים ל-Infrastructure ואז יהיו לנו יותר קל.
בעצם ”נפתח את הדלת לעתיד”, אם נרצה . . .
- (נתי) האימפקט של ה-Change יהיה הרבה פחות דרמטי, וזה חוזר חזרה לדוגמא של החברות Cloud
(אורי) זו בדיוק הבעיה - שזה עולה להם עכשיו חצי, וזה לא משתקף במחיר שלך . . .
- (נתי) נכון - אבל זו גם הגדולה של זה: הם יכולים To continuously optimize it, אבל יש Decoupling מאוד ברור בין השירות לבין מה שאתה משתשמש בו - ולכן הם יכולים לעשות את זה והם לא צריכים להגיד לך שום דבר.
- ובהרבה פעמים, מה שאנחנו מוצאים זה שיש המון Coupling היום בין ה-Workload לבין ה-Infrastructure - ואז, בשניה שיש את ה-Coupling הזה, אתה תקוע.
- עכשיו, חברות Cloud, בשונה ממה שהם עושים לעצמם - ללקוחות שלהם הם מעודדים לעשות את ה-Coupling הזה . . .
- “תשתמש בכל השירותים של ה-Cloud, כי זה מאוד קל ומאוד מהיר . . . . תשתמש . . . אה! יש לי פה עוד פיצ’ר ב-EKS שאם תשתמש בו בכלל תעוף . . .”
- ואז אתה מוצא את עצמך במקום ש . . . “אופס, אני כבר לא יכול לזוז משם” . . .
(אורי) אני לא יכול לזוז - וזה עולה לי . . . זה לא בחינם.
- (נתי) וזה לא רק זה - אני גם לא יכול לזוז משם, וזה המחיר היותר גבוה
- אני לא יכול עכשיו, אם יש לך משהו שהוא יותר יעיל - אני לא יכול להשתמש בו.
- אני לא יכול להשתמש בו כי אני “תפור” שם מ . . .
(רן) אז נמשיך בסיכום . . . זה פרק מרתק, אנחנו מסכימים, אבל בגדול - הצגנו את מה שנקרא “הפרדוקס של הענן”, שבא ואומר שבימים הראשונים של החברה זה בדרך כלל סופר-משתלם להיות בענן, אבל באיזשהו שלב צריך לחשוב האם זה באמת המקום הנכון בשבילכם לרוץ - ולפעמים אתם כבר תקועים, זה מה שאתה אומר . . .
לפעמים, אם לא השארתם לעצמכם איזשהו “פתח מילוט”, אז אתם כבר יכולים להיות תקועים, גם אם מצאתם דרך יותר יעילה לעבוד - עלות המעבר היא כל כך גדולה שזה לא שווה את זה.
(אורי) ולפעמים אין ידע . . . אין ידע, וזה הדבר שמבחינתי הוא הכי חבל. ידע זה כלי, זה כח, ואנשים איבדו את השריר הזה.
- (נתי) הייתה לי שיחה עם אייל פינגולד מ-Check Point, והוא אמר שבאמת יש סוג-של “שני מחנות” של אנשים, כשהם מקבלים החלטות על Infrastructure -
- יש את אלה שבאים ואומרים “זה בענן, ב-AWS, אני לא מחפש לעשות Multi-Cloud, לא מחפש ללכת לפתרונות אחרים, הם יודעים מה שהם עושים”
- ויש את אלה שאומרים “לא - אני רוצה את ה-Decoupling, אני רוצה אקח באמת Elastic מ-Elastic ולא את Elastic שלהם, אני אקח DataDog ולא את ה-CloudWatch . . .”
- זה ממש “שתי אונות במוח” - אתה רואה ממש שני מחנות, כמו הדמוקרטים והרפובליקנים . . . זה בערך . . . העולם מתחלק, פחות או יותר, לדברים האלה.
- ואני אומר - אנחנו צריכים יותר את הצד של ה-Decoupling, כי המחיר של הלא-Decoupling ב-Short-term באמת נראה עם Gain מאוד גבוה, אבל ב-Long-run הוא בסוף, כמעט תמיד, מוכיח את עצמו כמשהו שתוקע אותך והוא לא משתלם.
- ואני חושב שזו איזושהי תובנה שלא קיימת היום - והמחנה, אני לא יודע אם לקרוא לו דמוקרטי או רפובליקני, המחנה שמוכן “ללכת עד הסוף עם הענן”, הרבה פעמים עושה את זה עם הרבה מאוד נאיביות.
(רן) טוב - בנימה אופטימית זו, אנחנו מסכמים פודקאסט מרתק על עלויות ענן ו”אמרתי לכם!” . . .
(אורי) אני יכול להגיד עוד משהו? . . .
(נתי) יש פה רעיונות להרבה-הרבה סטארטאפים, עכשיו מהשיחה הזאת . . . למי ששמע: דברו איתנו . . .
(רן) טוב - תודה רבה אורי, תודה נתי, היה מרתק, להתראות.
ויש גם את ה-thread הזה של Or Hiltch על MemoryDB
האזנה נעימה ותודה רבה לעופר פורר על התמלול!