תוֹכֶן
להסיר:
השיחה שלנו עם בן ניי, מנכ"ל טורבונומי.
אולי שמעת על מחשוב אוטונומי. הכוונה ליכולת מחשב או מערכות להתארגנות עצמית ולניהול עצמי. ועד לא מזמן, זה עדיין היה קצת חלום צינור עתידני. רצינו ללמוד קצת יותר על איך מערכת אוטונומית עובדת, ולכן דיברנו עם בן ניי, מנכ"ל טורבונומי והמנכ"ל של ביין קפיטל ונצ'רס. טורבונומי (לשעבר VMTurbo) עברה לאחרונה מותג מחדש על מנת לתאר בצורה מדויקת יותר את מה שעושה התוכנה שלהם. השם החדש משלב בתוכו את נושאי הליבה של Turbonomic בפלטפורמת ניהול היישומים שלה: טורבו (ביצועים בזמן אמת), שליטה אוטונומית (ארגון עצמי וניהול עומסי עבודה) ועקרונות כלכליים (היצע וביקוש). כאן בן מדבר על מערכות אוטונומיות ועל חשיבות האוטומציה בסביבות מורכבות יותר ויותר מונעות נתונים.
Techopedia: אתה הופעת פעמים רבות ברשימת פורבס מידאס עבור בעלי ההון סיכון המובילים. כ- VC, יש לך נקודת תצפית מעניינת לראות את כל הנוף הטכנולוגי עם כמה שהעולם השתנה במהלך השנים. מה מפתיע אותך כשאתה מסתכל אחורה על כמה דברים השתנו במרכז הנתונים?
בן ני: התשובה הקצרה היא שלדעתי קצב השינוי במרכז הנתונים האיץ באמת מעבר לכל מה שאנשים ראו. מה שקרה היה פיתוח זה של מרכז הנתונים שהוגדר על ידי התוכנה וביסודו הפשטה הרחק מהחומרה. זה פתח כונן צמיחה שלם בתוך מרכיבי התוכנה.
אז עכשיו, במקום להתמודד עם מחזורי הרענון של ספקי החומרה (שבמשך תקופה ארוכה כמעט שימשו כשומר שער למרכז הנתונים), זה כעת נפתח פשוטו כמשמעו לאלמנט כמה מהר תוכלו ליצור רעיונות - מכיוון שתוכנה, באמת, זה רעיונות. ללא המגבלות על יצירת רעיונות, זו הייתה תקופה מרגשת ומהנה מאוד, אך קצב השינוי במרכז הנתונים ואפילו ההגדרה של מרכז הנתונים התפתח באופן מהותי ומהיר מאי פעם.
משהו שמעניין אותי מאוד בכך, כאשר הלכנו למרכז נתונים מוגדר תוכנה, כל בקרי ה- API והכפתורים של עולם החומרה הוגדרו מחדש בתוכנה. מה שעשינו היה לחשוב על זה במונחים של דרך חדשה להניע ביצועים ופרודוקטיביות, והיא לקחת את האפליקציה ואת השינוי בביקוש באפליקציה הזו ולקשור אותם לבקרים המוגדרים מחדש בתוכנה מכיוון שבסופו של דבר מדובר בתוכנה ל תוכנה.
כשתעשו זאת תוכלו כעת להסיר את התווך האנושי בין שכבת היישום לשכבת התשתית מכיוון שכעת, לראשונה, תוכלו לקשור אותם ישירות זה לזה - הנה מילה חשובה - באופן אוטונומי, כלומר פשוטו כמשמעו לאפשר ליישומים להיות ניהול עצמי וארגון עצמי.
זה גם הופך אותו לכלכלי במובן זה שכעת הביקוש מוצא היצע ואנחנו מתמקדים במודל צריכה של IT, מודל כלכלי במקום מודל מבוסס הקצאה או מודל מבוסס אספקה. זהו פיתול די מהותי בסיפור כיצד אמור לרוץ IT או מודל ניהול תעשייתי טק. וזה הביא לביצועים טובים יותר ויעילות רבה יותר מבחינת עלות. זה גם הופך את הלקוחות לזריזים וגמישים הרבה יותר, ומנצל את העבודה בצורה טובה יותר בשוק
הנה מה כל כך אירוני במה שקרה בשנת 2016 עם כל אחד ממרכזי הנתונים המוגדרים על ידי תוכנה. ראשית, אתה עוקב אחר החומרה שלך כדי לגלות מתי היישומים נשברים, כלומר הם הפרו איכות שירות או SLA, אך בעוד אנו משתמשים בתוכנה כדי למצוא את השגיאה, אנו נחזור לחומרה להתראות שנוצרו על ידי מכונה. . הרמז השני הוא שאנו מאפשרים ליישומים המנהלים את העסק להפסיק, ואז השלישית היא שאנו לוקחים את ההתראות הנוגעות על-ידי מכונה ואנו מוסרים התראות אלו. לאנשים.
אין באגים, אין מתח - המדריך השלב אחר צעד שלך ליצירת תוכנה לשינוי חיים מבלי להרוס את חייך
אתה לא יכול לשפר את כישורי התכנות שלך כאשר לאף אחד לא אכפת מאיכות התוכנה.
זה צריך להיות הפוך.
וכאן רצינו לשנות את מודל ניהול ה- IT הרחק מהקצאות או ניחושים ובחזרה למודל מבוסס דרישה מבוסס צריכה.
קרא: מרכז הנתונים המונע על ידי דרישה - מה שמנהלי מערכות יכולים ללמוד מוול סטריט
Techopedia: עכשיו כשאתה מזכיר את זה, כן, אנו מכנים הגדרת תוכנה לכל דבר, אבל אז ההתראות נשלחות רק לחלק האיטי של התהליך, שהוא, כאמור, כלי התווך האנושי.
הזכרת את המונח אוטונומי. אתה יכול אולי לדבר קצת יותר על החשיבות של מערכות אוטונומיות ב- IT? בהתחשב בשינוי השם מ- VMTurbo לטורבונומי, אני מנחש שהוא חשוב יותר מכפי שרוב האנשים מבינים.
בן ני: בהחלט. בראש ובראשונה, ההגדרה של האוטונומיה, כאשר היא מיושמת על מחשוב, היא סביב מערכות שיכולות לנהל את עצמן ולהתארגן בעצמן.
אז חשבו על רשתות בייסיות, חשבו על אלגוריתמי חיפוש, חשבו על נתונים גדולים, שאנשים מכנים כעת "למידה עמוקה". אלה צורות של בינה מלאכותית. מה שלדעתי הכי מעניין בטורבונומי הוא שזו הצורה האולטימטיבית של בינה מלאכותית מכיוון שעומסי העבודה של היישומים מקבלים החלטות באופן אוטונומי בתוכנה באילו אלמנטים תשתית הם צריכים להפעיל ומתי עליהם להזיז את עצמם, להגדיל את עצמם, להתחיל ולעצור את עצמם, שיבוט עצמם. זה ממש ממש מעניין - ואנחנו עושים זאת על ידי מינוף המופשט והנזילות שמספקים וירטואליזציה, או מכולות או עננים.
ואז, עם הפשטה דומה של כל צורות הדרישות השונות - כך שתוכלו להתקין מכשירי VM, יש לכם מכולות, יכולות להיות לכם JVMs - אנו בוחנים את כל צורות הביקוש הללו ואת כל צורות האספקה האלה ומופשטות. אז בואו נניח לביקוש לבחור או להתאים את עצמו להיצע. ואז אם הם נמצאים במארח פיזי אחד וזה מתחיל להתעכב, ולא להתחיל לתת לו להיכשל ולייצר התראה ויש לך את האפליקציה, אתה יודע, יפוצץ, למה לא פשוט לאפשר לו לקבל החלטה לעבור עצמה? כל עוד אתה מתמחר את ההחלטה שלך - המעבר והעלות לחזרה - אתה יכול למעשה לקבל החלטות מעניינות יותר על הקצאת משאבים.
Techopedia: אני אוהב את האנלוגיה של היצע וביקוש. בתיאוריה הכלכלית מקורות האספקה קבועים בטווח הקצר ויכולים להשתנות רק לאורך זמן רב. במה שאתה מתאר - אם תשמור על אנלוגיה כלכלית זו, אתה משנה את כל הפרדיגמה. כלומר, אתה יכול לשנות את היצע בטווח הקצר, נכון? יש לך גמישות מלאה למעשה להיות יעיל יותר, ולחשוב על ניצול המשאבים כשוק, יש לך שוק כמעט יעיל בזמן אמת?
בן ני: אתה צודק בדיוק. זהו מודל כלכלי שהופך לעיקרון שסביבו הביקוש מוצא היצע, אך IT מנוהל על פי עקרונות כלכליים. וכמו שאמר ג'ון מיינרד קיינס, "בטווח הרחוק כולנו מתים."
Techopedia: אני לא חושב שתפגוש כרגע CIO כלשהו שכבר לא עבר או שאינו שוקל ברצינות מהלך להציב משאבים נוספים בענן. לאן אתה רואה את הענף הולך בשנים הקרובות?
בן ני: אני חושב שאתה הולך לראות מספר שינויים. לנו די ברור שזה לא יהיה שינוי מחדש שלם של הטכנולוגיה. בדיוק כמו שהמיינפריים עדיין כאן, אני לא חושב שתראה אי פעם פורמט מחדש של 100%. סביר להניח שתראה עולם היברידי. יהיה לך פרטי וציבורי, עם זאת, אני חושב שציבורי באמת יהיה ענן ציבורי רב, ולא ענן יחיד ציבורי. כשמסתכלים על השחקנים הגדולים ביותר כאן, יש רק קומץ. אבל כשאתה נוסע לאירופה או לשאר העולם אתה רואה נשאים רבים שכולן גם עננים, ולכן אני לא חושב שזו קפיצה גדולה, נכון? השאלה האמיתית, עם זאת, היא כיצד לקוחות מקפידים לעננים הנכונים כדי להפעיל את עומסי העבודה שלהם? התיאוריה שלנו מאחורי החברה היא זו כל עומס עבודה אמור להיות מסוגל להימשך כל תשתית, בכל מקום. המשמעות היא לפני כיבוי או כבוי ובכל עת משום שזכור, הזמן הוא פונדקאית לביקוש.
לכן, כאשר הביקוש משתנה, ייתכן שתרצה להתפוצץ לענן. או אם אתה מתכוון להעביר את עומסי העבודה האלה לענן לצמיתות, אילו עומסי עבודה אתה מתכוון למשוך חזרה? כי עכשיו יש לך יכולת במרכז הנתונים שלך. למה לשלם פעמיים? וכך אחד הדברים שאנו עושים היום עם Verizon Intelligent Cloud Control אך גם עם סביבות אחרות הוא לאפשר ללקוחות לבסס את החלטתם לגבי היכן להפעיל עומסי עבודה אלה, לא רק על מחיר מכיוון שהמחיר יכול לנעול אתכם, אלא גם יותר חשוב על ביצועי האפליקציה. אז אתה יכול לקבל שיקולים אחרים כגון מחיר, תאימות, או ריבונות נתונים, או אבטחה ומשאבים אחרים שהם רק משאבים הניתנים לסחירה באופן בסיסי בשוק זה אותו אנו מתארים.
טקופדיה: זה המודל הכלכלי?
בן ני: כן. אז הכל בחזרה למודל הכלכלי. רק תחשוב על כמה זה הגיוני. זו לא סתם אנלוגיה, אגב, היא למעשה הדרך בה הדגם עובד. לעומסי העבודה יש תקציב ועומסי העבודה מסתכלים על תיאוריית תורים וגודש, ולכן היא מורחבת בהרבה. זו לא עליית מחירים ליניארית כשהיא מתחילה לגודש; זה עולה באופן אקספוננציאלי, מכריח את השפעת התקציב ולכן עומס העבודה על מנת לקבל החלטה לעבור.
כל עוד הסרתם את כל המורכבות במרכז הנתונים, תוכלו כעת לסחור ב- IOPS של תיבת XtremIO, תיבת אחסון טהורה ותיבה Compellent, ותיבה 3Par מכיוון שלכולם יש מאפייני IOPS שונים אך היישום יכול לכן קנו את המשאבים הללו לפי בחירתו. זה לא שונה מאשר להסתכל על מעבד או vCPU, MEM או vMEM, נכון? כולם סחירים, אז האם עלי לרוץ לכאן או לכאן? זה לא משנה! הסחורה הנפוצה כאן היא אספקת תשתית.
הסחורה הנפוצה כאן היא היצע התשתיות והסיבה שחשובה היא - אני הולך להשתמש באנלוגיה - אם אתה זוכר
בשנת 1978 ביטלנו את הרגיזציה של חברות התעופה. לפני כן כל מושב היה זהה, תמחורנו את כולם אותו הדבר ובעוד שזה היה הגיוני זה היה לא בסדר כיוון שצד הצריכה, נכונות התשלום הייתה שונה מאוד. אז המושבים היו מצרך, אך על ידי שינוי המיקוד לביקוש, המחיר למושב - למרות שהמושבים היו זהים - ניתן היה לברר נכונות אחרת לשלם. אז מה שעשינו זה שלקחנו את המשאב שייצג את הסחורה המשותפת, פרסמנו אותו ברשת - תחילה זה היו סאבר ואפולו, אבל אחר כך זה הפך ל- Travelocity, Kayak ו- Priceline.
פתאום, כשאתה נותן לביקוש לבחור את היצע, והנה התחלפה כל הענף. גורמי העומס עלו אך עלות הטיסה ירדה וכל התשתית של חברות התעופה שיש לנו במדינה זו התחדשה. זו הייתה התקדמות גדולה. אה, ואגב, אם אתה מסתכל על Priceline היום זה שווה 70 מיליארד דולר. זה יותר מכל חברת תעופה ואין להם מטוס אחד.
טקופדיה: מעניין. אייב מעולם לא חשבתי על זה ככה ...
בן ני: אין להם מטוס, אין להם שער, אין להם מושב, הם לא מעסיקים טייס, נכון? ואז אתה אומר, "אבל אילו דוגמאות נוספות יש לנו לכלכלה מרוכזת מבוססת אספקה?" בוא נעבור. מלונות מבוססים על אספקה, נכון? יש לך בית מלון, אתה לא יכול להזיז אותו. יש לך את החדרים האלה אבל איך אתה מתמחר את החדרים האלה? ולאורך הדרך מגיעים Hotels.com, ו- Expedia, ו- Travelclick וכו '. אותו דבר קרה. אתה מסתכל על מסעדות ויש לך OpenTable. אתה מסתכל בדפי זהב. זה הוחלף בעיקר מאת Google. אתה מסתכל על מודעות מסווגות בעיתונים והם הוחלפו על ידי eBay או Craigslist.
אחת הדוגמאות המועדפות עלי היא Uber. אם אתה מסתובב בעיר כלשהי תראה שורה של מוניות שמחכות לאנשים ואז אתה עולה לחלק אחר של אותה עיר ויש שורה של אנשים שממתינים למוניות. ואתה חושב, זה לא יכול להיות צודק. אחר כך מגיע Uber, שמשתמש בסמארטפון כדי לאפשר ביקוש להניע את היצע. כעת, עם Uber, 90% מהביקוש נפגשו תוך 10 דקות, בעוד שבעולם המוניות של המוניות 90% מהביקוש לא נענו תוך 10 דקות וזו הסיבה שהסבב האחרון של Uber היה 62 מיליארד דולר. וזכרו, אין להם מונית או מכונית!
טקופדיה: אז במרכז נתונים טיפוסי אנחנו בעצם עושים את אותו הדבר כמו לעכב מונית, נכון?
בן ני: אז חשבו על זה ככה: עומסי העבודה הם בעלי התקציב, בגלל זה בנינו את מרכז הנתונים. אז הם למעשה בני האדם שלך בדוגמה זו. ואז יש לי את המשאב הזה, המשאב המשותף הזה, שכולם מופשטים לחלוטין. זה נקרא היצע וזה יכול להיות בכל מקום - כל מה שמתחת לאפליקציה זקוקה לו, מהשרת וסביבת המחשבים למטה לרשת, וכלה באחסון. מה שאנחנו רוצים זה לוודא שמדובר בשוק יעיל. אז, בעלי התקציבים האלה צריכים להיות מסוגלים לפעול באופן אוטונומי, כלומר באופן אוטונומי ובזמן אמת בהתחשב בכמות השינוי בביקוש בעומס העבודה עצמו או במקרה זה ביישום. זו הסיבה שזה מאוד מקביל לביקוש למצוא היצע. בעזרת מערכת זו אתה מסתיים בביצועי יישומים טובים בהרבה מכיוון שאינך מחכה על צוואר בקבוק העבודה האנושי כדי להגיב להתראה שנוצרת מכונה כדי לקבל החלטת טיפול ואכילה עבור האפליקציה. במקום זאת אתה עושה את זה בזמן אמת. ואתה עושה את זה בקנה מידה מכיוון שהמוסדות האלה, הלקוחות האלה, מפעילים אלפי אפליקציות ביום והם צריכים לבצע.
אז קודם כל אתה מקבל חווית ביצועים טובה בהרבה. בנוסף, אין לך אנשים שמבלים את ימיהם בהיותם עושים. במקום זאת, הם חוזרים להיות הוגים והם לא סתם לוקחים התראות שנוצרו על ידי מכונה, הם חושבים שהם יכולים באמת לעזור לעסק. הם חושבים על אסטרטגיית שירותי המיקרו ואסטרטגיית היבריד ורב-ענן ועל רשתות ותפקודי רשת מוגדרים על-ידי תוכנה ווירטואליזציה - כל הדברים האלה שמקדמים את העסק בפועל ומוציאים אותם מהעולם של האכלת יישומי שבר ותיקון, או מגיבה עירנית.
אנו למעשה מגלים שבכל מקום בין 40% ל -60% מההון של מרכז הנתונים מוגדר יתר על המידה ואנחנו יכולים להרשות לעצמנו שהרבה מזה ייקצה מחדש - כך, הימנעות מרכישת חומרה חדשה - או שבוצעה מההסיבה והסיבה שזה כל כך חשוב זה -
טקופדיה: מצטער תן לי לבדוק זאת, 40-60%? סליחה, המספר הזה מדהים.
בן ני: כן. ומה שחשוב יותר הוא 14% מהחשמל במדינה זו נצרכת על ידי מרכזי נתונים.
טקופדיה: אז נוכל לחסוך 5-8% מכלל צריכת החשמל של המדינה אם לא היינו מספקים יתר על המידה את מרכזי הנתונים שלנו?
בן ני: הרשה לי לתת לך גיבוי כדי להסביר לך למה, בסדר? זה חוזר לעולם של כלכלה מבוססת אספקה. ראשית, כשיש לך אפליקציה חדשה ואתה מנהל חנות IT, איך אתה מגודל אותה?
טקופדיה: כן, אתה הולך לאדריכל והם סוגים ניחוש, נכון? ואז הם מחכים עד שזה ישבר.
בן: בדיוק. אתה עובר לתחום העיסוק שלך, ויש לך שיחה, והם לא יודעים דבר שאתה לא יודע. אז הם מנחשים ואתם מנחשים, ויחד אנחנו מנסים לנחש מה הגודל צריך להיות.
אז אתה הולך להקצות ארבעה או שמונה VCPUs. מה שמעניין הוא שההקצאה כוללת רגל פיזית, או כף רגל וירטואלית בשרת פיזי. בכל פעם שמגיעה בקשה מאותו יישום, היא עומדת בתור כארבע או שמונה VCPU. זה בעצם כמו ללכת למסעדה ולהגיד שאתה מסיבה של ארבע או שמונה, למרות שאתה יכול להיות רק מסיבה של אחת. לעולם לא תתיישב.
אנו מקצים יתר על המידה עם הניחושים שלנו, מה שאומר שאנחנו משיגים את הביצועים הגרועים ביותר וזה יקר בהרבה. זו הבעיה מספר אחת. הבעיה מספר שתיים היא שעכשיו אתה לא מצליח להגדיל את היישום שלך במדויק, מה שמוליך את השאלה: איך אתה ממקם אותו אם אתה לא מצליח להגדיל אותו?
אתה מנחש שוב. אוקיי, אז עכשיו אנחנו מנחשים על הדבר הראשון, אנחנו מנחשים על הדבר השני, ואז יש את הדבר הזה שנקרא VM sprawl, או VM בלי דרישה לכך. הוא נותר במצבו במקום להסיר אותו וזה גם שומר על חומרה. אז מה שאנחנו עושים זה לנסות לחבר את כל הדברים האלה במודל יכולת היסטורי מבוסס-אנוש ומכיוון שאנו מנהלים את זה רק פעם או פעמיים בשנה, עלינו לבנות גדר נוספת, אז דיברו 20-30% גידור בגלל הביקוש עשוי להגדיל את כל היישומים האלה ואז אנו "נסגור את האשכול", מכיוון שאנו רואים את חבורת המארחים כ"מלאה ". ממש שם נעלמתם עד כמחצית מהקיבולת של מרכז הנתונים שלכם והיא מספקת יתר על המידה.
טקופדיה: זה כאילו שאתה מסודר לכישלון, כאילו אין שום דרך בפרדיגמה הישנה של בעצם לא להעמיד יתר על המידה או לא לשפץ ...
בן ני: אם כל מה שאתה רואה ומנהל הוא אספקת תשתיות, איך בכל העולם אתה יודע אם יש לך מספיק אספקה בכדי להיות גמיש אם אתה לא רואה ומבין ובזמן אמת לקשור ביקוש? אם כל מה שאתה רואה זה היצע, איך אתה יודע אם יש לך מספיק? איך אתה יודע אם יש לך יותר מדי?
טקופדיה: ובכן, אתם בטח שוכרים עוד כמה ראשים כדי לנחש עוד כמה. אתה מוציא יותר כסף על חקירת הבעיה הזו, לא?
בן ני: ואתה עדיין בסופו של דבר מספק-יתר בסיסית לפי הסדר של, תקרא לזה חצי ואתה קונה חומרה שלא לצורך. כל הקונספט שעומד מאחורי הווירטואליזציה בהתחלת ההפעלה הראשונה שלו היה סביבו במקום להחזיק ערימה של חומרה ייעודית לכל אפליקציה אחת, אני אהיה מסוגל להעביר עומסי עבודה אלה בין ערימות ייעודיות, ולכן כל הרעיון היה לספק חומרה. לממוצע הפסגות במקום לסכום הפסגות של כל הון החומרה ההוא.
עם זאת, כשאתה לוקח עכשיו שליטה אוטונומית בזמן אמת, בקרת ביצועים, צד הצריכה של ה- VM או המכולה או הענן, ואתה חושב על אותו הדבר; מה אנחנו עושים? אנו יוצאים ואנחנו בודקים מתח בכל אפליקציה בודדת ויש אלפים - יש מאות עד אלפי אפליקציות בסביבה תלוי בגודל הלקוח - וכך אנו מבצעים בדיקת מתח לאלה עבור מעבד, עבור vCPU, עבור MEM, עבור vMEM וכן הלאה שכל האלמנטים או המשאבים השונים נכון? ואז אנו מספקים בהתבסס על סכום הפסגות שוב. ההבדל הוא אם אין לך פיגור או צוואר בקבוק הקשורים לעבודה וכעת אתה יכול לספק לממוצע הפסגות, נחשו מה אנחנו יכולים לעשות? אנו יכולים לנהל את הסביבה הזו באופן פעיל מכיוון שכל היישומים אינם מתרגלים בבת אחת.
טקופדיה: וואו. זה באמת חוזר למה שהווירטואליזציה הייתה אמורה להיות מלכתחילה.
בן: זה וירטואליזציה או מיכלי 2.0: בקרת ביצועים אוטומטיים בזמן אמת.
טקופדיה: אז אם לולאת הפריצה הישנה היא דרך חשיבה מיושנת, איך אתה מסביר את זה לבחור הממוצע בקו הקדמי?
בן ני: הרשה לי לשאול אותך שאלה פשוטה: מדוע צג אחד?
טקופדיה: ובכן אתה רוצה לדעת מה משתבש או כשמשהו משתבש, נכון?
בן ני: בסדר. כן. אתה רוצה לדעת מתי זה נשבר. אבל למה אתה רוצה לתת לזה להישבר? זו כל השאלה. תראה, בהכרח יתקיים פיקוח מסוים על כמה חטיבות או חלקים במרכז הנתונים שלך, אך באופן בסיסי, אם אוכל להבטיח שהיישומים שלי יפעלו בביצועים במה שאנחנו מכנים את המצב הרצוי, וזה הכמות הנכונה של משאבים ל תמכו בהם בזמן אמת, זה עולם טוב בהרבה מאשר לחכות לניטור והתראה, ולנסות להגיב לכך.
כאשר הווירטואליזציה הולידה לראשונה את מרכזי הנתונים המוגדרים על ידי תוכנה, זה היה קידום ממש מעניין, אבל הם עשו את זה צעד רחוק מדי מכיוון שקראו לעצמם מערכת ההפעלה של מרכז הנתונים של העתיד וזה היה ישר מהקופסה, נכון? אבל אם אתה הולך לחפש את חמשת הדברים שמערכת הפעלה אמורה לעשות, הראשון הוא ניהול ביצועים. אז הרשו לי לשאול אתכם, האם מפקח עושה ניהול ביצועים?
טקופדיה: ברור שלא.
בן ני: אין זכות. ואז הדבר השני שעליו לעשות הוא הקצאת משאבים. אז האם המפקח מבצע הקצאת משאבים? לא.
מה דעתך על תזמון משרות? מה לגבי הסתייגויות? מה דעתך על תכנון? לא, לא, ולא. אז פתאום אתה מבין שהדרך שהם השיגו זאת הוא שהם מייצרים התראות ומספר ההתראות גדל וגדל ככל שאנו משתמשים במשאבים ברמה גבוהה יותר, אך גם ככל שאנו יוצרים יותר אפליקציות, ועוד צורות של עומס עבודה ועוד מקומות בו הם יכולים לרוץ. פתאום אנו מוחצים אנשים עם כל ההתראות הללו.
אבל הדבר הגדול ביותר הוא שמה שאנחנו עושים על ידי כך שאנושיים רודפים אחרי ההתראות הללו הופך אנשים למערכות ההפעלה המודרניות של מרכז הנתונים, וזה מוזר מכיוון שכפי שמתברר, אנשים ישנים. לאנשים יש משפחות, אנשים יוצאים לחופשות, ולכן אנשים לא יכולים להיות מערכות הפעלה וזו הסיבה למה שעשינו זה שיצרנו את מערכת בקרת ביצועי האפליקציות הזו, טורבונומית, כדי להיות מסוגלים לעשות בדיוק את חמשת הדברים האלה. אנו מסכימים שהמפקח הוא המצאה נהדרת, ומכולות ועננים, אך אנו רואים בהם ספקי נזילות; הם לא מערכת הפעלה. שאר מערכת ההפעלה נובעת ממערכת בקרת ביצועי יישומים. זה עושה את הדברים האלה, זה עושה ניהול ביצועים, הקצאת משאבים, תזמון משרות, הזמנות ותכנון - זה כל הערך של מה שיש לנו. זו הסיבה שאנו קיימים בשוק.
Techopedia: ספר לי איזה תפקיד אתה חושב שלמידה מכונה או AI ממלאים את זה בשנה הבאה, אתה יודע, שנתיים עד חמש? כיצד טורבונומי עם AI משנה את מרכז הנתונים?
בן ני: ישנן כמה מסקנות מדהימות ומעניינות שאפשר לעשות בכל מיני סביבות שונות. הייתי אומר שמה שעשה זה להיות הרבה יותר מדויק מזה. זכור שאחת הבעיות עם ערכות נתונים גדולות גדולות היא שאתה זקוק לזמן כדי לפתח נתונים אלה ואז לתאם אותם ולהסיק את ההסקות על אותם נתונים.
לפעמים אתה תסיק את ההסקה הלא נכונה וקשה מאוד לדעת כמה זמן לוקח לערך הנתונים הגדולים לבטל את ההשלכה, בין אם זה נכון או לא נכון. ואז בסוף זה עדיין נגמר עם מרכיב אנושי או סוג כלשהו של עבודה אנושית סטטית כדי לנקוט בפועל. במקרה שלנו, זה אינטליגנציה אוטונומית. לא רק הבינה המלאכותית שלה ועומסי העבודה האלה באמת מקבלים החלטות בעצמם במודל, אלא שאתה עושה זאת במידה מסוימת של דיוק. זה הרבה יותר ממה שניתן להשיג באמצעות מערך נתונים גדול.
Techopedia: אם אתה יכול להשאיר אחד כזה עם מנהל המערכת הממוצע, או עם האדריכל הממוצע של מרכז הנתונים, או ה- CIO הממוצע, איפה הדברים עומדים להיות בשנה-שנתיים הקרובות? מה אנשים לא מבינים עכשיו שהם צריכים לדעת על 2017, 2018 ומעלה?
בן ני: אני חושב שהדבר החשוב ביותר הוא לזכור מדוע נכנסנו לזירת הטכנולוגיה; מכיוון שאנחנו סקרנים ביסודם, ואנחנו רוצים לאפשר לכלכלת ארה"ב - או כל כלכלה - לעשות יותר עם פחות. ככה חברות מפעילות ומתגלגלות. זה לא יכול להיות נכון לעמוד בגישה של ימינו של מודל מבוסס הקצאה או אספקה כאשר הוא דורש מאיתנו לרוץ בסדר גודל של 50% יתר על המידה, ובעולם יישומים של פיצול, והיכן שהפכנו את עבודה מהוגים לעושים.
יש דרך טובה יותר. הדרך הטובה יותר היא לאמץ רעיונות חדשים וטכנולוגיות חדשות של ספקים חדשים המעניקים לך את ההזדמנות להתבונן בצד הביקוש של המשוואה, בצד הצריכה של VM, של מיכל, של ענן, ולהפעיל ביצועים טובים יותר ב בקנה מידה גדול יותר עם עבודה חכמה יותר ויעילות טובה יותר בהון שלך, וגמישות מבחינת זריזות וגם כושר גמישות בכל פעולותיך ..
זו הסיבה שמצאתי את ההזדמנות הזו כה משכנעת שרציתי לנהל אותה, ולמה אני מאמינה בה כל כך.
אם תרצה פלטפורמת בקרת ביצועי יישומים של Turbonomic לנסיעת מבחן בחינם, תוכל להוריד כאן.