384 Carburetor 28 - 2020 predictions

רברס עם פלטפורמה

פרק מספר 384 של רברס עם פלטפורמה - קרבורטור מספר 28: אורי ורן מקריבים צפייה בגמר הכוכב הבא לאירוויזיון ומארחים בכרכור את נתי שלום (Cloudify) לשיחה השנתית על תחזיות לשנת 2020 (ה-10 וחצי חודשים שנותרו).

• מצמידים לכל דבר הסתברות ומקסימום מתקנים ב-1 באפריל.
• נתי מתמקד בענייני Infrastructure ו-Cloud, אז צפו שפחות נתמקד ב-iPhone הבא וכו’.
• מבוסס על מקרה אמיתי

חלק ראשון (ולא בהכרח טריויואלי למי שמגיע מעולמות ה-Enterprise) - עד כמה רחוק ארגונים יילכו עם Public Clouds?

• אורי בטח יזדהה עם תיאוריית ה”זה לא הולך לקרות כל כך מהר” (הקרבורטור הקודם על k8s and multi-cloud), אבל מכל הארגונים שאני (נתי) מדבר איתם זה על האג’נדה - והשאלה היא רק “כמה מהר?”
• וכן - אנחנו מדברים על ארגונים ”מסורתיים” - פיננסיים וכו’ - עם “רגולציה מפה ועד להודעה חדשה” והמון סיבות למה לא לעבור.
• עכשיו הם פתאום נמדדים על עד כמה מהר הם עוברים. זה עדיין לא קל להם, אבל השיחה היא רק על איך עוזרים להם לעבור, כי אין כבר משהו אחר.
• במקביל - מבחינת שחקני ה-Private Cloud בעולם הזה (בעיקר OpenStack) - נראה שהקרב כבר הוכרע
• מדהים איך בתוך 10 שנים הטכנולגיה הגיע ל-Peek מאוד גבוה ואז כמעט ונעלמה במושגים של טרנדים טכנולוגיים, לפחות בהיקפים האלה.
• באופן מפתיע, VMWare שכולם כבר הספידו מקבלים עוד כמה שנים של Grace
• זה תמיד נראה זמני ושה-Public Clouds מתישהו ינגסו גם בהם, אבל בינתיים הם מנסים “להיות חברים”
• גם זה שינוי מאוד משמעותי עבורם - כולל כמה רכישות משמעותיות וניסיון ללכת All-in על Kubernetes.
• (רן) אתמול הייתי בכנס שבו אחד המרצים היה איש Heptio לשעבר שעכשיו עובד ב-VMWare (אחת הרכישות המוקדמות שלהם בתחום).
• יש גם את ההשקה של AWS סביב VMWare - היכולת להריץ VMWare API על תשתיות של AWS, מה שפונה ללקוחות שכבר משתמשים ב- VMWare וכבר יש להם את ה-Skill-set והידע ולא רוצים “לאבד” אותו במעבר לענן הציבורי - ובכך “להרחיק את המעבר” ולשמר את הלקוחות
• בינתיים זה עובד להם לא רע
• חלק מזה נובע מכך ש-OpenStack נשלט על ידי RedHat - שבכלל רוצים לקדם את OpenShift ו-Kubernetes ו-OpenStack פחות מעניין אותם, מה שדי תורם למוות האיטי שלו.
• (אורי) אז מה באמת הבשורה ארוכת הטווח של VMWare?
• אין להם לדעתי (נתי), לפחות כרגע.
• הם קונים זמן, אבל האסטרטגיה שלהם היא סביב Kubernetes - ההנחה היא שארגונים, גם כשיעברו ל-Public Clouds, עדיין זקוקים לעזרה עם התשתית, ואנחנו (VMWare) נותנים פתרון שמקל על Enterprise להשתמש בתשתיות של Public Clouds, על ידי מעטפת ו-Dumbing-Down של התשתיות - לקחו את התשתיות המורכבות וייצרו שכבה “שמנרמלת את הסיבוכיות”.
• זה היה המהלך שלהם בעבר והם טוענים (במידה רבה של צדק) שהצורך הזה קיים גם (ואולי אפילו יותר) בעולם ה-Public Cloud.
• עוד שאלה לנקודת הזמן שבין 2019 ל - 2020: האם בראייה שלך הגענו ל-Game-Over: האם Kubernetes ניצח את עולם ה-Virtual Machines?
• המשפט שיוצא ממני הכי הרבה הוא “The only constant is change” . . . אין דבר כזה “Game Over” ואין דבר כזה ש”Kubernetes יכבוש את העולם”
• כולנו בוגרי Docker ובוגרי Ruby on Rails ועוד הרבה טכנולוגיות, והדינמיקה הזו (של לימוד טכנולוגיות חדשות כל הזמן) אפילו מתעצמת בעולם של Public Clouds, כך שיהיו עוד דברים.
• היום Docker הוא עדיין יחסית מסובך (ביחס לערך שהוא נותן) - ויהיו עוד אלטרנטיבות, שמישהו כנראה כבר עובד עליהן באיזושהי צורה.
• סביר להניח ש-AWS פחות אוהבים את זה ש-Docker הפך לסטנדרט כי זה קצת מייתר אותם והם ינסו לדחוף . . .
• למה?
• כיוון שהיתרון של AWS לעומת GCP למשל הוא שהם פיתחו הרבה מאוד IP סביב ה-Hypervisor של KVM, בעוד Google שהגיעו למצב ש-90% מה-Workload שלהם רץ על Containers ואז אין צורך בכלל ב-Hypervisor - ובכך הם “קפצו מעל” העולם של ה-Virtual Machines.
• בשלב הזה AWS יצאו עם הכרזה על Serverless - מעיין Pivot מחדש לעולם של containers ושל Kubernetes.
• שעוד לא לגמרי תפס . . .
• אם מסתכלים על Containers - זה כבר תפס; אם מסתכלים על Kubernetes, הוא יחסית במקום לא רע בכלל (במדדי Adoption), גם מבחינת כמות התורמים, גם מבחינת איכות הקוד ובכלל איכות הפרויקט; ב-Enterprises הוא במקום לא רע בכלל.
• ועדיין - יש סימן שאלה לא קטן סביב השאלה של כמה זמן זה יחזיק.
• כמו כל דבר - אימפריות נופלות בסוף (לאט?)
• בזמן האחרון דווקא די מהר . . . אם היינו עורכים את השיחה הזו לפני 2-3 שנים על Docker ועל Swarm למי שעוד מכיר, היינו מדברים על למה זה יותר גדול מ-Kubernetes.
• בדיעבד Swarm הצליח קצת פחות ו-Kubernetes די ניצח את הקרב. היו סימנים, ועדיין.

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

• שאלה חשובה, ואולי למי שבא מעולם הסטארט-אפים היא טריוויאלית, ועדיין - רובם פשוט נכשלו בניסיון להקים Private Cloud.
• בנו תוכניות מאוד אגרסיביות - ולא הצליחו, מכל מיני סיבות (אין Skill-set, אין את -DNA, . . .)

ומה לגבי חברות שכבר יש להן?

• אף אחד לא באמת מרוצה, בלשון המעטה . . .
• גם ברמת העלויות (הגבוהות מהמצופה) וגם ברמת היחידות העסקיות והתוצרים שמצופה מהן להביא לשוק - הם תקועים עם תשתית מאוד לא אג’ילית וכשהם רואים את ה-Public Clouds ואת המהירות שבא הם מאפשרים להביא מוצרים לשוק עם ה-IT שלהם הם מתוסכלים.
• בשלב הזה הארגון, ברמת ה-Business, עומד מול השאלה של האם לתת ליחידה העסקית להשיק מוצר מהר או מכתיב להם “לחיות” עם ה-IT שיש - ואז זה האינטרס הפנימי של לחיות עם ה-IT הקיים אל מול Delivery מהיר?
• הרי ברור שברמת השורה התחתונה העסקית יותר חשוב להביא את הפתרון מהר לשוק.
• כאן נכנסת גם “חרב הרגולציה”, שעדיין מחזיקה את הארגונים האלה על Private Cloud.
• גם כאן וה-Public Clouds עשו הרבה מאוד עבודה בתחום הזה ויצרו פתרונות כמו GovCloud כדי להפוך גם את הנקודה הזו ללא רלוונטית.
• וחוץ מזה יש גם פתרונות Private Cloud - כמו AWS Outposts ואת Azure Stack.
• כמעט כל הסיבות שהיו לשימוש ב-Private Cloud הפכו ללא רלוונטיות, והמעבר ל-Public Cloud הפך לכמעט “לא בעיה”.

אז גם Enterprises רוצים לעבור ל - Private Cloud. מה התחזית ל-2020?

• בהקשר הזה יש הרבה מאוד שיח לגבי Multi-Cloud - כבר לא Public Cloud כן או לא אלא שיחות (גם אם רובן הן ציניות) לגבי “למה צריך Multi-Cloud?” ו”הרבה יותר טוב לעבוד עם Cloud אחד שיפתור לך את כל הבעיות בעולם”.
• גם כאן חשוב לציין שיש הבדל בין Multi-Cloud (כמה Public Clouds) לבין Hybrid Cloud (בהקשר של Private & Public).
• כאן הטענה שלי היא שזה לא שארגון יושב ובוחר “אני הולך להיות Multi-Cloud” - אלא דומה יותר לבחירה “בעולם הקודם” בין Unix ל-Windows -
• היו ארגונים שהחליטו שהם Windows-only, והמציאות הכתיבה להם להיות גם Linux, בין אם זה בדלת האחורית או בדלת הקדמית (רכישות וכו’, היה בפרק על Multi-Cloud גם כן).
• בדיוק באותו אופן זה קורה עם Public Clouds - יש ספקי ענן ויש שירותים של ספקי ענן, לדגומא BigQuery שאנשים אוהבים ורוצים - אז גם אם אני עובד עם Azure, אני עדיין רוצה לעשות את ה-Analytics עם GCP.
• באופן דומה יש את Windows שרץ יפה עם Azure ונתמך ע”י מיקרוסופט ויש לזה Affinity מסויים.
• כמו בשיחה על Outbrain , אין לנו ספק אחד שטוב בהכל.
• (אורי) בוא נודה על האמת - ארגונים גדלים גם ברכישות . . .
• נכון. סיבה אחת היא שלא כולם שווים, והשנייה היא אכן רכישות.
• בשני המקרים זו מציאות שנכפית - זה לא שמישהו מחליט ללכת על Multi-Cloud אלא זו מציאות שארגונים מתגלגלים אליה, ואתה מוצא את עצמך בעולם של Multi-Cloud.
• לכן אני חושב שזו מציאות שאם לא תתכנן שלשם אתה הולך, בין אם תרצה או לא תרצה - תמצא את עצמך בכאוס שבו יש הרבה מאוד דברים לא עקביים (Consistent) ותגדל לתוך מציאות שאין לך עבורה פתרון.
• (אורי) ואז האם האמירה היא לא שהמציאות של Multi Cloud זה דבר שקורה (וגם בין Private ל-Hybrid), או כי רכשתי חברה או כי אני עושה פרוייקטים בטכנולוגיות חדשות כשעדיין “מה לעשות שה-Mainframe שלי ישאר כמו שהוא וה-Transnational Data שלי ישאר ב-Oracle כי אני בנק וככה זה”.
• כן, זה ה-Hybrid Cloud והיו לנו כמה שיחות עם לקוחות שאמרנו לנו “יש לנו שנה לעבור ל-Public Cloud”.
• במשך שנה עשינו את אותן שיחות והצלחנו להעביר רק 3 אפליקציות -90% עדיין לא עברו וזה כנראה הולך לקחת כמה שנים טובות - ויש מצב שחלק בכלל לא נרצה להעביר.
• המציאות של Public vs. Private, במיוחד עבור מי שכבר מושקעים ב-Private, תלווה אותנו גם לאורך זמן - אבל יש מגמה עם ראש חץ מאוד ברור -
• מקרים של Green-field ילכו ויכתבו מראש לסביבה של Public Cloud ודברים שהם Legacy או יותר מורכבים עם עם רגולציה משמעותית (Security) עדיין ישארו ב-Private - אבל זה ילך ויצטמצם.

הסיפור הזה על Hybrid ו - Multi-Cloud אותנו לנושא הבא - Networking: אם פעם הכל היה יושב “אצלך” ב - Data Center והייתה לך שליטה על כל ה - Networking, עכשיו את גם צריך איזושהי דרך לשלוט ברשת כולה, שכנראה מפוזרת בכל מיני מקומות בעולם ואצל Vendors שונים ברחבי העולם . . .

• השינוי הוא הרבה יותר מזה - וזה משהו שאנשים עוד לא לגמרי מפנימים, כי אני חושב שיש כאן גם הרבה מקום לחדשנות ולחשיבה הזו, וחלק מהחברות כבר מנצלות את החשיבה הזו
• ה - Cloud הפך ל - Network.
• בעבר ה - Network היה אוסף של Switches ו - Wires ו - Firewalls, והיית צריך להרכיב את כל הרכיבים האלה יחד כשהקו היה מעיין קו אינטרנט שכולם היו מתחברים אליו או איזשהו LAN פנימי.
• היום לכל אחד מה - Public Clouds יש Point of Presence שדי קרוב אליך - ואתה במרחק נגיעה מתשתית שכבר יש בה הכל: את הראוטר, ה-Firewalls - הכל נגיש ב-API ואתה כבר לא צריך לרכוש Devices נפרדים, רק לעבוד עם ה-API ולקנפג (Configure) אותם נכון.
• יש חברות שבנו עולם שלם סביב הדבר הזה - למשל Cato Networks בארץ (של שלמה קרמר, ממייסדי Check Point), שבנו מוצר שכל התפיסה שלו הייתה סביב ה-”Last Mile” לתוך ה-Cloud, כך שכל הגישה שלך וכל התקשורת בין המשרדים והתשתיות עובדים דרך “ענן וירטואלי”.
• בנו מזה פתרון וקראו לו SD-WAN (ועכשיו קוראים לזה אולי בשם אחר) - וזו תפיסה אחרת של Networking: כבר לא חיבור בין Devices, כשה-Cloud הוא עוד End-Point, אלא ה-Cloud הוא ה-Network, ועכשיו אני צריך לפתור את בעיית ה-”Last Mile” ואיך לקנפג תשתיות שכבר קיימות בענן במידה לא מועטה.
• היום בענן יש כמעט את כל סט שירותי הרשת (במיוחד ב-AWS וב-Azure, פחות ב-GCP), וזה שינוי דרמטי.
• כשאתה מסתכל על זה, זה בעצם משנה סדרי עולם באיך אתה מסתכל על Network ובונה רשת, כמו בדוגמא של Cato Networks ותקשורת בין משרדים.

• 
  

• (רן) אתם מדברים על ה-”Last Mile” ואני מבין שזו בעיה חשובה, אבל אני מדבר דווקא על הליבה - איך אתה מחבר Data Center של Azure לאחר של GCP?

• יש היום שירותי VPN מובנים וגם שם העסק מאוד השתכלל
• יש גם חיבור לשירותי VPN חיצוניים
• למעשה, אתה יכול להתחבר יחסית בקלות עם Client לתוך רשת של VPNs - והם כבר יודעים להביא אותך ל-VPN ב - PoP “הנכון” ולחבר אותך לרשת ב-Latency “הנכון”
• לא צריך להתחבר ל-VPN פיזי מסויים שנמצא במיקום מסויים כמו שהיה בעבר, ורק אז להבין שפתאום זזת למקום אחר ויש Latency הרבה יותר גבוה.
• הם נותנים את השירותים האלה היום, וזה הופך את בעיית ה-Networking לבעיית Orchestration, בדומה למה שקרה לנו ב-Data Centers.
• אם בעבר בשביל “להרים Data Center” היה צריך להזמין את כל המחשוב וה-Storage וכל הדברים האלה - היום אף אחד לא מתעסק עם זה, וזו הפכה להיות בעיקר בעיית Orchestration.
• עיקר הבעיה היא איך לעשות אוטומציה לכל התהליכים, ולא באיך להזמין כוח מחשוב ואחסון וכו’.
• מגמה מאוד דומה מתרחשת בנושא הרשת, וזה מייצר גם חשיבה אחרת לגבי ארכיטקטורה.
• כל תפיסה של “איך אני בונה רשת ארגונית” די נעלמת, והיא צריכה להיראות אחרת לגמרי.
• יש גם היבטים של פשטות ו-User Experience שונים - ואני יכול לעשות הרבה דברים שלא יכולתי לעשות בעבר.
• דוגמא אחרת שהתייחסתי אליה (בפוסט) הייתה מה -AWS Re:Invnet האחרון - הכרזה של AWS יחד עם Verizon והרבה חברות תקשורת אחרות על שירות בשם AWS wavelength
• מדובר בעצם ביכולת שלי להסתכל על האנטנה של הרדיו - אותה אנטנה סלולרית שאתם רואים לפעמים בדרך, מוסלקת בתוך כל מיני דברים יפים (אמרתם עץ קוקוס? כיוונתם נמוך).
• בסופו של דבר זו בעצם יחידת מיחשוב (וכשעוברים ל-5G היא הופכת ליחידת מחשוב יותר גדולה), שעד היום התייחסו אליה כאל כל מיני פרוטוקולים של איך מעלים ומה מריצים וכו’.
• כאן, AWS יצרו איזושהי הפשטה מאוד יפה (עם כל שיתופי הפעולה האלה), ואמרו שזה בעצם עוד Region . . . (כשיש לך פטיש גדול, כל העולם נראה כמו מסמר?).
• עבורך (כמפתח) זה לא משנה שזו “רק” אנטנה, ברמה הזו זה באמת פשוט עוד Region - יש לך Tag, אתה יכול להגיד שזה רץ על ה-”AWS wavelength “Region או על אחד ה-Data Centers “הרגילים” שלך - ושאר ה-API שלך נראים פחות או יותר אותו הדבר.
• זה בעצם עוד סוג של Point of Presence או CDN - רק שהם מכוונים את זה יותר לכיוון של Augmented Reality למשל.
• ה - Use Case הבסיסי הוא Latency - יש כאלו שדורשים Latency נמוך, כשה-Latency המינימלי עד ל-Data Center הקרוב הוא בסביבות המאות או עשרות mS (אלא אם יש לך Local Cache באפליקציה).
• ב-Augmented Reality יש כל מיני מקרים שהם “Heavy Latency Dependent”, ואתה צריך הרבה מאוד אינטראקציה מהירה ורוצה להביא לא רק מידע סטטי אלא גם לוגיקה שתיהיה “קרוב אליך” - וזה Use Case מאוד מסויים.

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

• זו לא פנטזיה . . .
• למשל - Walmart יצאו בהכרזה שהם רוצים לבנות תשתית ענן, כשהיתרון שלהם הוא שהחנויות שלהם נמצאות תמיד (ממוצע וסטטיסטיקה וכו’) במרחק של עד 10 קילומטרים מכל תושב בארה”ב
• הם רוצים להשתמש בחנויות בדיוק לתשתית ה-Edge הזו עבור מכוניות.
• אם כבר נמצאים 10 קילומטרים מכל אזרח בארה”ב, אפשר לנהל משלוחים ורכבים אוטונומיים יוכלו להגיע למידע הדרוש עם Latency יחסית נמוך ואיכותי.
• זה עדיין עתידני (מאוד?), אבל אני חושב שהמהפכה של החשיבה על Network בצורה אחרת כשה-Public Cloud הוא כבר לא רק לקחת את השרתים הפיסיים ולהפוך לוירטואליים אלא ממש חשיבה אחרת וארכיטקטורה אחרת לגמרי של איך בכלל ניגשים לבעיה. פתאום ה-Network קיים.

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

• קודם כל, אנחנו עוברים לבעיית Placement Policy - איך אני מנייד, למי ומתי
• גם אנחנו (נתי) כשעבדנו עם לקוח שמאפשר אינטרנט במטוסים, היינו צריכים להתייחס ל-Roaming אפליקטיבי - וזו בעיה לא פתורה עדיין.
• החדשות כאן הן שלמפתח הסביבה היא נגישה יחסית בקלות - ומה ש-AWS מביאים כאן זה את ה-Ecosystem עבור המפתחים.
• דמיינו את העולם שעכשיו תיארנו - עם האנטנות והכל - בלי AWS, ואז עם AWS, כשהוא רק Region בתוך ה-API שלי לעומת מצב שבו הוא עם API אחר לגמרי ואני צריך לחשוב כל הזמן - ותבינו שזו מהפכה.
• מורידים את כל ה-Friction - במקום שאני צריך לסגור הסכמים עם AT&T ו-Verizon וכו’, כשלכל אחד יש API שונה, יש לי מקום אחד.

(אורי) יותר מזה - בעולם של Data Centers ו-Regions ו-PoP של CDN - הכל בנוי על זה שהלקוח נייח - יושב באיזשהו מקום וצריך להגיע אליו, וה-Content שהבאת עד ל-PoP הקרוב רלוונטי לשם ויחסית סטטי.

• עכשיו, פתאום הלקוח מתחיל לזוז.
• אני מסתכל על ספקולציות, אבל לדעתי מה שה-Cellular Network Providers יודעים לעשות זה אלגוריתמיקה של דילוג של ה-Roaming, והם יודעים להעביר את ה-Session ממקום למקום - ויכול להיות שיש כאן אלגוריתם שיכול להבין את התוכן ואת האפליקציה שלי ו”לדלג אותה” ממקום למקום . . .
• (נתי) עבור מי שלא מבין איך זה עובד - היום אתה בדרך כלל פשוט מחזיק את ה-Session בכמה אנטנות שקרובות אחת לשנייה, כך שלא תצטרך לעשות את המעבר ב-Real Time (כבר קיים באנטנה שאתה עובר אליה), והאלגוריתם חוזה מה יהיה המקום הבא - וזה אף פעם לא “באפס זמן”.
• אתה מחזיק משהו כמו שני צעדים קדימה.
• כמו שה-CDN צמח באיזושהי נקודת זמן, כשאמרו שהתוכן הופך להיות גלובאלי והנגישות לתוכן כבר לא לוקאלית וצריך CDN כי אני צריך להביא את המידע קרוב למשתמש - יקרה משהו מאו דומה גם בהקשר של האפליקציות.
• אני ארצה להביא את האפליקציות היותר חכמות (ויותר Low-Latency), אבל אף אחד לא יודע לצייר בדיוק את מה שיהיה.
• זה קצת מזכיר לי את מה שקרה עם Serverless, לטוב ולרע - כשיצאו עם Serverless לא ידעו בדיוק לצייר איזה סוג של אפליקציות בדיוק ישתמשו ב-Serverless ותוך כמה זמן צצו סטארט-אפים שזה בדיוק מה שהם עושים ובנו עולם שלם של Workflows.
• (אורי) צצו יותר כלים ל-Serverless מאשר אפליקציות של Serverless . . .
• אמרנו “לטוב ולרע” . . . לכל טרנד כזה תמיד יש את הצד של ה-Overkill ואת כל אלה שמנסים לעשות את מה שזה לא נועד עבורו.
• (רן) ואמרנו כבר - כולם מנסים למכור אתי חפירה ומכנסי ג’ינס . . .
• (נתי) זו לדעתי מגמה מאוד מעניינת שמתכתבת עם מה שאמרתי לגבי Networking - עוד צעד קדימה, ואפילו הרבה יותר ממה שחשבתי.
• זה גם מתכתב עם מה שהזכרנו קודם על מעבר ל-Public Cloud - עצם זה ש-Telcos כמו Verizon חותמים על הסכם שיתוף פעולה עם Public Cloud Providers, שעד לא מזמן נחשבו מבחינתם לתחרות ואיום - גם אומר שהם הרימו דגל לבן על המלחמה על ה-Data Centers והיכולת לשלוט בארגונים וב-Connectivity, מעיין If you can’t beat them - Join them.

(רן) התחלנו בזה שאמרנו שגם ארגונים גדולים עוברים ל-Public Clouds - גם ל-Telcos הללו יש Data Centers עצומים, ושם יש שיקולי עלות משמעותיים מאוד, וכל bit חשוב - אתה רואה גם אותם עוברים ל-Public Cloud?

• אם אתה מסתכל על הסכמי שיתוף הפעולה האחרונים של AT&T עם Azure למשל . . .

שיתוף פעולה זה בסדר, השאלה האם היא האם הם עדיין יחזיקו את ה-Data Centersשלהם או יעברו גם.

• חלק מההסכם של AT&T עם Azure, והסיבה שהוא הגיע לכאלה מספרים, זה שהם קונים את ה-Data Centers.
• האם הם קונים כדי לסגור? לא ברור . . .
• במקרה הזה זה AWS מול Verizon ו-Azure מול AT&T, אבל אני מעריך שכולם ישחקו במשחק הזה.
• אני יודע שיש גם עניין של GCP מול Telcom Italy ועוד דברים שאי אפשר לדבר עליהם כרגע.
• בגדול - כשרואים עסקה מאוד גדולה של שחקן Cloud מול TelCos, אתה יודע שיש גם עניין של “קניית נדל”ן” ועוד הרבה דברים אחרים, ולא רק מכירת שירותי ענן.
• עכשיו שחקני ה-Public Cloud מתחרים ממש על ה-TelCos ומי יתפוס כמה שיותר “פיסות נדל”ן” כאלה, כי הם מזהים את ההזדמנות הזו שבה ה-TelCos מרימים דגל לבן ועכשיו אפשר לנגוס בזה נתח מאוד משמעותי - וזה Workloads מאוד גדולים וגישה להרבה מאוד לקוחות, כך שזה מאוד מפתה מהבחינה הזו.

זה מביא אותנו לאחת הנקודות הבאות, שכולן קשורות באיזשהו חוט שני מתמשך - ה-CI/CD, וההכרה ב-CI/CD כ”קו הייצור הארגוני”.

• עד היום התייחסו ל-CI/CD כאל עוד תשתית ארגונית, לצד עוד הרבה דברים אחרים.
• כמו שהסביר לי את זה ה-CTO של Morgan Sternly צבי גל - בעבר, כשאמרנו “Agile”, דיברנו על כל מיני תהליכים שבהם יש גם CI/CD, אבל כאמצעי ולא כדבר העיקרי. היום הבנו שעל מנת להיות Agile, אני קודם כל צריך לראות איך הדברים מסתדרים בתוך ה-Pipeline של ה-CI/CD, והתהליכים צריכים להתאים את עצמם.
• אם זה לא יהיה בתוך ה-Pipeline, אז כנראה זה לא Agile.
• זו אמירה מאוד משמעותית, כי אני חושב שהיא מייצגת בדיוק ת התפיסה הזו - אם זה לא CI/CD, כנראה שזה לא יהיה Agile, וזה משפט שנשמע פשטני אבל הוא מאוד משמעותי.

(אורי) תן דוגמא . . .

• למשל ה-Networking (ככה זה, הכל מתחבר) - כל עוד ה-Networking לא היה חלק מה-CI/CD, הוא לא היה Agile.
• אם היית רוצה לשנות משהו ב-Firewall שלך, היית צריך ללכת למישהו ו”לפתוח Ticket”, ומתישהו מישהו היה משנה אותו . . . עברת מ-Processes שהיו לוקחים כמה דקות או Builds שאפשר לעשות כמה ביום (אפילו מאות) למשהו שעובד בקבועי זמן של ימים או שבועות, וכל התהליך מתעכב כתוצאה מזה.
• זו דוגמא לתהליך שהיה עד היום לא נתפס - ויש עדיין תהליכים בארגונים שמנוהלים ע”י UI ומישהו שצריך לפתוח Tickets ב-ITSM ולהריץ אותם . . . SD-WAN זו דוגמא טובה מעולם ה-Networking.
• (רן) יש אצלנו בדיחה שאומרת שלא צריך Chaos Monkey - רק צריך לפתוח Ticket: “תפתח לי את ה-Port הזה של ה-Firewall”, ודברים כבר יקרו.
• זה אכן סוג של Chaos Monkey - השאלה רק מי ה-Chaos ומי ה-Monkey . . .
• בכל מקרה - זו תפיסה שלמי שבא מעולם הסטארטאפים נשמעת קצת כמו תקופת האבן, אבל המציאות בחוץ היא שלארגונים מאוד קשה עדיין עם כל התפיסות הללו של Agile ושל CI/CD ושהכל אוטומטי.
• בכלל - לחשוב על ארגון כעל קו ייצור ועל תוכנה כעל קו ייצור, כשאתה נמדד על KPI כמו כמה מהר אתה מוציא release ובאיזו איכות.
• בחברות שמנהלות קו ייצור מכירים את המושגים האלה על עולם פיזי, ועכשיו את מביא את זה לחברות IT שלא רגילות לחשוב במושגים כאלה ולא רגילים להימדד במושגים כאלה
• הם רגילים לעבוד הפוך - כמה שפחות שינויים, כמה שיותר Availability - ופתאום אתה נמדד על כמה מהר אתה עושה שינויים וכמה מהר אתה מריץ את ה-Pipeline ומאפשר לארגון לנוע בקצב יחסית גבוה.
• זה מחייב את הארגון לשבור Silos, כי אתה חזק כמו החולייה החלשה שלך.
• כדי שקו ייצור כזה ירוץ End-to-End, הכל צריך לדבר באותה שפה והכל צריך לעבור דרך אותם כלים.
• זה מייצר אתגר לא קטן לכל הארגונים האלה, ועכשיו זה מחזיר אותנו לעולם של Multi-Cloud ואיך זה מתחבר לשם.

רגע, עדיין במקום של CI/CD - עבור תהליכים שהם Agile והיכולת לייצר Impact כמה שיותר טוב וכמה שיותר מהר, ה-CI/CD הוא התשתית הטכנית. זה לא מספיק . . .

• אמרתי שאם זה לא יכול להתחבר ל-CI/CD, כנראה שזה לא יהיה Agile - אבל לא אמרתי את המשפט ההפוך . .
• אם זה מתחבר ל-CI/CD, זה עדיין לא בהכרח Agile - יש עוד דברים (גם בהיבט של ה-Multi-Cloud) בהם זה הכרחי אבל לא מספיק.
• מה המשפט הרלוונטי מלוגיקה? עקרון ההכלה וההדחה למי שמתגעגע לתורת הקבוצות וקומבינטוריקה.

(אורי) אני רואה הרבה מקומות שיש בהם סוג של “Water-Scrum-Fall” . . . ה-R&D אולי עובד ב-Scrum ויש לו CI/CD והכל, אבל כל התהליכים שלפני - כל התכנון, בניית ה-Roadmap, הכל מאוד Waterfall-י; יש את השלב שבו בונים והוא באמת Scrum-י - ואז כל שלב ה-Go-to-Market הוא שוב מאוד Waterfall-י.

• אתה נוגע בנקודה שהיא באמת מאוד קשה ואולי לא לגמרי פתירה.
• אולי ארגון חדש יכול לפתור את זה מ-Day One, אבל למי שלא בנה את זה ככה מההתחלה יהיה מאוד קשה עכשיו להפוך, למשל, תהליכי Marketing - המוצר יוצא עכשיו בהרבה מאוד Releases והרבה מאוד פיצ’רים, ואיך אתה עכשיו הופך את זה ל-Stream-lined יחד עם כל השיווק של כל הפיצ’רים האלה, שכבר נבנה במודל של Waterfall ב”איים ארגוניים” שונים?
• יש כאן חשיבה מאוד שונה על כל הנושא של Agile, והכרה בזה שאם זה לא יודע להתחבר ל-CI/CD אז כנראה שזה גם לא יהיה Agile.
• וכאן נכנסת גם שאלת ה-Multi-Cloud, שרק מחריפה את הבעיה: בהרבה מאוד ארגונים ראיתי שיש Jenkins עבור ה-Private Cloud ו-Git (או GitOps) באיזורים של Public Cloud, בחלק יש את Spinnaker בעולמות של SaaS - ופתאום אפילו ה-CI/CD נמצא במקום שבו יש לך כמה עולמות של CI/CD . . .
• הזכרנו את GitOps ויש גם Simple-CI ועוד פתרונות מהסוג הזה.

הדבר השני שראינו שקורה הוא שראינו שקורה הוא מעבר לענן ב-Scale לעומת One Application:

• רואים ש-Jnekins נמצא מאוד ב-Private Clouds וב-Data Centers, קצת (יהיו כאלה שיגידו הרבה) ב-Public Clouds - אבל לא תמיד הוא “מהגר” יחד עם כל התהליכים שלו אל ה-Public Cloud.
• נוצרת בעיה - ארגונים אומרים “אני עובר ל-Public Cloud”, אז לוקחים אפליקציה וצריכים להוסיף עבורה אוטומציה ל-CI/CD, והכל צריך להיות Software ו-API-Driven.
• אז יש Jnekins ויש Kubernetes ו-Ansible ו-Terraform . . . וכל אפליקציה בונה לעצמה את תהליכי האוטומציה.
• בשלב הזה אתה מגלה שכמעט עולם עושים פחות או יותר את אותו הדבר - אבל קצת שונה.
• אם תרצה עכשיו להפעיל רגולציה בתוך כל זה, למשל - “אסור לפתוח את ה-Ports האלה” או “מותר לרוץ רק ב-Region מסויים” - צריך לגשת לכל אפליקציה ולבדוק איך היא מתנהגת עם המון Instances של כמעט אותו הדבר וצריך להבין מה קורה שם. הרבה פעמים זה גם בנוי בצורה של Scripts, ולך תבין מה קורה שם . . .
• מי שכתב אולי מבין, אבל לא תמיד הוא בכלל נמצא בארגון בשלב הזה.
• לפעמים אתה מגיע לאיזשהו “ג’ונגל” שבו המעבר לאוטומציה מהר ייצור מצב בו אין לנו פתרון Well-engineered לאיך עושים את כל זה ב-Scale.
• בדוגמא של קו הייצור - אנחנו עכשיו יודעים להריץ את הייצור באופן אוטומטי, אבל עכשיו אם צריך להריץ עשרה סוגים של מכוניות ולא רק אחד, לא הגיוני שנמציא תהליך אוטומציה לכל מכונית בנפרד והכל יהיה שונה, כי בטוח יש המון משותף והרבה מאוד דמיון.
• המכנה המשותף מאוד גדול, וככל שה-Scale גדל אנחנו הופכים למאוד לא יעילים.

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

• כן . . . זאת מציאות שמחריפה את הבעיה.
• תהליכים שהיו טובים ב-Scale נמוך או בינוני, גם אם עבור ארגונים הומוגניים זה קצת שונה - אפילו עבור סטארטאפים שגדלו, יש את הבעיות האלה (הפרק עם Outbrain).
• הבעיות הללו עדיין לא פתורות, וזה עומד לפתחן של הרבה חברות, בין אם מדובר בחברות או בפתרונות SaaS וכו’ - השאלה היא איך לייצר Consistency בכל תהליכי האוטוציה הללו.
• אני רוצה לייצר מצב בו אני אולי לא משתמש בדיוק באותו CI/CD, אבל הצורה שבה אפליקציות ניגשות ל-Infrastructure תיהיה עקבית, ואפשר לתת את הכלים.
• אנחנו (ומסתבר שלא רק אנחנו) קוראים לזה Environment as a Service: מזכיר מאוד את מה שהיה בעולם של PaaS, רק הדור הבא -
• אם ב- PaaS על מנת לייצר עקביות (Consistency) אני צריך להגדיר איך אפליקציה נכתבת, באילו שפות, אילו Frameworks רלוונטיים, מה יהיו התהליכים וכו’ - ואז יש לי עקביות עבור Node.js למשל או לסוג מסויים של אפליקציה. זה מאוד מוגבל.
• ב-Platform as a Service הכוונה היא ל-Heroku למשל וכו’.
• אז אמנם זה היה טוב עבור הבעיה הזו, וכשכל האפליקציות נראו אותו דבר זה אפילו עבד מצויין, אבל אנחנו נמצאים במצב שבו השונות בין ארגונים, ואפילו בין אפליקציות כשאתה רץ על הענן, היא כל כך גדולה, עד שצריך לייצר הרבה מאוד סוגים שונים של PaaS ולהתאים אותם לארגון -
• וזה בדיוק ההבדל בין PaaS לבין Environment as a Service, שלא מתיימר לתת לך משהו סגור אלא את הכלים לאפשר לך לבנות לעצמך PaaS שונים.
• למשל - עבור Analytics או HPC או Web applications.
• אמנם כל אחד הוא סביבה בפני עצמה ואתה צריך לכתוב את זה עבור כל ארגון או סוג - אבל ההנחה היא שהיחס בין כמות הסביבות לכמות האפליקציות נוטה (בהרבה) לכיוון של הרבה יותר אפליקציות.
• אז אתה מצמצם את השונות ומרכז את הידע - ויכול להתחיל להתמודד עם הבעיה בלי לייצר בעיה של חוסר אג’ליות במקום אחר, כי יצרת מענה משותף נמוך מדי במקום אחר שלא מאפשר לך להשתמש בכל מיני פיצ’רים חדשים.
• זו תפיסה חדשה שמתחילה להיווצר.

(רן) אם ננסה לסכם את מה שאמרת - חברות מבינות שהן צריכות לאפשר היווצרות של “Platform as a Service פנימי”, ובאופן טיפוסי בחברה יכולים להיות שלושה-ארבעה-חמישה סוגים שונים (אחד עבור ה-Analytics ועוד אחד עבור ה-Online ועוד עבור ה-Storage וכו’).

• יכול להיות אפילו משהו אחר, כי יש עוד מימדים שלא מטופלים בכלל -
• יש הרבה סביבות Ad-hock, כמו סביבת Training למשל, שאתה רוצה להרים לפרק זמן מסויים ואז להוריד אותה.
• יש Benchmarks שאתה מייצר לפעמים ולא רוצה שמישהו “יפציץ” ויעביר אותך לאיזשהו Spike שיגרום לעלות לקפוץ בלי ששמת לב (קרה לנו כמה פעמים . . .).
• הנושא של Environments, בגדול, שהוא פתוח יותר, רלוונטי להרבה יותר use-cases מאשר מה שהיינו רגילים לחשוב עליו פעם בהקשר של PaaS (שזה בדרך כלל Web applications).

דבר נוסף שנתקלנו בו הרבה זה שברגע שאני יודע לפתוח את ה-Workloads ואת ה-Environments - למשל אצלנו, כשאתה עושה Build אז יש טסטים שאם הם יכשלו זה לא נורא כל כך ואפשר להריץ עוד פעם - ואולי ארצה להריץ אותם על Spot instances למשל.

• יש מקרים שבהם אני מוציא release, ואם משהו עכשיו נופל בזמן ה-Build אז אני מסתכל על זה כעל בעיה וזה מקפיץ לי אורות אדומים וכל המערכת נכנסת לסחרור וצריך לטפל בזה.
• מתי אני יודע שזה נפל בגלל שמדובר ב-Spot instance ומתי זה לא “באמת נפל”?
• היום מה שאני צריך לעשות זה ללכת למפתח ולהגיד לו שעכשיו, כשאתה בונה את הטסט, תבנה אותו גם עבור הסביבה הזו - וזה די מקובע.
• אם תרצה לשנות את הסביבה - למשל מSpot instances למשהו אחר - מישהו צריך לשנות את ה-Build Process, ולכתוב אותו אחרת כך שיתאים לסביבה שונה.
• מה שאתה באמת רוצה זה שזה יהיה מבוסס על Tags - אם אתה רוצה להריץ על Spot instance ומקסימום ייפול ותריץ שוב אז בסדר, ואם אתה רוצה להריץ בסביבה יותר “higher end” אז צריך לשנות רק את ה-Tag, וזה ימצא את הסביבה הנכונה וישייך את עצמו לסביבה הנכונה ויהיה אפשר להפעיל אותו.
• ככה גם אפשר להכניס שיקולים של Cost optimization.
• בגדול - הרעיון הוא להעלות את רמת האבסטרקציה של אופן הגישה ל-Infrastructure - קצת בדומה למה שהיה עם PaaS וחוסר הגמישות של PaaS - זה בגדול הרעיון של Environment as a Service.
• היום כשמדברים על סביבות מודרניות אז כמעט תמיד יש שם Kubernetes ו-Ansible ו-Terraform, ובנוסף גם דברים ספציפיים כמו Database כזה או אחר או Networking מסוג כזה או אחר.
• ברגע שיש לי גם הגדרה של Environment, היכולת שלי לעשות רגולציה כשפתאום יש לי משהו שמייצג את ה-End-to-End, הופכת למשהו יותר קל, ואני יכול להבין מה קורה.

אנחנו מתקרבים לסיום - זמן להמלצות קריאה!

• דיברנו על הרעיון של “תוכנה כקו ייצור” והרעיון עצמו לא חדש עבור מי שמכיר את השורשים של DevOps - אבל יש ספר יחסית מפורסם בשם The Phoenix Project (של Gene Kim ו Kevin Behr) - מאוד מומלץ.
• גם גרסת האודיו טובה מאוד.
• זו ספרות מקצועית “במסווה” של רומן - סיפור עלילתי מעניין שכיף לקרוא (או להאזין), ותוך כדי גם לומדים על חלק מאבני הבסיס של DevOps.
• זה לא משהו חדש (יצא ב-2013), אבל קריאה טובה לכל מי שרוצה להכיר את כל נושא התוכנה כקו ייצור.
• ותמיד אפשר גם לחזור למקור ולקרוא את The Goal, או אפילו רק להקשיב לד"ר אלי גולדרט ז”ל.

לסיכום הנקודות שהעלנו -

• הנקודה האחרונה הייתה ש-CI/CD הופכים להיות “קו הייצור של ה-Enterprise” (בסטארטפים זה כבר הרבה זמן).
• וההבדל הגדול הוא שהכל מתכתב עם זה - לא רק התשתית האפליקטיבית אלא גם ה-Networking וה-Marketing וכל השכבות הארגוניות צריכות להתכתב עם זה.
• בטוח שיש הרבה סטארטאפים שקמו עכשיו ולא עובדים ככה, גם אם הם מכירים במציאות הזו.
• יש כמובן את ה-Unicorns שעובדים ככה (אחרת הם לא היו מגיעים ל-Scale), אבל הרעיון שתפיסת ה-CI/CD היא הרבה מעבר לניהול של אפליקציה או Build של פיתוח לצורך העניין.
• “אם זה לא CI/CD - זה לא קיים”.
• אצל סטארטאפים או אפילו חברות יותר בוגרות אנחנו שמועים את זה כבר משהו כמו עשר שנים, והתחזית שלך (נתי) היא שזה הולך להיות המצב גם עבור Enterprises.
• כן - ומה שהוספתי והופך את זה לפחות טריויאלי זה נושא ה-Multi-Cloud . . .
• הנושא השני זה אכן ה-Multi-Cloud והמעבר של הארגונים הגדולים אל ה-Public Clouds.
• והנושא השלישי הוא ה-Networking - כשה-Network זה ה-Cloud Provider שלך
• ועם כל האתגרים דיברנו גם על החיבוריות ל-Edge ובין הליבות השונות - אם אתה נמצא ב-Multi-Cloud או Hybrid-Cloud.

נסתכן גם בתחזית לעשור?

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

וממש לסיום - Heads up משמח: התחלנו לעבוד על כנס רברסים 2020!

• הכנס הטוב ביקום. סובייקטיבי לחלוטין.
• הכנס מתוכנן כרגע לסביבות אוקטובר, נודיע על פתיחת ה-Call for Papers כשיהיה - היו קשובים ועיקבו.
• והאתגר השנה - Call for Papers ב-CI/CD?
• יהיה חם ומגניב, עם בוט שמודיע על קבלה . . .
• ומזל טוב לנתי שחוגג יומולדת במועד ההקלטה!

הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול