תומס גראף הוא המייסד וה-CTO של איזולנטי, ויוצר טכנולוגיית רשת פופולרית בקוד פתוח (ומקורית בענן) בשם סיליום. Cilium בנוי על גבי טכנולוגיית לינוקס ברמת ליבה הנקראת eGMP.
בראיון זה, Graf דן בתפקידים ש-Cilium ו-eBPF ממלאים באקו-סיסטם ההולכת וגדלה של רשת ענן, וכן בכמה מגמות רחבות יותר סביב האימוץ והאבולוציה של Kubernetes. הוא מסביר מי משתמש וקונה ב-Kubernetes בתוך ארגונים גדולים, שבהם התשתית המקומית בענן עדיין צריכה להשתפר, וכיצד הרצון לסטנדרטיזציה מניע חדשנות.
FUTURE: כיצד עלינו לחשוב על eBPF ו-Cilium בהקשר של מחשוב ורשת, באופן כללי, ולאחר מכן ספציפית בהקשר של מערכת אקולוגית מקורית בענן?
תומס גרף: בסך הכל, eBPF הוא הטכנולוגיה, והוא ברמה נמוכה ביותר. זה תוכנן עבור מפתחי קרנל, והרקע שלי הוא בפיתוח ליבה. eBPF הוא לקרנל, למערכת ההפעלה, מה ש-JavaScript עבור דפדפן. זה הופך את מערכת ההפעלה לניתנת לתכנות בדיוק כמו ש-JavaScript הופך את הדפדפן לניתן לתכנות. בעבר, היינו צריכים לשדרג את גרסאות הדפדפן שלנו כדי להשתמש בפועל באתרים מסוימים. ואז הגיע JavaScript, ופתאום צוותי יישומים ומפתחים יכלו לבנות יישומים מסיביים - עד לנקודה שבה יישום עיבוד התמלילים הפופולרי ביותר הוחלף ביישום בדפדפן. זה הוביל לגל ענק של חדשנות.
אותו דבר קורה עם eBPF, אם כי ברמת מערכת ההפעלה, כי פתאום אנחנו יכולים לעשות דברים ברמת הקרנל או מערכת ההפעלה שבה אנחנו רואים הכל ושולטים על הכל - וזה מאוד חשוב לאבטחה - בלי צורך להחליף ליבה קוד מקור. אנחנו בעצם יכולים לטעון תוכניות לתוך הליבה כדי להרחיב את הפונקציונליות שלו ולהביא איתו יכולות חדשות. זה גם פתח גל עצום של חדשנות. Hyperscalers כמו פייסבוק, גוגל ונטפליקס משתמשים בזה בעצמם, ישירות, עם צוותי הליבה שלהם.
מה ש-Cilium מביא לטבלה הוא שהיא משתמשת בטכנולוגיית eBPF ברמה נמוכה הזו כדי לספק למעשה גל חדש של תשתית תוכנה, במיוחד עבור הגל המקורי בענן. תחשוב על זה כמו רשת מוגדרת בתוכנה ומה Nicira, שהפכה ל-VMware NSX, עשתה עבור תעשיית הוירטואליזציה. אנחנו עושים את אותו הדבר עבור native בענן, שם זה שילוב של ספק ענן או תשתית ענן ציבורית, כמו גם תשתית מקומית. ואנחנו פותרים מקרי שימוש ברשת, אבטחה וצפיות עם זה בשכבת התשתית.
ו-Cilium Service Mesh, ששוחרר זה עתה, הוא אבולוציה של היכולות הללו?
מה שקורה כרגע, מלפני כשנה, הוא ששני החללים מתנגשים. מה ש-Cilium עשתה עד כה התמקד ברשתות, רשתות וירטואליות ולאחר מכן רשתות מקוריות בענן - אבל עדיין ברשת. אבל אז, כשהם מגיעים מלמעלה למטה, צוותי יישומים בטוויטר וגוגל עשו זאת רשת שירות דברים - תחילה באפליקציה, ולאחר מכן במודל מבוסס-car sidecar, המודל מבוסס-proxy, וזה מה שפרויקטים אוהבים Istio לִמְסוֹר. ועכשיו שני השכבות האלה מתקרבות יותר בגלל ארגונים מסורתיים נכנסים לעולם הילידים בענן, ויש להם דרישות לרשת ארגונית, אבל גם צוותי האפליקציות שלהם רוצים רשת שירות.
גרטנר מכנה את השכבה החדשה הזו "קישוריות שירות" - נראה אם המונח הזה יתפוס - אבל זה בעצם שכבה הכוללת את החלק של הרשת הארגונית ואת החלק של השירות שמגיע מצוותי היישומים. ומכיוון שזה מה שהלקוחות דורשים, הוספנו את היכולות לתוך Cilium עצמה. אז בעצם, Cilium הולך כלפי מעלה מהצד של הרשת הארגונית ורשתות השירות יורדות כלפי מטה ליותר מהצד של הרשת.
רשת שירות
לפי ויקיפדיה: רשת שירות היא שכבת תשתית ייעודית למתן תקשורת משירות לשירות בין שירותים או מיקרו-שירותים, באמצעות פרוקסי. שכבת תקשורת ייעודית יכולה לספק מספר יתרונות, כגון מתן צפייה בתקשורת, אספקת חיבורים מאובטחים, או אוטומציה של ניסיונות חוזרים והשבתה לבקשות שנכשלו.
מדוע יש כל כך הרבה התמקדות ברמת הרשת והשירות של ערימת Kubernetes?
כי עם הרצון לרוץ במספר עננים ולפצל יישומים למכולות, שכבת הקישוריות הפכה למרכזית. מה שפעם היה אולי תקשורת בין-תהליכים ותוכנות ביניים היא כעת הרשת, כך שהרשת הופכת חיונית לחלוטין עבור יישומים לדבר אחד עם השני וכדי לזרום נתונים.
ובמיוחד בענן, multi-cloud הופך להיות חיוני לחלוטין. לכל ספקי הענן יש שכבות רשת משלהם, אבל כמובן מותאמות לעננים שלהם. יש להם הצעות מקומיות, אבל הם לא באמת מרובי עננים. Cilium ו-eBPF מביאים לשולחן את אותה שכבה מרובת עננים ואגנוסטית. הוא מתנהג בדיוק באותו המקום כמו שהוא מתנהג בענן הציבורי. כמה מספקי הענן הציבורי משתמשים ב-Cilium מתחת למכסה המנוע עבור הצעות Kubernetes המנוהלות שלהם, וחברות טלקום משתמשות בו לתשתית 5G מקומית. מדובר בדיבור בשתי השפות ובחיבור בין העולמות הללו.
לכן יש כל כך הרבה דגש על זה: כי אחת הדרכים הקלות ביותר עבור ספקי ענן לנעול לקוחות היא להחזיק בשכבת הקישוריות הזו. אני חושב שמנקודת מבט של תשתית אסטרטגית, בדיוק כמו ששכבת הוירטואליזציה הייתה המפתח, כעת שכבת הקישוריות והרשת היא המפתח לחלוטין.
המקור לחדשנות [עתידית] יהיה קוד פתוח, והלקוחות והמשתמשים המניעים את הביקוש יהיו חברות רמה אחת למטה מה-hyperscalers - חברות כבר גדולות שעדיין מפריעות מאוד.
Kubernetes מקובל ומאומץ למדי בשלב זה, אבל עדיין מדברים בחוגים מסוימים על כך שזה מוגזם. למי לדעתך מיועדת Kubernetes, והמערכת האקולוגית של הענן בכללותה?
זה מיועד לצוותי יישומים מודרניים. אני חושב שההבנה החלה שאם אתה רוצה למשוך צוותי יישומים מודרניים, ולהיות מסוגלים לקבל זמני כניסה מהירים לשוק, אתה צריך לספק להם תשתית מקורית בענן. לעתים קרובות אנו רואים אב טיפוס - ראשוני, טרום-MVP, אפילו מוכיח את הרעיון או מכירה פנימית - ללא שרת, משהו כמו Lambda. ואז ב-Kubernetes, מכיוון שצוותי האפליקציות יכולים להחזיק בתשתית ישירות. ואז, כשהיא עוברת לייצור, הם עוברים להפצות ארגוניות, מקומיות של Kubernetes. אבל זה למעשה חלק קטן יחסית מכל התשתית, אולי אחוז חד ספרתי או נמוך.
עם זאת, ברור שזה יהיה הסטנדרט החדש. בדיוק כמו שאימוץ הווירטואליזציה היה איטי מאוד בהתחלה ואנשים אמרו שזה מוגזם - אבל עם הזמן, כמובן, זה התחיל להחליף את רוב הדברים - אנחנו נראה את אותו הדבר כאן. או בדיוק כמו בשפות מודרניות. אנשים אמרו ש-Java זה מוגזם, וכנראה שזה עדיין מתאים להרבה יישומים, אבל הייתה תקופה שבה היה קשה מאוד לבצע כל פיתוח אפליקציות מחוץ ל-Java כי זה מה שרוב מפתחי האפליקציות יכלו לכתוב בו. להיות נכון עבור צוותי יישומים מודרניים: הם יצפו לקבל Kubernetes בסביבה כדי לפתח זריז יותר ולהביא את המוצר לשוק במהירות.
בצד התשתית, זה עשוי להיות קצת מוגזם, אבל אם האלטרנטיבה היא לשכתב אפליקציה מחסר שרת ל-On-Prem, זו משימה מסיבית. אז Kubernetes הוא האמצע שם, וזה מאוד אטרקטיבי.
מה לגבי הרעיון ש-Kubernetes עדיין זקוקה לחוויית מפתח טובה יותר?
אם נסתכל על OpenShift המקורי, לפני שהוא התבסס מחדש על Kubernetes, זה היה זה. זה היה אפילו קרוב יותר לצוות היישומים והיה חווית מפתחי יישומים טובה עוד יותר. אתה יכול לדחוף ל-Git וזה יתפרס אוטומטית. Heroku גם ניסה את זה, אבל מבוסס SaaS.
Kubernetes לקח צעד אחורה ואמר, "אנחנו צריכים לשמור על כמה היבטים תפעוליים בו ולהפוך אותו קצת יותר קרוב למה שמנהל מערכת היה מצפה, גם כן. אנחנו לא יכולים להיות מותאמים רק ליישומים". זה דרך האמצע: היא צריכה להיות מספיק אטרקטיבית עבור צוותי יישומים, אבל עדיין צריך להיות אפשרי להפעיל את האפליקציה מחוץ לסביבה ספציפית, ולהיות מנוהל על ידי אנשים שאינם מפתחי אפליקציות.
הייתי אומר שהצעד הגדול ביותר בין Docker ל-Kubernetes היה ש-Docker עוסק כולו בחוויית מפתח. זה פתר את החלק הזה, אבל לא פתר את החלק האקולוגי של הענן הציבורי.
איך הגענו למצב הזה? האם זו ההתפתחות הטבעית מפלטפורמה כשירות (PaaS) ומכולות יישומים?
זה היה תמונות Docker והיבט האריזה של Docker. האסכולה הישנה הייתה כיצד לפרוס למכונות וירטואליות, והייתה כל מיני אוטומציה סביב זה. ואז היה מה שפייסבוק עשתה עם Tupperware - נבנה מאוד בהתאמה אישית ובקנה מידה גדול באמת. ואז הגיע Docker ובעצם סיפק את תמונת המכולה הזו וכולם יכלו להתייחס אליה כמו VM מיניאטורי. כעת אני יכול להפיץ את האפליקציה שלי ובמקום תמונה וירטואלית של 600MB, היא כעת מיכל של 10MB. אבל אתה יכול להתייחס אליו אותו דבר, יש בו כל מה שצריך.
זה פתח את היכולת להביא מתזמר כמו Kubernetes שעדיין מאפשר לך להתייחס ליישומים כמו מיני VMs, אבל אז גם לקחת צעד אחד קדימה ולמעשה להתייחס אליהם כאל שירותי מיקרו. זה מאפשר לך לעשות את שניהם.
הייתי אומר שהצעד הגדול ביותר בין Docker ל-Kubernetes היה ש-Docker עוסק כולו בחוויית מפתח. זה פתר את החלק הזה, אבל לא פתר את החלק האקולוגי של הענן הציבורי. לא הייתה לו, או בהכרח רצתה, אינטגרציה הדוקה עם ספקי הענן. Kubernetes פתר את זה.
מי אתה רואה שמנהל Kubernetes בתוך חברות? האם מדובר בצוותי יישומים בודדים?
יש שינוי מעניין שקרה עם native בענן, וזה שיש לנו את עלייתו של "צוות הפלטפורמה", אני אקרא לזה. הם לא מהנדסי יישומים. יש להם מעט ידע בפעולות רשת ויש להם לא מעט ידע באבטחה. יש להם ידע SRE והם יודעים לעשות אוטומציה בענן. הם מספקים את הפלטפורמה לצוותי יישומים, ומתייחסים אל צוותי היישומים האלה כאל הלקוחות שלהם.
צוותי פלטפורמה הם אלה שקונים Kubernetes וטכנולוגיות נלוות, שבהן הם משתמשים כי מוטלת עליהם המשימה לספק את התשתית של הדור הבא כדי לשמח צוותי אפליקציות מודרניים.
אני חושב שבהחלט יש מקום ללא שרתים, במיוחד לפיתוח יישומים מהיר מאוד. אבל בארגונים, אנו רואים את native בענן כשכבה החדשה על גבי הוירטואליזציה
האם זה קונה חדש או צוות חדש? או שמא צוותי פלטפורמה דומים למשהו שקיים בתוך מקומות כמו גוגל או פייסבוק וכעת הולכים למיינסטרים?
הם בעיקר קבוצה חדשה. אני חושב שהם, במידה מסוימת, כמו צוותי SRE בגוגל ובפייסבוק. עם זאת, צוותי היישומים כנראה מחזיקים יותר בפריסת האפליקציות בארגונים, מכיוון שלארגונים אין את ההבחנה הברורה הזו בין מהנדסי תוכנה ל-SREs כמו גוגל ופייסבוק. הייתי אומר שההתפתחות הזו דומה מאוד לאופן שבו היו לך צוותי וירטואליזציה, ואז הרבה פעולות רשת עברו מ- או התפתחו או התקדמו מ- הקשורות לרשת חומרה להיות על רשת וירטואליזציה. והצוותים האלה, למשל, התחילו להפעיל את VMware NSX. אותו דבר קורה כאן.
למרות שזה לא בהכרח תקציב חדש. אנו רואים שהתקציבים עוברים מאבטחה ומרשתות לצוות הפלטפורמה הזה, למשל, ככל שההוצאות בענן גדלות ומבזבזות פחות על חומרת רשת. לעתים קרובות הם פועלים עם צוות האבטחה ועם צוות ההפעלה של הרשת כדי לקבל רכישה, אבל למעשה יש להם גודל די משמעותי של התקציב.
איך אתה רואה את קרן מחשוב מקומית לענן מתפתח, והאם Kubernetes תמיד יהיה במרכזה - או של התנועה הילידים בענן בכלל?
Kubernetes הוא מה שהצית את CNCF, ובשנתיים הראשונות הכל היה על Kubernetes וענן ציבורי. מה שראינו מאז לפני כשנה הוא שעכשיו זה כבר לא רק על Kubernetes, זה בעצם יותר על ענן native עקרונות. זה בעצם אומר שזה גם לא בהכרח ענן יותר, אפילו לא ענן פרטי. לעתים קרובות זה אפילו רשתות ארגוניות מסורתיות, תשתית מקומית משעממת, שרתי מתכת חשופה וכל זה, אבל עם העקרונות המקוריים של הענן המובנים.
הנורמה החדשה היא כעת היברידית וכוללת מספר רב של ספקי ענן ציבוריים, כמו גם תשתית מקומית. חברות רוצות לספק את אותה זריזות מפתחי יישומים, או לספק צפייה עם כלים מקוריים ענן מודרניים, או לעשות אבטחה עם כלים מקוריים ענן מודרניים - למשל, אימות, במקום רק פילוח או אכיפה מבוססת זהות - כל המושגים החדשים של ענן מקוריים על תשתית קיימת.
אנו רואים דרישה חזקה מאוד עדיין להתחבר לעולם הישן ולדבר על MPLS, VLAN, sFlow ו-NetFlow - כל הסט הקיים של דרישות ארגוניות. אף אחד מהם לא נעלם.
כעשור לתוך זה, המרחב היליד בענן לא נראה כמו אופנה. כמה מקום יש לזה להמשיך ולהתפתח?
בהחלט היה זמן שבו זה היה כמו, "הו, Kubernetes הוא כנראה קצר מועד, וללא שרתים הולך להיות השכבה הבאה." או, "Kubernetes דומה ל-OpenStack. או, "זה ייעלם וזה הולך להיות פרט יישום." וזה לא קרה.
אני חושב שבהחלט יש מקום ללא שרתים, במיוחד לפיתוח יישומים מהיר מאוד. אבל בארגונים, אנו רואים את native בענן כשכבה החדשה על גבי הוירטואליזציה, ואנו מאמינים שיש לה חיי מדף דומה לזה של וירטואליזציה. מה שאומר שאנחנו ממש בתחילת ההגירה המקומית בענן.
אילו בעיות גדולות עדיין צריכות להיפתר ברמת התשתית?
אנו רואים ארגונים במצב שבו פתאום, בין אם הם רוצים ובין אם לא, הם צריכים אסטרטגיה מרובת עננים. מכיוון שיש להם גם תשתית מקומית, הם זקוקים כעת לאסטרטגיית ענן היברידית נוסף על כך. והם צריכים להבין כיצד לבצע אבטחה ופונקציות אחרות באופן אוניברסלי על פני התשתית הזו מבלי להינעל בענן ציבורי מסוים.
אז זה האתגר הגדול הבא: מי תהיה השכבה האגנוסטית ההיא עבור מולטי עננים וענן, כמו מה שהפך VMware? מי הולך להיות VMware עבור מקורי ענן?
אני חושב שההבנה החלה שאם אתה רוצה למשוך צוותי יישומים מודרניים, ולהיות מסוגלים לקבל זמני כניסה מהירים לשוק, אתה צריך לספק להם תשתית מקורית בענן.
ולמרות שאימוץ מקורי בענן עשוי היה להיות קל יחסית עבור חברות האינטרנט המודרניות שהיו מאמצות מוקדמות, האתגר מנקודת המבט שלך הוא בניית טכנולוגיות חדשות שמגשרות על הפער בין העולם המודרני הזה לבין הכלים והמערכות הארגוניות הקיימות?
החלק הקשה הוא שצוותי אפליקציות מודרניים רגילים לכך ששכבת התשתית תתפתח באותה מהירות כמוהם. וזה אילץ את שכבת התשתית להיות עוד יותר ניתנת לתכנות, יותר מתכווננת. זו הסיבה שאנו רואים למעשה שכבת רשת ושכבת אבטחה על גבי שכבת הרשת בענן. אבל עכשיו יש לנו ארגונים שנכנסים, ואנחנו רואים דרישה חזקה מאוד עדיין להתחבר לעולם הישן ולדבר על MPLS, VLAN, sFlow ו-NetFlow - כל הסט הקיים של דרישות ארגוניות. אף אחד מהם לא נעלם, כל כללי הציות עדיין זהים. ו אפילו חלק מחברות ה-SaaS המודרניות מתמודדות כעת עם האתגרים האלה כשהן גדלות והן דואגות לציות וכן הלאה.
מנקודת מבט טכנולוגית, מדובר על איך לחבר את העולם החדש של הענן לדרישות הארגוניות הקיימות. מכיוון שהרבה מהבעיות הללו הוסתרו על ידי ספקי הענן הציבוריים. ספקי ענן ציבורי פתרו את בעיות התאימות, אבל הם לא פתחו קוד פתוח או פרסמו שום דבר מזה; הם פתרו את זה לבד. זה חלק מערך הענן. ארגונים צריכים כעת לבנות מחדש ולקנות את זה אם הם לא רוצים לנעול את עצמם בהצעות הענן הציבוריות.
מאיפה אתה רואה את הגל הבא של חדשנות מקורית בענן? האם זה עדיין מגיע מחברה כמו גוגל, או שיש סוג חדש של חברה שמובילה את המטען?
זה מאוד מעניין. הייתי אומר שזה כנראה לא מגיע מהגוגלים והפייסבוקים. מקור החדשנות יהיה קוד פתוח, והלקוחות והמשתמשים שמניעים את הביקוש יהיו חברות ברמה אחת למטה מה-hyperscalers - חברות כבר גדולות שעדיין מפריעות מאוד, כמו Adobe, Shopify או GitHub. אבל גם חברות בסיכון להפרעות על ידי טכנולוגיה, כמו שירותים פיננסיים, ספקי ביטוח וטלקום. לחברות אלו יש אינטרס משותף בסטנדרטיזציה של תשתיות עם מודלים של פיתוח ותשתית שניתן לחזור עליהם.
פורסם ב -26 ביולי 2022
טכנולוגיה, חדשנות ועתיד, כפי שסיפרו הבונים אותו.
תודה על ההרשמה.
בדוק בתיבת הדואר הנכנס שלך לקבלת הערת קבלת פנים.
הצפיות המובעות ב"פוסטים" (כולל מאמרים, פודקאסטים, סרטונים ומדיה חברתית) הן אלה של האנשים המצוטטים בהם ואינן בהכרח הדעות של AH Capital Management, LLC ("a16z") או החברות המסונפות שלה בהתאמה. מידע מסוים הכלול כאן התקבל ממקורות צד שלישי, כולל מחברות פורטפוליו של קרנות המנוהלות על ידי a16z. למרות שנלקחה ממקורות האמינים כאמינים, a16z לא אימתה מידע כזה באופן עצמאי ואינה מציגה מצגים לגבי הדיוק המתמשך של המידע או התאמתו למצב נתון.
תוכן זה מסופק למטרות מידע בלבד, ואין להסתמך עליו כייעוץ משפטי, עסקי, השקעות או מס. עליך להתייעץ עם היועצים שלך באשר לעניינים אלה. הפניות לניירות ערך או לנכסים דיגיטליים כלשהם נועדו למטרות המחשה בלבד, ואינן מהוות המלצת השקעה או הצעה לספק שירותי ייעוץ השקעות. יתר על כן, תוכן זה אינו מכוון ואינו מיועד לשימוש על ידי משקיעים או משקיעים פוטנציאליים כלשהם, ואין להסתמך עליו בשום פנים ואופן בעת קבלת החלטה להשקיע בקרן כלשהי המנוהלת על ידי a16z. (הצעה להשקעה בקרן a16z תתבצע רק על ידי מזכר ההנפקה הפרטית, הסכם המנוי ותיעוד רלוונטי אחר של כל קרן כזו ויש לקרוא אותה במלואה). המתוארים אינם מייצגים את כל ההשקעות בכלי רכב המנוהלים על ידי a16z, ואין כל ודאות שההשקעות יהיו רווחיות או שלהשקעות אחרות שיבוצעו בעתיד יהיו מאפיינים או תוצאות דומות. רשימה של השקעות שבוצעו על ידי קרנות המנוהלות על ידי אנדריסן הורוביץ (למעט השקעות שעבורן המנפיק לא נתן אישור ל-a16z לחשוף לציבור וכן השקעות בלתי מוקדמות בנכסים דיגיטליים הנסחרים בבורסה) זמינה בכתובת https://a16z.com/investments/.
תרשימים ותרשימים המסופקים בתוכם מיועדים למטרות מידע בלבד ואין להסתמך עליהם בעת קבלת החלטת השקעה כלשהי. ביצועי העבר אינם מעידים על תוצאות עתידיות. התוכן מדבר רק נכון לתאריך המצוין. כל תחזיות, הערכות, תחזיות, יעדים, סיכויים ו / או דעות המובעים בחומרים אלה עשויים להשתנות ללא הודעה מוקדמת ועשויים להיות שונים או מנוגדים לדעות שהביעו אחרים. בבקשה תראה https://a16z.com/disclosures למידע חשוב נוסף.
